When a multi-agent run goes sideways, the question is rarely what did the agent say? The logs have that. The real question is why did it transfer to that sub-agent, and what did it know at that moment?
Most systems make this a forensic exercise: rerun with extra logging, inspect context windows, and infer what happened.
We think that question deserves a better answer than guesswork.
Multi-agent systems are state machines in disguise
A single agent is a loop: read, think, act, repeat. A multi-agent system is something else. Every transfer to a specialist, every delegated sub-task, every fallback to the default is a state transition.
But many runtimes treat each handoff as just a log line. It happens in memory, gets folded into a final answer, and disappears when the request ends. By the time someone investigates, the control flow that produced the output is gone.
That is the gap: the what survives, the why does not.
Handoffs as a first-class artifact
Our approach starts with a simple commitment: every handoff is a structured event persisted before the next step runs.
It is not free-text. It has shape: which sub-agent handed off, which one received, what transition type it was (full handover, scoped delegation, fallback), and the message at that moment.
Every event is tied to the run that produced it. A run is no longer one blob of output; it is a sequence of transitions you can step through.
The orchestration itself follows an explicit reason-then-act loop. The agent picks a tool or a transfer, executes it, reads the result, then chooses the next move. Every move crossing an agent boundary is written to the timeline.
Why persist instead of log? Because transition records are only useful if they survive. In-memory traces help for seconds. A durable timeline helps next week, when someone says, "This run returned the wrong thing on Tuesday," and you need to reconstruct what happened.
Watching the run, after the run
In our product, each multi-agent run writes to this timeline during execution. Admins can inspect the run as a sequence of handoffs, using the same endpoint the UI uses to render routing events.
A run with eight transfers across five sub-agents is no longer one wall of output. It is eight inspectable events. You can review each step, see what each sub-agent received, and rebuild the decision tree without rerunning anything.
Output also streams live as execution happens, so the timeline is not only post-mortem tooling; it is also an operational view.
That also makes it useful for audit trails. Compliance teams usually care less about prose output and more about who decided what, when, and with what context. Persisted handoff events answer that directly.
The trail is the answer
We did not add this because someone asked for better logs. We added it because the hardest bugs in multi-agent runs were control-flow bugs, and control flow was exactly what we had not recorded.
Once we persisted handoffs as durable events, the same classes of bugs took minutes instead of afternoons.
If you are building with multiple agents collaborating, this is the one thing we would prioritize first. The runtime matters, but the trail it leaves behind is what makes the system debuggable later.