Composability & the Agent Platform

The single most important architectural fact about AgentCore is in the overview docs almost as an aside: the services are modular and "work together or independently." You do not have to adopt the whole platform. Each service has its own SDK/API surface and is independently billable, so you can wire up exactly the primitives your problem needs and run the rest of the stack however you already run it.

That modularity falls out of two foundational properties of the platform:

• Framework-agnostic — Runtime hosts a container that speaks a known protocol, not a framework. Strands, LangGraph, CrewAI, your own loop — they all live inside the container.
• Model-agnostic — the model is just a config value inside your agent code; AgentCore never inspects it.

Because of this, the docs frame AgentCore around three headline use cases, and these map directly onto the three composability patterns you'll build:

The rest of this lesson is those three patterns plus the multi-agent designs that connect them.

The all-in pattern is what you get when you scaffold a project with the CLI and let AgentCore own every production concern. The mental model: each service owns exactly one job.

Status note (verify before relying on it): the first five services above (Runtime, Memory, Gateway, Identity, Observability) reached GA. AgentCore Policy's GA status is not first-party-confirmed as of writing — treat it as the dossier does (a service in flux) and check the live services page before you make it a hard dependency: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html

The agent itself stays tiny — the SDK wrapper is famously "four lines to deploy":

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent

app = BedrockAgentCoreApp()
agent = Agent()  # framework + model live here

@app.entrypoint
def invoke(payload):
    result = agent(payload.get("prompt", "Hello"))
    return {"result": result.message}

if __name__ == "__main__":
    app.run()  # local http://localhost:8080; in container binds 0.0.0.0:8080

Memory, Gateway, Identity, Observability, and Policy then attach around that entrypoint — you don't rewrite the agent, you compose services onto it. The CLI's develop → deploy → operate lifecycle is the all-in workflow:

# develop locally, then ship the whole scaffold
agentcore deploy        # packages (CodeZip or Container/ECR), provisions a
                        # serverless Runtime endpoint with session isolation,
                        # CloudWatch logging, and observability

In operation you invoke the endpoint and attach Memory / Gateway / Identity / Browser / Code Interpreter as needed; monitor with Observability; govern with Policy.

Sometimes you already have an agent running happily on EKS, Lambda, or ECS, and you only have one hard problem — say, you need a sandbox to run model-generated code, or a managed browser, or a place to persist memory. The à-la-carte pattern says: leave your agent where it is and consume the single AgentCore service you need through its own client. Nothing forces that agent to run inside Runtime.

Only Code Interpreter — a managed, isolated sandbox for executing code. Your EKS-hosted agent calls it directly through the SDK:

from bedrock_agentcore.tools.code_interpreter_client import CodeInterpreter

code_client = CodeInterpreter("us-west-2")  # region is positional
code_client.start()  # spins up an isolated session
result = code_client.invoke("executeCode", {
    "language": "python",
    "code": "import pandas as pd; print(pd.__version__)"
})
code_client.stop()

Only Memory — a managed store you read and write from anywhere. The control plane (bedrock-agentcore-control) creates the memory; the data plane (bedrock-agentcore) records and retrieves:

import boto3
data = boto3.client("bedrock-agentcore")  # data plane
data.create_event(
    memoryId="mem-123", actorId="customer-456", sessionId="session-789",
    payload=[{"conversational": {"content": {"text": "..."}, "role": "USER"}}])
data.retrieve_memory_records(
    memoryId="mem-123",
    namespace="/customer-support/user-1/preferences/",
    searchCriteria={"searchQuery": "...", "topK": 5})

Only Gateway — expose your existing APIs/Lambda as MCP tools and point your own agent's MCP client at the gateway URL. (We build this out in Pattern 3.)

Only Browser — a managed, isolated cloud browser your agent drives with Playwright, browser-use, or Nova Act.

The through-line: every AgentCore service is a standalone managed primitive. À la carte is the lowest-commitment way onto the platform, and it's the right call when your agent stack is already mature and you have a single, specific operational gap to fill.

This is the pattern an organization reaches for when it wants to stop every team from re-inventing tool integrations and instead offer a paved path: a central place where approved, governed tools live, with auth, observability, and compliance handled once and shared.

Gateway solves the M×N integration problem (M agents × N tools). It converts APIs, Lambda functions, OpenAPI/Smithy schemas, and existing MCP servers into MCP-compatible tools behind a single endpoint, with both ingress and egress auth managed for you. A platform team creates a gateway once:

import boto3
client = boto3.client("bedrock-agentcore-control")
gw = client.create_gateway(
    name="my-gateway",
    roleArn="arn:aws:iam::123456789012:role/my-gateway-service-role",
    protocolType="MCP", authorizerType="CUSTOM_JWT",
    authorizerConfiguration={"customJWTAuthorizer": {
        "discoveryUrl": "https://cognito-idp.us-west-2.amazonaws.com/<pool>/.well-known/openid-configuration",
        "allowedClients": ["clientId"]}},
    protocolConfiguration={"mcp": {"searchType": "SEMANTIC"}})  # enables semantic search
