The Orchestrator

Underneath everything in this chapter, the stack is simple enough to draw:

objective
   ↓
context + memory + skills + evidence
   ↓
inference engine
   ↓
task agent: interpret → choose → act → inspect
   ↓
tools and data interfaces
   ↓
deterministic infrastructure
   ↓
state, traces, evaluation, approval, rollback
   ↓
next agent, human reviewer, or stop

The controls in that stack are not intelligent at all, and they determine whether intelligence can safely act: sandboxes, containers, worktrees, operating-system permissions, API scopes, approval queues, secrets management, rate limits, feature flags, deployment gates, rollback mechanisms. A system that can propose a change differs from one that can apply it, and a system that can apply a change in a branch differs from one that can merge. Authority is a sequence rather than a checkbox. Concretely: an agent may be allowed to open a branch, and not to run the tests on that branch; allowed to run the tests, and not to open a pull request; allowed to open a pull request, and not to approve or merge one; allowed to merge, and not to deploy. Each step should be a separate grant, granted by a separate decision, and separately revocable where the enforcement system supports it. When you look at a delegated system, do not ask “is it authorized?” — ask “authorized for which of these steps, by whom, and until when?”

HQ 8 — Authored. I wrote the argument, structure, examples, and prose. AI tools were used for research assistance and light editorial polish; the voice, ideas, and substance are mine.