The Orchestrator

Take a customer who asks for a small change to the return flow: let someone start a return without a paper receipt.

Before: the request sits in support tags until Friday, a manager summarizes it, and product discusses it the following week. Someone opens a Jira ticket. Engineering asks which API owns the decision, and the work waits for planning, then for a sprint, and eventually a developer writes one implementation. Not because it was necessarily the best answer, but because the organization was never going to fund two implementations in parallel just to compare them. That is how the work is usually assigned: one engineer takes the task, makes the decisions that seem reasonable, and hands over the result. QA finds an exception. Security asks some skeptical questions about how the purchaser’s identity is being verified. The fix waits for another release meeting. A simple customer request has consumed a month of coordination and nobody yet knows whether the proposed solution works.

That is the old picture, and it has worked until now. The fix itself might have taken an hour or two if the right people had simply talked to each other. Instead, the elapsed time is a month, because what is being paid for is not the fix — it is the coordination, the passing of work from one team to the next until the original question is barely visible in the artifact that comes out the other end. That is where all the time went, and there is no acceleration inside that structure. Every step in the process was reasonable on its own, and the organization could absorb the delay. But that is about to change.

After: the same request arrives at 4:00 a.m. Pacific time. What follows is an illustrative target state — a scenario I will use throughout this chapter — and the numbers in it are scenario assumptions, not results from a named deployment. The question is whether the shape of the work is plausible, and I will argue that it is. The shape is not speculative, either — only the scale is. Microsoft and LinkedIn’s 2024 Work Trend Index, a survey of 31,000 workers across 31 countries, found 75 percent of knowledge workers already using generative AI at work, 78 percent of them bringing their own tools rather than waiting for IT to sanction one, and — the number that explains Maya’s whole morning — 52 percent reluctant to admit they use it on their most important tasks, because 53 percent worry it makes them look replaceable.¹ People are already doing this work in the dark. Maya is what it looks like when someone finally does it with the lights on, and the organization decides to build around her instead of pretending she does not exist. By 5:00, five or six parallel agents have analyzed the customer evidence and characterized the problem: when the request occurs, when it does not, which cases are genuine, and which problems actually need to be solved. The work has moved from collecting information to deciding what to do with it.

The systems do not stop at a single recommendation. They explore several paths, test them in isolated branches and staging environments, and bring the results back for review. Some paths work better than others. The agents challenge one another, try additional approaches, and leave a record of what they tested and where each option failed. That is the important change: the team receives alternatives and evidence, not just one implementation produced by one engineer. Product has visibility into how these agents work and, in the best case, helps maintain them.

One of the agents belongs to Maya — a composite, assembled from practices that exist today (unapproved agent fleets, self-taught governance, senior engineers quietly carrying delegated authority), with no such person at any real home-goods company; the practice is the evidence, and Maya is how this book shows it. She is a senior engineer responsible for risk and compliance, and one of her agents evaluates proposed changes against the policies and requirements encoded into the system, records the evidence, and flags anything that falls outside the boundaries Maya has established. That is only the beginning of the governance model; a later chapter returns to how these controls are built and operated. For now, the important point is that governance becomes part of the orchestration rather than a separate process waiting at the end.

At 8:00 a.m. — four hours after the customer’s report — one of the paths is already staged for a controlled A/B test. It is not in production, and a human still has to approve the release. But there is now something real to approve: three working options, test results, a security review, a revenue-impact model, a support-impact estimate, and a rollback plan.

At 8:18 a.m., Maya receives the report:

Subject: Returns workflow — several solutions ready for review

We reviewed 1,840 customer conversations tagged return-without-receipt and prepared several possible solutions. Some work better than others. One is ready for a limited test. The evidence, assumptions, and risks for each option are attached. Approval, rejection, or a revised scope is required.

Maya now has something to decide. In some other organization, she might have to fight for a place in that decision, or wait for a chain of managers to make it for her. Here, she can bring the solution to management on the same day, along with the evidence for why it is the right one. That is more output than a team of forty could produce in a month.

Maya is not just inspecting code and making sure it is ready to be merged with the main branch. What Maya is doing is investigating how the decisions were made. What was the process? How did the independent agents reach this conclusion, and what is the evidence they had?

This is what an orchestrator’s job is now. It is making sure the system made its decisions with the right constructs and the right parameters in place: the context it needed, the authority it needed and no more than that, an evaluation that measured the outcome that mattered. That is a much more involved job than sitting in meetings. Maya still decides whether any of the work reaches production.