What this guide covers
A concise ownership map from the guide's eight-stage value stream and six architectural areas to the chapters that define each concept in full.
On this page4 sections
Use this page to answer two questions: Does the guide cover this? and Where is the canonical treatment? It is an index, not a third model.
For orientation, start with Chapter 2. Its eight-stage value stream explains how work progresses. Its six-area architecture explains where responsibility lives. This page maps the deeper material to those two models. The glossary preserves the full reference vocabulary.
Coverage by value-stream stage
| Stage | Core question | Orientation brief | Canonical depth |
|---|---|---|---|
| 1. Intent | What outcome is wanted, under which constraints, and how will success be recognized? | Builder Intent | Authoritative records, intent and specification, governance and risk |
| 2. Plan | How will the outcome be achieved, decomposed, routed, and proved? | Plan | Intent and specification, agent and loop engineering, quality contracts |
| 3. Define Agent | Which exact, eligible capability versions and grants bind to the work? | Define Agent | Agent Factory, model selection, routing, security |
| 4. Execute through Harness | How does probabilistic work run durably inside deterministic controls? | Execute through Harness | Control and execution planes, durable execution, harnesses and protocols, environments |
| 5. Apply Skills | How does reusable organizational method guide work without widening authority? | Apply Skills | Agent Factory, agent architecture, agent and loop engineering |
| 6. Evaluate | What independently proves that the exact Candidate is correct and eligible? | Evaluate | Quality and evidence, testing, evaluation, proof packages |
| 7. Improve | How do attributed outcomes become safer future versions? | Improve | Production feedback and review, governed learning |
| 8. Deliver Software | Who authorizes progression, and how does a Candidate become an observed outcome? | Deliver Software | CI/CD and production verification, platform operation, resilience |
Stage boundaries preserve important distinctions: Plan approval does not dispatch execution; execution completion does not prove correctness; verification does not grant acceptance; acceptance does not imply merge; merge does not prove a production outcome.
Coverage by architectural area
Intent
Intent covers the human–agent operating model, business outcome, specification, durable records, risk, authority, economics, attention, and coordinated multi-repository scope.
- Chapter 4: human roles, agent boundaries, delegation, and escalation.
- Chapter 5: Company, Workspace, Repository, Mission, Plan, WorkOrder, Task, Attempt, Candidate, evidence, and release records.
- Chapter 6: requirements, ambiguity, Definition of Correct, and quality contracts.
- Chapter 7: policy, authority, autonomy ceilings, exceptions, and risk-tiered approval.
- Chapter 8: trusted throughput, cost per accepted outcome, budgets, and scarce human attention.
- Chapter 10: workspace manifests, coordinated change sets, dependency ordering, and atomic delivery limits.
Harness
Harness covers the control and execution planes, orchestration, durable state, retries and recovery, inner and outer harness contracts, protocols, environments, tools, context, memory, and autonomous workflows.
- Chapter 13: authority boundaries, command and event contracts, workflow state, and admission.
- Chapter 14: Tasks, Attempts, leases, fencing, idempotency, checkpoints, pause, cancel, and recovery.
- Chapter 15: inner and outer harnesses, adapters, lifecycle hooks, MCP, ACP, AG-UI, and A2A.
- Chapter 17: reproducible development environments, sandboxes, compute fleets, isolation, and capacity.
- Chapter 18: agent loop, tool gateway, MCP use, context, and memory mechanics.
- Chapter 19: data quality, authoritative knowledge, ingestion, retrieval, semantic contracts, provenance, and freshness.
- Chapter 20: per-attempt context selection, compilation, sufficiency, lifecycle, and evaluation.
- Chapter 26: long-running, bounded workflow patterns and stopping behavior.
The guide keeps knowledge preparation, per-Attempt context selection, harness execution, and workflow governance distinguishable. They may share infrastructure, but they fail differently and need different owners.
Capability
Capability covers reusable agents, skills, tool contracts, workflow templates, registries, packaging, versioning, evaluation, publication, deprecation, quarantine, and revocation.
- Chapter 11 owns the capability supply chain and registry lifecycle.
- Chapter 18 defines the relationship among model, agent, skill, tool, and harness.
- Chapter 23 covers bounded loops, convergence, topology, escalation, and producer–verifier separation.
- Chapter 34 covers contribution, ownership, paved roads, and capability release clocks.
Model
Model covers profiles, eligibility, provider adapters, routing, fallback, reasoning effort, context limits, latency, reliability, privacy, and token economics.
- Chapter 21 owns profiles, eligibility, adapters, and capability selection.
- Chapter 22 owns routing, fallback, escalation, and route evaluation.
- Chapter 8 owns budget and cost-per-outcome measures.
- Chapter 29 owns the evaluations required to make routing and model replacement real.
Models are capabilities, not workflow architecture. The best route for a stable transformation may be deterministic software rather than a model.
Trust
Trust covers independent verification, testing, evaluation, evidence, provenance, currentness, human decision rights, security, identity, policy, privacy, supply chain, and compliance.
- Chapters 27–31 move from quality architecture through tests, eval assets, and proof packages.
- Chapter 32 connects exact-current evidence to CI/CD, rollout, and observed production health.
- Chapter 33 owns workload identity, least privilege, secrets, untrusted context, agentic threats, containment, provenance, and supply-chain controls.
- Chapter 35 connects logs, metrics, traces, events, lineage, and forensic reconstruction.
- Chapter 36 covers failure classification, incident response, recovery, and operator intervention.
- Chapter 37 covers operator surfaces, events, storage, and durable control-plane contracts.
Learning
Learning covers production feedback, reproduction, automated review, merge maintenance, datasets, experiments, failure clustering, governed adaptation, promotion, rollback, and compounding engineering.
- Chapter 39 owns feedback-to-reproduction, risk-tiered automated review, structured findings, and merge-queue operation.
- Chapter 40 owns learning signals, diagnosis, experiments, and governed proposals.
- Chapter 41 owns promotion gates and the path from correction to skill to automation.
- Chapter 42 shows which parts exist in Mission Control, which are partial, and which are future.
Learning is allowed to propose aggressively. Promotion changes authority or behavior and therefore follows explicit evidence and policy.
Adoption surrounds the architecture
Adoption is not a seventh architecture area. It is the operating concern around all six: product experience, platform ownership, rollout, support, governance adoption, build-versus-buy, organizational change, and the metrics that prove repeated value.
- Chapter 34 owns the platform product and contribution model.
- Chapter 38 owns staged adoption, infrastructure choices, migration, and enterprise operating concerns.
- Chapter 43 turns the material into an explanation, defense, and practice program.
- Chapter 44 identifies future directions without making them current requirements.
Reference material
The appendices support lookup and verification rather than the main teaching sequence:
- The glossary preserves the complete vocabulary.
- The Principles appendix collects durable theses for review.
- The research canon records external sources and provenance.
- The Mission Control maturity map is the canonical source for implemented, partial, and future case-study claims.
- Coverage and maturity, the changelog, and the reviewer guide track the state of the guide itself.
- The software architecture and system design study guide supports architecture design, technical reviews, and design defense.
Protocol and vendor details are time-sensitive. The owning chapters link to official specifications and state the review boundary. They should be reverified before a production decision.
Recommended routes
- First-time reader: How to read → Chapter 1 → Chapter 2 → the six-part guide.
- Executive: Chapter 2 → governance → economics → adoption.
- Architect: Chapter 2 → the relevant architectural area above → Mission Control evidence.
- Builder: Search for the task or term → open its owning chapter → use the stage brief to see the upstream and downstream contract.
- Reviewer: Start from the claim → inspect its
Go deepersources → check the evidence boundary and currentness → distinguish standard, research, vendor claim, practitioner opinion, internal synthesis, and repository evidence.
For the full chapter list, use the guide index.