One Agent Is Not Enough
A single AI agent with tool access can handle straightforward tasks. Answer a question. Look up data. Send an email. But real-world workflows are complex and messy. A software development task involves understanding requirements, writing code, running tests, fixing bugs, reviewing for security issues, and deploying. No single prompt or tool set handles all of these well. Asking one agent to be a coder AND a reviewer AND a tester stretches it too thin.
Multi-agent systems solve this the same way human organizations do: through specialization and collaboration. Instead of one person doing everything, you have a team where each member has a defined role and expertise. The same principle applies to AI agents.
How Multi-Agent Systems Work
The core idea is straightforward: instead of one large agent doing everything, create multiple specialized agents that communicate with each other. Each agent has its own system prompt, tool set, and area of responsibility. The magic is in how they coordinate.
Several coordination patterns have emerged, each suited to different types of problems:
- Supervisor pattern: one 'manager' agent breaks tasks into subtasks and delegates to specialized worker agents. The manager reviews results, provides feedback, and coordinates the overall workflow. This mirrors a tech lead delegating tasks to a team.
- Debate pattern: multiple agents independently analyze the same problem, then discuss and reconcile their answers. This reduces errors through diverse perspectives. If three agents agree on an answer, it is more likely to be correct than if one agent produced it alone.
- Pipeline pattern: agents are arranged in sequence, each performing one step and passing results to the next. A research agent gathers information, a drafting agent writes content, a review agent checks for errors. Like an assembly line where each station adds value.
- Autonomous teams: agents have defined roles (researcher, coder, reviewer) and communicate through a shared workspace. More complex to orchestrate but handles open-ended creative tasks where the workflow cannot be predetermined.
The Major Frameworks
Several frameworks have emerged to make multi-agent systems practical:
AutoGen (Microsoft Research) pioneered the 'conversational agents' approach. Agents talk to each other in a group chat format, taking turns contributing to the conversation. A user proxy agent represents the human. An assistant agent handles coding. A code executor agent runs the code. They chat back and forth until the task is complete. AutoGen made multi-agent systems feel natural and intuitive.
CrewAI takes a role-based approach inspired by how companies work. You define a 'crew' with agents that have specific roles (researcher, writer, editor), goals (find accurate information, write engaging content, ensure quality), and backstories that shape their behavior. The crew executes tasks collaboratively, with each agent contributing their expertise.
MetaGPT goes even further, simulating an entire software company. It assigns roles like product manager, architect, project manager, and engineer. The PM writes requirements, the architect designs the system, the engineer writes code, and the QA agent tests it. The output is structured documents and working code, not just chat messages.
Code Execution and Sandboxing
An agent that can write code is powerful. An agent that can write AND execute code is transformative. But it is also dangerous. An agent with unrestricted code execution could delete files, exfiltrate data, consume all available compute resources, or make network requests to internal services.
Sandboxing is the solution: isolated execution environments that contain the blast radius. The principle is simple: never let an AI agent execute code in your production environment. Always use isolated containers with strict limits.
- Docker containers: create a fresh container for each execution, with no access to the host filesystem or network. Destroy it after the code runs.
- E2B (e2b.dev): cloud-based sandboxes purpose-built for AI code execution. Spin up a sandbox in milliseconds, run code, get results, tear it down.
- Language-specific sandboxes: Python's RestrictedPython, JavaScript's VM2. Lighter weight but less isolation than containers.
- Resource limits: cap CPU time, memory usage, disk space, and network access. An agent cannot mine cryptocurrency if it only gets 10 seconds of CPU time and no network access.
OpenAI's Code Interpreter (now called Advanced Data Analysis) demonstrated this pattern at scale. It runs Python in a sandboxed container with no internet access, limited memory, and a timeout. Users can upload files, the model writes and executes code against those files, and the results (charts, processed data, analysis) come back. The security boundary between the agent and the host system is absolute.
Human-in-the-Loop: Autonomy Is a Spectrum
The industry learned quickly (and sometimes painfully) that fully autonomous agents are risky. An agent that can send emails without approval might send embarrassing messages. An agent that can make purchases might overspend. An agent that can modify databases might corrupt critical data.
The solution is not to remove autonomy entirely, because that would eliminate the value of agents. The solution is to make autonomy a spectrum with clear boundaries:
- Approval gates: the agent proposes an action, a human reviews and approves or rejects before execution. Essential for high-stakes actions like financial transactions, external communications, and data modifications.
- Confidence thresholds: the agent acts autonomously on high-confidence decisions and escalates low-confidence ones. Reading data is usually safe to automate. Deleting data should always require approval.
- Budget and scope limits: define boundaries upfront. 'Process returns under $50 automatically, escalate anything above.' 'Answer product questions directly, route complaints to a human.'
- Audit trails: log every agent action with full context. Critical for compliance, debugging, and understanding what went wrong when things go wrong (and they will).
- Kill switches: humans can halt agent execution at any point. If something looks wrong, stop everything immediately. This seems obvious but many early agent systems did not include it.
The paradigm has shifted from 'replace humans with AI' to 'augment humans with AI that asks for help when needed.' The best agent systems are the ones where humans and AI each handle what they are best at. AI handles scale, speed, and consistency. Humans handle judgment, nuance, and accountability.
MCP: A Standard for Agent-Tool Communication
Before Model Context Protocol, every agent framework invented its own way of defining tools. LangChain had its tool interface. AutoGen had its function registration. CrewAI had its tool decorator. If you built a tool for one framework, it did not work with any other. This fragmentation was holding the ecosystem back.
MCP (Anthropic, late 2024) provides a universal protocol for connecting AI agents to external tools and data sources. Define your tool once with an MCP schema, and any MCP-compatible agent can discover and use it. Think of it like USB for AI tools. Before USB, every device had its own proprietary connector. After USB, everything just worked together.
Google's A2A (Agent-to-Agent) protocol addresses a different problem: how agents from different systems communicate with each other. MCP connects agents to tools. A2A connects agents to other agents. Together, they are building the foundation for an interoperable agent ecosystem where agents from different vendors and frameworks can collaborate on complex tasks.
These protocols are still early. Adoption is growing but not universal. The important thing is not which specific protocol wins, but that the industry is moving from custom integrations to standardized interfaces. Build to the protocol, not to the framework, and your tools and agents will remain useful as the ecosystem evolves.
Multi-agent systems are powerful but dangerous. The more autonomous the agents, the more critical the safety mechanisms. Build guardrails first, capabilities second. Trust is earned incrementally, not granted upfront.
Try It in the Lab
Act 3 of the pipeline lab introduces multi-agent patterns. When you design systems with multiple Router components and specialized sub-pipelines, you are building the same kind of task decomposition that multi-agent frameworks use. The scoring system rewards proper delegation patterns and penalizes systems without appropriate human oversight.
Further Reading
- Wu et al. (2023): 'AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation'
- Anthropic MCP documentation (modelcontextprotocol.io)
- Google A2A protocol specification
- CrewAI documentation and examples
- OpenAI Code Interpreter system card for sandboxing patterns
