Multi-agent orchestration: what worked and what didn’t

I have been running multi-agent orchestration experiments for about four months. The short list of observations, in order of usefulness:

Specialization beats generality, almost always. A single agent with a broad prompt and many tools is harder to reason about and less reliable than three agents with narrow prompts and fewer tools each. Breaking a task into specialized agents forces the system designer to articulate boundaries clearly, which is where most of the reliability gains come from.

The orchestrator is the hard part. The individual agents are comparatively easy. Coordinating them — deciding who runs when, what state gets passed between them, how to handle partial failures — is where the complexity lives. Most of my time has gone into orchestration logic, not agent prompts.

Determinism at the boundaries; non-determinism inside. The inputs and outputs of each agent should be schema-validated, deterministic, and logged. The reasoning inside the agent can be non-deterministic. If you let non-determinism leak into the boundaries, debugging becomes impossible.

Budget every call. Multi-agent systems generate cost at a multiple of single-agent systems. Without per-call and per-run budgets, a buggy orchestration can burn through a month of spend in an hour. I learned this by burning through a month of spend in an hour.

The counterintuitive thing: multi-agent systems are not about intelligence. They are about decomposition. The intelligence is in how you break the problem apart.