Everyone is building multi-agent systems. Almost nobody is building them to survive production.
The pattern is always the same: a demo works beautifully with three agents passing messages on a developer's laptop. Six months later, the same system is burning through API tokens, dropping tasks, and producing inconsistent results at 100x the input volume. The team adds retry logic, then queues, then a monitoring layer, then a fallback orchestrator. Suddenly the "autonomous system" has more human intervention points than the manual process it replaced.
This isn't a tooling problem. It's an architecture problem.
The microservices trap
The most common mistake in multi-agent design is treating agents like microservices. The reasoning seems sound: decompose a complex task into specialized units, give each one a clear responsibility, and orchestrate them through message passing.
But agents aren't services. A service receives a well-defined input and produces a deterministic output. An agent receives ambiguous input, reasons about it, and produces a probabilistic output that may or may not be what you expected. When you chain probabilistic outputs across five agents, the compound error rate makes the system unreliable at scale.
The microservices mental model gives you clean architecture diagrams and terrible production outcomes.
What actually breaks
Three things kill multi-agent systems as they scale.
Context degradation. Each agent in a chain receives a lossy summary of what happened before it. By the third handoff, critical context is diluted or lost. The agent makes a reasonable decision based on incomplete information, and the downstream cascade produces garbage.
Orchestration complexity. Linear chains are simple. Real workflows have conditionals, loops, parallel branches, and error recovery paths. The orchestration logic itself becomes the hardest part to maintain, and it's usually the least tested.
Cost amplification. Every agent call costs tokens. A naive architecture that re-reads the full context at each step multiplies cost linearly with chain depth. At scale, this makes the system economically unviable before it becomes technically unviable.
Architecture patterns that survive
After building systems that actually run in production, not demos, not prototypes, a few patterns consistently hold up.
Shared memory over message passing
Instead of agents passing summaries to each other, give them access to a shared structured state. Each agent reads what it needs and writes what it produced. No information loss. No context degradation. The state object becomes the source of truth, not the conversation between agents.
This is closer to a blackboard architecture than a pipeline. And it scales because each agent's context window stays constant regardless of how many other agents participated before it.
Narrow agents with hard contracts
The broader an agent's capability, the less reliable it is. An agent that "handles customer inquiries" will fail unpredictably. An agent that "extracts invoice line items from Portuguese PDF documents and returns a typed JSON object" will succeed consistently.
Define strict input/output contracts. Validate them programmatically, not with prompts. If an agent's output doesn't match the expected schema, that's a hard failure, not a retry.
Deterministic orchestration, probabilistic execution
The orchestrator should be pure code. No LLM in the loop for routing decisions. Which agent runs next, under what conditions, with what timeout: all deterministic logic. The only probabilistic layer is inside each individual agent.
This gives you predictable costs, testable workflows, and debuggable failures. When something breaks, you know exactly which agent failed and what it received.
Progressive autonomy
Don't give agents full autonomy from day one. Start with human-in-the-loop for every decision. Measure accuracy over hundreds of executions. When an agent consistently gets it right, remove the human checkpoint for that specific decision, not for the whole workflow.
This isn't a lack of confidence in AI. It's engineering discipline applied to a probabilistic system.
The real problem
The industry's obsession with autonomy is premature. The value of AI agents isn't that they replace humans. It's that they handle the volume and speed that humans can't. A system that processes 10,000 documents per day with 95% accuracy and human review on the remaining 5% is infinitely more valuable than a system that promises 100% autonomy and delivers 80% accuracy with no way to catch the errors.
Build for reliability first. Autonomy is earned, not assumed.
This is how we think about agent architecture at Falnoa. If you're building multi-agent systems and hitting scaling walls, we should talk.