The Orchestrator

I have been writing software and designing systems for more than three decades. I have been a developer, an architect, and, at various points, the person who had to explain to a room full of people why the system they had just approved was not going to behave the way they hoped. My father was a developer too, back when the work was more physical and more obviously constrained: punched cards, machine language, machines that made you wait. The distance between an idea and its execution was visible then. You could hold part of the program in your hands.

That distance has never disappeared. It has only moved.

I have watched the work change as the machines changed. The programmer went from manipulating instructions to composing systems, from writing everything by hand to standing on layers of libraries, services, frameworks, and infrastructure built by other people, and with each layer the systems became more capable and the work became more distributed. Responsibility never distributed with it. Someone still had to decide what the system was allowed to do, how anyone would know whether it had done it, and who would answer when it did the wrong thing.

For the last several years I have listened to people explain generative AI and come away with the same uncomfortable conclusion, which is that I do not think we have got it yet. The explanation is almost always one of two things. Either it is peak hype-cycle marketing, in which everything is about to be automated, every job is about to be transformed, and the future has apparently arrived on the schedule of a product launch — or it is the mirror image, a cynical account in which the technology is only a confidence trick, the use cases are all fraudulent, and nothing important is changing. Both are useful as reactions. Neither is a sufficient description of the work.

I began looking for a better description by writing fiction. Writing the Condition Set trilogy — Redundant, Contingent, and Essential — forced me past the demonstration and into the operating environment: who is present when a system acts, what authority they have, what evidence they can see, what the organization has chosen not to know, and what happens to ordinary people when a technical decision hardens into an institutional fact. In one of the novels, regulated industries are required to keep a certified orchestrator on the team. The title started as world-building — a plausible role inside a future regulatory regime, the sort of phrase that turns up in a standard before anyone has fully agreed what it means. But the more I wrote the word, the less it behaved like a science-fiction detail. Orchestrator. The role kept making sense.

Once I could see the role in the fiction, I started noticing its unfinished version in the present. I met people working with models and agents who were exhausted, and not because they had become less technical — because they had quietly taken on a second job. They were defining tasks for systems that could not reliably define their own limits, reviewing more output than they had time to understand, and deciding which errors mattered, which uncertainties could be tolerated, and which ones had to send the work back. They were doing orchestration without a title, a training path, or an agreed budget for the attention it consumed.

Companies were struggling with the same change from the other side. They wanted to know where these tools belonged, what work could be delegated, what evidence would be enough, and how an organization could move faster without confusing speed with control. So they reached for the familiar language — automation, productivity, transformation, augmentation — because the vocabulary available to them had been built for an earlier arrangement of work. That language was not exactly wrong. It was simply too small for what it was being asked to hold.

Meanwhile I kept reading an embarrassing amount of nonsense about the future, much of it from people who had not spent much time with the present. The market’s certainty was matched, beat for beat, by the skeptics’ certainty. And in both accounts the person who actually has to make the system work had gone missing.

This book is my attempt to put that person back.

The argument is not that every new tool deserves a new profession. It is that a profession is already forming around a genuinely new engineering problem: how to design and govern delegated intelligence when the output can exceed the capacity of any one person to produce, inspect, or remember. Naming it gives us something to examine, which is the whole point of naming it. A vague anxiety becomes a role with boundaries, artifacts, training, authority, failure modes, and consequences.

This book is written for the long term of AI’s impact, after the current vocabulary has gone stale. You may already be doing this work, or you may already employ someone who is. What follows gives the role a name, and then asks what training, authority, evidence, handoff, and institutional support that name has to carry.