The book's vocabulary
67 terms from the book's glossary, published as data. Each definition is the book's working meaning — including the distinctions the book exists to draw, like the difference between a permission envelope and a capability, or fixed and dynamic disposition.
terms.json · stable IDs like https://readorchestrator.com/vocabulary/permission-envelope/ · search the book
Delegated systems helping create, test, review, and prepare software, usually supervised at the artifact boundary. Contrast operational orchestration.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.2 The survey: connecting the taxonomy to the market, Chapter 3: Delegation Is Architecture — 3.1 Operational orchestration + 1 more section
Using a tool to perform an existing task faster, while the person remains the source of the plan and the surrounding process stays intact. Valuable, and not by itself a new profession.
Discussed in Chapter 1: Your Next Job Title Is Orchestrator — 1.3 The orchestrator job changed before the title did, Chapter 2: You May Already Be an Orchestrator — 2.4 For managers + 13 more sections
Related essay: Chapter 3 Has Been Released
Software that can perform a sequence of actions without a person directing every step in real time. Autonomous does not mean conscious, self-aware, or capable of forming its own intentions.
Discussed in Chapter 3: What an Orchestrator Orchestrates — 3.4 What is delegated?, Chapter 1: Your Next Job Title Is Orchestrator — 1.5 The real revolution + 5 more sections
Related essay: Chapter 3 Has Been Released
What a system can technically do. Capability alone grants neither permission to execute an operation nor authority to decide that it should occur.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.14 The chapter in one picture, Chapter 1: The Orchestrator's Toolkit — 1.3 Inference engines and models + 48 more sections
Related essay: Governing Agents as Their Understanding Changes
Software that can interpret, choose, produce, or act within a defined boundary on behalf of a person or organization. The capability is granted, bounded, and still owned by the person or institution that delegated it.
Discussed in Chapter 3: What an Orchestrator Orchestrates — 3.9 The components of a delegated intelligence, Chapter 3: What an Orchestrator Orchestrates — 3.3 Delegated intelligence + 30 more sections
Related essay: Chapter 3 Has Been Released
Three lifecycle functions: building and testing capabilities; performing authorized work; and investigating shortcomings and proposing revisions. They may be agents, services, workflows, or teams. An orchestration layer coordinates their handoffs and enforces promotion rules.
Introduced in the glossary
Writing that treats unfinished pieces of the present as reportable without pretending the profession has already consolidated.
Discussed in Introduction — This isn’t here yet, What More Will Be Required — 18.9 Near-future nonfiction, one last time + 1 more section
Delegated systems that observe and act inside a live business environment, supervised at the decision and consequence boundary. Contrast agentic development.
Discussed in Chapter 3: Delegation Is Architecture — 3.3 Topology, Chapter 3: Delegation Is Architecture — 3.1 Operational orchestration + 3 more sections
The design and governance of delegated intelligence so that connected systems can pursue a bounded objective while remaining understandable, reviewable, and stoppable.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.12 Multi-agent coding systems, Chapter 1: The Orchestrator's Toolkit — 1.14 The chapter in one picture + 82 more sections
Related essay: Chapter 4, “Orchestration in Practice,” is available
The professional responsible for the objective, context, connections, authority, evidence, evaluation, intervention, and consequences of a system of delegated intelligence.
Discussed in Chapter 5: Orchestration in Practice — 5.3 Before and after: two ways to change a website, Chapter 3: Delegation Is Architecture — 3.2 Contracts and grants + 113 more sections
Related essay: The Orchestrator Ecosystem
The person responsible for building or changing software. The unit of work is code. Distinct from an orchestrator, whose unit of work is the outcome.
Discussed in Chapter 3: What an Orchestrator Orchestrates, Chapter 3: What an Orchestrator Orchestrates — 3.1 Software developer + 2 more sections
The scope of independent judgment entrusted to a system: decision subjects, permissible consequences, required evidence and conditions, and limits on adopting changes to its authoritative operating model. The permission envelope records and enforces those bounds.
Introduced in the glossary
Related essay: Bounded Agency: When Meaning Changes Authority
What the system may decide without a human, and which customers, shipments, accounts, or patients that decision can affect.
Discussed in Chapter 3: Delegation Is Architecture — 3.5 Design review and the profession, Chapter 4: Living with Nondeterminism — 4.2 The failure envelope
The judgments and consequences a person or institution has delegated under specified conditions. Distinct from technical capability and resource-operation permission.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.7 Identity and access control
Related essay: Bounded Agency: When Meaning Changes Authority
The conditions under which the system must stop acting and ask a human or a higher-authority system to decide.
Discussed in Chapter 3: Delegation Is Architecture — 3.1 Operational orchestration, Chapter 3: Delegation Is Architecture — 3.5 Design review and the profession
Giving a system more reach, permissions, or autonomy than the task requires. Injection is the input-side compromise; excessive agency is what gives it consequences.
Discussed in Chapter 5: Keeping Agents Uncompromised — 5.1 What compromise looks like, Chapter 5: Keeping Agents Uncompromised — 5.6 The orchestrator’s security job is not Infosec’s job
Grant only the access the work requires, and narrow it as the system matures. Applies to service accounts and to an agent's freedom to change itself.
Discussed in Chapter 3: What an Orchestrator Orchestrates — 3.10 Fixed and dynamic disposition, Chapter 3: What an Orchestrator Orchestrates — 3.13 What this chapter is not + 5 more sections
Related essay: The Other Permission System
The bounded authority to affect a live system, business process, or customer outcome.
Discussed in Chapter 3: Delegation Is Architecture — 3.1 Operational orchestration
The conditions in which an automated response is expected to be safe: signals, thresholds, actions, rollback, and response time specified in advance.
Discussed in Chapter 3: Delegation Is Architecture — 3.1 Operational orchestration, Chapter 4: Living with Nondeterminism — 4.2 The failure envelope
The boundary around a delegated intelligence: the authority that grants it, credentials and enforcement controls that bound it, and directives that guide it. The system may not widen its own authority. Changes require an authorized person or control process outside its reach.
Discussed in Chapter 3: What an Orchestrator Orchestrates — 3.12 The permission envelope, Chapter 5: Orchestration in Practice — 5.6 Concrete artifacts — what exists, and why it is not enough + 33 more sections
Related essay: Chapter 3 Has Been Released
Adopting an identified candidate release for operation after the required validation and authorization. It may follow a human decision or previously approved rules enforced outside the proposing agent.
Discussed in Chapter 3: Delegation Is Architecture — 3.2 Contracts and grants, Chapter 1: Your Next Job Title Is Orchestrator — 1.2 The Orchestrator + 8 more sections
A nonhuman identity under which software accesses resources. Credentials authenticate that identity; permission grants and policy determine what it may do. A service account with narrowly scoped grants can help enforce a permission envelope.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.7 Identity and access control, Chapter 3: What an Orchestrator Orchestrates — 3.12 The permission envelope + 2 more sections
A named case in which the system must halt, escalate, or reverse rather than continue.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.10 Task agents, Chapter 3: Delegation Is Architecture — 3.2 Contracts and grants + 4 more sections
What the system knows during a run: the current work, files, conversation, records, and constraints that apply to this case. Distinct from memory, which persists across runs.
Discussed in Chapter 2: The Instructions Are Part of the System — 2.5 Diagnosing the environment, Chapter 2: The Instructions Are Part of the System — 2.1 Layers beneath the prompt + 75 more sections
Related essay: Chapter 5 Is Now Available
The token capacity of one model request, including the input and reserved output. An agent run may make many such requests. Tools compress, summarize, or drop content to fit; what survives depends on the system's context-management rules.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.3 Inference engines and models, Chapter 2: The Instructions Are Part of the System — 2.1 Layers beneath the prompt + 4 more sections
Instructions telling the system what to do and how to behave: objective, constraints, prohibitions, and the conditions under which it must stop or escalate. Not the model. What the model is given to work with.
Discussed in Chapter 3: What an Orchestrator Orchestrates — 3.10 Fixed and dynamic disposition, Chapter 3: What an Orchestrator Orchestrates — 3.9 The components of a delegated intelligence + 8 more sections
Related essay: Chapter 3 Has Been Released
The model that interprets a goal and generates language or structured proposals for next steps. The runtime selects and executes tool calls around it. Typically a large language model generating next tokens from learned distributions, not a database lookup.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.3 Inference engines and models, Chapter 2: The Instructions Are Part of the System — 2.2 The instruction tree + 17 more sections
The instructions a run carries — system, organization, project, skill, user — each with a different scope and lifetime. Retrieved material supplies evidence and context; it does not acquire authority merely because the model reads it. Confusing those roles is how governance disappears.
Discussed in Chapter 7: How to Begin — 7.3 Before you touch a tool, Chapter 2: The Instructions Are Part of the System — 2.4 Learning, traces, and authority + 1 more section
Stored assertions about particular entities and situations, with their supporting evidence and provenance. Distinct from the ontology's conceptual model and from policy governing what the system may decide.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.4 Retrieval systems
What survives a run: facts about the organization, the project, past decisions, failures, and corrections. A curated store, not a feature you switch on.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.5 Memory systems, Chapter 2: The Instructions Are Part of the System — 2.5 Diagnosing the environment + 52 more sections
Related essay: Chapter 4, “Orchestration in Practice,” is available
An explicit model of a domain's concepts, categories, relationships, and constraints. Case facts, supporting evidence, and authority policies remain distinct, even when represented in the same technical system.
Introduced in the glossary
Related essay: The Other Permission System
The system's connection to the outside world: read a file, query a database, open a ticket, run a test, deploy, send a message. The same model with different tools is a different delegated system.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.14 The chapter in one picture, Chapter 1: The Orchestrator's Toolkit — 1.6 Tool interfaces and actuation + 109 more sections
Related essay: The Emerging Role of the Orchestrator
The ability to identify and recover the versioned artifacts that defined an operating arrangement, with the relevant evidence retained separately. It does not guarantee identical model outputs or external results.
Introduced in the glossary
A system that may update its skills, refine its directives, or extend its understanding over time. More powerful and more dangerous in the same motion. Contrast fixed disposition.
Discussed in Chapter 3: What an Orchestrator Orchestrates — 3.10 Fixed and dynamic disposition, Chapter 1: The Orchestrator's Toolkit — 1.5 Memory systems
A system whose skills, directives, and permissions do not change unless a person changes them. It can still exercise judgment. It cannot rewrite its own instructions or expand its own authority.
Discussed in Chapter 3: What an Orchestrator Orchestrates — 3.10 Fixed and dynamic disposition, Chapter 3: What an Orchestrator Orchestrates — 3.12 The permission envelope + 1 more section
Which sources may update skills or memory, what kinds of updates each source can trigger, and what requires human review before it becomes permanent.
Discussed in Chapter 5: Orchestration in Practice — 5.6 Concrete artifacts — what exists, and why it is not enough, Chapter 3: What an Orchestrator Orchestrates — 3.10 Fixed and dynamic disposition + 3 more sections
Who or what a system is permitted to learn from. Permission to learn is not permission to learn from anything.
Discussed in Chapter 3: What an Orchestrator Orchestrates — 3.10 Fixed and dynamic disposition, Chapter 3: What an Orchestrator Orchestrates — 3.13 What this chapter is not
Related essay: Chapter 3 Has Been Released
A record of an observation the current operating model or procedure cannot adequately handle: evidence, the model version, the failed interpretation, the operational consequence, and any provisional explanation. It initiates investigation; it does not promote a new concept into the authoritative model.
Introduced in the glossary
A versioned record binding the ontology and its dependencies to capabilities, tools, model, instructions, policy, validation, evaluation, and deployment configuration. The decision record identifies the manifest actually used.
Introduced in the glossary
Permission to adopt changes to the shared operating model as authoritative for operational decisions. Discovering or proposing a concept does not confer this authority, and the term does not imply control over a model's private internal reasoning.
Introduced in the glossary
A change in the effective scope of permitted decisions caused by changed category definitions or relationships, even when the written authority policy remains unchanged.
Introduced in the glossary
An explicit agreement about the versioned meanings and dependencies a capability uses and the conditions under which it was validated. It binds the declared operating model; it cannot certify every internal interpretation of a language model.
Introduced in the glossary
What must stay invariant in a run, and what may vary. A customer-service system may change its wording and may not invent a return policy.
Discussed in Chapter 4: Living with Nondeterminism — 4.1 Variation and fences, Chapter 4: Living with Nondeterminism — 4.5 The operating record
A reconstructable record of what the system received, which version and instructions it used, what it did, and what happened next. Required whenever the action has consequences.
Discussed in Chapter 3: Delegation Is Architecture — 3.1 Operational orchestration, Chapter 3: Delegation Is Architecture — 3.4 The governance layer that does not exist yet + 10 more sections
The run-time twin of an architecture decision record: inputs, context, instructions, model or agent, permissions, output, approval, action, and result, one per consequential action.
Discussed in Chapter 3: Delegation Is Architecture — 3.1 Operational orchestration, Chapter 3: Delegation Is Architecture — 3.5 Design review and the profession + 10 more sections
Cases used to test the system: common, boundary, adversarial, badly formed, and situations where refusal is the correct answer. Whatever the set contains is what will receive attention.
Discussed in Chapter 3: Delegation Is Architecture — 3.2 Contracts and grants, Chapter 4: Living with Nondeterminism — 4.2 The failure envelope + 20 more sections
What variation the system can tolerate, what it cannot, what signals drift, and what evidence causes intervention.
Discussed in Chapter 4: Living with Nondeterminism — 4.2 The failure envelope, Chapter 4: Living with Nondeterminism — 4.5 The operating record + 3 more sections
Visible boundaries around an unpredictable output: acceptable outcome range, evaluation, and an intervention path. Distinct from a guardrail on a fixed track. The system must operate within the boundary; a learning system may also use the recorded failures to improve.
Discussed in Chapter 4: Living with Nondeterminism — 4.5 The operating record, Chapter 4: Living with Nondeterminism — 4.1 Variation and fences + 5 more sections
A designed pause that presents evidence, shows alternatives, records who decided, and can reverse the action where reversal is possible. Not a slogan for "someone glanced at it."
Discussed in Chapter 3: Delegation Is Architecture — 3.5 Design review and the profession, Chapter 5: Orchestration in Practice — 5.3 Before and after: two ways to change a website + 10 more sections
Who can pause the workflow before an irreversible action, with the authority and the practical ability to do it under pressure.
Discussed in Chapter 4: Living with Nondeterminism — 4.1 Variation and fences, Chapter 4: Living with Nondeterminism — 4.2 The failure envelope
The property that the same input can produce different outputs. Serving and sampling choices can reduce or remove some variation; operational systems still need envelopes for changing context, uncertain evidence, and imperfect judgment.
Discussed in Chapter 4: Living with Nondeterminism — 4.5 The operating record, Chapter 4: Living with Nondeterminism + 10 more sections
What the system actually did: actions, input sources, permissions used, and decision points, recorded from outside the model. The central artifact of Chapter 8 and the security log of Chapter 14.
Discussed in Chapter 4: Living with Nondeterminism — 4.5 The operating record, Chapter 4: Living with Nondeterminism — 4.3 Topologies and decision records in the wild + 14 more sections
A designed way to reverse a consequential action. If nobody has practiced it, nobody can claim it works.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.14 The chapter in one picture, Chapter 3: Delegation Is Architecture — 3.1 Operational orchestration + 16 more sections
Simon Willison's name for a combination that opens a path for data exfiltration: private data in reach, untrusted content in context, and a way to send data out. Cut one leg off.
Discussed in Chapter 7: How to Begin — 7.4 What to read next, Chapter 7: How to Begin — 7.8 What the first week should not do + 3 more sections
Drew Breunig's name for fixing behavior by appending more English to the system prompt until the application couples itself to one model's quirks.
Discussed in Chapter 2: The Instructions Are Part of the System — 2.1 Layers beneath the prompt, Chapter 2: The Instructions Are Part of the System — 2.5 Diagnosing the environment + 2 more sections
Instructions that reach the model through content it reads — email, tickets, pages, records — rather than through the system prompt. Direct when the attacker types them; indirect when they arrive as data.
Discussed in Chapter 5: Keeping Agents Uncompromised — 5.6 The orchestrator’s security job is not Infosec’s job, Chapter 2: The Instructions Are Part of the System — 2.4 Learning, traces, and authority + 5 more sections
Generation without prioritization: each addition is locally reasonable, and the original goal disappears. Named in The AI Developer's Field Guide; the mechanism is kept, the sea monster is optional.
Discussed in Chapter 4: How Orchestration Fails — 4.10 Why this chapter belongs before the daily practice chapters, Chapter 4: How Orchestration Fails — 4.5 Lack of clarity — the Scope Creep Kraken
Personal AI throughput treated as organizational capacity. The person preempts the team's work and leaves invisible repair labor behind.
Discussed in Chapter 4: How Orchestration Fails — 4.1 Look around, Chapter 4: How Orchestration Fails — 4.3 Solo Sovereign — and managing the executives who hear “orchestrator” as “headcount” + 1 more section
A record of which classes of action a system may take alone, which require a named person, and who owns each consequence. Meeting policy, not a slide.
Discussed in Chapter 1: Stop Holding Meetings About Possibility — 1.4 The team after: roles, titles, and the scrum question, Chapter 1: Stop Holding Meetings About Possibility — 1.5 The approval map: which conversations the institution needs + 6 more sections
Tim O'Reilly's name for a small kernel with standard interfaces that lets people extend the work without asking permission. This book treats it as a design bet for orchestrated systems: components that can be swapped, inspected, extended, and governed.
Discussed in Introduction — What this book is not, Chapter 5: Orchestration in Practice — 5.6 Concrete artifacts — what exists, and why it is not enough + 5 more sections
The artifact a meeting reads: findings, prototypes, estimates, assumptions, and the data that supports or cannot support each claim. Investigation happens before the room convenes.
Discussed in Chapter 7: Infrastructure for the Agentic Era — 7.5 Evidence packs: the operating record as infrastructure, Chapter 6: Cost as a Standing Constraint — 6.4 Measuring, not estimating + 1 more section
What the person responsible for a system must still be able to inspect and understand, even when they did not produce every artifact by hand.
Discussed in Chapter 1: Your Next Job Title Is Orchestrator — 1.7 The knowledge boundary
A review of a meeting that existed to assign investigation the system could have done overnight: what the room produced, what it delayed, and whether the meeting should still exist.
Discussed in Chapter 1: Stop Holding Meetings About Possibility — 1.7 A recipe book
A formation path in which a person learns orchestration by holding real authority under supervision, the way a medical resident learns by practicing under an attending. The answer Chapter 12 gives to the missing beginner work.
Discussed in Chapter 6: Educating Orchestrators — 6.3 The resident-engineer model, Chapter 6: Educating Orchestrators — 6.7 Create the path before removing the rung + 3 more sections
Cory Doctorow's name for a worker pressed into service as a peripheral for the machine, rather than a person using a machine to pursue a human goal.
Discussed in Introduction — What this book is not
Procedural knowledge: how this organization does a particular kind of work. Not merely what to do.
Discussed in Chapter 2: The Instructions Are Part of the System — 2.5 Diagnosing the environment, Chapter 2: The Instructions Are Part of the System — 2.3 Beyond a single prompt + 58 more sections
Related essay: Chapter 4, “Orchestration in Practice,” is available
An open protocol for connecting a model to tools and data sources. A standard interface, not a permission envelope.
Discussed in Chapter 1: The Orchestrator's Toolkit — 1.14 The chapter in one picture, Chapter 1: The Orchestrator's Toolkit — 1.6 Tool interfaces and actuation + 30 more sections