Multi-Agent Architecture Patterns with Amazon Bedrock AgentCore Runtime
A practical guide to deploying multi‑agent architectures on Amazon Bedrock AgentCore Runtime, covering Agents‑as‑Tools (subagents), Agent‑as‑MCP, and Agent‑to‑Agent (A2A) patterns with guidance on runtime topology, security boundaries, and shared context.
As more teams move from "single smart assistant" to modular, multi-agent systems, a recurring architectural question emerges:
How should we deploy agents on Amazon Bedrock AgentCore Runtime?
This post maps common multi-agent collaboration patterns to runtime topology decisions (single Runtime vs. multiple Runtimes), covering Agents-as-Tools (subagents), Agent-as-MCP, and Agent-to-Agent (A2A) protocol.
There is no single correct architecture. The goal is to provide a decision framework you can adapt to your workloads.
Amazon Bedrock AgentCore Runtime at a glance
Amazon Bedrock AgentCore Runtime is the managed environment for running AI agents and tools. Key capabilities include:
- A managed, container-based runtime compatible with any agent framework and any model
- Support for both real-time and long-running agent workloads
- Built-in authentication (SigV4, OAuth 2.0), session isolation, and tool execution
- First-class hosting of MCP servers, enabling agents and tools to be exposed as MCP endpoints
- Native support for the A2A protocol for agent-to-agent collaboration
AgentCore Runtime is framework-agnostic and model-agnostic. You can host agents built with Strands Agents , LangGraph, Claude Agent SDK, Google ADK, OpenAI Agents SDK, or any custom framework — all within the same managed infrastructure. On the managed-agents side, Amazon Bedrock Agents supports multi-agent collaboration, where a supervisor agent coordinates one or more collaborator agents for multi-step tasks.
Core question: single Runtime vs. multiple Runtimes?
An AgentCore Runtime is a deployment unit — one
CreateAgentRuntime resource running one container image. Because AgentCore Runtime uses a single container (not a pod or task with multiple containers as in Amazon EKS or Amazon ECS), follow standard container best practices: run a single process and rely on your agent SDK to manage subagent invocation within that process.Within that container, the main agent process can invoke subagents through SDK-level calls. The first design decision is how many of these deployment units your architecture requires.
Single Runtime, multiple agents — The main agent and its subagents run within the same container process. Each subagent is invoked through the SDK (for example, as a tool call that spawns a subagent instance). Because subagents share the main agent's resources — RAM, CPU, storage, and OS namespace — collaboration is in-process with no network overhead. This topology is best for low-latency, tightly-coupled flows and rapid iteration.
Multiple Runtimes, one or few agents each — Each specialized agent is deployed as its own AgentCore Runtime, invoked over the network (
InvokeAgentRuntime API, MCP, or A2A). This topology is best for isolation, independent scaling, cross-team ownership, and cross-framework interoperability.In practice, most production systems end up hybrid: a supervisor agent plus a few lightweight helpers co-located in a single Runtime, with several heavy or shared agents deployed as separate Runtimes.
Context boundaries. Whether in-process or remote, each subagent invocation starts with a fresh context by default. The subagent does not automatically inherit the parent agent's conversation history or state. If you need a subagent to operate within the parent's context, use the mechanisms provided by your chosen SDK — such as passing conversation summaries, shared memory references, or explicit context injection.
The sections below explore how each collaboration pattern maps to these topology choices.
Pattern 1: Agents-as-Tools (subagents)
What it is
An orchestrator agent calls subagents as tools — each subagent runs an agentic loop internally and returns a result synchronously in a request/response style. This pattern is implemented by running a framework that supports subagents (such as Strands Agents, LangGraph, or Claude Agent SDK) inside a single AgentCore Runtime. The orchestrator invokes a subagent the same way it invokes any tool: it selects the tool, passes parameters, and receives a result. Because a subagent is exposed as a tool, it can define typed parameters that the orchestrator uses when invoking it — for example, a
query string, a language enum, or a max_results integer — giving the orchestrator structured control over the subagent's behavior.When to choose this pattern
Choose Agents-as-Tools when subagents are tightly coupled to the orchestrator's lifecycle, latency must be minimal, and a single team owns the full codebase.
Pros
- Minimal operational overhead — one Runtime to build, deploy, and observe.
- Simple mental model: "call this tool, get a result."
- Easy to iterate on prompts, tools, and subagent behavior in a single codebase.
Cons
- Shared blast radius: one misbehaving subagent can exhaust tokens or crash the process.
- Scaling is bounded by a single Runtime's concurrency and resource allocation.
- Harder to enforce strict security boundaries between subagents — for example, all subagents share the same filesystem, network access, and IAM permissions.
Remote agent patterns
When you move beyond a single Runtime, agents communicate over the network rather than through in-process calls. This shift — from in-process to remote invocation — unlocks several shared benefits regardless of which remote protocol you choose:
- Isolation: each agent runs in its own container with independent scaling, resource allocation, and failure boundaries.
- Cross-team ownership: different teams can develop, deploy, and version their agents independently.
- Cross-framework and cross-language compatibility: agents can be built with different SDKs and programming languages.
- Heterogeneous compute: assign GPU instances to a vision agent while running a retrieval agent on CPU-optimized instances.
The two primary protocols for remote agent invocation on AgentCore are MCP and A2A. They solve different problems and introduce different trade-offs, described below.
Pattern 2: Agent-as-MCP
What it is
AgentCore Runtime can host MCP servers . In the Agent-as-MCP pattern, the MCP server is not merely a thin wrapper around a database query or API call — it embeds a full agent behind one or more MCP tool endpoints. When a caller invokes a tool on this MCP server, the request triggers a complete agentic loop on the server side: the remote agent plans, reasons, calls its own tools, and iterates until it produces a result. This is what distinguishes Agent-as-MCP from a standard MCP tool call, where the server executes a single, deterministic action and returns.
An Agent-as-MCP server can structure its interface in two ways:
- Single broad tool: the server exposes one tool (for example,
handle_customer_request) and routes all invocations into a single agentic loop that decides how to fulfill the request.
- Multiple specialized tools: the server exposes several focused tools (for example,
process_refund,check_order_status,update_payment_method), each backed by its own agentic loop scoped to that domain.
In both cases, every tool call performs a full agentic loop cycle — the remote agent reasons about the request, selects its internal tools, and iterates to produce a result.
Runtime topology
Each Agent-as-MCP server typically runs in its own AgentCore Runtime. The orchestrator can connect to it in two ways:
- Through AgentCore Gateway : the recommended approach for production. Gateway provides a centralized layer for authentication, authorization, observability, semantic tool discovery, and policy enforcement across all MCP server targets. Gateway discovers the MCP server's tools via the
SynchronizeGatewayTargetsAPI and exposes them through a unified catalog.
- Direct Runtime invocation: calling the MCP server's Runtime endpoint directly via the
InvokeAgentRuntimeAPI. This approach is simpler but requires you to manage authentication, discovery, and routing yourself. It can be appropriate during development or for tightly scoped internal integrations.
When to choose Agent-as-MCP
- A capability requires strong isolation or a separate lifecycle (sensitive data, regulated system).
- Multiple teams or products need to reuse the same capability from different orchestrators.
- You want to stay in the "agent + tool" interaction model (the caller selects a tool by name and passes typed parameters) while gaining the benefits of remote invocation.
Pros
- Stronger isolation — crashes or resource spikes in the MCP agent do not affect the caller.
- Cross-language and cross-stack compatibility — any MCP client can invoke the agent.
- Natural fit when different teams own different capabilities (for example, a "Billing" MCP server and a "Compliance" MCP server).
- Gateway integration provides centralized auth, observability, and semantic tool discovery.
Cons
- More moving parts to operate — multiple MCP servers, and optionally a Gateway configuration.
- Increased latency and cost per call due to network and serialization overhead.
- Still tool-oriented: the caller must know the tool name and provide structured parameters. Discovery is handled by Gateway's catalog or by static configuration.
Pattern 3: Agent-to-Agent (A2A) protocol
What it is
Amazon Bedrock AgentCore AgentCore Runtime lets you deploy and run Agent-to-Agent (A2A) servers in the AgentCore Runtime. The A2A protocol standardizes how agents discover, describe, and communicate with each other across Runtimes, frameworks, and clouds. It uses JSON-RPC 2.0 over HTTPS, with streaming support via Server-Sent Events (SSE).
Key concepts:
- Agent Card — each agent exposes a JSON document at
/.well-known/agent-card.jsonthat describes:
- Basic information: name, description, service URL, provider, version, and documentation link
- Capabilities: supported features such as streaming, push notifications, and state transition history
- Authentication: required schemes (for example, Basic, Bearer) and credential information
- Default interaction modes: supported input and output MIME types
- Skills: specific capability units the agent can perform, each with a unique ID, name, description, tags, example prompts, and optionally skill-specific input/output modes
- Task-based interaction — rather than invoking a named tool with structured parameters (as in MCP), the caller sends a task (a natural-language message or structured payload) and the remote agent decides autonomously how to fulfill it. The A2A server may stream partial results, request additional input, or push notifications as it works.
These concepts together form the foundation of the A2A protocol, enabling different agents to communicate and collaborate in a structured, standardized way.
How A2A differs from Agent-as-MCP
Both Agent-as-MCP and A2A enable remote agent invocation with full agentic loops on the server side. The key differences lie in the interaction model:
Dimension | Agent-as-MCP | A2A |
|---|---|---|
Invocation style | Tool-oriented: caller selects a tool by name and passes typed parameters | Task-oriented: caller sends a task (often natural language); the remote agent decides how to fulfill it |
Discovery | Tool catalog via Gateway or static config | Agent Cards at a well-known URL with self-describing skills, capabilities, and auth requirements |
Interaction | Typically single request/response per tool call | Supports multi-turn conversations, streaming partial results, push notifications, and task state transitions |
Coupling | Caller must know tool schemas | Caller only needs to know the agent's skills and input modes; the agent handles internal routing |
In short, MCP treats the remote agent as a tool with an agentic implementation — the caller controls what to invoke and how. A2A treats the remote agent as an autonomous peer — the caller describes what it needs and the agent decides how to deliver it.
Runtime topology
A2A is inherently a multi-Runtime pattern. Each agent is deployed as its own AgentCore Runtime (or on another platform) and exposes an A2A server. Orchestrators and peer agents discover each other via Agent Cards and communicate using the A2A protocol.
When to choose A2A
- Independent ownership and SLAs per domain agent (for example, a "Risk" agent owned by Risk, "Pricing" by Finance, "Compliance" by Legal).
- Workloads that benefit from task-level delegation rather than tool-level invocation — the remote agent should autonomously decide how to fulfill a request.
- You are building or participating in a multi-team or multi-vendor agent ecosystem and need a standard, open protocol with built-in discovery, rather than internal APIs.
Pros
- Strong isolation with independent scaling per agent.
- Cross-framework interoperability: Strands, OpenAI Agents SDK, LangGraph, Claude Agent SDK, and Google ADK agents can all communicate via A2A.
- Built-in discovery and self-description through Agent Cards, reducing the need for external registries.
- Task-oriented interaction supports richer collaboration patterns — multi-turn exchanges, streaming, and negotiation — that go beyond single tool calls.
Cons
- Highest operational overhead. Moving from a single Runtime to distributed A2A agents introduces complexity similar to breaking a monolith into microservices: you now manage service discovery, inter-service security, SLOs, versioning, and distributed tracing across multiple independent services.
- Harder global state and session management across multiple services.
- Interface changes require contract negotiation and versioning; the ecosystem is still maturing compared to established tool-calling patterns.
Agent discovery, communication, and shared context
Once you adopt multiple Runtimes, several cross-cutting concerns need attention.
Communication channels
Channel | How it works | Best for |
|---|---|---|
InvokeAgentRuntime | Call another Runtime via the AWS SDK from any compute (Lambda, ECS, another AgentCore Runtime, etc.) | Internal fan-out/fan-in where you own both sides |
MCP over AgentCore Gateway | Deploy MCP servers on AgentCore Runtime and expose them through AgentCore Gateway. Gateway provides centralized authentication, observability, semantic tool discovery, and policy enforcement. | Production workloads requiring managed routing, auth, and a unified tool catalog |
MCP direct Runtime invocation | Call the MCP server's Runtime endpoint directly via InvokeAgentRuntime | Development, testing, or tightly scoped internal integrations where Gateway overhead is unnecessary |
A2A protocol | Deploy A2A servers on AgentCore Runtime; use JSON-RPC 2.0 over HTTPS with Agent Cards for discovery | Task-oriented agent-to-agent collaboration across frameworks, teams, or vendors |
Service discovery
For MCP and direct
InvokeAgentRuntime calls, discovery is typically static — Runtime ARNs or endpoints stored in configuration, AWS Systems Manager Parameter Store, or a lightweight registry. When using AgentCore Gateway, the Gateway's unified tool catalog serves as the discovery layer.For A2A, discovery is dynamic. Agents expose an Agent Card at
/.well-known/agent-card.json that describes capabilities and endpoint URLs. An orchestrator or control plane queries these cards and caches them for routing.Session and context sharing
- Shared session IDs: Propagate the same
X-Amzn-Bedrock-AgentCore-Runtime-Session-Idheader (or a correlation ID) when multiple agents work on the same user task.
- AgentCore Memory: Use Amazon Bedrock AgentCore Memory as a managed backend for both short-term working memory (conversation context within a session) and long-term intelligent memory (extracted insights and preferences across sessions). AgentCore Memory provides hierarchical namespaces for multi-agent, multi-tenant memory isolation, and integrates natively with AgentCore Runtime.
- External state stores: For additional shared state, use Amazon DynamoDB, Amazon RDS, or a vector store. Each agent reads and writes based on session ID; the orchestrator composes views.
Performance and cost considerations
Single Runtime, multiple agents
- Latency: Lowest overhead — no network hops, minimal serialization.
- Throughput: Bounded by a single Runtime's concurrency and the heaviest agent's resource needs.
- Cost: Fewer Runtimes, but you may over-provision to satisfy one resource-intensive agent.
Multiple Runtimes (MCP / A2A)
- Latency: Each inter-agent call adds network and protocol overhead. This overhead is noticeable in tight tool-invocation loops.
- Throughput: Better independent scaling — you can assign GPU resources to only the agents that need them.
- Cost: More Runtimes, but each can be right-sized. Cold-start and idle costs can matter for spiky workloads.
Optimization tips
- Use coarser-grained calls to remote agents (for example, "analyze these logs and return a summary") rather than chat-style back-and-forth.
- Keep high-frequency, low-latency subagents in-process; deploy low-frequency, compute-heavy agents as separate Runtimes.
- Use parallel invocation (thread pools, async I/O) to fan out to multiple agents when SLAs permit.
Security and governance considerations
Security often drives topology decisions more than performance does.
When a single Runtime is sufficient
- All agents are owned by the same team, share a trust boundary, and access the same data classifications.
- You are comfortable with shared IAM roles and do not require strict per-agent isolation.
When to split into multiple Runtimes
- Different agents must run under different IAM roles or tenants (for example, Finance vs. HR).
- You need defense in depth: network boundaries, separate AWS accounts, or stricter policies for some capabilities.
- You want centralized authentication, audit, and rate limiting at the Gateway or A2A boundary when connecting to critical backends.
A2A-specific security practices
- Treat A2A endpoints like any externally facing API: mTLS between agent Runtimes, scoped OAuth or JWT tokens per caller, and tenant-aware routing with per-agent role-based access control (RBAC).
- Version Agent Cards and capabilities to avoid breaking consumers. Advertise deprecation windows.
Putting it together: a decision guide
A recommended approach for designing your next AgentCore multi-agent system:
- Start in a single Runtime. Co-locate the supervisor and subagents while you are still experimenting. Measure token usage, latency, and failure modes.
- Split when you have a clear reason. A capability needs a different IAM role, resource profile, or owner. You want to reuse an agent across teams or products. A single agent's resource consumption dominates the Runtime's footprint.
- Choose the right remote boundary.
- InvokeAgentRuntime / MCP via Gateway — for internal, same-organization reuse where the caller knows which tool to invoke.
- A2A — when exposing an autonomous agent to heterogeneous peers, or when you need task-level delegation with built-in discovery.
- Add a control plane as you scale. Implement or adopt an orchestrator that maintains awareness of which agents exist (Agent Cards, Gateway catalogs), how to route tasks among them (skills, cost, SLOs), and how to collect traces, metrics, and audit logs.
Next steps
To get started with the patterns described in this post, deploy your first agent or tool on Amazon Bedrock AgentCore Runtime — the managed infrastructure that handles scaling, authentication, and session isolation so you can focus on agent logic. For agent development, explore the Strands Agents SDK , an open‑source, model‑agnostic framework with deep integration across the AWS ecosystem, including native support for AgentCore Runtime, AgentCore Memory, and AgentCore Gateway.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article