The Orchestrator

The profession begins with a single distinction: between a person who uses software and a person who develops a system that can do work on their behalf. A software developer writes and changes software. An orchestrator develops and operates delegated intelligence — systems that can interpret a request, make a bounded judgment, produce an artifact, or take a limited action for a person or an organization.

The precision is necessary because the field is new enough that people use words like agent, autonomous, orchestration, and intelligence as though everyone agreed on them. Nobody does. Two people can have an entire conversation about AI agents and only discover at the end that one of them meant a chatbot that drafts text while the other meant a system that reads a repository, changes code, runs tests, and opens a pull request. The disagreement stays invisible until something goes wrong, at which point the two definitions produce two different answers about who was responsible.

I am not trying to legislate the language, which would be futile anyway. Other people will use these words differently, and the field is renaming itself almost weekly — the Introduction’s note on Stellman’s AI-driven development is one example of that churn being handled well.¹ What I want is a working vocabulary for this book, so that when it says delegated intelligence or orchestration you know what it means and, just as importantly, what it does not.