Sequential agent chains are a latency tax — the event-driven pattern that makes independent agents run in parallel
Description and use
A five‑stage agent pipeline built as a linear chain caused unnecessary serialisation, inflating wall‑clock time by up to five times. By re‑architecting to event‑driven concurrency, independent stages ran in parallel, reducing latency and improving observability, at the cost of added operational complexity.
Problem
A multi‑agent pipeline built as a linear chain caused unnecessary serialisation, inflating wall‑clock time by up to five times.
Outcome
By shifting from a sequential chain to event‑driven concurrency, the author eliminated unnecessary serialisation, reduced latency, and gained visibility into back‑pressure and ordering, while accepting increased operational complexity.
Workflow
- 1. Researcher fetches multiple sources independently.
- 2. Analyst performs separate analyses on fetched data.
- 3. Writer compiles final output once all upstream data is available.
- 4. Fact‑checker verifies claims independently of earlier stages.
- 5. Formatter formats the final document. In the new design, each agent subscribes to the specific events it needs and processes them as soon as they arrive.
Evidence
I once watched a nine-minute agent workflow spend seven minutes and forty seconds doing nothing.
The math is unforgiving. If you have N stages with average latency L, your wall-clock time is N × L. If K of those stages are independent, the floor is (N − K) × L + L, not N × L.
In a sequential chain, work starts because the previous step finished. In an event-driven architecture, work starts because the data it needs has arrived.
Cisco's CAIPE runs multi-agent orchestration across Argo CD, Kubernetes, and Komodor, where agents chain across tools and respond to cluster events rather than polling in sequence. Their reported outcome: response times dropped from hours to seconds, with MTTR reduced by up to 80%.
- Record date: 2026-10-01T22:10:56.705Z