When a single AI agent isn’t enough, the next logical step is to use several. But putting two agents to work on the same codebase isn’t like putting two developers to collaborate — it’s more like putting two assistants who don’t talk to each other in the same room, and hoping they don’t break anything.
Multi-agent orchestration has become one of the most active topics in the AI ecosystem in 2026. Six frameworks are competing to define how agents coordinate. New tools like Sandcastle solve the problem of environment isolation. And the hidden costs of parallelization are starting to become visible.
Sandcastle: Isolation by Container
Sandcastle is a TypeScript library created by Matt Pocock (@ai-hero/sandcastle on npm) that allows running multiple coding agents in parallel, each in its own Docker container with its own git branch.
Each agent is launched with sandcastle.run(), receives its own copy of the repository on an isolated branch inside a container, and when finished, Sandcastle merges the changes. It supports Docker, Podman, and Vercel Firecracker (microVMs) backends. The metaphor is simple: treat each agent as a temporary developer with its own virtual machine.
The YouTube video that originated this research calls it “Docker Worktrees” — a portmanteau combining Docker (containers) with git worktrees (parallel branches). It’s not exactly git worktree in the native sense, but the idea is the same: total isolation so no agent contaminates another’s work.
Minimax Agent Teams: Leader, Worker, Verifier
On May 27, 2026, MiniMax announced its agent team architecture as part of the Mavis update. The design is explicit and structured:
- Leader: translates user objectives into a task structure, decides which Workers to run and in what order.
- Workers: execute specific subtasks with specialized tools and context. They can run in parallel.
- Verifiers: review the Workers’ output independently, in an adversarial loop — similar to quality assurance versus development.
The system uses a state machine (Team Engine) with a produce → verify → done cycle. If verification fails, the producing node wakes up to redo the work. This is deterministic logic, not prompt-based.
MiniMax is honest about costs: it identifies three types — handoff cost (reorganizing information between agents), sharing cost (giving visibility to all agents), and aggregation cost (merging parallel outputs). They cite the “Cost of Consensus” paper showing 2.1-3.4x token consumption in homogeneous configurations without accuracy improvement.
The Framework Landscape
Multi-agent orchestration has at least six competing approaches, each with a different coordination model:
| Framework | Model | Author |
|---|---|---|
| LangGraph | Graph-based (supervisor) | LangChain |
| OpenAI Agents SDK | Handoff (transfer between agents) | OpenAI |
| CrewAI | Role-based | CrewAI |
| AutoGen/AG2 | Conversational | Microsoft |
| Google ADK | Hierarchical (A2A protocol) | |
| Claude Agent SDK | Tool-use + MCP | Anthropic |
Claude Code also has its own experimental Agent Teams, where a Lead Agent creates a team, assigns tasks to Teammates with isolated contexts, monitors progress, and merges results. Each Teammate is a full instance of Claude Code with its own context window.
The Problems No One Has Solved Yet
1. Parallelization cost. Running N agents in parallel doesn’t cost N times more — it often costs more due to coordination, verification, and merge overhead. The promise of “free parallelism” doesn’t exist in practice.
2. Semantic conflicts. Sandcastle and git worktrees resolve textual conflicts (two agents modifying the same line), but not semantic ones (two agents changing the same function in incompatible ways across different files). Git merge catches the former, but the latter requires human review.
3. Shared state. How do you share context between agents without saturating their context windows? How do you ensure one agent knows what another did without tripling the tokens? Every framework has a different answer, and none is universal.
4. Multi-agent evaluation. If evaluating a single agent is hard (as we saw in the previous article on benchmarks), evaluating a multi-agent system is an order of magnitude more complex. No accepted multi-agent benchmarks exist.
What It’s Good for Today
Multi-agent orchestration isn’t for every project. It makes sense when:
- You need one agent to research while another writes code and a third reviews.
- You’re working with large codebases where a single agent loses context.
- You want to parallelize independent tasks (tests, documentation, isolated refactors).
For an individual developer with a small project, a well-configured single agent is probably more efficient. But as teams and projects grow, multi-agent orchestration is becoming an infrastructure necessity, not an experimental luxury.
Sources: Sandcastle GitHub · MiniMax Agent Team Blog · GuruSup: Multi-Agent Frameworks 2026 · Claude Code Agent Teams · Addy Osmani: Code Agent Orchestra