The Orchestrator

Before naming any specific tools, it is worth establishing what a delegated intelligence is actually made of — not a particular product, runtime, or architecture, but the components that show up in some form whenever you build a system capable of exercising delegated judgment.

This description is deliberately abstract, because the form factor is the least interesting thing about it. A delegated intelligence does not have to be an agent running in a persistent loop on a server, and it does not have to be always on. It could wake on a trigger, do its work, and go dormant. It could move between nodes — laptop, then server, then cloud instance — carrying its context along. It could exist for the duration of a single task and then disappear. What makes it delegated intelligence is not where it runs but which of the following parts it has, and few systems have all of them cleanly separated.

3.9.1 Directives

Directives are the instructions telling the system what it is supposed to do and how it is supposed to behave: the objective, the constraints, the rules of engagement, the prohibitions, and the conditions under which it must stop or escalate. They can be as simple as a prompt or as elaborate as a layered policy document with conditional rules, role definitions, and escalation procedures.

Directives are not the model. They are what the model is given to work with, which is why the same model under different directives is a different delegated intelligence.

3.9.2 Skills

Skills are procedural knowledge — the ability to do specific kinds of work in specific ways. A skill might describe how to review a pull request, how to investigate a production incident, how to format a compliance report, or how to triage support cases. What skills encode is the approach: not merely what to do, but how this organization does it.

Skills can be written by people, learned from examples, or refined through feedback, and they are one of the main channels by which an organization’s expertise reaches the system. In practice their quality and specificity determines the quality of the output more reliably than the choice of model does.

3.9.3 Context

Context is what the system knows during a run: the current state of the work, the relevant files, the conversation history, the customer record, the error log, the project background, and the constraints that apply to this particular situation. It is worth keeping distinct from memory — context is what sits in front of the system right now, while memory is what persists across runs.

Deciding what context the system receives is part of the orchestrator’s job, and it is a two-sided problem. Too little context and the system guesses; too much and the signal disappears into the noise. The right context is never everything the system could conceivably know. It is what it needs in order to make a good decision in this specific case.

3.9.4 Memory

Memory is what survives a run: facts about the organization, the project, the customer, the codebase, past decisions, past failures, and corrections that were applied. Memory is what lets a system operate as though it has been here before — even though a stateless API call may carry no memory of an earlier call, while the model’s weights still contain learned information and the surrounding agent may retain conversation or long-term memory.

None of that is automatic. A system without persistent memory starts fresh every time, which means it repeats mistakes, re-asks questions it has already had answered, and cannot build on its own experience — while a system with well-curated memory can recall that a similar approach failed last month, that a particular customer prefers a specific format, or that a certain kind of change always requires security review. The orchestrator decides what the system remembers and what it forgets, and memory is not a feature you switch on. It is a curated store, and the curation never finishes.

3.9.5 Tools

Tools are the system’s connection to the outside world. A tool might read a file, query a database, search a repository, open a ticket, run a test, deploy a change, send a message, or call an API, and collectively they are what turn the system’s judgments into actions.

Which is why tools belong in the definition of the system rather than in its implementation details. The same model with read-only access to a repository and the same model with permission to merge and deploy are two entirely different delegated systems.

3.9.6 Communication

The system needs some way to communicate, with other systems or with people or both, and that includes producing output a person can read, producing structured data another system can consume, handing off work to another agent, requesting approval, reporting status, and raising an alert when something has gone wrong.

A system that can reason but cannot communicate cannot do delegated work.

3.9.7 Learning: The Optional Ability to Learn

This component requires the most deliberate decision, and it is one of the most important conversations an orchestrator will have with the organization.

Some delegated intelligence systems can learn: they can update skills from feedback, add to memory from experience, and adjust directives based on what worked and what did not. It is worth being precise about what “learning” means here, because four different mechanisms get folded into that word: changing model weights through training or fine-tuning; retaining or retrieving memory; changing prompts, skills, or configuration; and selecting a proposed change for a later version. This chapter’s concern is the last three. None of them is a model being retrained. They are the system’s operational layer becoming more capable over time — which is also why they can be governed, versioned, and rolled back in a way that retraining cannot.

But not every system should learn on its own, and there are good reasons to want a system that is deliberately static — operating from instructions, skills, and permissions that do not change unless a person changes them. A system handling compliance reviews may need a fixed process that does not drift. A system making decisions about medical logistics may need decision criteria that are locked and auditable. A system touching financial records may need to be predictable above every other property.

Whether a system learns, how much, and under what limits is a decision with its own name — disposition — and it is the subject of the next section.