The Orchestrator

Not every human review is a meeting, and one of the quiet institutional wins of orchestration is that the organization can finally be precise about which decisions need a room. The instrument is the approval map: a written definition, for a given system, of what may happen with no human involvement, what needs one person, what needs several owners, and what needs formal sign-off. Maya’s version has four levels, and the pattern generalizes. (Maya, for the reader starting here: the composite senior engineer whose home-goods company opened this series — she began with three unapproved agent workflows on her laptop and no second operator, and the last volume left her the morning she stopped being the only person who could see what her systems were doing.)

Level 0 — the system acts. A clear production bug inside an existing service: the fix adds no feature and changes no promise, tests demonstrate the failure and the correction, the deployment passes the normal pipeline and can be rolled back. The system fixes it and releases it, and the humans find out in the changelog. Nobody needs ten people in a room to approve correcting a crash.

Level 1 — one human reviews. A change inside the existing permission envelope with real customer effect: a limited change to the return page, an adjustment to a retry policy. The named owner reads the evidence and approves or rejects, usually asynchronously.

Level 2 — several owners review. The change crosses departmental responsibilities — refund timing touches product, finance, support, and operations. The system routes the proposal to all of them; they review in parallel, mostly asynchronously; the meeting happens only when the owners need to argue tradeoffs with each other, and when it happens, the system brings the evidence, the prototypes, the affected customer groups, and the exact decision required. The meeting is Level 2’s escalation path, not its default.

Level 3 — formal approval. The change moves the boundary itself: using customer data for a new purpose, granting an agent access it did not have, changing which system can issue refunds, entering a new region or regulated category, changing a public promise, doing anything difficult to reverse. The system recognizes these conditions from the proposed change itself, halts its own execution, explains why it stopped, names the required approvers, and prepares the code, the tests, and the impact analysis. It may not grant itself the new authority.

Read as a diagram, the map is a gate at every boundary, with the gate width set by the blast radius:

 agent proposes
      │
      ▼
 [Level 0] no human ──► act (bounded bug fix, tests prove the promise held)
      │ only if outside Level-0 scope
      ▼
 [Level 1] one owner ──► act (in-envelope, real customer effect)
      │ only if crossing a department
      ▼
 [Level 2] owners together ──► act (refund timing, shared surface)
      │ only if the boundary itself moves
      ▼
 [Level 3] formal approval ──► act (new data use, new access, new promise)

One institutional note. The map is the meeting policy: read the four levels and you know which conversations the institution needs to have and which it has stopped needing. Chapter 7 covers how the levels get enforced in policy engines and runtimes; the point here is that the enforcement is organizational first and technical second, and the artifact itself fits on one page.

There is one more human capacity worth naming, because it is the institutional twin of the approval map: when the prepared evidence is wrong, somebody has to investigate. The investigation runs across the whole workflow and then deep into one component — the wide mode and deep mode of Chapter 16, Section 16.5, which covers the mechanics. What belongs in this chapter is the institutional fact: the investigation role must exist, be named, and be staffed, or the first wrong pack will turn the after-meeting back into the before-meeting — ten people, guessing, assigning homework.