Multi-Agent Topology Design on Managed Runtimes vs Frameworks

Tier: Advanced · Hands-on time: ~40 minutes

"Multi-agent orchestrations" is verbatim posting language, and AWS's own multi-agent guidance centers on supervisor routing to domain specialists. But the sharpest lesson in this area is the churn itself: Bedrock Agents classic closes to new customers in July 2026, pushing workloads toward AgentCore — teams that coupled their designs tightly to the first-generation service are now migrating. Topology is the durable decision; runtime is the replaceable one, and the design should encode that asymmetry.

When to use

• A workload has outgrown a single agentdistinct domains, tool sets, or context budgets are fighting inside one prompt.
• A managed-runtime-vs-framework decision is due and lock-in must be assessed with recent history in mind.
• An RFP or design review demands a multi-agent architecture and you need it to be defensible, not fashionable.
• Don't reach for this when a single agent with a well-designed tool set clears the requirement — multi-agent is an escalation past pb-34's patterns, not a starting point.

Prerequisites

• A pattern classification from pb-34 showing why single-agent designs fail this workload.
• The domain decomposition: which specialist capabilities exist, their tool needs, and which interactions between them matter.
• Vendor documentation for AgentCore and Foundry Agent Service, plus LangGraph docs, open for verification.
• A chat assistant for topology stress-testing.

The workflow

1. 1.

   Justify multi-agent at all. Write the single-agent failure concretely: context window exhausted by combined tool schemas, irreconcilable personas, or separable failure domains. If the justification is "the diagram looks better," stop here.

2. 2.

   Choose the topology from the three families. Supervisor/router — a coordinating agent classifies and delegates to specialists; the default for heterogeneous requests, and the shape AWS's multi-agent-orchestration guidance documents. Peer collaboration — agents hand off directly without a coordinator; fits pipelines with clear sequential ownership. Hierarchical — supervisors of supervisors; justified only at genuine scale of domains. Prefer the supervisor pattern until measured coordination overhead argues otherwise.

3. 3.

   Design the interaction contracts before picking a runtime. For each edge in the topology: what is passed (structured payloads beat free prose between agents), what each specialist may assume, how failures propagate upward, and where the human gates from pb-38 sit. These contracts are portable; runtime APIs are not.

4. 4.

   Map to candidate runtimes with lock-in explicit. Rajesh is solutioning Meridian Retail's support copilot plus order-status agent:

   Copy

   I have a supervisor topology: router agent -> two specialists
   (order-status agent with read-only order APIs; support-KB agent with
   RAG retrieval). Interaction contracts attached.
   
   Map this onto three candidates: Bedrock AgentCore, Azure AI Foundry
   Agent Service, and self-managed LangGraph on our container platform.
   
   For each: (1) which parts of my topology map to native constructs vs
   custom code; (2) what state/memory the runtime owns vs what I own;
   (3) exit cost — concretely, what would migrating this topology OFF the
   platform in 18 months require, given the Bedrock Agents classic ->
   AgentCore transition as the reference case for how these platforms churn;
   (4) a VERIFY list of capability claims I must confirm in current docs.
   Do not recommend. Surface trade-offs and unknowns.
   

5. 5.

   Weigh managed vs framework on the real axes. Managed runtimes buy session management, scaling, and identity plumbing at the price of platform coupling and roadmap dependence; frameworks like LangGraph buy portability and control at the price of owning the operational surface (the DevOps track's problem, but your design creates it). Regulated or client-tenancy constraints can decide this outright before preferences enter.

6. 6.

   Design for the churn you just studied. Keep interaction contracts and specialist prompts in your repo, not only in platform configuration; isolate runtime-specific glue in a thin adapter layer; record in the ADR which parts of the design are portable and which are hostage. The AgentCore transition is the case study to cite when a reviewer asks why the adapter layer exists.

7. 7.

   Write the topology ADR and diagram. Topology chosen with the single-agent failure that justified it, runtime chosen with exit costs stated, the contracts appendix, and revisit triggers — including "platform announces successor product," which is no longer hypothetical.

Verify before you trust it

• Runtime capability claims checked against current docs. Session limits, memory features, identity propagation, regional availability — confirm each on the vendor's live documentation; agent platforms are the fastest-moving surface in this track, and AI-recalled capabilities are reliably stale.
• The topology survives a trace-through. Take five real request types and walk each through the diagram by hand: every hop has a contract, every failure path lands somewhere designed.
• Coordination overhead is estimated with real prompts. Multi-agent means multiplied LLM calls — count tokens for a representative request across the topology versus a single-agent baseline; the multiplier goes in the ADR.
• Exit cost is written as a migration sketch. One paragraph per managed candidate describing the actual off-ramp; if you cannot write it, you do not understand the coupling yet.
• Lock-in lessons cited accurately. If the ADR references the Bedrock Agents to AgentCore transition, state it precisely — classic closing to new customers July 2026 — and verify against AWS's current announcement page before the ADR ships.

Restricted-environment variant

Topology design is client-safe when abstracted — specialist roles, contracts, and failure paths described without client names or API details work in any approved assistant. Runtime selection often is not: client MSAs may mandate the client's cloud, subscription tenancy, or on-prem execution, which collapses the candidate list before trade-offs matter — extract those constraints first. For restricted builds, LangGraph self-hosted inside the client boundary with client-tenancy model endpoints (Bedrock or Azure OpenAI in their subscription) is the standard pattern; a local Ollama-served model can stand in for development and topology testing at reduced capability.