Capstone D: the research service
The last capstone, and the one where the product is most open-ended. Given a question and a budget, fan out searchers, read sources, adversarially fact-check the claims, and synthesize a cited report, exposed as a service with per-request budgets. Where Capstone C processed a stream of structured documents, Capstone D produces a piece of judgment on demand, and its whole value is the difference between claims that were checked and claims that merely sound right. The verification mesh returns as the star.
The job and its shape
This realizes the research-service use case: coverage requires parallel exploration down different paths, and quality requires verification agents that try to refute what the searchers claim, neither of which is expressible as a fixed pipeline. The topology composes two the book built: orchestrator-workers for the fan-out (searchers and source-readers) and a debate-and-judge mesh for the fact-checking. It is exposed as a service, so unlike the other three it runs per request with a per-request budget, which makes budget discipline a product feature rather than an ops concern.
Dominant gates: 3 (Budgets), 8 (Evals via verification). A research answer that blew its budget or cited a claim no one checked is a failed product, so those two gates carry the design.
The platform, configured for open-ended work
D is A's architecture, retuned from "audit a fixed repo" to "research an open question":
- Per-request budgets as a product feature (Chapter 42). Each request carries a token budget, and the admission ledger enforces it: a research run that exhausts its budget returns its partial findings with what remains enumerated, not a surprise bill or a runaway. Because the service is user-facing, "you asked for a $2 research run and got a $2 research run" is a promise the budget plane keeps. Gate 3, as a contract.
- The verification mesh is the product (Chapter 26). Searchers and readers are coverage-biased: they find lots, including things that are wrong. The fact-checking panel, blind and adversarial, tries to refute each claim against its cited source, and only claims that survive reach the report. The Capstone A lab's precision lift, 53% to 93%, is the same mechanism doing the same job on research claims instead of code findings, which is the point of having built it once: the mesh is job-agnostic. Gate 8, and the difference between research and confabulation.
- Citations are provenance (Chapter 34). Every claim in the report links to the source that supports it, through the event ledger, and the verifier checked the claim against that citation. A research report you can audit claim-by-claim is the deliverable; one that reads well but cannot be traced is exactly the thing the mesh exists to prevent.
The build (T2)
The full Hive control plane: searcher and reader workers on Fargate (runs are minutes, not seconds), the verifier panel with majority gates, per-request budget enforced at admission, the report assembled with citation provenance from the ledger, and a thin API in front (API Gateway plus a coordinator). The model portfolio: a strong model to plan the research and to verify (the best-judge rule, because a research service's verifier is its quality floor), middle-tier readers, and small models to pre-filter obvious noise before the frontier panel spends real tokens.
Costed and torn down. Per-request pricing makes the cost model
legible: a request's budget is its price ceiling, so the service can
offer tiers (a quick $0.50 answer, a thorough $5 one) that map directly
to token budgets the ledger enforces. Tagged lab:capstone-d; teardown
removes the API, the worker fleet, and the tables. The cost lesson D
closes on: when budgets are a product surface rather than an internal
guardrail, the admission ledger the book built in Part 6 becomes the
thing that lets you sell a bounded-cost research answer at all.
What Capstone D proves
That the verification mesh earns its tokens on open-ended work, where the product is judgment and being wrong is the whole risk. A research service that spends 10x more on checking than on finding, and returns a cited report where every claim survived an adversarial panel, is a service you can trust because of the machinery, not despite it. Gates 3 and 8, a budget ledger and a verification mesh, are what make "research on demand, under a bounded cost, that you can audit" a buildable thing rather than a wish.
The book, closed
Four capstones, one platform. A audited a repo overnight under budget with resumable progress; B investigated incidents with production access it could not misuse; C processed a document stream without double-filing or trusting a miscalibrated score; D researched open questions under a per-request budget with every claim verified. The platform did not change between them. The topology, the fan-out bundle, the model portfolio, the trust posture, only the dials moved, and that is the entire argument of the book made concrete: build the platform once, with its twelve gates, its six planes, its governor and ledger and mesh, and the applications are configurations of it.
That is the difference the introduction promised between a demo and a system. The demo agent from the first afternoon still works; what changed across fifty-six chapters is everything around it, the identity, isolation, budgets, replay, evals, observability, and the runbook that let a team be on call for it at 3 a.m. The loop was always the easy part. The platform was the point.
👉 The remaining pages collect the glossary and the references. The build is done.