print(gw["gatewayUrl"])  # https://{gateway-Id}.gateway.bedrock-agentcore.{Region}.amazonaws.com

Teams then add targets — e.g. a Lambda-backed tool, an OpenAPI service:

agentcore add gateway-target --name TestLambdaTarget --type lambda-function-arn \
  --lambda-arn <ARN> --tool-schema-file tools.json --gateway TestGateway

Consuming agents (anywhere — Runtime, EKS, a laptop) point an MCP client at the gatewayUrl and call tools by their namespaced name: ${target_name}___${tool_name} — a triple-underscore prefix, e.g. LambdaUsingSDK___get_order_tool. With searchType="SEMANTIC", the gateway also exposes a built-in x_amz_bedrock_agentcore_search tool so agents can discover the right tool across thousands by intent rather than knowing its name.

Registry is the catalog half of the paved path. It's a centralized place to discover and manage agents, MCP servers, tools, skills, and custom resources across an org, with a governed publish/review/approve workflow and hybrid semantic + keyword search. Gateway exposes governed tools; Registry makes them discoverable and governable across teams. Together they are the dossier's literal definition of the tool-provider pattern: "Gateway + Registry to publish governed MCP tools other teams' agents consume."

Centralized governance is what makes this a platform rather than a shared URL:

• Centralized auth — Gateway is an MCP resource server. One authorizer (CUSTOM_JWT via Cognito/Okta/Auth0, or SigV4) gates inbound; outbound credentials are injected per-tool via Identity's token vault, so no team handles raw secrets.
• Centralized compliance — attach a Cedar Policy engine to the gateway to intercept every tool call before execution (policyEngineConfiguration={"mode":"ENFORCE"|"LOG","arn":"...policy-engine/..."}), plus per-invocation gateway interceptors (custom Lambda).
• Centralized observability — every tool call flows through one endpoint, so the platform team gets one place to trace and monitor usage.

Once you have more than one agent, the question becomes how they talk to each other. AgentCore gives you two distinct mechanisms, and they are not the same thing.

A2A — peer agents discover and call each other. A2A is one of the wire protocols a Runtime container can declare (alongside HTTP, MCP, AG-UI). It runs JSON-RPC 2.0 on port 9000 at the root path, and its defining feature is discovery via Agent Cards served at /.well-known/agent.json. An agent fetches another's Agent Card to learn what it can do, then calls it. The SDK ships a serve_a2a helper (install the bedrock-agentcore[a2a] extra):

from strands import Agent
from strands.a2a import StrandsA2AExecutor
from bedrock_agentcore.runtime import serve_a2a

agent = Agent(model="us.anthropic.claude-sonnet-4-20250514",
              system_prompt="You are a helpful assistant.")
serve_a2a(StrandsA2AExecutor(agent), port=9000)
# serves /.well-known/agent.json (the Agent Card) + JSON-RPC + /ping

Agent-as-tool — front a deployed agent as a Gateway HTTP target. The other mechanism turns a whole Runtime agent into a single tool that other agents call through Gateway. In Gateway's target taxonomy, AgentCore Runtime agents are an HTTP target — the one HTTP (proxied) target type. HTTP targets are path-based proxies: no aggregation, no semantic search, but they let a supervisor/orchestrator agent invoke a specialist agent exactly as if it were any other MCP tool.

The outbound-auth options differ from MCP targets, and Runtime HTTP targets uniquely support Caller IAM (via Forward Access Sessions) and token passthrough:

When to use which: reach for A2A when agents are peers that negotiate and delegate among themselves and you want capability discovery via Agent Cards. Reach for agent-as-tool when you have a clear orchestrator → specialist hierarchy and you want the specialist to appear in the same governed tool catalog as everything else, sharing the gateway's auth, policy, and observability.

There is no single right architecture — the pattern follows your team's maturity and how much governance you need.

A useful progression for a growing organization:

1. A team starts à la carte — they have a LangGraph agent on Lambda and just need a code sandbox. Lowest commitment.
2. A new project goes all-in — they want isolation, memory, identity, and traces without building plumbing.
3. As multiple teams accumulate overlapping tool integrations, a platform team stands up the tool-provider paved path so everyone consumes governed MCP tools from one Gateway (+ Registry, once GA), with auth and compliance handled centrally.

These patterns also compose with each other: an all-in agent in Runtime can consume tools from the platform team's Gateway, persist to a shared Memory store, and be fronted as a Gateway HTTP target so other teams' agents can call it. The composability isn't only within one architecture — it's across them.