On Building Multi-Agent Systems
March 21, 2026
A few months ago I started building multi-agent AI systems in earnest. Not demos. Not toys. Production systems that replace workflows that used to take people days.
Here's what I've learned.
Simple beats clever
The first agent I built was overengineered. Dynamic routing, complex state machines, a beautiful orchestration layer. It was slow, hard to debug, and broke in weird ways.
The second one I built like I'd build any boring software: explicit state, predictable flow, logs everywhere. It's been running in production for months without incident.
The hard part of multi-agent systems isn't the AI. It's the same stuff that's always hard in distributed systems: shared state, failure modes, observability.
Shared state is the real problem
Every agent in a system needs context. What's been tried. What failed. What the goal actually is. Get this wrong and agents contradict each other, repeat work, or spin in loops.
I solved this in Agent Composer by giving every agent read access to a shared context object, and write access only to their own output. One writer, many readers. Same principle as a message bus.
The loop problem
Agents will loop. An agent tasked with "fix this bug" will sometimes decide the fix is to rewrite the function that calls it, which introduces a new bug, which triggers the agent again.
The fix is boring: iteration limits, explicit done states, and a supervisor agent that can veto.
What's actually new
The thing that surprised me most is how much of this work is just software engineering. Good abstractions, clear interfaces, explicit state. The AI part is almost the easy part — you write a good prompt and the model does something useful.
What's new is the scale of what you can automate. Not just tasks, but entire workflows. The first time a system I built replaced a week of expert review with twenty minutes of compute, something clicked.
That's the part worth building toward.