The Orchestrator

Chapter 3 defined seven components and the vocabulary around them, one at a time, and a list is easy to read and hard to hold. They are not separate things. They are parts of one arrangement that runs the same way every time, and the arrangement is easier to remember than the list:

The arrangement starts with a need — someone outside the system wants something changed. A customer wants a feature. An operator wants an incident closed. A finance team wants a report that is currently assembled by hand. The need is not a technical artifact; it is the reason the system exists, and it comes from outside the loop.

The need becomes an objective once it has a shape the system can act on. That shape has four parts, and Chapter 3 named each of them: the objective itself (what does success look like), the context (what the acting systems are allowed to know about the need and the world), the memory (what they carry from past runs), and the permissions (what actions the loop is allowed to take while pursuing the objective). This is the layer the orchestrator writes, and it is where the work is either made safe or made dangerous — an objective without context produces confident nonsense, and an objective without permission limits produces a system that can do anything in pursuit of it.

Then the work happens. Delegated-intelligence systems — agents, models, and deterministic tools connected together — interpret, plan, build, test, and monitor. This is the layer with the machinery in it, and Chapter 5 surveys it piece by piece: the inference engines, the retrieval, the memory systems, the tools, the policy engines. Notice what the arrangement says about it: the work layer is in the middle, not at the top. It does not own the objective, and it does not own the decision.

The work returns evidence, not just results. Artifacts, decisions, and handoffs come back out of the loop in a form a person can inspect: the plan that was followed, the alternatives that were rejected, the test results, the security review, the record of who did what and when. This layer is what separates an orchestrated system from a black box. The evidence is the reason a person can approve the next layer honestly rather than on faith.

And the arrangement ends with a decision that belongs to a person. Review, approval, intervention, or stop — the loop closes when a human looks at the evidence and chooses. Sometimes that decision is routine, a glance and a signature. Sometimes it is the whole job, the moment where hours of automated work are either released or thrown back. Either way the arrangement reserves it for a person, and the orchestrator’s judgment is exercised most directly there.

Two things in the figure are not layers, and both matter. The orchestrator spans all five: the objective layer is designed, the work layer is assembled, the evidence layer is specified, and the decision layer is governed by the same person, so the arrangement is a designed loop rather than a stack of parts that happen to be adjacent. And the arrows on the sides close it: evidence returns to the decision, and the decision flows back — approval releases the work, rejection sends it back with the reason attached. A system where the work layer never returns to the decision layer is not an omission in the diagram; it is the failure mode Chapter 9 is about.

No single piece of this arrangement is new. Workflow engines moved work between queues, ticketing systems tracked handoffs, and humans reviewed results long before delegated intelligence. What is new is that the interpretation in the middle is now done by systems that can act with judgment — and the moment that is true, the surrounding layers stop being paperwork and start being the safety architecture.