The Orchestrator

Up to this point, most of the examples in this book have involved agents helping people develop software. A coding agent can inspect a repository, propose a change, generate tests, and open a pull request, which is an impressive use of delegated intelligence and also a forgiving one. The agent may well be wrong, but the work is happening in a development branch, a sandbox, or a test environment, where a developer can inspect the result before it reaches a customer. A bad development run creates rework. A bad operational decision reaches customers before anyone has time to look at it.

So this chapter changes the subject to agents supporting the operation of a business or a live production system, which is a completely different kind of work with completely different requirements. When you orchestrate the operation of a business, you are building things that make decisions — decisions that can affect real humans, real accounts, real shipments, real power. The downside stops being a bad pull request. That is why this chapter talks about rules and procedures that do not exist yet as finished products. The beginning of this practice is visible everywhere; nobody has perfected it, and the parts that are missing have to be designed by hand for now.