Agents Integration Patterns

A catalog of integration patterns for multi-agent AI systems — the missing vocabulary between Enterprise Integration Patterns and the agentic era.

License: CC BY 4.0 Contributions Welcome

Why This Exists

In 2003, Gregor Hohpe and Bobby Woolf published Enterprise Integration Patterns — a vocabulary of 65 named patterns that gave architects a shared language for connecting distributed systems. That book became the foundation of enterprise middleware, message brokers, and ESBs for over two decades.

In 2025, we are building a new class of distributed systems: networks of autonomous AI agents that collaborate to solve complex tasks. These agents communicate through protocols like Model Context Protocol (MCP) and Agent-to-Agent (A2A), orchestrated by frameworks like LangGraph, AutoGen, CrewAI, and Spring AI.

Yet we lack a shared vocabulary. Teams reinvent patterns with different names. Architecture reviews debate the same trade-offs without common terms. Papers exist that taxonomize the space (arXiv:2501.06322, arXiv:2502.14321, arXiv:2508.01186) but stop short of prescriptive, named patterns with intent, problem, and solution structure.

Computer science is cyclical. The same fundamental ideas resurface across decades under different names — message queues become event streams become agent channels; remote procedure calls become tool invocations; process managers become orchestrators. As new terms and frameworks multiply around LLM agents, the noise makes integration harder, not easier. This catalog was created to cut through that noise: to give teams a stable, reusable vocabulary for connecting agents to harnesses, models, and each other — regardless of which framework or protocol they use today.

This repository fills that gap.

It draws from:

  • Enterprise Integration Patterns (Hohpe & Woolf, 2003)
  • 12-Factor Agents (HumanLayer, 2025)
  • Google's A2A protocol specification
  • Anthropic's MCP specification (v2025-11-25)
  • Academic surveys on multi-agent LLM systems (2025–2026)

The Protocol Foundation

Before patterns, the two protocols that define the integration surface of modern agent systems:

Model Context Protocol (MCP) — Vertical Integration

"The USB-C port for AI"

MCP (Anthropic, 2024) is built on JSON-RPC 2.0, inspired by the Language Server Protocol. It standardizes how agents connect downward to tools, data sources, and resources.

MCP Protocol

What MCP provides: Tool invocation, resource access, prompt templates, sampling.

Agent-to-Agent (A2A) — Horizontal Integration

"The HTTP for agents"

A2A (Google, April 2025) enables agents to discover and delegate tasks to other agents without exposing internal state, memory, or tools. Discovery happens through Agent Cards — capability manifests served at /.well-known/agent.json.

A2A Protocol

What A2A provides: Agent discovery, task delegation, capability negotiation, multi-framework interoperability.

The Complementary Axis

Both protocols co-exist under the Linux Foundation's Agentic AI Foundation (AAIF) as of December 2025. They are not competitors:

Complementary Axis — A2A horizontal, MCP vertical

Security Note: Combining A2A and MCP introduces compounded risks — confusion, downgrade, and relay-abuse attacks arise because the two protocols operate under different trust assumptions. See Security Patterns. (arXiv:2505.03864, arXiv:2602.11327)

Two Engineering Disciplines

Building reliable agent systems requires two distinct disciplines that are easy to conflate but must be designed separately:

Discipline Focus Core question Failure symptom
Loop Engineering The iterative cycle an agent runs toward its goal What does the agent do each pass, and when does it stop? Runaway loops, premature stops, stalling
Harness Engineering Everything surrounding the agent — scaffolding, plumbing, infrastructure What can the agent access, and how does it operate safely? Production crashes, invisible failures, unrecoverable errors

Loop Engineering designs what happens inside each iteration: what tools are called, how progress is evaluated, what triggers the next cycle, and — most critically — the completion criteria. Vague exit conditions are the leading cause of loop failure: "the report is written" is not a criterion; "the report contains an executive summary, three supporting sections each with at least two data citations, and passes a relevance check" is.

Harness Engineering designs what happens around the loop: tool routing and credential management, memory and context handoffs, output pipelines, observability, error recovery, and security. A common failure mode is context pollution — accumulated errors and irrelevant information passing between sessions without pruning, degrading later iterations.

Pattern alignment

