"Build us an agent" is a requirement the way "build us a database" is a requirement. This module gives you the design vocabulary — five composable patterns, topology choices, memory, MCP tool integration, blast-radius control and tenancy — to turn agent hype into architecture, starting with the question of whether you need an agent at all.
The posting evidence sets the bar plainly: "multi-agent orchestrations" and "orchestration, tool calling, memory, planning" now appear verbatim in senior architect JDs. But the most valuable judgment this module installs is the opposite of enthusiasm — knowing when a deterministic workflow beats an autonomous agent, and being able to defend that call to a client who asked for the buzzword.
Meridian Retail's RFP reads: "an AI agent that handles order status, returns initiation, and support escalations." Rajesh's solution team reads "agent" and starts drawing.
The first draft is a swarm. Five collaborating agents, a planner, shared memory, autonomous tool use end to end. Impressive diagram. Rajesh asks one question per box: what decision does this component make that a lookup can't?
Pattern mapping. He maps each requirement to Anthropic's five composable patterns. Order status is fetch → summarize → respond: prompt chaining with a routing front end. Escalation triage is routing. Only returns initiation — judgment over policy, then a state-changing action — justifies an agent, and a bounded one.
The platform lesson. The team's draft targeted Bedrock Agents classic — which closes to new customers in July 2026, with AgentCore as the successor. One slide in Rajesh's deck now reads: agent platforms churn; architect for replaceable runtimes.
The tool layer. All agent access to Meridian's order APIs flows through one MCP server with tiered authorization: reads are free, refund-issuing writes require human approval. The client's risk team, skeptical of "AI agents," approves this slide first.
Rajesh presents a workflow for roughly 70% of the scope and one narrowly scoped, approval-gated agent for the rest. Cheaper to run, testable in CI, and the client's own words come back: "this is the first agent proposal our risk team didn't kill."
The deliverable Rajesh sold was not an agent — it was a defensible boundary between deterministic workflow and model autonomy, with the autonomy priced, gated and revocable. That boundary is this module.
Anthropic's "Building Effective Agents" taxonomy is the industry's de-facto design vocabulary — mirrored in Spring AI's docs and aligned with the AWS Agentic AI Lens design principles. It matters because it gives you five composable workflow patterns to exhaust before you reach for autonomy:
An agent, in this vocabulary, is the step beyond: the model plans its own path, chooses tools in a loop, and decides when it's done. That flexibility costs you predictability, testability, latency, tokens, and a much harder review with the client's risk team — so the design rule is blunt: use the simplest pattern that meets the requirement, and make autonomy earn its place per capability, not per project.
Here is Rajesh's Meridian mapping — the worked example this module's lab repeats across six scenarios:
| Requirement | What it actually needs | Pattern | Why not an agent? |
|---|---|---|---|
| Order status queries | Fetch order, summarize state | Prompt chaining behind routing | Deterministic path; nothing to plan |
| FAQ / policy answers | Retrieve policy, answer with citation | Routing → RAG chain | Retrieval quality problem, not autonomy problem |
| Escalation triage | Classify severity, route to queue | Routing | The routes are business rules |
| Returns initiation | Judge eligibility, then act on the order system | Bounded agent | Policy judgment + state change; gated by approval |
When an assessment scenario says the stakeholder "wants an agent," the scored skill is pattern selection — the correct answer names the cheapest of the five patterns that satisfies the requirement, and reserves the word "agent" for scope that needs dynamic planning plus tool use.
When one agent's context or tool surface grows too broad, you split it — and the split has a shape. Three topologies cover practice:
The runtime decision runs on a familiar axis — managed runtimes (Bedrock AgentCore, Azure AI Foundry Agent Service, Vertex's agent platform) give you sessions, memory, identity and gateway integration off the shelf; frameworks (LangGraph, CrewAI, Strands) give you portability and control with the ops bill attached. But this market adds a twist the RAG module didn't have: churn is structural. The case study is first-party: Bedrock Agents classic closes to new customers in July 2026, with AgentCore as the successor — teams that coupled their agent logic to the classic service's abstractions inherited a migration. The design consequence:
Agents fail without memory design the way web apps fail without session design — and the JD bar names memory explicitly. Separate three concerns:
Context-window budget is the fourth, quieter concern: an agent that stuffs its entire history into every call burns tokens quadratically and degrades its own reasoning. Decide at design time what gets summarized, what gets retrieved on demand, and what gets dropped.
Every memory decision is also a compliance decision — long-term memory containing personal data inherits DPDP/GDPR retention and deletion obligations, so the "can we delete one user's memory?" question belongs in the design review, not the incident review.
The tool surface is where an agent touches your real systems, and it now has a standard worth betting on: the Model Context Protocol was donated to the Linux Foundation's Agentic AI Foundation in December 2025 with AWS, Google, Microsoft and OpenAI backing — vendor-neutral governance is exactly the signal an architect waits for before standardizing. The 2025-06-18 specification added the pieces enterprise designs need: structured tool output, OAuth resource-server authorization, and RFC 8707 resource indicators.
Designing the tool surface means four decisions:
A tool-tier table is the artifact — one row per tool, and the lab grades it:
| Tool | Verb | Blast radius | Tier | Gate |
|---|---|---|---|---|
get_order_status | read | none | 1 | log only |
search_policies | read | none | 1 | log only |
update_ticket_priority | write | reversible | 2 | allowlist + log |
initiate_return | write | customer-visible | 3 | human approval |
issue_refund | write | irreversible, financial | 3 | human approval + dual control |
The blast radius of a hijacked or simply wrong agent is everything it can do — so what it can do is a designed, written-down quantity. Four mechanisms compose the architecture that the DevOps track's guardrail operations then run:
Autonomy itself is a setting you write down and revisit — never a property that drifts upward because the agent has been reliable lately:
The agent proposes actions; humans execute them. Every proposal is logged and graded against what the human actually did.
Allowlisted actions execute after a human clicks yes. Anything derived from untrusted input always routes through the gate.
The agent acts without waiting — on reversible, low-blast-radius, allowlisted actions only, under kill switch and sampling review.
An agent design without a kill switch, an allowlist and written promotion criteria is not "autonomous" — it is unsupervised, and the ARB (and the client's risk team) will be right to kill it.
Two org-level decisions close out the module.
Tenancy. A customer-facing agent serving many tenants forces the pooled-vs-siloed choice. AWS's first-party pattern for AgentCore — a pooled runtime behind a centralized MCP gateway — is the economical shape: one runtime, with per-tenant identity propagated through every tool call, tenant-scoped memory, and per-tenant cost metering. The discipline that makes pooled safe: the tenant's identity, not the platform's, is what each tool sees — so a confused or hijacked agent still can't cross a tenant boundary the tools enforce. Siloed (per-tenant) runtimes trade cost for structural isolation, and regulated tenants may contractually require exactly that; noisy-neighbor behavior and per-tenant kill switches push the same direction. This is the RAG tenancy decision again, one layer up — and the same bias applies: the more regulated the data, the more structural the isolation.
Interoperability and registries. Agent-to-agent protocols (A2A-class), internal MCP registries, discovery and capability versioning are consolidating under the Linux Foundation umbrella — but registry practice is young, and honest guidance says so. The strategy that survives churn: standardize on MCP for tools now (governance and backing justify it), keep an internal catalog of approved servers and agent capabilities (a reviewed allowlist is a registry seed), version tool contracts like any API, and treat cross-org agent-to-agent interop as a quarterly-revisit ADR rather than a commitment. Place small bets on standards, big bets on portability.
Agentic design is subtraction — exhaust the five workflow patterns before granting autonomy, route every tool call through a tiered MCP layer, bound every action by allowlist and approval tier, and treat runtime choice as a churn-priced, revisitable ADR — because the agent that survives review is the one whose blast radius was designed, not discovered.
Take this module into Lab 09 (agent pattern selection workshop) — six scenarios, from support triage to pricing approval, each mapped to one of the five patterns or "no agent needed," with your justification graded — and Lab 10 (multi-agent POC with an MCP tool layer), where you'll build a supervisor plus two specialists with every tool call flowing through one MCP server with read/write authorization tiering, and demonstrate a blocked unauthorized write as the completion artifact.
Companion playbooks: pb-34 (Workflow vs Agent — the Five Composable Patterns), pb-35 (Multi-Agent Topology Design on Managed Runtimes vs Frameworks), pb-36 (Agent Memory & State Architecture), pb-37 (Tool-Calling & MCP Integration Architecture), pb-38 (Agent Blast-Radius & Human-Approval Architecture), pb-39 (Multi-Tenant Agent Architecture), and pb-40 (Agent Interoperability & Registry Strategy).