The capstones: one platform, four jobs
The platform is built. Fifty-one chapters constructed Hive plane by plane, from the loop to the on-call runbook, and every piece was justified by a gate on the production bar. Part 11 puts it to work. Four capstones apply the same platform to four different jobs, and the point of doing four rather than one is the thesis the introduction opened with: a repository-audit fleet, an incident responder, a document-intake swarm, and a research service look like four different products, and underneath they are one architecture with the dials set differently.
How a capstone is presented
Each capstone follows the same structure, so you can read them as variations on a theme:
- The job and its shape. What it does, and which use-case gallery entry it realizes.
- The gates that dominate. Not all twelve gates matter equally for every job; each capstone names the two or three that carry it, which is where its design effort concentrates.
- The platform, configured. Which planes do the heavy lifting and how the dials are set, the topology, the fan-out bundle, the model portfolio, the trust posture.
- The build, costed and torn down. Each capstone is a real deployment (tier T2) with an up-front cost estimate, tagged resources, and a teardown checklist, honoring the lab catalog's rule that a T2 lab states its price before its deploy command.
The flagship, Capstone A, additionally gets an end-to-end local simulation (tier T0) that composes the whole platform into one runnable pipeline, so you can see every plane cooperating before spending a dollar on the cloud version.
The four, at a glance
| Capstone | Job | Fleet | Dominant gates | Star plane |
|---|---|---|---|---|
| A Repository-audit fleet | Find and verify bugs across a large repo | Hundreds, overnight | 3 Budgets, 6 Resumability, 8 Evals | The verification mesh |
| B Incident responder | Investigate an alarm, propose a fix | One to three, on event | 1 Identity, 10 Human control, 11 Blast radius | Trust |
| C Document-intake swarm | Extract and grade documents at volume | Tens to hundreds, streaming | 5 Failure semantics, 8 Evals, 9 Observability | The event-driven queue |
| D Research service | Fan out, read, fact-check, synthesize | Tens, per request | 3 Budgets, 8 Evals | The verification mesh again |
Read the "dominant gates" column and the four jobs separate cleanly: A and D are about spending a fleet's budget well and verifying its output; B is about trust because it touches production; C is about throughput and failure handling at volume. The same twelve gates, weighted four ways.
What the capstones prove
Each capstone is an existence proof for a claim the book has been making:
- Capstone A proves the platform runs at its hardest common case, hundreds of agents against a large input, overnight, under a budget, with adversarial verification and resumable progress. If A works, the others are subsets.
- Capstone B proves the trust plane holds when the stakes are real: an agent with production access that must be constitutionally unable to act without a human, defended by scoped identity and approval gates rather than a careful prompt.
- Capstone C proves the throughput and failure machinery holds under a continuous stream, where at-least-once delivery, idempotent effects, and honest confidence decide whether the volume flows or floods.
- Capstone D proves the verification mesh earns its tokens on open-ended work, where the product is the difference between claims that are checked and claims that merely sound right.
The recurring lesson, stated once for the whole part: the platform did not change between capstones; the configuration did. That is what it means to have built a platform rather than a demo, and it is why the book spent fifty-one chapters on the machinery and only four on the applications.
👉 Next: Capstone A, the flagship, with the end-to-end simulation that shows every plane of the platform cooperating in one run.