Loop Engineering patterns Harness Engineering patterns
Reflection Loop, LLM-as-Judge, Ensemble Judge Checkpoint & Resume, Circuit Breaker, Dead Letter Agent
Orchestrator, Choreography, Saga Exception Handler Chain, Idempotent Agent, Trust Boundary
Content-Based Router, Pipeline Blackboard, Context Injection, Tool Provider

Build sequence: establish the loop first (iteration logic, completion signal, basic failure handling), test with simplified inputs until behavior stabilizes, then add the harness. Building both together makes failures harder to attribute — did the wrong output come from faulty iteration logic or unsanitized tool data?

Source: MindStudio (2025). Loop Engineering vs Harness Engineering and What is Harness Engineering?

How to Read These Patterns

Each pattern follows this structure:

Field Description
Intent One-sentence purpose
Problem What forces this pattern resolves
Solution The structural approach
Diagram Visual representation
Consequences Trade-offs (forces resolved vs. introduced)
Known Uses Where this appears in production systems
Related Patterns What to use before/after/instead

Pattern Catalog

🔌 Messaging Patterns

These patterns govern how agents exchange information.

1. Direct Message

Intent: Send a task from one agent to exactly one other agent through a point-to-point channel.

Problem: An agent needs to delegate a specific subtask to another agent with known capabilities, without broadcasting to others.

Solution: Establish a dedicated channel between two agents. The sender pushes a structured message (task + context) to the receiver's endpoint. The receiver acknowledges receipt and returns a result.

Direct Message — Agent A sends Task Request to Agent B and receives Task Result

Consequences:

  • ✅ Simple, predictable, easy to trace
  • ✅ Low latency — no intermediary
  • ❌ Tight coupling — sender must know receiver's address
  • ❌ No load balancing or failover without additional infrastructure

Known Uses: A2A task delegation, LangGraph node-to-node edges, tool calls in ReAct agents.

Related Patterns: Agent Card Registry (for discovery), Supervised Delegation (for reliability).

See full pattern: patterns/messaging/direct-message.md

2. Broadcast Message

Intent: Send information from one agent to all interested agents simultaneously without knowing who they are.

Problem: An agent produces information (an observation, a state change, a completed subtask result) that multiple downstream agents need to act upon.

Solution: Publish the message to a shared channel or topic. Interested agents subscribe and react independently. The publisher has no knowledge of subscribers.

Broadcast Message — Agent A (Publisher) publishes to Agent B, Agent C, and Agent D simultaneously

Consequences:

  • ✅ Decoupled — publisher unaware of subscribers
  • ✅ Easily extensible — add agents without modifying publisher
  • ❌ No delivery guarantee without infrastructure
  • ❌ Risk of message storms if subscribers produce new messages

Known Uses: Event-driven CrewAI flows, AutoGen group chat broadcasts, Kafka-backed agent pipelines.

Related Patterns: Scatter-Gather (when you need results back), Choreography (event-driven coordination).

See full pattern: patterns/messaging/broadcast-message.md

3. Blackboard

Intent: Share a structured, mutable context space that multiple agents read from and write to asynchronously.

Problem: Multiple agents work on parts of the same problem. No single agent has the full picture, but they all need to read each other's intermediate results.

Solution: Maintain a shared "blackboard" — a structured key-value or document store. Agents read relevant state, contribute their results, and observe changes. An optional controller monitors the blackboard and triggers agents when relevant conditions are met.

Blackboard — shared context space read and written concurrently by Agent A, Agent B, and Agent C

Consequences:

  • ✅ Natural for parallel, loosely-coupled agents
  • ✅ Agents contribute at their own pace
  • ❌ Requires conflict resolution when agents write to same key
  • ❌ Hard to reason about causality without event ordering

Known Uses: AutoGen shared memory, multi-agent research workflows (e.g., multi-agent RAG with shared document store).

Related Patterns: Context Injection (for read-only context), Orchestrator (for centralized control).

See full pattern: patterns/messaging/blackboard.md

🗺️ Discovery Patterns

How agents find each other without hardcoded addresses.

4. Agent Card Registry

Intent: Allow agents to advertise their capabilities and be discovered by other agents at runtime without prior configuration.

Problem: In a dynamic multi-agent system, you cannot hardcode which agent handles which task. New agents join the system, capabilities change, and routing decisions need to happen at runtime.

