The Orchestrator

This chapter is about how an organization creates orchestrators, which is a harder problem than it looks.

Today’s orchestrator is usually an experienced developer, staff engineer, architect, or operations engineer who started using agentic systems for something beyond code completion. They know how software is built, they have learned to work with coding agents, and they are now pointing the same tools at production systems, operational workflows, evaluation, and continuous improvement. That is the current path into the role, and it will not be enough for the next generation.

What an organization needs is a way to train people who can work alongside a system as it develops, operates, and improves itself — people who understand how to give the system better questions, set goals, define a permission envelope, inspect the work, recognize failure, and narrow or stop the system when the evidence does not hold up. That cannot be done with a prompt-writing course, and it certainly cannot be done by handing a nontechnical employee an agent platform and calling them an orchestrator. An orchestrator does not have to be the best programmer or database administrator in the building. An orchestrator does have to understand technology well enough to reason about the system they direct.