Multi-Agent Workflow Latency: Find the Gaps Between Handoffs
Use a production log to inspect multi-agent workflow latency, separate message gaps from processing time, and choose the next handoff event to record.
A multi-agent workflow can produce useful answers quickly and still take much longer to close the task. The useful diagnostic question is where elapsed time accumulates: before an agent receives work, during its processing, at a human decision, or after the result is ready.
Our production team log exposes part of that picture. A task to investigate indexing and prepare a content fix reached final acceptance in 2,099 seconds. The largest visible gap between adjacent channel messages was 936 seconds. Those are observations about the workflow’s record, not measurements of model processing or an agent’s queue.
The distinction matters when deciding what to change. A long silence is a place to investigate. It does not, by itself, tell you to replace the model or add another worker.
A production run with a visible interruption
On 29 October 2026, an orchestrator assigned an indexing investigation to a manager. The manager delegated checks to specialists. Their reports informed a patch, which then went through build, deployment and verification.
The elapsed time from the initial assignment to the ready patch was 1,368 seconds. Final acceptance came at 2,099 seconds. These intervals include coordination and checks; they do not isolate computation.
The panel also recorded a loop guard. From the guard message to the orchestrator’s technical explanation, 1,085 seconds elapsed. However, specialist messages continued after the guard. The longest adjacent-message gap was 936 seconds, within that broader interval.
| Observed interval | Seconds | What it establishes |
|---|---|---|
| Initial assignment to ready patch | 1368 | Elapsed time to that recorded milestone |
| Initial assignment to final acceptance | 2099 | Elapsed time across the recorded cycle |
| Last specialist message before the long silence to the next channel message | 936 | The largest visible adjacent-message gap |
| Guard message to technical explanation | 1085 | A broader, overlapping interval |
The last intervals overlap. Adding them would count part of the same time twice.
The operator attributed the interruption to the guard. The log supports the presence of the guard and the subsequent message gap. It does not establish that every agent stopped, or how much faster the task would have finished with a different configuration.
Read the chart as a record of messages
Observed gap between channel messages (seconds) — calculated from displayed timestamps. Each category represents the next pair of adjacent messages in the exported sequence. The horizontal spacing represents message order, not a continuous time axis. The largest bar is 936 seconds. This is a single production run, not a benchmark.
Production team log, 29 October 2026. Gaps calculated from displayed timestamps. Message order is categorical. These are channel gaps, not measured processing durations.
The separate guard-to-explanation interval is 1,085 seconds. It is not another bar to add to these adjacent gaps.
The export’s precomputed gap column differs slightly from differences calculated using its displayed timestamps. This chart consistently uses the displayed times, which have second-level precision. The original fractional timestamps are unavailable in this export.
Draw the handoffs without inventing a serial pipeline
The sequence also contained rework. A patch-format issue and a build failure required attention before closure. A diagram that collapses those boundaries into a single “agent execution” box would hide information needed to diagnose the cycle.
For a workflow built around recurring launches, check the expected result and delivery separately. A process starting or a status turning green does not close every boundary.
What to record in your own handoff log
Start with a task identifier that survives delegation. For each handoff, record these events from the systems that actually observe them:
| Field | Operational definition | If it is missing |
|---|---|---|
| handoff_ready | The sender has completed and released the input the receiver needs | The beginning of the handoff interval is unknown |
| receiver_start | The receiver begins processing that specific input | Queue delay cannot be separated from processing |
| finish | The receiver completes the agreed output boundary | Processing duration cannot be closed |
| clock_basis | Timezone and clock source for the events | Cross-system subtraction may be misleading |
| branch_and_dependencies | Which inputs this step needs and which work can run concurrently | A serial total may misrepresent the workflow |
| result_check | Evidence that the agreed output passed its check | Completion remains an agent claim |
When those events share a usable clock basis, calculate:
def handoff_durations(handoff_ready, receiver_start, finish):
"""Proposed worksheet calculation; inputs are comparable datetimes."""
if not handoff_ready <= receiver_start <= finish:
raise ValueError("Check event order and clock basis")
return {
"wait_seconds": (receiver_start - handoff_ready).total_seconds(),
"service_seconds": (finish - receiver_start).total_seconds(),
}This is a proposed calculation for an instrumented journal. It was not used to recover missing processing events from our channel.
In our export, a manager’s assignment was followed by a recipient’s acknowledgement after 14 seconds. The ready patch appeared 115 seconds after that acknowledgement, or 129 seconds after assignment. An acknowledgement establishes that a message was sent; it does not establish the exact processing start. Those elapsed intervals therefore cannot fill the wait and service fields above.
For parallel branches, follow dependencies to the result that closes the task. Do not add overlapping branch durations as if all work happened consecutively. The multi-agent dashboard case provides a related view of work that combines outputs from several agents.
Use an unknown boundary to choose the next observation
If the record stops at a handoff, improve receipt and processing-start events. If a result is ready but the next decision is absent, inspect that decision boundary. If a build fails, keep its execution evidence separate from the agent’s completion message.
Our log identifies a large visible gap and several workflow boundaries. It does not identify a typical delay, an isolated processing bottleneck, or a measured improvement after a fix. Better instrumentation would let the next investigation distinguish those possibilities without treating silence as a diagnosis.