Solution: Each agent publishes an Agent Card — a structured capability manifest — at a well-known endpoint (/.well-known/agent.json). A registry (or peer-to-peer discovery) indexes these cards. Agents query the registry for capabilities they need, then establish direct connections.

Agent Card Registry — Agent A queries registry for capability, discovers Agent B via Agent Cards, then connects directly

Consequences:

  • ✅ Dynamic composition — agents join/leave without reconfiguration
  • ✅ Capability-based routing
  • ❌ Registry becomes a single point of failure
  • ❌ Stale cards if agents don't update their capabilities

Known Uses: A2A Agent Cards specification, AWS Bedrock Agent Aliases, Azure AI Foundry agent catalog.

Related Patterns: Content-Based Router (routing after discovery), Agent Proxy (abstraction layer).

See full pattern: patterns/discovery/agent-card-registry.md

5. Agent Proxy

Intent: Provide a stable interface to an agent (or group of agents) while hiding implementation details, protocol differences, or versioning.

Problem: Consumers of an agent's capabilities should not need to know whether the agent is a single LLM call, a sub-graph of agents, an external API, or which protocol it speaks.

Solution: Introduce a proxy agent that presents a uniform interface. The proxy translates protocols (e.g., A2A ↔ MCP), routes to appropriate backend agents, and handles versioning.

Agent Proxy — Consumer Agent sends A2A to Agent Proxy, which forwards via A2A, MCP, or REST to backend agents

Consequences:

  • ✅ Decouples consumers from implementation
  • ✅ Enables A/B testing and gradual migration
  • ❌ Adds a network hop and latency
  • ❌ Proxy becomes a bottleneck if not stateless

Known Uses: LangGraph remote agent nodes, API gateway patterns for agent endpoints, MCP proxy servers.

Related Patterns: Agent Card Registry, Circuit Breaker.

See full pattern: patterns/discovery/agent-proxy.md

25. Broker

Intent: Dynamically match tasks to capability providers at runtime by selecting the best available candidate based on quality scores and load — going beyond a static registry lookup to active routing.

Problem: A static registry returns all agents with a matching capability but does not answer: which one should I call right now? When multiple providers exist, selection logic (load balancing, quality routing, version preference) gets duplicated across every caller.

Solution: A broker maintains a registry of providers with declared capabilities and quality scores. On each task, it filters by capability, ranks by score and load, routes to the best candidate, and updates scores based on outcomes. Callers express what they need; the broker decides who delivers it.

Consequences:

  • ✅ Callers decoupled from specific provider instances
  • ✅ Quality-aware routing improves average answer quality
  • ❌ Broker is a single point of failure and potential bottleneck
  • ❌ Quality scores require outcome feedback — adds instrumentation

Known Uses: MCP multi-server capability selection, LangChain tool selection (LLM-driven broker), Buschmann POSA1 Broker pattern, AWS API Gateway routing.

Related Patterns: Agent Card Registry (passive lookup; Broker is the active selector built on top of it), Circuit Breaker (Broker excludes providers the breaker has opened), Content-Based Router (routes by task content; Broker routes by provider quality).

See full pattern: patterns/discovery/broker.md

⚡ Context Patterns

How agents share, inject, and manage contextual information — inspired by MCP primitives.

6. Context Injection

Intent: Supply an agent with relevant external context (documents, database records, user state) before it reasons, without the agent needing to fetch it.

Problem: An agent's reasoning quality depends on context. Requiring agents to actively fetch every piece of context they need is slow, couples them to data sources, and often exceeds context window limits.

Solution: Before invoking an agent, a host or orchestrator retrieves relevant context from data sources (via MCP Resources) and injects it into the agent's prompt or message. The agent reasons over pre-assembled context.

Context Injection — MCP Resources feed into Context Assembler inside Host, which injects context into Agent before reasoning

Consequences:

  • ✅ Agents stay stateless and focused on reasoning
  • ✅ Context is controlled and auditable
  • ❌ Host must know what context is relevant (retrieval quality matters)
  • ❌ Large contexts consume tokens; retrieval must be precise

Known Uses: RAG pipelines, Anthropic's contextual retrieval, MCP Resources in Claude Desktop.

