Skip to main content
Every interaction produces a trace — a structured record of the agent’s reasoning for that turn: the input it saw, what it understood, the decisions it took, the parameters it computed, the rules it evaluated, and the response it gave. Two ways to fetch traces on the messaging surface: The interactionId is the message.id from a send-message response.
On the WebSocket session, the final message envelope embeds the same trace as data.trace_info when the session was opened with include_trace=true.

Get a thread’s traces

cURL
Returns an array of trace objects, one per interaction, oldest first.

Get one interaction’s trace

cURL

The trace object

object
The end-user message the turn started from (input.message).
object
What the agent understood: the detected intents and the guardrails outcome (passed, reason).
array
The decisions the agent took while handling the message — one entry per step.
array
Parameters the agent computed during the turn (code, title, scope).
array
Every rule evaluated: its code, whether it triggered, and the per-condition reason breakdown.
object
How the agent answered: the response type and message, follow-up suggestions, what it was asking_for, any block_message, and rendered jsx_widgets.
Trace fields are additive: new fields may appear as the reasoning engine evolves, so treat unknown fields as informational rather than errors.

Traces on the management surface

The same traces are available under /management/v1 for back-office tooling — GET /management/v1/threads/{threadId}/trace and GET /management/v1/interactions/{interactionId}/trace — authenticated with a management credential. See Management → Threads.