Six months ago, we shipped a feature called Mission Control. It was our take on the agent swarm pattern: multiple AI agents working together as a team, with one designated as the leader, coordinating through agent-to-agent (A2A) messaging to complete complex missions. On paper, it was elegant. In practice, we just replaced it with something simpler that works better.
This is not a failure postmortem. This is a case study in why the obvious architecture is not always the right one, and why shared memory beats message passing for multi-agent AI systems.
What Mission Control Was
Mission Control let users assemble teams of specialized agents and give them coordinated tasks. You could designate a Team Leader agent that would break down objectives into milestones, delegate tasks to specialist agents, and orchestrate the workflow through our A2A protocol.
The architecture looked like this:
- User assigns a mission to the Team Leader agent
- Team Leader creates milestones and identifies which specialist agents are needed
- Team Leader sends task messages to specialists via A2A protocol
- Specialists complete their work and reply with results
- Team Leader synthesizes outputs and delivers the final result
We built this because it matched the mental model of how human teams work. A project manager coordinates, specialists contribute, information flows through structured communication. It felt right.
The Promise of Agent Swarms
We were not alone in exploring this pattern. Perplexity has experimented with agent swarms for complex research queries. Kimi built a multi-agent lookup and context system. The broader AI community has been excited about frameworks like AutoGPT, CrewAI, and LangGraph that orchestrate multiple agents through message passing.
The theoretical benefits are compelling:
- Specialization: Each agent can be optimized for a specific task
- Parallelism: Multiple agents can work simultaneously
- Modularity: You can add or remove agents without redesigning the system
- Transparency: Message passing creates an audit trail of who did what
When LLMs were expensive and less capable, this made sense. You might need one agent for research, another for writing, another for fact-checking, each with different system prompts and tool access. The coordinator would route work to the right specialist.
What We Actually Observed
We ran Mission Control in internal testing for three months before deciding to pull it. Here is what the data showed:
Latency compounded badly. Every A2A message added round-trip time. A simple task that required input from three specialists turned into a cascade of waits. The Team Leader would send a request, wait for a response, send another request, wait again. Users sat through 30-45 second delays for tasks that a single well-configured agent could handle in 10 seconds.
Quality did not improve meaningfully. This was the finding that surprised us most. We expected that having specialized agents tackle specialized subtasks would produce better outputs than a single agent handling everything. It did not. The categorization and structuring that Mission Control added was helpful for organizing the process, but the actual output quality was nearly identical to what a single Sage 1.5 agent produced when given the same information upfront.
Coordination overhead ate into capability. The Team Leader agent spent most of its reasoning capacity on orchestration rather than substance. It was tracking who had done what, formatting requests, parsing responses, and managing state. This is exactly what happens in human organizations when too much management overhead crowds out actual work.
Context fragmentation created its own problems. Each specialist agent only saw its slice of the problem. When their work needed to build on each other's outputs, we had to pipe context through messages, which meant redundant processing and context window consumption.
The Shared Memory Alternative
While we were running Mission Control experiments, we were also building out our memory infrastructure for other reasons. Sage 1.5 agents already had persistent memory blocks for storing long-term context. The natural question emerged: what if agents could just share these memory blocks directly?
Instead of Agent A sending a message to Agent B and waiting for a reply, both agents simply read from and write to the same memory block. Changes are immediately visible. There is no round-trip. There is no waiting.
The architecture is fundamentally different:
With A2A messaging:
- Agent A sends request to Agent B
- Agent B processes and sends response
- Agent A receives response and continues
- Total time: Agent A processing + network latency + Agent B processing + network latency + Agent A processing
With shared memory:
- Agent A writes to shared memory block
- Agent B reads from shared memory block when needed
- Total time: Agent A processing (memory operations are essentially instant)
How Shared Memory Actually Works
The implementation is straightforward. Every memory block in Sage 1.5 has metadata including ownership, type, capacity, and sharing status. When you attach a memory block to another agent, both agents read and write to the exact same block. Changes made by one agent are immediately visible to all others.
We added a few features to make this robust:
Timestamps and delta tracking. Every memory modification is timestamped. Agents can see when information was last updated and by whom. If you need to understand the evolution of a piece of knowledge, the history is there.
Type-based organization. Memory blocks are categorized by type: Knowledge, Identity, Working, and Custom. This helps agents understand what kind of information they are accessing and how to use it.
Capacity management. Each block has a defined capacity (typically 5,000 characters). This prevents unbounded growth and forces agents to synthesize rather than accumulate.
Selective sharing. You control exactly which memory blocks are shared with which agents. Your Financial Advisor might share "Company Info" with your Legal Guardian agent, but not with your Wellness Coach. The boundaries are explicit.
Why This Works Better
The results from our testing were clear enough that we made the decision to deprecate Mission Control entirely.
Latency dropped dramatically. Tasks that took 30-45 seconds with A2A orchestration now complete in 8-12 seconds. Memory operations are essentially instant compared to the round-trip overhead of agent messaging.
Quality stayed the same or improved. We ran blind evaluations comparing Mission Control outputs to shared memory outputs. Evaluators could not reliably distinguish them, and when they did, they slightly preferred the shared memory versions. Our hypothesis: removing the coordination overhead let agents spend more reasoning capacity on the actual task.
User experience simplified. With Mission Control, users had to understand team structures, leader designation, and task delegation. With shared memory, you just share a memory block. The mental model is "these agents know the same things" rather than "these agents talk to each other."
The architecture is more honest. A2A messaging implies autonomous agents making independent decisions. But in practice, the LLM is stateless, the "communication" is synthetic, and the user is ultimately the only real principal. Shared memory makes the actual data flow explicit rather than hiding it behind a metaphor.
When Multi-Agent Still Makes Sense
We are not arguing that multi-agent systems are never useful. There are cases where you genuinely need multiple LLM calls with different configurations:
- Different model capabilities: If one task needs vision and another needs deep reasoning, you might need different model variants
- Truly parallel workloads: If tasks are genuinely independent and you want to run them simultaneously
- Hard security boundaries: If agents must not share certain information under any circumstances
But these cases are rarer than the AI hype cycle suggests. For most real-world use cases, a well-configured single agent with comprehensive context outperforms a swarm of specialists passing messages.
The Broader Lesson
The agent swarm pattern emerged from a reasonable intuition: complex problems benefit from division of labor. But that intuition was formed in the context of human teams, where communication overhead is a necessary cost of leveraging specialized skills.
LLMs are different. A single model can context-switch between specialties instantly. It does not need to send a message to its "researcher" persona and wait for a reply. It can just think about research. The communication overhead in multi-agent systems is artificial, imposed by the architecture rather than required by the capability.
Shared memory acknowledges this reality. Instead of building synthetic communication channels between synthetic agents, it simply ensures that relevant context is available when needed. The result is faster, simpler, and, in our testing, just as capable.
What We Shipped
The shared memory system is now live in Sage 1.5. Any memory block can be attached to multiple agents. Changes propagate instantly. The interface is a simple modal: select which agents should share the memory, click attach, done.
For users who built workflows around Mission Control, we are providing migration guides. The core insight is that most Mission Control use cases map cleanly to shared memory: instead of having agents coordinate through messages, share the relevant context blocks and let each agent access what it needs.
We spent six months building an orchestration system we ended up replacing with a database feature. That is product development. The lesson is not that we wasted time. The lesson is that we validated an assumption the industry has been making and found it lacking.
Multi-agent AI is compelling in theory. Shared memory is compelling in practice. We chose practice.
---
If you want to see shared memory in action, explore Sage 1.5 or get in touch for a walkthrough.