Related Patterns: Blackboard (shared mutable context), Tool Provider (active tool use vs. passive injection).

See full pattern: patterns/context/context-injection.md

7. Tool Provider

Intent: Expose capabilities (functions, APIs, data queries) to agents as invocable tools through a standardized interface.

Problem: Agents need to take actions in the world — query databases, call APIs, execute code, search the web. Hardcoding these capabilities into agents makes them brittle and non-reusable.

Solution: Wrap capabilities as MCP Tools with structured schemas. Agents discover available tools via the MCP tools/list endpoint and invoke them via tools/call. The tool provider handles execution and returns structured results.

Tool Provider — Agent issues tools/list and tools/call to MCP Tool Server exposing search_web, query_db, and run_code

Consequences:

  • ✅ Agents are decoupled from specific tool implementations
  • ✅ Tools can be versioned, replaced, or mocked independently
  • ❌ Tool schemas must be well-designed; poor schemas confuse LLMs
  • ❌ Tool explosion — too many tools degrades agent performance

Known Uses: MCP Tool Servers, LangChain Tools, OpenAI Function Calling.

Related Patterns: Context Injection, Least-Privilege Tool Scope.

See full pattern: patterns/context/tool-provider.md

🔀 Routing Patterns

How tasks are distributed across agents.

8. Content-Based Router

Intent: Route an incoming task to the appropriate agent based on the content, type, or attributes of the task itself.

Problem: A system receives diverse tasks that require different specialized agents. A human (or caller) should not need to know which agent handles which type of task.

Solution: A router agent examines the content, metadata, or intent of each incoming task and forwards it to the appropriate specialist agent. The router may use LLM-based intent classification, rule-based matching, or embedding similarity.

Content-Based Router — Incoming Task enters Router Agent (LLM classifier), routed to Coding Agent, Research Agent, or Data Agent

Consequences:

  • ✅ Single entry point for callers
  • ✅ Specialists can evolve independently
  • ❌ Router is a bottleneck and single point of failure
  • ❌ Classification errors misroute tasks

Known Uses: AWS Bedrock Supervisor mode, LangGraph conditional edges, semantic routing in CrewAI.

Related Patterns: Orchestrator (when routing is just the first step of coordination), Agent Card Registry (capability-based routing).

See full pattern: patterns/routing/content-based-router.md

9. Scatter-Gather

Intent: Send the same task to multiple agents in parallel, then aggregate their responses into a single coherent result.

Problem: Complex questions benefit from multiple independent perspectives. Sequential querying is slow. The best answer may require synthesizing diverse outputs.

Solution: A dispatcher sends the task to N agents simultaneously. Each agent processes independently. A gatherer/aggregator waits for responses, then synthesizes them — via voting, merging, or a synthesis agent.

Scatter-Gather — Dispatch fans out to Agent A, B, and C in parallel; all results flow into Aggregate

Consequences:

  • ✅ Parallel execution reduces latency vs. sequential
  • ✅ Multiple perspectives improve quality (useful for factual tasks)
  • ❌ N× token cost
  • ❌ Aggregation is non-trivial; requires a synthesis step

Known Uses: Multi-agent debate (Google DeepMind), parallel tool calls, ensemble agent evaluation.

