Yes, Build Multi-Agent Systems: A Bold Manifesto for Those Who Dare
A response to "Don't Build Multi-Agents" - because sometimes the hard path is the right path
The Coward's Way Out
The recent post "Don't Build Multi-Agents" by Cognition AI makes some valid points about context sharing and decision conflicts. But here's the uncomfortable truth: avoiding multi-agent architectures because they're hard is like avoiding distributed systems because single-threaded programs are simpler. Yes, they're simpler. They're also limited, slow, and fundamentally unable to handle the complexity of real-world problems at scale.
The author's core argument boils down to: "Multi-agent systems are fragile because agents can't share context effectively and make conflicting decisions." This is like saying "Don't build microservices because distributed transactions are hard."
Of course they're hard. That's not a reason to avoid them - it's a reason to build them right.
The Fundamental Flaw in Sequential Thinking
The post's examples reveal a critical misunderstanding: they're trying to apply sequential, synchronous thinking to an inherently asynchronous, parallel problem space. Look at their Flappy Bird example - they spawn subagents and then try to combine results at the end, as if agents were just fancy function calls.
This is fundamentally wrong. Agents are not threads. They're not processes. They're autonomous entities operating in uncertain timeframes with unpredictable execution paths.
Trying to orchestrate them like traditional software components is like trying to manage a team of humans using CPU scheduling algorithms. It's the wrong mental model entirely.
The Right Way: Event-Driven Choreography, Not Orchestration
Here's how you actually build robust multi-agent systems:
The Architecture That Actually Works
Look at this architecture carefully. Notice what's NOT here? No orchestrator trying to control everything. No agents waiting on each other. No complex dependency graphs. Instead, you have:
1. System of Records as the Source of Truth
Every agent interaction goes through a central system of records (SoR). This isn't just a database - it's the living, breathing state of your entire system. When the Sourcing Agent finds candidates, it doesn't tell the Interviewing Agent directly. It updates the SoR using CRUD operations.
Sourcing Agent → Updates SoR → Triggers Event → Agent X Reacts
This solves the context problem entirely. Every agent always has access to the full system state. There's no "context passing" because context isn't passed - it's shared through the system of records.
2. Event-Driven Architecture with Semantic Gates
The Event Bus is the nervous system of the entire operation. When any agent crosses a semantic gate (completes a meaningful chunk of work), it updates the SoR, which triggers an event. The Events service processes these and publishes them to the Event Bus. Other agents subscribe to relevant events and react accordingly.
Notice the timer symbol? That's because we genuinely don't know when an agent will return. The Sourcing Agent might take 30 seconds or 30 minutes to find the right candidates on LinkedIn. The Vetting Agent might be processing complex documents. This is why synchronous architectures fail - you can't treat agents like function calls.
3. Protocols That Actually Work
Notice how each agent connects to external systems through well-defined protocols:
We've implemented this successfully using:
MCP (Model Context Protocol) for agent ↔ tool interactions:
A2A (Agent-to-Agent Protocol) for inter-agent communication:
These aren't theoretical - they're battle-tested in production with complex integrations across Claude, GPT-4V, LinkedIn, Monster, Google Spreadsheet, vector databases, and internal company tools.
Why Multi-Agent Systems Are Actually MORE Reliable
The post claims multi-agent systems are fragile. This is only true if you build them wrong. When built correctly, they're actually far more robust than single-agent systems:
1. Measurable Performance Gains
Our KPIs tell the story:
These aren't vanity metrics. They directly translate to marketplace liquidity. We can handle multiple external and internal systems seamlessly because each agent specializes in its domain.
2. Production-Grade Security and Monitoring
Real multi-agent systems need:
The scope isn't just "building agents" - it's building a complete ecosystem with choreography, monitoring, and continuous improvement built-in.
3. True Parallelism with Specialized Agents
Our vendor marketplace system demonstrates this perfectly:
While the post worries about "conflicting decisions," our agents don't conflict - they collaborate through the System of Records with clear boundaries and responsibilities.
4. Engineering Solutions to Real Challenges
Yes, we faced challenges. Here's how we solved them:
Choreography Loops: Early versions had infinite loops in delegation chains. Solution? Introspectable logging and trace IDs per delegation step, with debug planner logic to track execution paths.
Multi-Agent Failures: Nested agent calls made debugging hard. Solution? Structured JSON logs with agent name, step, and status. Input/output snapshots per agent enable postmortem debugging.
Schema Mismatches: Inconsistent responses between agents. Solution? Strict JSON Schema validation at controller boundaries, standardized MCP wrappers for uniform request/response formats.
Controller Complexity: The central planner grew unwieldy. Solution? Intent-specific handlers (handle_vision_intent, handle_rag_query, handle_pdf_processing) with declarative configs mapping intents to agent sequences.
These aren't theoretical problems - they're real engineering challenges we've solved in production.
Real-World Success: Vendor Marketplace at Scale
Let me give you the full picture from our production vendor recruitment system. This isn't a toy example - it's handling real marketplace operations:
The Challenge: Traditional vendor onboarding taking 3-5 days per expert, limited vendor pool, manual verification nightmare, inconsistent quality assessments.
The Results:
When a client needs a specific expertise, the Choreographer immediately delegates to Sourcing and Communication agents. While Sourcing scans LinkedIn for relevant experts and checks internal databases, Communication sets up initial touchpoints. As potential vendors flow in, Vetting processes their credentials and portfolios in parallel batches. The marketplace UI shows real-time progress by reading the System of Records.
This is what "doing it right" looks like - not HR automation, but a sophisticated marketplace system.
The Hard Truth About Context
The post makes a big deal about context windows and keeping full traces. This is a red herring. You don't need every agent to see every detail of what every other agent did. That's like saying every microservice needs to see every other service's internal state. It's not just unnecessary - it's actively harmful.
What you need is:
Our system of records maintains all of this without bloating individual agent contexts. Agents subscribe to the events they care about and ignore the rest. When debugging is needed, trace IDs let us reconstruct the entire flow without every agent carrying the full history.
Embrace the Chaos
Yes, multi-agent systems are complex. Yes, they require careful design. Yes, you can shoot yourself in the foot if you don't know what you're doing.
But here's the thing: the future of AI is not a single, monolithic model trying to do everything. It's specialized agents working together, each excellent at their domain, coordinating through well-designed protocols.
The authors of "Don't Build Multi-Agents" are right that naive implementations fail. Where they're wrong is in concluding that means you shouldn't build them at all.
The solution isn't to retreat to single-agent systems. The solution is to build multi-agent systems that actually understand the nature of autonomous, asynchronous agents.
A Challenge to the Industry
To those saying multi-agent systems are too hard: you're right, they are hard. So was TCP/IP. So was distributed computing. So was machine learning itself.
The question isn't whether multi-agent systems are difficult. The question is whether they're worth it.
And for those of us building real-world AI systems that need to:
The answer is unequivocally yes.
The Future Is Multi-Agent
Single-agent systems are training wheels. They're fine for demos, prototypes, and simple applications. But when you're ready to build something that truly pushes the boundaries of what's possible with AI, you need multi-agent architectures.
The key is understanding that agents are not traditional software components. They're autonomous entities that require:
Get these right, and multi-agent systems aren't just viable - they're vastly superior to any single-agent alternative.
So yes, build multi-agent systems. Build them if you have what it takes to do it right. Build them if you're ready to move beyond the limitations of sequential thinking. Build them if you want to create AI systems that can truly scale.
The future belongs to those who dare to build what others say is too hard.
Want to see multi-agent systems done right? Check out our implementation using MCP and A2A protocols, handling everything from recruitment workflows to complex RAG pipelines. Because while others are writing about why it can't be done, we're busy doing it.
Special thanks to @divyank whose insights were instrumental in finetuning our multi-agent agent architectures.