Reading the routing timeline
Every routing transition in a run is persisted as one timeline row; a completed run always ends with exactly one final_response row. By examining these events, you can reconstruct the exact handoff sequence when investigating a misrouted or stuck execution.
Routing events glossary
| Event Type | Meaning |
|---|---|
transfer | One sub-agent handed the ENTIRE conversation to another sub-agent, which is now the active responder. |
delegation | One sub-agent asked another for an answer to a specific sub-task and got a result back, while staying in charge itself. A single step can contain more than one of these (fan-out to several targets). |
route_error | A transfer or delegation was attempted but did not complete. Inspect the recorded error code — see the limits and budgets page for what each code means. |
tool_call | A sub-agent invoked an ordinary tool — unrelated to routing between sub-agents. |
final_response | The terminal responder for the run. Exactly one per completed execution; identifies which sub-agent (or the "self" sentinel) produced the final answer. |
Authoring implications
If you're building tooling on top of the execution data, treat these five event types as the complete, stable vocabulary — don't infer additional ones from prose in a tool call payload.
Common Pitfall: Treating a route_error as the run having failed outright. A single blocked
or failed delegation target is often non-fatal, as the caller can still finish with other targets'
results, or its own answer.
Related