What is a Trace?
A trace in Galtea represents a single operation or function call that occurs during an AI agent’s execution. Traces capture the internal workings of your agent—such as tool calls, retrieval operations, chain orchestrations, and LLM invocations—providing deep visibility into how your agent processes requests. Traces are linked to inference results, enabling you to understand not just what your agent responded, but how it arrived at that response.Why Use Traces?
Debugging
Identify exactly where and why your agent failed or produced unexpected results.
Performance Optimization
Pinpoint slow operations with latency tracking at every step.
Compliance & Auditing
Maintain a complete audit trail of all operations for regulatory requirements.
Cost Analysis
Understand which operations consume the most resources.
Trace Hierarchy
Traces support parent-child relationships, allowing you to visualize the complete execution flow of your agent. When a traced function calls another traced function, the hierarchy is automatically captured.id: Unique identifier for the traceparent_trace_id: Reference to the parent trace (null for root traces)name: The operation namenode_type: Classification of the operation
Node Types
Traces are classified by node type to help you understand the nature of each operation and debug issues more effectively:| Node Type | Definition | Why This Matters for Tracing |
|---|---|---|
| CHAIN | A node composed of multiple smaller steps (e.g., a LangChain RunnableSequence or LangGraph node). | Composite orchestration nodes that run multiple internal steps and pass data between stages. Exposing each internal step in traces uncovers hidden failures, clarifies data flow, and pinpoints performance hotspots. |
| TOOL | A node executing deterministic code (search, calculator, API). | Deterministic or external calls where inputs, outputs, and side effects determine correctness. Tracing tool inputs, outputs, and results makes failures reproducible, reveals integration issues, and simplifies debugging. |
| RETRIEVER | A node specifically for fetching context (RAG operations). | Operations that fetch contextual data which directly affect prompt relevance and the context window. Making retrieval inputs, results, and ranks visible helps diagnose low-quality context, improve relevance, and avoid wasted context and cost. |
| LLM | A node that wraps a direct model API call (OpenAI, Anthropic, etc.). | This is where cost (tokens) and latency come from. This way you can clearly see these operations and identify expensive calls and bottlenecks. |
| CUSTOM | Any generic Python function that doesn’t fit the above (e.g., data formatting, state parsing). | Utility or glue-code functions that don’t map cleanly to other types but shape runtime behavior. Tracing these operations surfaces subtle bugs, data transformations, and state changes that would otherwise be opaque. |
The @trace Decorator
The @trace decorator automatically captures function inputs, outputs, timing, errors, and parent-child relationships.
Syntax Options
Error Tracking
The decorator automatically captures exceptions. When an error occurs, the trace records:- The error message in the
errorfield - The execution time until the error
- Input data that caused the error
Viewing Trace Hierarchy
After collecting traces, you can visualize the execution flow:SDK Integration
Tracing Tutorial
Step-by-step guide to instrumenting your agent and collecting traces.
Trace Service
Manage and collect traces for your AI agent operations using the SDK.
Trace Properties
The session to which the trace belongs.
The inference result this trace is associated with.
The name of the traced operation (e.g., function name).
The type of operation: TOOL, CHAIN, RETRIEVER, LLM, or CUSTOM.
The ID of the parent trace for hierarchical relationships.
The input parameters passed to the operation.
The result returned by the operation.
Error message if the operation failed.
The execution time of the operation in milliseconds.
ISO 8601 timestamp when the operation started.
ISO 8601 timestamp when the operation completed.
Additional custom metadata about the trace.
Best Practices
Use meaningful trace names
Use meaningful trace names
Trace at meaningful boundaries
Trace at meaningful boundaries
Trace operations that represent logical units of work, not every single function:
Select appropriate node types
Select appropriate node types
Classify operations correctly to enable better filtering and analysis in the dashboard.
Keep input/output data reasonable
Keep input/output data reasonable
The decorator captures function arguments automatically. Consider what’s useful for debugging: