The reference architecture: one platform, six planes

This chapter draws the system the whole book builds: Hive, a multi-agent execution platform on AWS. Later parts implement the pieces; the capstones apply the platform to four different jobs. Here we fix the shape, walk one task through it end to end, and make the big build-versus-buy calls explicit.

One word first, because the chapter is organized around it. A plane is architecture jargon, borrowed from networking, for a group of components that share one responsibility and one failure conversation. Network engineers split routers into a control plane (decides where packets should go) and a data plane (moves them); we extend the same move to six responsibilities, so that "who owns this" and "what breaks if this breaks" always have a one-word answer. Every AWS service placed on a plane below is explained, internals and all, in the decoder ring; this chapter is about how they compose.

Design tenets

Five decisions shape everything else, so they come first:

1. Event-sourced everything. The unit of truth is an append-only event log per run. State is derived, checkpoints are offsets, replay is free. This single choice buys gates 4, 5, and 6 from the production bar at design time.
2. Budgets are admission control, not accounting. A run's token budget is checked before work is admitted and decremented as it executes. The ledger lives in the scheduler, so no prompt and no model behavior can overspend it.
3. The model quota is a shared resource with a governor. Workers never call Bedrock directly at full speed; they draw tokens from a shared client-side bucket sized to the account quota. Backpressure propagates to the queue, not to a 429 storm.
4. Effects are gated; analysis is free. Agents may read, search, and compute liberally. Anything that changes the world outside the platform (spend, send, write to a production system) passes a verification step, an approval gate, or both.
5. Isolation is bought where possible, built where necessary. Session and code isolation ride on Firecracker-backed services by default; we build our own sandbox only when egress policy, statefulness, or price forces it. Part 5 does that analysis honestly.

The six planes

            +--------------------------------------------------------+
            |                     CONTROL PLANE                      |
            |  API (API Gateway + Lambda)  |  intake queues (SQS)    |
            |  scheduler: priorities, budget ledger, admission,      |
            |  checkpoints, fleet state    (Step Functions + Lambda) |
            +-----------------------------+--------------------------+
                                          |
                     work units           |          results, events
                                          v
+---------------------+   +--------------------------------------------+
|     MODEL PLANE     |   |              EXECUTION PLANE               |
|  Bedrock (Claude)   |<--|  agent workers running the loop:           |
|  inference profiles |   |   - Lambda (short tasks)                   |
|  prompt caching     |   |   - Fargate (long tasks)                   |
|  batch tier         |   |   - AgentCore Runtime (managed sessions)   |
|  token-bucket gov.  |   +---------------------+----------------------+
+---------------------+                         |
                                                v
                          +--------------------------------------------+
                          |               SANDBOX PLANE                |
                          |  code execution + browsing for agents:     |
                          |  AgentCore Code Interpreter / Browser,     |
                          |  or DIY Firecracker service (Part 5)       |
                          +---------------------+----------------------+
                                                |
                                                v
+----------------------------------+   +------------------------------+
|       STATE & MEMORY PLANE       |   |    TRUST & OPS PLANE         |
|  DynamoDB: events, checkpoints,  |   |  IAM roles per tool, STS     |
|  budgets, leases (single table)  |   |  session policies, approval  |
|  S3: artifacts, shards, reports  |   |  gates, guardrails, OTEL     |
|  S3 Vectors / OpenSearch: memory |   |  traces, token ledger, evals |
+----------------------------------+   +------------------------------+

Six planes, one sentence each:

• Control plane: how work arrives, gets admitted against a budget, is sharded into units, scheduled, checkpointed, and resumed.
• Model plane: how tokens are bought: Bedrock with Claude, inference profiles for capacity, caching to bend the cost curve, the batch tier for offline work, and a governor so the fleet shares quota deliberately.
• Execution plane: where the agent loop runs; the compute that holds a conversation with the model and calls tools.
• Sandbox plane: where untrusted execution happens; strictly separated from the execution plane so a compromised tool run cannot see the worker's credentials.
• State and memory plane: the event log, checkpoints, artifacts, and long-term memory.
• Trust and ops plane: identity, gates, guardrails, traces, ledgers, and evals; cross-cutting by nature, listed as a plane so it gets an owner.

Don't be confused: execution plane vs sandbox plane. The execution plane runs your code (the agent loop, trusted by construction). The sandbox plane runs the agent's code and parses hostile content (untrusted by definition). Collapsing the two is the single most common architecture mistake in agent platforms: it hands the model's output a path to the worker's IAM role. In Hive they are different processes on different infrastructure with different credentials, always.

Life of a task

The best way to read the diagram is to push one task through it. The example is a Capstone A work unit ("audit this slice of the repository"), but the path is generic.

1. Submit. A client calls the API with a task spec and a budget cap. The API authenticates the caller, writes a run.created event, and returns a run id. Nothing has been promised yet except durable intent.
2. Admit. The scheduler checks the budget ledger and current fleet load. Admission is where over-demand turns into queueing rather than quota exhaustion. An admitted run gets run.admitted; a run beyond the tenant's ceiling parks with run.rejected and a reason.
3. Shard. A planner step (sometimes an agent itself, sometimes plain code) splits the task into work units and writes them to S3 plus a unit.created event each. For a repository audit this is file groups; for document intake it is one unit per document.
4. Fan out. The scheduler dispatches units to the execution plane, respecting per-run concurrency and the global token governor. Each worker leases a unit (a conditional write in DynamoDB), so a crashed worker's lease expires and the unit is re-dispatched instead of lost.
5. Execute. The worker runs the agent loop: model calls through the governor to Bedrock, tool calls under a task-scoped role, code execution delegated to the sandbox plane. Every turn appends events; every N events the worker writes a checkpoint offset.
6. Verify. Finished units flow to verifier agents (a smaller fleet with a different prompt and no write tools) that try to refute the findings. Verified results get unit.verified; refuted ones return to the queue with the refutation attached, budget permitting.
7. Gate. If the run's outputs include effects (open a PR, send a report, file tickets), the effect list parks at an approval gate: a Step Functions callback that waits for a human token. Read-only outcomes skip ahead.
8. Merge and finish. A merger assembles unit results into the final artifact with provenance links back to events. The run closes with run.completed, a full token ledger, and a trace; or run.exhausted with partial results and an exact statement of what remains.

Eight steps, and each maps to gates from Chapter 1: admission is gate 3, leases are gate 5, checkpoints are gate 6, the governor is gate 7, verification and approval are gate 10, the ledger and trace are gate 9. The architecture is the checklist, folded into a shape you can deploy.

Service choices, and the alternatives

Defaults for each plane, with the honest alternates. "Default" means what the book deploys in the capstones; parts 2 through 7 develop the reasoning.

Two decisions deserve their own tables because teams get stuck on them.

Where does the agent loop run?

Queue or state machine?

What Hive is not

Scope cuts, stated early so the design stays honest:

• Not a framework. Hive is an architecture with reference code, not a library to import. Where a framework helps (Strands for the loop, MCP for tools), we use it and read its internals; the value here is the system design, which survives framework churn.
• Not provider-portable by abstraction. We do not wrap every AWS service in an interface layer on day one. The event-log and scheduler designs are portable ideas; chasing runtime portability up front costs more than a later migration would.
• Not agentic everywhere. The scheduler, the governor, the ledger, and the merger are plain code. A useful default from the wider industry applies: use deterministic code wherever the logic is known, and spend model calls only where judgment is the actual product.

👉 Next: the use-case gallery, eight systems that map onto these six planes, including a few that should not be built as agents at all.