The map: every part, every chapter
This chapter is the whole book in miniature. Eleven parts, each broken into chapters with their topics spelled out, so you always know where a subject lives and what depends on what. Chapters listed here are written in order and added to the sidebar as they land; titles may get sharpened, but the structure is the contract.
Every term used below (the loop, event sourcing, microVMs, quotas, MCP, and the rest) was defined in the concepts chapter, and every AWS service named below is opened up in the decoder ring. If a line here reads as jargon, one of those two chapters owes you the explanation; this one only has to tell you where things live.
How the parts fit together
Part 1: the agent loop (from scratch)
|
+------------------------+------------------------+
| | |
Part 2: Bedrock Part 4: serverless Part 5: sandboxes
(model plane) skeleton (Lambda, (Firecracker,
| Step Fns, events) microVMs)
| | |
Part 3: AgentCore <------------+------------------------+
(the managed runtime, dissected against parts 4 and 5)
|
Part 6: swarms and parallel execution
|
+------------------------+------------------------+
| | |
Part 7: memory, Part 8: trust Part 9: operating
knowledge, state (security, safety) agents (obs, evals,
| | cost, on-call)
+------------------------+------------------------+
|
Part 10: protocols (Strands, MCP, A2A)
|
Part 11: capstones (four production builds)
Part 1 is the only hard prerequisite for everything else. Parts 2 through 5 can be read in any order. Part 6 assumes 2 and 4. The capstones assume all of it.
Part 1: The agent loop, from scratch
The loop is the atom of everything else in the book, so we build it with no framework and no cloud, in plain Python. This part is written; the titles link to the chapters.
The loop. Model, tools, stop conditions. What a tool-use turn actually looks like; the loop as a five-beat cycle (think, remember, check the stop reason, act, report); parallel tool calls inside a single turn; why tool failures become messages instead of exceptions; the same loop against a scripted model, first-party Claude, and Bedrock. Lab: a 100-line agent with three tools and a transcript printer, runnable locally.
Tool design. Tools as the contract between model and world: schemas, descriptions that steer triggering ("use when..." as a first-class field), error results written for the model to recover from, idempotency keys in effectful tool inputs. When to promote an action from a bash-style escape hatch to a dedicated tool (gating, rendering, auditing, parallel safety). Lab: the same twelve requests routed against vague and sharp toolsets, with the wrong-call rate measured (5/12 versus 12/12).
The event store. The agent transcript as an append-only event log; deriving "current state" as a fold over events; checkpoints as saved offsets, not saved blobs; why event sourcing is the design that later makes replay, audit, and resumption cheap. Lab: an event-store module (JSON lines on disk) that every later local lab reuses, with the checkpoint property verified.
Replay. Deterministic re-execution against recorded model responses; diffing two runs; injecting a fault and watching the divergence; the record-at-the-edges rule that keeps replay exact. Lab: record a run, replay it byte-identically, patch one tool result, and diff the two futures.
Part 2: Bedrock, the model plane
Bedrock is where the tokens come from, so its mechanics set the physics for everything downstream: latency, cost, quotas, and failure modes. This part is written; the titles link to the chapters.
Bedrock mechanics. No API keys: SigV4 and
IAM as the door, model access as policy. The three request styles
(InvokeModel, Converse, and the Anthropic-native Mantle endpoint for Claude
Opus 4.7 and later) and when each earns its keep; reading the two model-id
dialects (dated ids with us./eu./global. profile prefixes versus
undated anthropic. ids); inference profiles as routing; Bedrock versus
Claude Platform on AWS. Lab 2.3 part one: first calls through both doors.
Prompt caching. What the provider actually caches (the model's reading state, which is why prefixes must be byte-exact); the five rules (markers, minimums, TTLs, prices, batch exclusion); freeze-the-prefix and append-only as design habits. Lab 2.1: one 40-turn session priced four ways: no cache $4.84, 5-minute TTL $1.26, 1-hour TTL $1.13 (the two 7-minute pauses cost the short TTL $0.28), batch $2.42; caching discounts input only.
Steering and structure. The control ladder: ask (prompt), constrain (schemas, structured output), filter (Guardrails: content, topics, PII redaction, prompt-attack detection, grounding), forbid (IAM and policy). The agent gap: guardrails wrap a call's edges, but injected text arrives in tool results mid-loop, so checks run at the tool boundary; what filters cannot catch and why blast radius beats detection.
Throughput engineering. The two meters (RPM and TPM) and bucket-shaped enforcement; the anatomy of a 429 storm (retry amplification, account-wide blast radius). Lab 2.2: 40 workers against a 200k TPM quota: greedy makes 800 attempts (500 rejected) and starves a bystander workload to 69%, governed makes exactly 300 attempts, zero 429s, bystander 100%, for a 6% wall-clock tax. Then the pipe-changing levers: quota increases, provisioned throughput, batch, routing.
Model operations. Pin in production, track in evaluation (alias versus snapshot); the five-step upgrade playbook (baseline, candidate evals plus replay corpus, expect token counts to move, canary, rollback written first; caches run cold across the switch); degrading gracefully (timeouts, jittered retries through the governor, fallback chains in order of sameness); the model portfolio: frontier plans and verifies, middle tier executes, small models filter and extract.
Part 3: AgentCore, the managed runtime dissected
Amazon Bedrock AgentCore is AWS's framework-agnostic agent platform, and since mid-2026 it is also the only door: the original Bedrock Agents service is now "Agents Classic," in maintenance mode and closed to new customers, so AgentCore is where AWS's managed-agent investment lives. Each chapter opens on the vendor-free agentic concept (what is an agent runtime, agent memory, a tool gateway, an agent sandbox) and the wider ecosystem before decoding the AWS implementation. This part is written; the titles link to the chapters.
The agent runtime. The four jobs every agent runtime does (session lifecycle, per-session isolation, scaling, invocation), then AgentCore Runtime decoded: bring-your-own-loop, dedicated Firecracker microVM per session, 8-hour sessions with idle timeout, and the pricing insight (CPU billed only while active, so an agent that mostly waits costs almost nothing to keep alive). The gates table: what Runtime inherits for you and what stays yours. Lab 3.1: the Part 1 agent deployed, follow-along.
Agent memory. The five-stage pipeline every memory system implements (capture, extract, store, retrieve, inject) and where the ecosystem sits on it (Letta and mem0 lineage, Anthropic's memory tool, AgentCore Memory); short-term versus long-term strategies; the design questions buying does not answer (what to remember, staleness and provenance, when to consult, memory evals); the four-shape decision table.
Tools over the wire. Lab 3.0, fully local: a working MCP server and client from scratch in 150 lines of standard library (newline-delimited JSON-RPC, initialize, tools/list, tools/call), with the Part 1 investigation re-run over the wire: same loop, same verdict, tools now remote and discovered rather than hardcoded. Then Gateway as the MCP-server factory (Lambda, OpenAPI, Smithy, and MCP-server targets, plus search) and Identity as the confused-deputy fix: OAuth choreography with tokens that never transit the model.
Managed hands. Why code execution and browsing keep appearing in every agent stack (code is how an agent escapes the token economy; the browser is the tool for software with no API) and why both are maximally dangerous; Code Interpreter and Browser decoded as session-shaped microVM sandboxes; Nova Act's Playwright underpinnings; the buy-versus-build table previewing Part 5, and the Code-Interpreter-versus- tool-host trust distinction.
Watching and governing. Trajectories, not requests, as the unit of agent observability (OTEL and its GenAI conventions; traces for operators versus the event ledger for replay); Policy as rung four made real (natural language compiled to open-source Cedar, enforced outside the reasoning loop where no jailbreak reaches); Evaluations as managed judges over traces, with the buy-versus-own split for eval suites stated honestly.
The verdict. The full build-versus-buy matrix (DIY equivalent, crossover, and what is portable on exit, component by component); the production-bar scorecard (isolation and observability inherited, budgets, replay, failure semantics, resumability, throughput, and operability not for sale); three team profiles; and the Agents Classic migration note.
Part 4: The serverless skeleton
The un-glamorous half of production agents, framed through the agent lens: how work arrives, how it is scheduled, and what happens when it fails. This part is written; the titles link to the chapters.
Lambda as tool host and agent host. Two jobs (the agent's tools as functions with per-tool IAM = a per-tool wall; short event-driven agents as functions); the 15-minute ceiling as a design input (short agents fine, long agents to Fargate/Runtime, the event ledger makes the split safe); response streaming; SnapStart decoded as the Part 5 Firecracker snapshot restore applied to cold starts; tool-host-vs-sandbox trust box.
Step Functions as the orchestrator. Workflow vs free loop (most agentic work is mostly-known control flow with a few judgment steps; a state machine with model-call states beats a free loop on cost/audit/failure-reasoning); the agent loop as a state machine; Standard vs Express; waitForTaskToken as the platform-enforced human gate; retryable-failure vs poisoned-task as declarative Retry/Catch; StepFunctions-vs-swarm-scheduler box.
Distributed map and fan-out. The map state from the inside (item source, max concurrency = set to N* not 10,000, child workflow, result writer + tolerated failure) mapped onto the Part 6 simulator; item batching as the hidden cost lever; redrive as resume-as-a- button (but it doesn't know your ledger, so crash-doubled spend stays yours); the buy-vs-own table (AWS supplies the distributed mechanics, you keep governor + ledger); map-vs-Parallel box.
Event-driven agents. Reactive agents (EventBridge rule -> SQS -> worker); the at-least-once contract and the mechanisms that tame it (visibility timeout tuned for agent latencies, idempotency keys, DLQ). Lab 4.1: one alert through the queue three ways (no idempotency double-fires (2 tickets for 1 alert), an idempotency key makes it exactly-once (1 ticket), a poison message dead-letters after 3 receives); idempotency is a TOOL property not plumbing; at-least-once-vs-exactly-once box.
The scheduling layer in practice. Priorities (lanes, keep them few) and tenant fairness (interleave, don't let one tenant monopolize); backpressure end to end (governor throttles -> admission slows -> queue absorbs -> shed at the door); draining for a deploy (stop intake, finish in-flight, deploy, resume, only possible because of event sourcing plus idempotency); the whole-skeleton assembly; buy-the-plumbing-own-the-economics; scheduling-layer-vs-orchestrator box.
Part 5: Sandboxes and microVMs
Agents write and run code, fetch URLs, and handle untrusted input. Isolation is not optional, and on AWS the isolation story is Firecracker. This part is written; the titles link to the chapters.
Firecracker from first principles. Why containers are the wrong wall for hostile code (one shared kernel, ~350 syscalls of attack surface); what a microVM is (own guest kernel on KVM, a tiny hardware interface); Firecracker's design as a list of things it refuses to emulate (no BIOS, almost no devices, the jailer as a second fence); the NSDI numbers (<125ms boot, <5MB overhead, 150 microVMs/s); snapshots as booting-faster-than-booting. Lab 5.1: cold vs warm-pool vs snapshot sizing, seeded: cold 2500ms flat, warm(5) 71% hit but p99 still cold, warm(20) instant but 10GB reserved, snapshot 250ms at zero standing memory.
Build your own sandbox service. The five components (control API, microVM manager, rootfs pipeline, snapshot, metal fleet), only one exotic; the rootfs pipeline as a security decision (minimal base, exactly the runtime, read-only where possible); the request path (restore snapshot, run under timeout, destroy the microVM = freshness by destruction); the pool policy the lab already decided; the bare-metal reality (T2) that makes "build" a legible cost.
Locking the box. Isolation stops escape; these stop damage. Egress as the control that matters most (no network by default, an allowlist proxy when needed); secrets kept outside the box and injected at the proxy (the Identity pattern again); quotas that stop the boring attacks (timeout, the microVM's native memory cap, CPU, disk); logging from the trusted side. The failure-to-control mapping table; sandboxing-vs-guardrails box.
Buy, build, or borrow. The three options (managed sandbox, the DIY Firecracker service, hardened containers via gVisor or Kata) scored on isolation, latency, egress, images, price at both volumes, and operational load; buy-first as the default with the specific build- and borrow-triggers; the one non-negotiable (plain containers are never an acceptable sandbox for hostile code); the sandbox-is-a-plane box.
Part 6: Swarms and parallel execution
The book's center of gravity: many agents, one goal, bounded budget. This part is written; the titles link to the chapters.
Topologies. What a second agent actually buys (fresh context windows first, then parallelism, independence, and specialization) against its honest cost (order of fifteen times chat token spend); the five shapes (orchestrator-workers, pipeline, debate and judge, blackboard, hierarchical delegation) with failure modes; Strands and LangGraph vocabulary mapped on; the selection rule, and the multi-agent-versus-parallel-tool-calls box.
The swarm scheduler. Every topology reduces to queue, workers, governor, ledger, all plain code with judgment kept in the workers. Lab 6.1, seeded: a 400-unit fleet run with full stats; the worker-scaling sweep (25 workers 5,091s, 100 workers 1,746s, 200 workers 1,604s) hitting the Little's law crossover at N* = 119; budget exhaustion as a clean, resumable landing at 206/400 units.
Fan-out on AWS. The same machine in three bundles: distributed map (managed dispatch, redrive, batch-shaped), SQS plus a worker fleet (continuous intake, priorities, your ledger: Hive's default), AgentCore Runtime sessions (pay-active, long-idle units), with the decision table and their composition. Then the distributed governor: central counters, batched allowance draws, adaptive concurrency, and the composite that works.
Failure semantics. The five-way taxonomy (transient, poison, worker death, partial, exhaustion) with leases, dead-letter queues, and idempotent effects. Lab 6.2: the fleet murdered at t=700s and resumed: only the 100 in-flight units re-executed, but the crash's 1.2M wasted tokens correctly drained the ledger and the resumed run landed 11 units short, which is why budgets carry crash reserves.
The verification mesh. Finders biased for coverage, refuters instructed to demolish, blind panels, dedup before judging. Lab 6.3: raw findings at 50% precision and 96% recall become 96% precision with a 3-vote panel (one real finding lost) and 100% with five votes, priced at 15,652 verify tokens per false alarm removed, with the sweep as a menu and planted decoys as the production monitor.
Communication. The three patterns in escalating regret: results-only through the ledger (the default, and further-reaching than intuition suggests), blackboards for data not control (with their injection surface named), and A2A decoded (agent cards, task lifecycle) for genuine cross-boundary counterparties; the independence tension resolved by phase separation; the communication-versus-delegation box.
Part 7: Memory, knowledge, and state
This part is written; the titles link to the chapters.
The state store. Why an agent's state store wants a key-value engine, not SQL (append-heavy writes, single-partition reads, narrow sharp concurrency); single-table design (every entity type in one table, keyed by partition + sort, one query returns a run's whole story); the two conditional writes the control plane rests on (sequence integrity, leases). Lab 7.1: the store simulated locally, two workers racing for a sequence number, and a lease acquired, refused, and reclaimed after a crash.
Vector memory. Similarity search built from scratch (embed, cosine, top-k) with an honestly-labeled toy embedding; Lab 7.2 pits it against grep: vectors win fuzzy multi-concept recall, grep wins exact set membership (an agent wants both). Then the store decision matrix (in-process, pgvector, S3 Vectors, OpenSearch) on latency, cost floor, scale, and operational weight, with the start-smallest heuristic.
Knowledge for agents. Why chat-RAG's one-shot retrieval is the wrong model for an agent that can iterate: the loop reformulates, switches between grep and vector per sub-question, and verifies; the consequences (coarser chunking, recall over precision-at-one, retrieval as a tool decision steered by descriptions); Bedrock Knowledge Bases as one tool among several, not the whole flow; grounding and its limits.
Long-term memory pipelines. Consolidation (distilling transcripts into durable facts, offline, batch-tier); provenance (memories cite their source events, so the mesh can check them); staleness (facts age, and similarity has no sense of recency; the supersede/timestamp/overwrite policies). Lab 7.3: the plant-disturb-probe- score harness showing recall decay (100% to 80% as distractors grow) and the staleness failure (a stale fact outranking its own correction, 0.894 vs 0.661); forgetting-vs-losing.
Part 8: Trust: security, safety, isolation
This part is written; the titles link to the chapters.
IAM for agents. The agent as a principal whose IAM policy, not its prompt, bounds what a compromise can do; the tension (one broad agent role, many narrow tasks) resolved by STS session policies that can only narrow (effective = intersection). Lab 8.1: a faithful policy engine scopes a broad role to a read-only-for-Alice session, denying Bob's data (the confused-deputy defense), all writes, and tickets, while a role-level Deny on SSNs wins under both.
Prompt injection in production. Why it cannot be patched (instructions and data share one channel); the lethal trifecta (private data + untrusted content + an egress path); containment over detection. Lab 8.2: one attack against a menu of defenses. Detection catches the blatant wording and BREACHES on a polite rephrase; every structural defense (egress allowlist, per-context tool scoping, data separation) holds because each cuts a leg. How this answers gate 11; injection-vs-jailbreak.
Approval gates. What to gate (irreversibility x reach) and the prefer-the-workflow-as-gate move (a PR is its own gate); the pause-park-resume mechanism (an approval event, a durable park, Step Functions waitForTaskToken, resume via replay); gate fatigue as the real failure mode and the design defenses (gate rarely, make decisions cheap and complete, watch the approval rate); gate-vs-guardrail.
Multi-tenant isolation. Four questions (data, budget, compute, throughput) each answered by an earlier control gaining a tenant key: tenant in the partition key AND the IAM resource scope (isolation enforced twice); per-tenant budget caps and quota shares against the noisy neighbor; microVM-per-execution as tenant compute isolation (sandboxes never reused across tenants). The onboarding checklist; multi-tenant-vs-multi-agent.
Part 9: Operating agents
This part is written; the titles link to the chapters.
Observability. Why the trajectory, not the request, is the unit (a per-request view cannot see a useless loop or a token blowout); traces as span trees; the token ledger as a first-class metric. Lab 9.1: a from-scratch tracer renders one run as a trajectory tree (model calls dominate the wall clock) and rolls up the token ledger from the same spans (72% cache hit). Onto OTEL + CloudWatch GenAI; tail-based sampling; traces (for operators) vs the event ledger (for replay).
Evals as regression tests. Why agent evals are harder than unit tests (open-ended outputs, the trajectory is the unit); the three pieces (golden task set, grader = code where checkable + LLM judge where not, gate); LLM-judge calibration against human labels (relative beats absolute, use a strong judge); where evals run (CI on every change, canary in prod, scheduled against drift); the replay/memory-eval/mesh trinity as one idea at three scopes.
Cost engineering. The cost equation and its three levers (fewer tokens, more cached, cheaper tokens); budgets as admission control at three tiers (run, tenant, fleet). Lab 9.2: a cost regression gate: a caching win passes (-18%), a verbose-prompt regression fails on the per-task rule (+42% on a small task) that the aggregate (+5%) would have hidden. Showback (attributing spend per tenant/team/change); cost-vs-latency.
On-call for agents. The agent-specific pages (budget blowout, quota storm, stuck fleet, verification collapse, approval-rate anomaly), each mapped to a metric an earlier chapter emits; the two switches (kill = stop now, drain = stop intake and finish in-flight); runbooks that resolve (confirm/contain/diagnose-by-replay/resolve/recover); the banned root cause ('the model got weird' replaced by a replayable trace); reliability-vs-safety incidents. Part 9 closes: the platform now passes all twelve production-bar gates.
Part 10: Protocols and frameworks
Strands Agents internals. AWS's open-source agent SDK: the model-driven loop, tool registration, session persistence, and its multi-agent primitives (agents-as-tools, swarm, graph, workflow); what the framework does for you and what it hides; reading its source as a design review of Part 1.
MCP end to end. The Model Context Protocol as the tool bus: servers, tool discovery, and schema loading economics; hosting MCP servers on Lambda; AgentCore Gateway as an MCP-ifier; when MCP is overhead and a plain function call is enough.
A2A and the multi-vendor future. The Agent2Agent protocol: agent cards, task lifecycles, and where cross-vendor agent communication is actually useful today; a sober look at which standards are load-bearing in 2026 and which are still aspiration.
Part 11: Capstones
Four production builds on the Hive platform from Chapter 2. Each capstone states its production gates up front and ends with a costed, torn-down deployment.
Capstone A: the repository-audit fleet. The flagship. Point Hive at a large codebase; shard into work units; hundreds of worker agents in sandboxes; adversarial verification of findings; a merged report with provenance; overnight-run economics and checkpointed resume. This is the full platform exercised at once.
Capstone B: the incident responder. EventBridge-triggered agent that investigates alarms with read-only tools, assembles a timeline, proposes remediation behind an approval gate, and writes the postmortem draft. Small fleet, high trust requirements: parts 8 and 9 do the heavy lifting.
Capstone C: the document-intake swarm. Claims-style intake: documents land in S3, extraction agents fan out per document, judge agents score against a rubric, humans arbitrate the low-confidence tail. Throughput economics and batch-tier routing are the story here.
Capstone D: the research service. A deep-research API: fan-out searchers, source-reading workers, adversarial fact-checkers, and a synthesizer with citations, exposed as a service with per-request budgets. The verification mesh from Part 6 is the star.
Don't be confused: parts vs passes. The parts are organized by subject, but the book is designed for two reading passes. Pass one: Part 0 plus the first chapter of each part, which gives you the complete conceptual system. Pass two: the remaining chapters as you build. The map above is subject-ordered; neither pass requires reading every chapter in sequence.
👉 Next: under the hood, the decoder ring for every AWS service this map just named: what each one actually is, and the open-source machinery underneath it.