The Orchestrator

The first of those responsibilities is the hardest, because almost none of it is written down anywhere the system can reach. It includes the product history missing from the current repository, the customer cases that actually matter, the metrics that distinguish improvement from damage, and the situations in which the system must stop and ask. The more capable the systems get, the more that human work matters.

The same distinction is surfacing inside the companies building and deploying these systems, though it is arriving wrapped in workforce decisions that are neither settled nor comfortable. Marc Benioff has described Salesforce’s support organization shrinking from roughly 9,000 people to about 5,000 and connected the reduction to AI; headcount reductions can include layoffs, attrition, and roles not refilled, so the mechanism is his account, not a verified accounting.⁷ Amazon’s January 2026 statement said roughly 16,000 roles were affected; the company framed it as restructuring and efficiency, while the broader reading — that AI is changing the shape of organizations — is mine.⁸ Those are consequential and contested decisions, and I am not offering them as a model for the profession this book describes. They are evidence of something narrower: major companies have stopped treating AI as software that helps an employee work faster, and started treating it as part of the machinery by which the company operates.

The question for an orchestrator is what happens after that recognition lands. Do we use the machinery only to remove people from an old process? Or do we use it to create new forms of invention, service, analysis, and care, with humans deciding what the machinery is for?

Answering that in practice runs straight into the second responsibility, and the hard part is not writing the boundaries down but sizing them: the system gets enough authority to do the work, never enough to end the conversation. Those boundaries are not bureaucratic residue. They are part of the design, and calibrating them is most of the design.

The evaluation loop is where most of the difficulty actually lives, because the measures compete. A change that lifts completion rate can raise fraud; a change that cuts latency can cut accessibility. If the system investigates a reporting discrepancy, someone has to decide in advance what evidence would distinguish a data bug from a genuine change in customer behavior. None of this is ceremonial human approval bolted onto the end of an automated process. The human is developing the system that produces the options, choosing what it is allowed to learn from, and deciding whether the evidence is good enough to change the company’s behavior.

The company changes along with the job, and the changes are visible in the calendar. Product meetings become decisions about tradeoffs rather than reconstructions of customer complaints. Engineering meetings challenge an architecture map instead of rebuilding it from memory. QA reviews whether the evaluation reaches the real failure, security reviews the authority granted to the systems, and managers start budgeting for review capacity, memory, operations, and recovery rather than only for implementation.

The teams still exist; what changes is the handoff model. The connected system prepares a common working object that all of them can inspect and challenge.