The Orchestrator

The word delegated is doing a great deal of work in that phrase, much as artificial does in artificial intelligence, and it repays taking apart. When we say delegated intelligence, what exactly is being handed over?

The first thing is knowledge. An organization knows how it handles support cases, how it triages bugs, how it decides which features to build, how it reviews code, how it deploys changes — and that knowledge lives in people’s heads, in documentation, in past decisions, in code comments, in commit messages, and in the accumulated experience of a team. Building a delegated intelligence means getting that knowledge somewhere the system can reach it: into skills, instructions, examples, retrieval systems, policies, sometimes the training data itself.

The second thing is the decision tree. Someone handling support cases follows a mental sequence — read the complaint, identify the affected system, check for known issues, decide whether this is a bug or a feature request, route it to the right team, write the response — and that sequence can be encoded, imperfectly but usefully, into instructions, skills, and evaluation criteria. The system does not invent the decision tree. It inherits one.

The third thing is an approach, which is harder. A senior engineer does not simply follow a checklist; they have a sense of what matters, what to investigate first, when to be careful, when to move fast, when to ask for help, and when to stop. That sense resists encoding, and it can still be approximated through skills, examples, feedback, and accumulated corrections. The system’s approach will never be identical to the person’s, and within a bounded context it can be close enough to be useful.

The fourth thing is authority, and it is the one that matters most for the rest of this book.

When you delegate work to a person, you are not only handing over knowledge and instructions. You are granting the authority to make decisions inside a boundary: within this scope, you decide — you can approve this, reject that, change this, stop that. The authority arrives with limits attached, which is what makes it authority rather than abdication: a scope, a set of conditions, a duty to report, and somebody who can override.

Delegating work to a system has to work the same way. The system needs a permission envelope — a boundary defining what it can see, what it can change, what it can decide, and what it must escalate. Inside the envelope it has genuine authority to act. Outside it, it has none.

A system that can read your repository, write code, run tests, and open a pull request has been granted real authority — the authority to change software that real people depend on. A system that can read customer data and make recommendations has been granted authority over information carrying legal and ethical weight.

And as these systems become more central to ordinary life — managing power grids, medical logistics, financial systems, public services — the conversation is going to stop being about what the technology can do and start being about that authority. Who delegates it? Who is entitled to delegate it? Is the delegation explicit or merely implied? How is it recorded, reviewed, and reaffirmed over time? What happens when it needs to be revoked? Those are not abstract questions. They are what determines whether a system is governable at all, and answering them is the orchestrator’s job.

An orchestrator is not personally liable for every action an autonomous system takes; the organization that deploys the system must decide who owns the risk. But as autonomous systems act more directly, liability will become a sharper question. Regulation is already moving toward transparency, record-keeping, and traceability for high-risk systems — the EU AI Act imposes logging and transparency requirements on specified high-risk systems, and NIST’s AI Risk Management Framework emphasizes documentation for transparency and accountability, on a voluntary basis.³ The orchestrator does not need to become the lawyer. The orchestrator does need to make consequential actions reconstructable: what the system received, which version and instructions it used, what it did, and what happened next.