The Orchestrator

Do not start by deleting departments. Start by assigning responsibilities, because every orchestrated system needs at least:

• an outcome owner;
• a human orchestrator;
• a domain specialist;
• an evaluation owner;
• a runtime or operations owner;
• a security and data-protection contact; and
• a customer or frontline representative.

In a small organization one person may hold several of those responsibilities, while in a larger one each may be a team. What matters is that the responsibilities are named and the handoffs are visible.

Team shape. The software world already has a vocabulary for this, and it maps cleanly onto orchestration. Team Topologies, a team-design method in wide use, recognizes four team types: stream-aligned teams that own a flow of work end to end; platform teams that provide internal services the other teams build on; enabling teams that help other teams gain a capability and then move on; and complicated-subsystem teams, where deep specialist knowledge concentrates.⁹ An orchestrated organization uses the same four. The outcome cell — a small team that owns one outcome and the delegated system that serves it — is the stream-aligned team. The platform group, which runs the shared agent infrastructure, permissions, and telemetry, is the platform team. The senior orchestrators who train residents and audit permission envelopes form the enabling team. The component specialists this chapter described are the complicated-subsystem owners. For size, Amazon’s long-standing two-pizza rule — no team too big to feed with two pizzas, in practice fewer than ten people — is a good ceiling, and orchestration changes the reason for it: a cell of five to eight people no longer includes anyone hired for routine execution, so the working constraint is how much candidate work the humans can review.¹⁰ A representative outcome cell has one orchestrator, one goal owner, one senior reviewer, one runtime or operations owner, part-time embedded specialist capacity, and — once the program is mature — a resident from the Chapter 12 path. Chapter 10 named the roles; the cell is where they sit together.

How many orchestrators. There is no universal ratio, and the number has to be derived from your own inventory. The arithmetic: orchestration collapses the routine-execution category from section 11.4’s sort while leaving expert judgment and system responsibility roughly constant or larger, so count the judgment load first — consequential decisions per week, how many need an evidence pack, how many need a human approval. Then derive the structure from the outcome streams: one orchestrator per cell, at the scope that connects components into an end-to-end process; a two- or three-person platform group once more than two or three cells share infrastructure; and one orchestrator at the enterprise scope — common permissions, telemetry, review, and escalation across systems — for roughly every three to five cells. A mid-sized organization with four critical workflows might end up with four cells, that platform group, one enterprise orchestrator, and a senior orchestrator supervising one or two residents: six to nine people doing orchestration work at different scopes, plus the specialists. Those numbers are illustrations, not targets; the real inputs are your decision load and your review bandwidth, and if the review queue is the bottleneck, adding orchestrators makes it worse. What the number does not do is shrink to zero. The two cases at this chapter’s start are the poles: Block cutting toward a model-coordinated structure of answerable individuals, JPMorgan building bounded assistants by the thousand on a platform — and in both, somebody is still paid to be accountable when things go wrong.

Specialists. Yes — you still employ specialists, and the more consequential the systems, the more senior they need to be. What changes is the work. The database administrator whose week went to writing schema changes and fixing queries now spends it on migrations, recovery design, data lineage, and reviewing the changes a cell’s system proposes, because the routine end of the old job is what delegated systems absorb first. The security specialist moves from ticket-level access reviews toward permission-envelope design, agent attack surface, and the injected-instruction threats of Chapter 14. The operations specialist moves from executing runbooks by hand toward owning the runtime, the stop conditions, and the rollback. None of this is a demotion; it is the removal of the routine layer that used to bury the expertise. The failure mode is not keeping specialists. It is keeping too few of them, shared across too many cells, so that they harden into a slow approval queue. Publish what each specialist reviews, what evidence they require, how quickly they respond, and when they must be involved, and let several of them review one evidence packet in parallel when a decision touches all their areas.

There is also a newer responsibility working its way onto that list, and it deserves naming because no existing department owns it outright. In a highly orchestrated system responsibility for one decision can be a matrix of entities rather than a single owner — the decision-authority matrix of Chapter 5, Section 5.7.2 — and somebody has to be accountable for reading and recording that matrix. That is not a security policy alone, and it does not fit the old org chart: it is a new organizational responsibility — part authority design, part record-keeping, part review.

A company that builds one orchestrated system and leaves every surrounding department unchanged has created an impedance mismatch, and tool adoption does not repair unclear priorities, weak testing, or overloaded review.¹¹ The system will be able to act continuously while the organization can only respond through weekly meetings, quarterly releases, and informal requests sent to whoever happens to know the answer.