The Orchestrator

Several routes lead into the role, and the two that matter most right now start from opposite ends of the problem.

If you already know how to build these systems, you have to take that knowledge and learn how to orchestrate systems doing similar things — the kind of work you have built by hand — and you also have to learn how the business works: what the workflow being automated is for, what the customer experiences, where the organization makes or loses money. If you already know how the business works, you have to learn just enough about how systems are built — code, data, permissions, testing, deployment — to understand what you are directing and hold it accountable.

Neither route is shorter than the other, whatever the vendors selling prompt training would prefer you believe.

What you read after every frontier-model release. The claim is that the technical part is over and anyone can build software now. To be plain about it: if you are not familiar with technology, you should not be trying to orchestrate a system without the assistance of someone who has implemented that kind of technology before. It might be a mobile app on iOS, a web server, a system consuming open-source components — there is still a lot of knowledge required to orchestrate the operation of these things. The creation of them might be automated — a first-person-shooter demo, a simple website — but if you are technical, you can still tell there are some flaws in what is generated.⁴ You still really need technical experience to use these things profitably.

6.2.1 The experienced developer or architect

This is the most common route today, taken by someone who already understands repositories, services, data, deployment, and failure, and who started with coding assistance before moving toward agentic development. Their next training is a widening of scope, and they have to learn to:

1. Start from a goal rather than a ticket.
2. Map the whole workflow rather than one repository.
3. Ask delegated systems to investigate and compare options.
4. Define what the system may do without approval.
5. Design evaluations before allowing the system to act.
6. Operate the system and interpret its telemetry.
7. Change the instructions, tools, tests, routing, or permissions when evidence shows a problem.
8. Explain the system to security, operations, finance, customer service, and executives.

The developer is not leaving engineering. They are taking responsibility for more of the engineering system.

6.2.2 A supervised assignment

Asha, a senior orchestrator, gives Marcus, an experienced developer learning the role, a real system to study, and she does not ask an agent to answer the question for him. She asks Marcus:

What would have to change in this system for the requested behavior to be safe in production?

Marcus has read-only access to the repository, API documentation, database schema, tests, deployment configuration, incident records, and runbooks. He must trace the request through the implementation himself. He identifies the input, the service that receives it, the data that changes, the tools and agents involved, the permissions applied, the tests that cover the behavior, and the people who would be affected by a mistake.

He does not have to memorize every file. He does have to understand the relevant implementation well enough to explain it, identify its assumptions, and say what evidence is missing, and if he cannot trace the request without asking an agent to summarize the code for him, he is not ready to hold authority over the system.

None of which is punishment for using AI. It is the training exercise that gives him a system model, so that later, when an agent does most of the mapping and proposes the changes, Marcus can evaluate that work because he learned the underlying system first.

Asha then asks him the questions the system should eventually learn to ask before it proceeds:

• What does this request change?
• Which records and permissions does it touch?
• What could be true in the interface but false in the database?
• Which existing tests would fail to catch the mistake?
• What is the smallest safe change?
• What would require a new approval?
• How would we operate this if the model were unavailable?

6.2.3 The domain expert

A claims specialist, warehouse operator, nurse, accountant, or customer-service leader often understands the consequences of a decision better than any engineer does, and that person can absolutely become an orchestrator — though not by learning a vocabulary of prompts. What the domain expert needs is a technical foundation: reading a simple program, inspecting an API request, identifying a sensitive database field, understanding a test, tracing a decision, recognizing a permission change, following a rollback. Enough, in other words, to challenge the system and to ask a technical specialist a precise question. In exchange they bring the knowledge engineers usually lack — the real meaning of a record, the exceptions buried in a process, the regulatory consequence, and the human cost of being wrong.

6.2.4 The operations or reliability engineer

Operations people already understand monitoring, incidents, runbooks, escalation, and recovery, and what they have to learn is how models, context, memory, agent handoffs, evaluation sets, and permission envelopes change those practices. They tend to be well suited to orchestration because they are already in the habit of asking what happens when a dependency fails, and an orchestrator has to ask that same question about a model provider, a retrieval index, an agent loop, a tool credential, or the system’s own learned procedure.

---

4. Microsoft Research, WHAMM! Real-time world modelling of interactive environments, April 2025, https://www.microsoft.com/en-us/research/articles/whamm-real-time-world-modelling-of-interactive-environments — an interactive, AI-generated rendition of Quake II gameplay served through Copilot Labs. Microsoft’s own framing: “Think of this as playing the model as opposed to playing the game” and “We do not intend for this to fully replicate the actual experience of playing the original Quake II game.”↩︎