The third chapter of The Orchestrator is now live: “What an Orchestrator Orchestrates.” This is the vocabulary chapter, and it exists because the field is new enough that people use words like agent, autonomous, orchestration, and intelligence as though everyone agreed on them. Nobody has. 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 — and then the two definitions produce two different answers about who was responsible. The chapter’s core move is a single distinction. A software developer builds and changes software. An orchestrator develops and operates delegated intelligence: systems that interpret a request, make a bounded judgment, produce an artifact, or take a limited action on a person’s or an organization’s behalf. Delegated intelligence gets a formal definition, because the phrase needs to survive contact with marketing: software that can interpret, choose, produce, or act within a defined boundary on behalf of a person or organization. No claims about consciousness or inner life. Bounded judgment plus action. From there the chapter works through what the word delegated actually hands over — knowledge, the decision tree, the approach, and authority — and authority is the one the rest of the book hangs on. When you delegate work to a person you grant the right to decide inside a boundary. Delegating to a system has to work the same way, which is why every delegated intelligence needs a permission envelope, not a hope. There is also a scale in this chapter, because the words sit somewhere in time. Assistance — a tool that performs one step faster, the person keeping the plan — is 2023–2024. Autonomous systems, running sequences of steps without a person directing each one, are 2025–2026. Delegated intelligence, an autonomous system acting on your behalf inside a boundary, is 2027 onward. Assistance accelerates existing work. Delegated intelligence redefines how organizations work. The product word agent blurs all three, which is why the useful question is never “is it an agent” but “whose authority does it carry.” Then the chapter takes delegated intelligence apart into its components: directives, skills, context, memory, tools, communication, and learning. None of these is a product. All of them show up in some form no matter whose model you use, whose runtime you deploy, whose framework you wire together. The parts practitioners should read twice Disposition. A fixed-disposition system does exactly what it was told, the same way, until a person changes it. A dynamic-disposition system updates its own skills, memory, and approach as it runs. Most production systems are mixed, and deciding where the line falls is the orchestrator’s call. The chapter also names a pattern I expect orchestrators to use constantly: run a system dynamic while the approach is still being discovered, guide it through several iterations of learning, then freeze it — lock the skills, curate the memory, settle the directives — so what runs in production is predictable. The learning is captured; the drift is retired. Learning sources. If a system learns, from whom? Not the open internet, not a conversation it overheard in a support channel. Named sources: your feedback, a designated reviewer, a curated set of approved examples. When you delegate work to a person, you don’t only tell them what to do; you tell them who to listen to. Delegated intelligence needs the same rule. The permission envelope. The boundary around a delegated intelligence, made of three things: the authority that grants it, the credentials that enforce it, and the general boundaries that guide it. Directives are interpreted — the model reads them and usually follows them. Credentials are enforced — a system holding read-only credentials cannot write, whatever its instructions say and however creatively it reads them. When the consequence is real, the boundary belongs in the credentials. And the envelope is static at runtime: the system may ask for a wider one, but it may never widen its own. What this chapter is not It is not about a Cursor plugin or an OpenAI tool, and it does not assign these concepts to easy-to-install software components. There is no product called a permission envelope and no setting called learning sources. The components are concepts, and an orchestrator has to be able to think in them, ask about them, and notice when one is missing — before any specific product matters. On pace: I am accelerating the authoring process for this book, and my plan is to release the bulk of it this month. Chapter 3 was the vocabulary. The chapters that follow put it to work. Read Chapter 3, “What an Orchestrator Orchestrates,” now. Then look at the systems you already run and ask the question the chapter leaves you with: whose authority do they carry? HQ 6 — Assembled. I set the direction, the argument, and the review. A drafting tool wrote portions of the prose; I assembled, edited, and take responsibility for the whole.