Related Patterns: Orchestrator (coordinates the scatter-gather), Broadcast Message (when you don't need results back).

See full pattern: patterns/routing/scatter-gather.md

10. Pipeline

Intent: Pass a task through a sequence of agents, where each agent transforms or enriches the result before passing it to the next.

Problem: A complex task requires a series of transformations — each step depends on the previous result.

Solution: Chain agents as pipeline stages. The output of agent N becomes the input of agent N+1. Each agent has a focused responsibility.

Pipeline — Input passes through Agent A (Plan), Agent B (Execute), and Agent C (Verify) to produce Output

Consequences:

  • ✅ Clear separation of concerns; each agent is testable in isolation
  • ✅ Easy to insert, remove, or replace stages
  • ❌ Sequential — total latency = sum of all stages
  • ❌ Early errors propagate through all downstream stages

Known Uses: LangGraph linear graphs, CrewAI sequential process, Anthropic's "prompt chaining" workflow.

Related Patterns: Scatter-Gather (parallelize stages when independent), Checkpoint & Resume (for long pipelines).

See full pattern: patterns/routing/pipeline.md

🎭 Coordination Patterns

How multiple agents decide who does what.

11. Supervised Delegation

Intent: A supervisor agent decomposes a goal into subtasks, delegates each to a specialist agent, monitors execution, and intervenes on failure.

Problem: Complex goals exceed any single agent's capacity. Tasks need to be distributed, but the overall goal must remain coherent and failures must be handled.

Solution: The supervisor maintains the high-level plan, assigns tasks to worker agents (via Direct Message or A2A), monitors their progress, and retries, reassigns, or escalates on failure. The supervisor never executes domain tasks itself — it only coordinates.

Supervised Delegation — Supervisor Agent decomposes goal and delegates to Worker A, Worker B, and Worker C

Consequences:

  • ✅ Clear accountability; supervisor owns the goal
  • ✅ Fault tolerance — supervisor can retry or reassign
  • ❌ Supervisor is a bottleneck
  • ❌ Supervisor quality determines overall quality

Known Uses: AWS Bedrock Multi-Agent Supervisor, AutoGen GroupChatManager, LangGraph supervisor pattern.

Related Patterns: Orchestrator (lighter-weight, no monitoring loop), Circuit Breaker (for worker failures).

See full pattern: patterns/coordination/supervised-delegation.md

12. Orchestrator

Intent: A central coordinator defines the execution flow, sequences agent calls, and manages state — without monitoring individual agents at runtime.

Problem: A workflow requires coordinating multiple agents in a defined sequence, but you need a single place that defines the execution plan and holds shared state.

Solution: The orchestrator holds the workflow graph. It calls agents in sequence or parallel according to the plan, passes state between steps, and handles branching logic. Unlike a supervisor, it follows a pre-defined plan rather than dynamically deciding based on monitoring.

Orchestrator — central workflow executes step1→step2→step3 calling Agent A, Agent B, Agent C with centralized state

Consequences:

  • ✅ Predictable execution; easy to audit and test
  • ✅ Centralized state management
  • ❌ Orchestrator must be updated when workflow changes
  • ❌ Less adaptive than choreography for dynamic scenarios

Known Uses: LangGraph StateGraph, Azure Semantic Kernel planners, Anthropic's "orchestrator-subagents" pattern.

Related Patterns: Choreography (decentralized alternative), Supervised Delegation (when monitoring is needed).

See full pattern: patterns/coordination/orchestrator.md

13. Choreography

Intent: Agents coordinate through events without a central controller — each agent knows what to do when it receives a specific event.

Problem: Centralized orchestration creates bottlenecks and single points of failure. In high-scale or highly dynamic systems, you need agents to coordinate without depending on a coordinator being alive.

Solution: Each agent subscribes to events relevant to its role and publishes events when it completes. No agent knows the global flow — each only knows its own triggers and outputs. The workflow emerges from the interaction of locally-rational agents.

Choreography — task_created triggers Agent A, emitting data_extracted; Agent B reacts; Agent C emits done — no central coordinator

Consequences:

  • ✅ Highly decoupled — agents can be developed and deployed independently
  • ✅ No single point of failure
  • ❌ Global workflow is implicit; hard to understand and debug
  • ❌ Distributed transactions and compensation are complex

Known Uses: Kafka-based agent pipelines, CrewAI event-driven process, agent-based saga patterns.

Related Patterns: Orchestrator (centralized alternative), Dead Letter Agent (for unhandled events).

See full pattern: patterns/coordination/choreography.md

14. Peer-to-Peer Delegation (A2A)

Intent: An agent directly delegates a subtask to another agent through a capability-negotiated channel, without involving a central coordinator.

Problem: An agent discovers mid-execution that a subtask requires capabilities it does not possess. It needs to find and delegate to a capable peer without involving a supervisor.

Solution: Using Agent Card discovery, the agent identifies a peer with the required capability, establishes an A2A channel, sends the task, and awaits the result. The delegating agent resumes once the result is received.

Peer-to-Peer Delegation (A2A) — Agent A discovers Agent B via registry, then delegates task directly via A2A without a central coordinator

Consequences:

  • ✅ No coordinator needed; scales horizontally
  • ✅ Agents remain autonomous; can delegate dynamically
  • ❌ Discovery overhead per delegation
  • ❌ Trust must be established between every agent pair

Known Uses: Google A2A protocol, multi-agent Salesforce Agentforce flows.

Related Patterns: Agent Card Registry, Supervised Delegation (when a supervisor should control delegation).

See full pattern: patterns/coordination/peer-to-peer-delegation.md

15. Group Chat

Intent: Let multiple agents solve a problem or validate work by participating in a shared conversation thread, coordinated by a chat manager that decides who speaks next.

Problem: Some decisions require agents to react to each other, challenge claims, and converge. A fixed pipeline cannot capture this cross-talk, and parallel scatter-gather discards the back-and-forth that produces the insight.

Solution: A chat manager coordinates an accumulating conversation thread, deciding which agent responds next. The Maker-Checker loop is the canonical specialization: a maker proposes, a checker evaluates against acceptance criteria and either approves or returns specific feedback — the loop repeats under an iteration cap to prevent runaway threads.

Group Chat — chat manager drives a maker-checker loop between Maker and Checker agents

Consequences:

  • ✅ Captures cross-agent reasoning that pipelines and scatter-gather miss
  • ✅ Single accumulating thread is transparent and auditable; ideal for human-in-the-loop
  • ❌ Token cost and latency grow with turns × participants
  • ❌ Flow control degrades past ~3 agents; requires iteration caps

When to avoid: Real-time latency budgets, when a simpler pipeline already suffices, or when the chat manager has no objective way to decide the task is complete.

Known Uses: Microsoft Agent Framework Group Chat / Maker-Checker, AutoGen GroupChatManager, Google DeepMind multi-agent debate.

Related Patterns: Scatter-Gather (parallel, no cross-talk), Ensemble Judge (when discussion reduces to independent verdicts).

See full pattern: patterns/coordination/group-chat.md

16. Magentic Orchestration

Intent: Solve open-ended problems with no predetermined plan by having a manager agent build and continuously refine a task ledger in collaboration with specialized agents, adapting the plan as the context evolves.

Problem: A pre-defined plan (Orchestrator) cannot express a workflow whose very structure is unknown until work begins. Pure event-driven coordination gives no global view to reason about progress.

Solution: A manager agent maintains a task ledger — a living document of facts gathered, the current plan, completed steps, and open questions. It assigns tasks to specialists, incorporates their results, and re-plans each round. An iteration/stall limit prevents unbounded looping.

Magentic — manager maintains task ledger, re-plans each round, dispatches to registered specialists

Consequences:

  • ✅ Handles open-ended goals with no upfront plan — the only pattern that does
  • ✅ The task ledger keeps an emergent process inspectable
  • ❌ Non-deterministic: different runs may diverge; hard to test and reproduce
  • ❌ Highest operational complexity; demands strict stall/iteration limits

When to avoid: When the workflow can be specified in advance (use Orchestrator), regulated domains requiring reproducible runs, or when the problem decomposes into a known set of specialists.

Known Uses: Microsoft Magentic-One / Agent Framework, AutoGen Magentic orchestration.

Related Patterns: Orchestrator (fixed plan; use it whenever the plan is knowable), Supervised Delegation (monitored but pre-decomposed).

See full pattern: patterns/coordination/magentic.md

🛡️ Resilience Patterns

How agent systems fail gracefully and recover.

17. Dead Letter Agent

Intent: Route tasks that cannot be processed (failed, unroutable, or timed out) to a dedicated agent or human for inspection and resolution.

Problem: In any distributed system, some messages cannot be processed. Without a safety net, failed tasks are silently dropped.

Solution: Any unprocessable task is forwarded to a Dead Letter Agent — typically a human-in-the-loop interface, an alert system, or a queue for manual review. The dead letter agent logs the failure, notifies operators, and optionally enables reprocessing.

Dead Letter Agent — Agent A failure routes to Dead Letter Agent, which triggers Human review and alert queue

Consequences:

  • ✅ No silent data loss
  • ✅ Human-in-the-loop safety net
  • ❌ Requires monitoring and human attention
  • ❌ Dead letter volume is a system health signal that must be tracked

Known Uses: HITL patterns in Anthropic's agent cookbook, LangGraph interrupt/resume, CrewAI human-input tool.

Related Patterns: Circuit Breaker (prevent cascading failures), Checkpoint & Resume (retry from last known state).

See full pattern: patterns/resilience/dead-letter-agent.md

18. Circuit Breaker

Intent: Stop making calls to a failing agent or tool, allow recovery time, and automatically resume when it becomes healthy.

Problem: When an agent or tool dependency fails, continued retries amplify load, cascade failures, and consume resources without producing results.

Solution: Wrap calls to external agents/tools with a circuit breaker. After N consecutive failures, the circuit opens — all subsequent calls fail fast without attempting the downstream call. After a timeout, a probe call tests recovery. On success, the circuit closes.

Circuit Breaker — call enters Circuit Breaker: CLOSED passes to healthy Agent B, OPEN fast-fails, HALF-OPEN probes for recovery

Consequences:

  • ✅ Prevents cascade failures
  • ✅ Fast failure gives callers a chance to try alternatives
  • ❌ Requires tuning of thresholds and recovery timeouts
  • ❌ False positives may block healthy agents temporarily

Known Uses: Spring AI resilience patterns, LangChain RetryWithError, Temporal workflow retry policies.

Related Patterns: Agent Proxy (circuit breaker is often implemented in the proxy), Dead Letter Agent (route failures).

See full pattern: patterns/resilience/circuit-breaker.md

19. Checkpoint & Resume

Intent: Persist intermediate agent state so that long-running tasks can be paused and resumed without restarting from scratch.

Problem: Long agent workflows take minutes or hours. Network failures, context window limits, cost constraints, or human review requirements may interrupt execution. Restarting from zero is expensive and may produce inconsistent results.

Solution: After each significant step, serialize and persist the agent's state (memory, task progress, accumulated context). On failure or interruption, load the last checkpoint and resume from that point.

Checkpoint & Resume — Step 1 → Checkpoint → Step 2 → Checkpoint → Step 3, with resume arrow on failure pointing back to last checkpoint

Consequences:

  • ✅ Survives failures; enables long-horizon tasks
  • ✅ Enables human-in-the-loop review at checkpoints
  • ❌ Checkpoint storage and schema versioning complexity
  • ❌ Non-idempotent operations may produce duplicates on resume

Known Uses: LangGraph memory/persistence (SQLite/Postgres checkpointers), AWS Step Functions for agent workflows, 12-factor-agents principle "Own your control flow."

Related Patterns: Idempotent Agent, Dead Letter Agent.

See full pattern: patterns/resilience/checkpoint-resume.md

🔐 Security Patterns

How to establish trust, limit blast radius, and detect attacks in agent networks.

20. Least-Privilege Tool Scope

Intent: Grant each agent access only to the minimum set of tools and resources it needs to complete its task.

Problem: Agents with access to powerful tools (code execution, database writes, external APIs) can cause irreversible damage through prompt injection, misconfiguration, or bugs.

Solution: Define tool scopes at the MCP server level. Each agent receives a connection to an MCP server configured with only the tools relevant to its role. Scope is enforced at the MCP layer, not in the agent's prompt.

Least-Privilege Tool Scope — Research Agent connects to read-only MCP scope (search_web, read_document); Execution Agent connects to write MCP scope (write_file, run_code)

Consequences:

  • ✅ Limits blast radius of compromised or confused agents
  • ✅ Auditable: tool access is declared, not emergent
  • ❌ Requires upfront design of tool scope per agent role
  • ❌ Overly restrictive scopes block legitimate agent actions

Known Uses: Claude's MCP permission model, AWS IAM for agent roles, Anthropic's guidance on minimal footprint.

Related Patterns: Trust Boundary, Least-Privilege Tool Scope.

See full pattern: patterns/security/least-privilege-tool-scope.md

21. Trust Boundary

Intent: Explicitly define which agents trust which other agents, and at what level, preventing unauthorized task delegation or data access.

Problem: In a multi-agent system using A2A, an attacker (or a compromised agent) may attempt to impersonate a trusted agent or inject malicious tasks through agent-to-agent channels.

Solution: Define trust tiers explicitly. Agents verify the identity of callers via Agent Card authentication (OAuth/bearer tokens) before accepting tasks. Internal agents that call each other are in a higher trust z