AgentCore XI: Multi-Agent Is Not About Scale. It Is a Context Manager in Disguise.
Part 11: Multi-agent on AgentCore is a context manager implemented as topology: subagents, A2A, and hybrid fleets exist so noisy work gets its own head, not because fan-out diagrams look impressive.
Multi-Agent Is Not About Scale. It Is a Context Manager in Disguise.
Multi-agent on AgentCore is a context manager implemented as topology: subagents, A2A, and hybrid fleets exist so noisy work gets its own head, not because fan-out diagrams look impressive.
On Amazon Bedrock AgentCore, subagents and the A2A protocol exist so noisy work gets its own head. Speed and security are real side effects of that context decision.
You think you split agents for speed or security. AWS’s real reason is that one agent reading ten pages fills its own head with HTML.
In this article: You will learn AWS’s actual rationale for multi-agent design (context isolation, not fan-out for its own sake), the three AgentCore architectures from in-process DeepAgents subagents through
serve_a2ato hybrid fleets, how Agent Cards and the ID chain work on the wire, and the decision rule that keeps you from shipping a slower, more expensive system that only looks impressive in a diagram.
This is part 11 of the AgentCore series where Harness Engineering meets the Hyperscalers of AWS.
Support this Substack by subscribing and sharing.
The obvious argument for multi-agent is scale: three competitors, three workers, three times faster. That argument is true, and AWS’s reference implementation reports it (four to six minutes for three real sites, versus up to three times longer sequentially). It is also not the argument they lead with.
Their stated rationale is context. If your agent reads ten web pages, its context window fills with raw content. If the same agent then generates charts, the chart-generation logic competes with strategic reasoning for the space that is left. So you delegate deep work to isolated subagents that return only concise results, and the coordinator’s context stays clean enough to actually reason.
Read that again as harness engineering. AgentCore still does not ship a first-party context compaction product. Multi-agent architecture is a context manager implemented as topology instead of as a compaction function. You are not selecting and evicting tokens. You are giving the noisy work its own head.
The speed is a side effect. The security is a side effect. Both are real, and both are downstream of a context decision.
Three architectures, ascending
There are exactly three ways to do this on AgentCore, and they differ in how decoupled the workers are.
One: in-process subagents
The default, and the one you should stay on longer than you want to.
Each competitor gets its own browser toolkit and a scoped subagent dict; the coordinator alone holds memory tools and the combined subagent list.
research_subagents = []
for company_name, company_url in COMPETITORS:
browser_toolkit, browser_tools = create_browser_toolkit(region="us-west-2") # ①
browser_toolkit.session_manager.session_wait_timeout = 60.0 # ②
toolkits_to_cleanup.append(browser_toolkit)
research_subagents.append({
"name": f"research-{company_name.lower()}",
"description": f"Researches {company_name} by browsing {company_url}.",
"system_prompt": RESEARCHER_PROMPT,
"tools": browser_tools, # ③
})
agent = create_deep_agent(
model=model,
subagents=[*research_subagents, analyst_subagent], # ④
tools=memory_tools, # ⑤
system_prompt=COORDINATOR_PROMPT,
name="competitive-research-coordinator",
)
① One browser toolkit per competitor means one Browser MicroVM each, with no shared cookies or shared context. ② The session wait timeout is raised so browser navigation does not fail at the default short deadline. ③ Each researcher receives only browser tools; memory, catalog, and sandbox stay off the worker. ④ The coordinator’s subagent list fans research workers and the analyst under one in-process agent. ⑤ Memory tools sit on the coordinator only, so researchers that read hostile pages cannot write memory.
Note: The full extracted listing at code/agent-core/part-11-multi-agent-a2a/listings/01-in-process-subagents.py shows the same configuration with the marker comments removed.
One microVM. One deployment. Subagents are dicts with a name, a description, a system prompt, and a tool list. DeepAgents also accepts any LangGraph CompiledStateGraph as a subagent, so a subagent can be an arbitrarily complex graph rather than a prompt with tools.
The Claude Agent SDK does the same thing through AgentDefinition and the Agent tool, with each subagent getting a fresh conversation and an isolated context. Subagent delegation, parallelization, and orchestrator-workers ship off the shelf in the SDK.
Two lines carry the whole architecture.
One toolkit per competitor means one Browser MicroVM per competitor. Three isolated Chromium instances, no shared cookies, no shared context, running concurrently.
"tools": browser_tools means each researcher holds its own browser and nothing else. No memory tools. No catalog. No sandbox. The researcher that reads the hostile page cannot write to memory, because it does not have the tool. Not policy. Physics.
That is the cheapest security control in multi-agent design, and you were going to build it anyway for context reasons.
Two: protocol-fronted with A2A
When your agent needs to be callable by agents that are not yours, you front it with the A2A protocol on AgentCore and publish an Agent Card.
pip install "bedrock-agentcore[a2a]"
An A2A executor maps the protocol task context onto a DeepAgents thread, publishes an Agent Card as the public contract, and serves both through serve_a2a.
If you are a paid subscriber, thank you. Your support makes this work possible.
If you are a free subscriber and find these articles useful, please consider upgrading. A paid subscription is $80 per year or $8 per month.
