MODULE 7 — Multi-Agent Systems, MCP, and A2A¶
7.1 Why Multi-Agent Architecture Exists¶
A single agent hits fundamental limits in three dimensions:
Context window limits. A complex task — analyze 500 contracts, audit all systems for compliance, coordinate a cross-functional project — exceeds what fits in one agent's context window. Breaking the task across specialized agents each with their own focused context is the structural solution.
Specialization limits. A general-purpose agent is a generalist. For tasks requiring deep domain expertise — a coding agent that specializes in test generation, a research agent that specializes in regulatory filings, a communication agent that specializes in customer-appropriate language — specialized agents outperform generalists by having tightly scoped prompts, tools, and knowledge bases.
Parallelism limits. A sequential agent handles one thing at a time. Multiple agents can run in parallel, reducing wall-clock time on workflows with independent subtasks from O(n) to O(max depth of dependency chain).
Multi-agent architecture is the solution to these three limits. It is also a source of new complexity, new failure modes, and new security risks that do not exist in single-agent systems. The architect's job is to apply multi-agent patterns where the benefits justify the costs — and to resist the temptation to use multi-agent because it sounds sophisticated.
7.2 Multi-Agent Communication: The Protocol Landscape¶
Before 2024, multi-agent communication was proprietary. Every framework — LangChain, AutoGen, CrewAI — had its own agent communication model. Agents from different frameworks could not communicate. Agents from the same framework could communicate only within that framework's abstractions.
Two open standards emerged in 2024–2025 that are changing this fundamentally:
- MCP (Model Context Protocol): How an agent accesses tools and data — agent-to-tool connectivity
- A2A (Agent-to-Agent Protocol): How one agent communicates with another agent — agent-to-agent coordination
Understanding both and when each applies is now a core architectural competency.
7.3 MCP: Model Context Protocol — Deep Dive¶
What MCP Solves¶
Before MCP, the enterprise AI integration problem looked like this:
N AGENTS × M TOOLS = N×M custom integrations
Agent 1 ── custom code ──► GitHub API
Agent 1 ── custom code ──► Slack API
Agent 1 ── custom code ──► Jira API
Agent 2 ── custom code ──► GitHub API (re-implemented)
Agent 2 ── custom code ──► Slack API (re-implemented)
Agent 3 ── custom code ──► GitHub API (re-implemented)
...
At 10 agents × 20 tools = 200 custom integrations to build and maintain.
Each one is a unique codebase, each one can break independently.
MCP solves this with a single protocol that any agent can use to connect to any tool:
WITH MCP:
GitHub MCP Server ◄──── MCP Protocol ────► Any MCP-compatible agent
Slack MCP Server ◄──── MCP Protocol ────► Any MCP-compatible agent
Jira MCP Server ◄──── MCP Protocol ────► Any MCP-compatible agent
10 agents × 20 MCP servers = 20 integrations (the MCP servers), not 200.
Any new agent automatically gets access to all 20 tools via the protocol.
Anthropic introduced MCP in November 2024. OpenAI officially adopted MCP in March 2025 — a watershed moment that effectively made it the industry standard. MCP was donated to the Agentic AI Foundation under the Linux Foundation in December 2025, ensuring vendor-neutral governance. As of April 2026, 78% of enterprise AI teams report at least one MCP-backed agent in production, and 92% of new agent frameworks released during 2025 and Q1 2026 ship with built-in MCP support.
The MCP Architecture¶
MCP uses a client-server architecture inspired by the Language Server Protocol (LSP):
MCP ARCHITECTURE
┌─────────────────────────────────────────────────────────────┐
│ MCP HOST │
│ (The application containing the agent: Claude Desktop, │
│ custom app, IDE, enterprise platform) │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ MCP CLIENT │ │
│ │ Lives inside the host. Manages connections to │ │
│ │ MCP servers. Handles protocol negotiation, │ │
│ │ authentication, capability discovery. │ │
│ └──────────────────┬───────────────────────────────────┘ │
│ │ MCP Protocol (JSON-RPC 2.0) │
└─────────────────────┼───────────────────────────────────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│MCP Server│ │MCP Server│ │MCP Server│
│ (GitHub) │ │ (Slack) │ │(Postgres)│
│ │ │ │ │ │
│ Tools: │ │ Tools: │ │ Tools: │
│ list_prs │ │ send_msg │ │ query │
│ create_pr│ │ read_ch │ │ describe │
│ │ │ │ │ │
│ Resources│ │ Resources│ │ Resources│
│ repos │ │ channels │ │ schemas │
│ │ │ │ │ │
│ Prompts │ │ Prompts │ │ Prompts │
│ pr_review│ │ announce │ │ sql_gen │
└──────────┘ └──────────┘ └──────────┘
MCP Primitives: What a Server Exposes¶
Tools — Actions the agent can invoke that have side effects:
{
"name": "create_pull_request",
"description": "Creates a pull request in the specified repository",
"inputSchema": {
"type": "object",
"properties": {
"repo": {"type": "string", "description": "Repository name"},
"title": {"type": "string"},
"body": {"type": "string"},
"base_branch": {"type": "string", "default": "main"}
},
"required": ["repo", "title", "body"]
}
}
Resources — Data the agent can read (no side effects):
Examples: file contents, database records, API responses,
email threads, calendar entries, code files
URI pattern: github://repos/myorg/myrepo/pulls
Prompts — Reusable prompt templates the server exposes:
Examples: "code_review_checklist", "sql_query_generator",
"incident_summary_template"
The agent can invoke these as structured starting points.
MCP Transport and the 2026 Scaling Challenge¶
MCP uses two transport mechanisms:
stdio transport (local): The MCP server runs as a subprocess. Communication is via standard input/output. Used by Claude Desktop, local development tools. Not suitable for production enterprise deployment — no horizontal scaling.
Streamable HTTP (remote): The MCP server runs as a web service. Communication via HTTP with Server-Sent Events. This unlocked remote MCP servers in 2025, but stateful sessions clash with modern cloud architectures. Servers holding session state in memory prevent straightforward horizontal scaling, force sticky routing, and complicate restarts. The 2026 MCP roadmap's primary focus is resolving this — stateless or near-stateless session models that work with standard load balancers.
Architectural implication: For production enterprise MCP deployments today, horizontal scaling of MCP servers requires session affinity (sticky sessions). Design for this now; plan for stateless sessions when the spec evolves.
MCP Security Architecture¶
MCP introduces security concerns that most teams under-address:
Tool scope and least privilege. An MCP server exposes every tool it has to every connected client. There is no built-in per-client tool scoping in the base MCP spec. An agent connected to the GitHub MCP server can call every tool that server exposes — including tools it should not have access to for its current task. Enterprise MCP deployments must implement authorization at the MCP server level, not rely on the agent's prompt to self-restrict.
Supply chain risk. As of 2026, enterprises increasingly put MCP proxies or gateways ("MCP firewalls") and governed server registries in front of agents to control which agents connect to which data sources. The specific threats these controls address are tool poisoning, "rug pulls" (tool definitions changing after approval), and cross-server tool shadowing. They are covered with controls in Module 9 §9.4. The OpenClaw/Clawdbot Skills architecture (Module 10) illustrates this: community-contributed Skills can install arbitrary packages and access system resources, and MCP servers carry the same kind of supply-chain risk. Enterprise MCP server deployment must have the same review process as any third-party software deployment.
MCP Governance Registry. For enterprise deployments, maintain a registry of approved MCP servers:
ENTERPRISE MCP SERVER REGISTRY
{
server_id: "github-mcp-v2.1",
vendor: "GitHub/Microsoft",
approved_by: "security-team",
approval_date: "2024-11-15",
security_review: "passed",
data_residency: "US",
tools_exposed: ["list_prs", "create_pr", "review_pr"],
tools_BLOCKED: ["delete_repo", "manage_team_members"],
approved_for_agents: ["code-review-agent", "release-agent"],
NOT_approved_for: ["customer-facing-agents"],
audit_log: "required",
last_reviewed: "2025-03-01"
}
Agents may only connect to servers in the registry. Connection attempts to unregistered servers are blocked at the network layer.
MCP Authentication. The MCP spec supports multiple authentication models. For enterprise, the patterns that matter:
- OAuth 2.0 with scoped tokens: The agent presents an OAuth token when connecting to an MCP server. The token scope limits which tools the agent can invoke. A code review agent's token grants access to
list_prsandreview_prbut notdelete_repo. This is the recommended approach for multi-tenant enterprise deployments. - mTLS (mutual TLS): Both the MCP client and server present certificates. Used for high-trust internal server-to-server communication where certificate management infrastructure already exists (e.g., Istio service mesh).
- API Keys: Simple but problematic at scale — key rotation requires coordination, key sharing between agents defeats per-agent access control. Avoid for production multi-agent systems.
MCP Server Cards. A 2026 MCP roadmap initiative standardizes server discovery via a metadata format served at /.well-known/mcp-server-card.json. This allows registries, browsers, and orchestrators to discover what an MCP server exposes without establishing a live connection. Enterprise MCP governance registries should populate from Server Cards rather than manual registry entries.
7.4 A2A: Agent-to-Agent Protocol — Deep Dive¶
What A2A Solves¶
MCP solves agent-to-tool connectivity. It does not solve agent-to-agent coordination. In a multi-agent system where Agent A needs to delegate a task to Agent B — potentially built by a different team, running on a different framework, deployed on a different cloud — there was no standard before A2A.
Google released the Agent-to-Agent (A2A) protocol in April 2025 as an open protocol that enables AI agents built by different vendors to discover each other, delegate tasks, and coordinate work across enterprise systems. It uses HTTP, Server-Sent Events, and JSON-RPC 2.0 for transport, and Agent Cards for capability advertisement.
A2A reached v1.0 in early 2026 with added support for gRPC, signed Agent Cards, and multi-tenancy. As of 2026, both MCP and A2A are governed by the Agentic AI Foundation (AAIF) under the Linux Foundation, with 146 member organizations including Anthropic, Google, OpenAI, Microsoft, and AWS.
The MCP vs. A2A Distinction (Critical)¶
MCP: Agent ──────────────────────────► Tool/Data Source
(How an agent gets information and takes actions)
A2A: Agent ──────────────────────────► Agent
(How one agent delegates tasks to another agent)
ANALOGY:
MCP is plumbing — it connects an agent to the resources it needs.
A2A is the communication network — it connects agents to each other.
Most production multi-agent systems need both:
Agent A uses MCP to access its tools (GitHub, Slack, database)
Agent A uses A2A to delegate subtasks to Agent B (specialized analyst)
Agent B uses MCP to access its tools (different tools, different scope)
The A2A Architecture¶
A2A ARCHITECTURE
AGENT DISCOVERY:
Every A2A-compatible agent publishes an Agent Card:
GET /.well-known/agent-card.json
Agent Card example:
{
"agent_id": "data-analysis-agent-v2",
"name": "Financial Data Analysis Agent",
"description": "Specializes in financial statement analysis and ratio computation",
"capabilities": ["financial_analysis", "ratio_computation", "trend_detection"],
"input_types": ["financial_statement", "csv", "json"],
"output_types": ["analysis_report", "json"],
"supported_tasks": ["analyze_financials", "compute_ratios", "detect_anomalies"],
"authentication": {"type": "oauth2", "scopes": ["agent.invoke"]},
"endpoint": "https://agents.internal/financial-analyst/v2"
}
TASK DELEGATION:
Agent A → POST /tasks/delegate to Agent B's endpoint
{
"task_id": "uuid",
"task_type": "analyze_financials",
"input": {financial_statement_data},
"requester": "orchestrator-agent-v1",
"requester_auth": {jwt_token},
"callback_url": "https://agents.internal/orchestrator/v1/callbacks/task123",
"deadline": "2024-03-15T16:00:00Z"
}
TASK LIFECYCLE:
submitted → working → [input_required] → completed | failed | cancelled
Agent B can pause and request more input from Agent A
(the input_required state handles human-in-the-loop at agent boundaries)
Agent B streams progress updates via SSE during long-running tasks
COMPLETION:
Agent B → POST to callback_url
{
"task_id": "uuid",
"status": "completed",
"result": {analysis_report},
"metadata": {"processing_time_ms": 3420, "model_used": "..."}
}
Trust in A2A: The Critical Design Question¶
When Agent A delegates to Agent B, what does Agent B trust? This is the most important security question in multi-agent architecture.
A2A TRUST LEVELS
SCENARIO 1: Same organization, internal agents
Trust model: Internal PKI or shared OAuth provider
Agent B trusts Agent A's JWT signed by the internal auth service
Agent B grants Agent A's requests based on Agent A's registered capabilities
Risk level: Medium (agents still bounded by their own auth scope)
SCENARIO 2: Different organizations (external agent delegation)
Trust model: Mutual TLS + signed Agent Cards + OAuth
Agent B must verify Agent A's identity independently
Agent B must enforce its own authorization — it cannot trust
Agent A's claim that the human authorized this action
Agent B should log all external agent interactions with full context
Risk level: High — external agents are equivalent to third-party API callers
SCENARIO 3: Agent acting on behalf of a human user
Trust model: The human's authorization token must chain through
all agents in the delegation path
Agent B must receive proof that the HUMAN (not just Agent A) authorized
the action that Agent B is performing
Delegated auth chains: Human → Agent A → Agent B
Each delegation step reduces permissions (never elevates them)
Risk level: Depends on action scope, mitigated by auth chaining
The elevation attack. The most dangerous multi-agent trust failure: Agent B trusts Agent A's instructions at Agent A's trust level, even though Agent B should be operating under the human's (lower) trust level. An orchestrator agent that has elevated permissions should never be able to cause a sub-agent to act with those elevated permissions on behalf of a low-privilege user. The trust model must prevent permission elevation through delegation chains.
7.5 Multi-Agent Architecture Patterns¶
Pattern 1: Orchestrator / Sub-Agent¶
ORCHESTRATOR / SUB-AGENT PATTERN
[Orchestrator Agent]
- Owns the goal
- Manages task decomposition
- Coordinates sub-agents
- Aggregates results
- NOT a domain specialist
│
┌──────────────┼──────────────┐
▼ ▼ ▼
[Sub-Agent A] [Sub-Agent B] [Sub-Agent C]
Data Retrieval Analysis Communication
- Knows how to - Knows how to - Knows how to
get data analyze data draft messages
- Limited tool - Limited tool - Limited tool
scope scope scope
Key architectural decisions: - The orchestrator does not have direct tool access to the sub-agents' domains - Sub-agents do not communicate with each other — all communication flows through the orchestrator - The orchestrator is responsible for synthesizing results, not the sub-agents - Sub-agents are stateless — they receive a task, return a result, done
When to use: Workflows with a clear top-level goal that decomposes into specialized subtasks with no interdependencies between specializations.
Pattern 2: Supervisor / Worker¶
Similar to orchestrator/sub-agent but with explicit quality control:
SUPERVISOR / WORKER PATTERN
[Supervisor Agent]
- Assigns tasks to workers
- Evaluates worker outputs
- Requests revisions
- Routes to specialized workers based on task type
│
┌────┴────────────────────────┐
▼ ▼
[Worker A] ←── [Supervisor] [Worker B]
Generates Reviews & Revises
Routes
Use case: Content generation workflows where quality review is embedded in the process. Legal document drafting where a specialized reviewer agent checks compliance before output is returned.
Pattern 3: Peer-to-Peer / Debate¶
PEER-TO-PEER / DEBATE PATTERN
Agent A (Analyst) ◄──── debate ────► Agent B (Devil's Advocate)
│ │
└──────────► [Synthesis Agent] ◄───────┘
(or human reviewer)
Use case: High-stakes decision support where multiple independent perspectives improve decision quality. Investment thesis validation, risk assessment, policy analysis. Not for production workflows at scale — expensive and slow.
Pattern 4: Swarm / Parallel Execution¶
SWARM PATTERN (Parallel independent workers)
[Task Dispatcher]
│
┌────┼────┬────┬────┐
▼ ▼ ▼ ▼ ▼
[W1] [W2] [W3] [W4] [W5] ← Independent workers, same task type
Different data partitions
└────┴────┴────┴────┘
│
[Aggregator]
Combines results
Use case: High-volume document processing where 500 contracts need to be processed and each contract is independent. Workers process in parallel, aggregator synthesizes. The classic map-reduce pattern applied to AI workloads.
Architectural requirement: Each worker must be stateless and idempotent. Aggregation logic must handle partial results gracefully (some workers may fail or timeout).
7.6 State Management in Multi-Agent Systems¶
State management is where most multi-agent systems break. Every agent has its own context. The state of the overall workflow is distributed across those contexts. Without a disciplined state management architecture, the system is brittle and impossible to debug.
The State Management Principle¶
Agent state is local. Workflow state is external.
An agent's context window is local, ephemeral, and scoped to its current invocation. The state of a multi-agent workflow — what has been done, what is in progress, what remains, what has failed — must live in an external store that survives individual agent failures and is accessible to any agent in the system.
MULTI-AGENT STATE ARCHITECTURE
EXTERNAL WORKFLOW STATE STORE (Redis, Postgres, Temporal):
{
workflow_id: "wf-abc123",
goal: "Process Q4 financial audit",
status: "in_progress",
phases: {
data_collection: {status: "completed", result_ref: "s3://results/wf-abc123/data"},
analysis: {status: "in_progress", assigned_to: "agent-analysis-v2", started_at: "..."},
review: {status: "pending"},
report: {status: "pending"}
},
agent_assignments: {
"agent-analysis-v2": {
task: "analyze_financial_data",
input_ref: "s3://results/wf-abc123/data",
started_at: "2024-03-15T10:00:00Z",
deadline: "2024-03-15T12:00:00Z"
}
},
audit_trail: [
{"event": "workflow_started", "timestamp": "...", "actor": "orchestrator"},
{"event": "phase_data_collection_completed", "timestamp": "...", "result_ref": "..."},
{"event": "analysis_agent_assigned", "timestamp": "...", "agent": "agent-analysis-v2"}
]
}
Why this matters: If the analysis agent fails at 60% completion, the orchestrator can inspect the external state, determine what was completed, resume from the last checkpoint (not from the beginning), and assign the remaining work to a new agent instance. Without external state, the workflow restarts from scratch on every failure.
7.7 Emergent Behavior: The Hardest Problem¶
Emergent behavior is when a multi-agent system produces outcomes that were not designed or intended, arising from the interactions between agents rather than from any individual agent's behavior.
This is not theoretical. It occurs in production multi-agent systems.
How Emergent Behavior Manifests¶
Feedback loops. Agent A produces output that influences Agent B's behavior. Agent B's output influences Agent A's next invocation. The agents converge on a behavior not intended by either's design.
Goal misalignment amplification. A small bias in one agent's prompt gets amplified as it propagates through the system. Agent A has a slight tendency to emphasize risk. Agent B, receiving Agent A's output, interprets it through its own analysis lens. The final output dramatically overweights risk in a way no individual agent was designed to produce.
Prompt injection propagation. An injection attack against one agent produces output that injects into the next agent. Each agent amplifies the effect as it interprets and acts on the injected instruction.
Resource competition. Multiple agents competing for the same tool (a database, an API with rate limits) create unexpected serialization and retry patterns that produce non-deterministic workflow behavior.
Detection and Mitigation¶
EMERGENT BEHAVIOR CONTROLS
Detection:
├── Workflow outcome distribution monitoring
│ If the distribution of outcomes shifts (more escalations,
│ different risk ratings, changed recommendations),
│ investigate the interaction patterns — not just individual agent outputs
│
├── Agent interaction graph visualization
│ Map: which agents receive output from which other agents?
│ Visualize the data flow. Unexpected feedback loops become visible.
│
├── Output diversity monitoring
│ Track variance in outputs for similar inputs.
│ Low variance that increases suddenly = convergence on unexpected behavior.
│ High variance that wasn't there before = instability.
│
└── Red team exercises
Design scenarios specifically to test whether the multi-agent system
produces unexpected behaviors under adversarial or edge-case conditions.
Mitigation:
├── Typed inter-agent contracts
│ Agents receive structured schema objects, not free-form text.
│ A schema cannot carry emergent amplification the way natural
│ language can. The structure constrains the signal.
│
├── Agent output auditing before propagation
│ High-stakes workflows: a validation step checks agent output
│ against expected ranges before it is passed to the next agent.
│ Outliers trigger human review, not automatic propagation.
│
└── Deliberate simplicity
Minimize the number of inter-agent connections.
Each connection is an emergent behavior pathway.
The simplest multi-agent topology that accomplishes the goal
is the most governable one.
7.8 Cost and Latency Modeling for Multi-Agent Systems¶
Multi-agent systems multiply cost and latency relative to single-agent systems. This is not always appreciated upfront.
The Multiplication Effect¶
COST MODEL: SINGLE AGENT VS. MULTI-AGENT
Single Agent Task:
LLM calls: 5
Tokens per call: 2,000 (avg)
Total tokens: 10,000
Cost at $3/M tokens: $0.030
Multi-Agent (5 agents, 3 calls each):
LLM calls: 15 (3x)
Tokens per call: 3,000 (avg — agents receive prior agent context)
Total tokens: 45,000 (4.5x)
Cost at $3/M tokens: $0.135 (4.5x single agent cost)
At 10,000 tasks/month:
Single agent: $300/month
Multi-agent: $1,350/month
Delta: $1,050/month
Question the architect must answer: Does the quality/capability improvement
from multi-agent justify $1,050/month in additional cost?
If not: redesign as a single agent with more focused prompt.
Latency Modeling¶
LATENCY MODEL: SEQUENTIAL VS. PARALLEL MULTI-AGENT
Sequential (each agent waits for the prior):
Agent A: 3s
Agent B: 4s (waits for A)
Agent C: 2s (waits for B)
Total: 9s
Parallel (independent agents run simultaneously):
Agent A: 3s ─────────────────────┐
Agent B: 4s ──────────────────────┤ run in parallel
Agent C: 2s ─────────────┐ │
Aggregator: 1s └──────┘ (waits for all)
Total: max(3, 4, 2) + 1 = 5s
Parallelism savings: 9s → 5s (44% reduction)
Constraint: Only possible where agents are independent.
Define dependencies explicitly. Parallelize everything that can be.
7.9 The OpenClaw / Clawdbot Architecture: An Architectural Case Study¶
OpenClaw (also known as Clawdbot, briefly Moltbot) is an open-source, self-hosted personal AI agent that became architecturally significant in early 2026 for two reasons: its architectural approach and its security vulnerabilities.
The Architecture¶
OpenClaw operates through a lightweight local gateway that manages communication, tools, and persistent state. This gateway runs as a background service, handling incoming messages while orchestrating LLM-powered responses and actions. It features persistent sessions with long-term memory stored locally, a tool integration layer with modular Skills written in TypeScript/JavaScript, and a proactive engine using cron jobs, webhooks, and heartbeat checks for autonomous behavior.
OPENCLAW ARCHITECTURAL PATTERN
User (via WhatsApp/Telegram/Slack)
│
▼
[Gateway] — central orchestration layer
├── WebSocket/HTTP communication
├── Session and state management
├── Agent runner (MCP-based tool execution)
└── Channel adapters (normalize messaging platforms)
│
▼
[MCP Tool Layer] — Skills system
├── Built-in tools: shell, file system, web browsing
├── Community Skills (from ClawdHub)
└── Custom Skills (user-built)
│
▼
[LLM Backend] — Claude or OpenAI API
(reasoning happens in cloud, execution on your machine)
The Architectural Lessons¶
Lesson 1: MCP-first architecture is the right approach. OpenClaw built its tool integration on MCP before MCP was the industry standard. Every tool is an MCP server. The agent communicates with tools through the MCP protocol. This is now the production best practice — the architecture was ahead of the curve.
Lesson 2: The Skills supply chain is the attack surface. The Skills system powers OpenClaw's extensibility through community-contributed modules. Skills can arbitrarily provide instructions and references to packages to install from various registries. Snyk's 2026 "ToxicSkills" audit scanned thousands of skills from the public registries that power OpenClaw (ClawHub and skills.sh) and reported a substantial share with serious security issues, including credential-exposure paths (reported; the audit covers the skills ecosystem, not OpenClaw's own code).
The architectural lesson: extensibility systems (Skills, plugins, connectors, MCP servers) must be treated as third-party software supply chains. "Community-contributed" does not mean "reviewed." An enterprise deploying OpenClaw-style agent architectures must: - Require security review before any third-party Skill/plugin is deployed - Sandbox Skill execution (no direct host system access) - Scope tool permissions explicitly (a Skill for calendar management should not have file system access) - Monitor Skill behavior in production (unusual network calls, unexpected file access)
Lesson 3: Shell access + LLM = maximum blast radius. OpenClaw's ability to execute shell commands directly means a successful prompt injection attack yields arbitrary code execution on the host machine. This is the highest possible blast radius for an agent system. For enterprise deployments: - Agents should never have direct shell access - Command execution must go through sandboxed environments (Docker containers, isolated VMs) - The principle is: the agent calls a tool API, the tool executes in isolation, the result returns to the agent
Lesson 4: Messaging-as-interface is powerful and ungoverned. OpenClaw integrates with WhatsApp, Telegram, Slack — your messaging apps become command interfaces to a system with local machine access. For enterprise, this pattern is attractive (employees can interact with AI agents through tools they already use) and dangerous (the same channels may be used for social engineering). The enterprise deployment must enforce: agent commands accepted only from verified, authenticated sources, not from any message in a channel.
7.10 When Multi-Agent Is the Wrong Answer¶
The most valuable architectural guidance on multi-agent systems is often knowing when not to use them.
MULTI-AGENT ANTI-PATTERNS
Anti-pattern 1: Decomposing a simple task
BAD: "Summarize this document" → orchestrator → reader agent →
summarizer agent → formatter agent → output
RIGHT: One LLM call with a clear prompt.
Test: If a capable person could do this in one step, one agent can too.
Anti-pattern 2: Multi-agent for parallelism that isn't parallel
BAD: Three agents that all need the previous agent's output before
they can start — this is sequential, not parallel.
RIGHT: Evaluate the actual dependency graph. Parallelism only
helps where agents can genuinely work simultaneously.
Anti-pattern 3: Adding agents to fix a prompt problem
BAD: Single agent produces poor quality output → add a critic agent
→ add a revision agent → add a validation agent.
RIGHT: Diagnose why the single agent produces poor output.
Multi-agent critic chains are expensive. A better prompt
or a better model is usually cheaper and more reliable.
Anti-pattern 4: Agent proliferation without governance
BAD: "We have 47 agents now. Most of them were created for specific
projects and nobody is sure what they all do."
RIGHT: Every agent has an owner, a versioned definition, and a
registered purpose. Agents are deleted when the use case
they served is no longer active.
Anti-pattern 5: Multi-agent for the appearance of sophistication
This is real. Teams build multi-agent architectures because they
sound more impressive than single-agent systems. The cost is higher,
the failure modes are more complex, and the governance burden is greater.
Build the simplest architecture that achieves the goal.
Complexity is a liability, not an asset.
7.11 Production Readiness Checklist for Multi-Agent Systems¶
Protocol and Integration - [ ] Tool integration uses MCP (not custom per-tool implementations)? - [ ] Agent-to-agent communication uses A2A or equivalent typed protocol? - [ ] MCP servers registered in enterprise governance registry? - [ ] Third-party MCP servers reviewed before deployment?
Trust and Security - [ ] Trust level assigned to every inter-agent message (internal/external)? - [ ] Permission elevation through delegation chains impossible by design? - [ ] Agent identity separate from user identity for audit purposes? - [ ] Injection sanitization at every agent boundary? - [ ] MCP server tool scope restricted to minimum necessary per agent?
State and Reliability - [ ] Workflow state external (not in any individual agent's context)? - [ ] Agent failures isolated (one agent failure doesn't cascade)? - [ ] Idempotency keys used for all stateful operations? - [ ] Partial completion recoverable (resume, not restart)?
Cost and Performance - [ ] Cost model documented: expected LLM calls, tokens, cost per workflow? - [ ] Dependency graph analyzed: what can parallelize, what must sequence? - [ ] Per-workflow cost ceiling enforced? - [ ] Agent proliferation governed: owner and purpose for every agent?
Observability - [ ] Inter-agent message log: who sent what to whom? - [ ] Workflow state transitions logged with triggering conditions? - [ ] Emergent behavior detection: outcome distribution monitoring? - [ ] Cost and latency per workflow type tracked with alerts?
EXERCISE — MCP Server Portfolio Design: Your organization has 3 AI agents: a customer support agent, a code review agent, and a data analysis agent. Each currently has custom integrations to 5 tools. Design the MCP server portfolio: which tools become MCP servers, which servers are shared across agents, which are agent-specific, and what the governance registry entry looks like for each server.
PONDER — The Trust Chain: In your current or planned multi-agent system, trace the complete authorization chain for the most privileged action any agent can take. Who authorized it originally? How does that authorization evidence propagate through agent handoffs? At each handoff: is it possible for permissions to be elevated? If yes, that is your highest-priority security architecture gap.
WORKSHOP — Multi-Agent vs. Single Agent Decision: Take a complex business workflow that a team in your organization is planning to build as a multi-agent system. Apply the anti-patterns from Section 7.10. Determine whether multi-agent is genuinely necessary. If it is: draw the agent topology, define the trust model, and model the cost vs. a single-agent alternative. If it isn't: redesign as a single agent with more focused prompting and compare the cost, latency, and operational complexity.
WORKSHOP — MCP + A2A Architecture Design: Design a multi-agent financial analysis system using both MCP and A2A. Agent A (orchestrator) delegates to Agent B (data retrieval) and Agent C (analysis). Agent B uses MCP to access financial databases. Agent C uses MCP to access calculation tools. Agents communicate via A2A. Draw the complete architecture: MCP servers, A2A endpoints, Agent Cards, trust model, and the audit trail. Identify every point where a security failure could occur.
Next: Module 8 — Copilot Ecosystem and Skills Architecture