2.2 The instruction tree
Agentic systems now carry several kinds of instruction, each with a different scope and a different lifetime, and confusing them is how governance quietly disappears.
2.2.1 System instructions
System instructions are the runtime’s standing operating guidance, and they may define the agent’s identity, tool-use conventions, output format, safety reminders, execution behavior, or rules for handling long-running work. OpenClaw documents a system prompt assembled fresh for each run out of fixed sections, available tools, skills, workspace files, runtime facts, and provider contributions, and it can produce smaller prompt modes for subagents while separating stable content from dynamic per-run material.16
For an orchestrator the important question is not whether the system prompt sounds authoritative. It is which parts are stable, which are rebuilt each run, which can be changed by a provider or a plugin, and which are enforced somewhere other than the model’s context. A system prompt is a control document, and it is not necessarily a control mechanism.
It is not common practice yet, but if a company is trying to control how AI is used, this layer should be governed. A system prompt that carries company guidance should be distributed from a central source — possibly baked into a machine image, possibly populated by a hook whenever a system is created — and it should not be something anyone who uses the tool can change. Governing it means deciding who may publish or change it and keeping that provenance visible. A hidden system prompt is not a secret-storage mechanism or a permission boundary. Some users have a practice of inserting their own user-specific system prompt whenever they use these tools, on top of whatever the company supplied. An orchestrated system usually does not depend on user-level customization — the environment you designed is the point — but as an orchestrator you need to know that layer exists, because it is one more source of instructions that someone can change without review.
2.2.2 Organization instructions
An organization may have rules meant to apply to every agent working on its systems:
- never send customer data to an unapproved provider;
- never modify production without a recorded approval;
- run the security scan before opening a release request;
- use the approved error format;
- do not access repositories outside the assigned project.
Claude Code documents managed CLAUDE.md files for organization-wide instructions, and Codex documents administrator, user, repository, and directory-level instruction sources; both mechanisms are attempts to make organizational expectations portable across many sessions and many people.1718 An organization-wide Markdown file is still guidance until something enforces it, though.
2.2.3 Project and repository instructions
This layer is a mess, and the mess is not accidental: it is what tool-specific practices produce. A company that standardized on Claude Code has CLAUDE.md files in its repositories. A company using other tools has AGENTS.md files. A company using several tools has both, plus whatever equivalents each harness brought along. The mixture does not lend itself to portability between tools and models. Both are Markdown, but automatic discovery is tool-specific. Codex requires configuration to discover alternate filenames; Claude Code can import shared instructions explicitly. Even when both load the same text, different models have different assumptions about how they will use the directive files they find in a file system, so the same file does not produce the same behavior everywhere.
Project instructions describe the local system — its architecture, commands, testing conventions, deployment rules, terminology, and known traps — and AGENTS.md, CLAUDE.md, and their equivalents belong here. They are the written version of the explanation an experienced engineer gives a new hire on the first day: this is how the repository is laid out, this is the command that runs the tests, this service owns that data, and do not change this interface without checking those consumers.
Their value is that they preserve knowledge that would otherwise live in one engineer’s head, and their failure mode is that they turn into noise with remarkable ease. A project file containing architecture notes, personal preferences, temporary incident notes, unresolved arguments, obsolete commands, and everyone’s contradictory opinions makes it harder for the agent to work out what matters, so the orchestrator has to decide what every run must know and what should surface only when a particular task requires it. Conflicting instructions leave the model to choose an interpretation. It may choose differently across runs, and the resulting mistake can be hard to trace back to the file.
A file can also be an attack. An attacker does not need access to the system prompt to influence an agent: anything the agent reads — a README an outsider can edit, a ticket, a web page, a document the retrieval system returns — enters the same working input as the instructions, and if the model reads it as an instruction, it is one. This is indirect prompt injection, and Chapter 14 covers its mechanics and defenses in full: the lethal trifecta, the controls stack, and why the defense is permissions rather than wording. Every context source therefore has to be interrogated. Who created it? Who can change it? When was it last reviewed? Is it an instruction, evidence, or ordinary data? What happens if it is wrong? Can it override anything, or can it only inform a recommendation? Is the source visible in the run record? The line to hold is that no retrieved document may grant itself new permissions or cancel a security requirement. A document can suggest; a permission, a policy check, or a human approval must decide.
2.2.4 Path-scoped and conditional rules
A rule about the billing service should not necessarily govern the marketing site, a rule about TypeScript API handlers should not necessarily govern the documentation directory, and a deployment skill that requires Docker should not even appear as available on a machine without Docker. Claude Code documents path-specific rules, and OpenClaw documents skill gating based on operating system, binaries, environment variables, configuration, and plugin availability.19
What that gives the instruction system is a tree rather than a pile:
The narrower rule is not automatically more important; it is only more specific. The runtime still needs some way to resolve conflicts between branches and to show the operator which rules were actually active during a run.
Path-scoped approaches like these can be powerful, but they are often specific to one tool, and that is the standing challenge of project-level context. Skills are closer to a universal standard now — the Agent Skills specification is deliberately tool-neutral — but the same skill file is not interpreted identically by every tool that reads it. In practice, instructions, plugins, and skills end up aligned with the specific tool, agent, harness, or approach a team is using. That is why the open standards deserve an orchestrator’s attention: the Model Context Protocol and the Agent2Agent protocol, both governed by the Linux Foundation, and the Agent Skills specification — donated to the Linux Foundation’s Agentic AI Foundation on October 22, 2026 — are the current attempts to make context, tools, and instructions portable across vendors.20 Chapter 16 returns to this from the infrastructure side.
2.2.5 User and task instructions
The user request is the immediate objective, and it may be a question, a change request, an investigation, or a request for a decision. A task instruction is usually more structured, stating the objective, the inputs, the constraints, the desired output, and the point at which work should stop.
A one-time task belongs in this layer. A procedure that recurs every week almost certainly does not. If Maya finds herself pasting the same 900-word workflow into every customer-feedback request, she has not discovered a better prompt. She has discovered a missing skill. And the ladder does not stop there. Something repeated often enough as a skill is a candidate to be promoted again — into a tool, a deterministic script that runs the same steps in code instead of a nondeterministic prompt that has to be interpreted every time. Code is cheaper and faster to execute, and more reliable than depending on an inference engine to walk through a series of procedural steps. People who started using these systems in the last year or two often miss this entirely. The instinct for when work should stop being prompted and start being programmed is one of the habits that separates an orchestrator from a user.
When someone tells you they wrote a skill for arithmetic. Sooner or later someone will tell you, usually proudly, that they created a skill to handle rudimentary arithmetic — invoice totals, tax math, financial calculations — by dictating the steps to the model. That is a warning sign. If a calculation matters, do not have an inference engine perform it. An inference engine can produce different answers for the same input, because it is nondeterministic by construction, and the error will be confident, plausible, and wrong in a decimal place nobody thinks to check. Arithmetic that touches financial data belongs in code the model calls, not in steps the model performs. A skill that teaches a model long arithmetic has not discovered a capability; it has rediscovered the calculator, with worse reliability and a per-token bill.
2.2.6 Static and dynamic instructions
Some instructions exist before the run and others get assembled during it, and the distinction matters more for auditing than for execution.
Static instructions are authored, versioned, and available before a task begins: organization policy, repository rules, a skill file, a plugin manifest, a tool schema, a subagent role, an evaluation rubric, a sandbox profile, a deployment policy. Static does not mean permanent — it means the artifact can be reviewed and changed before the run that uses it.
Dynamic instructions are assembled at runtime: the user’s current request, the active branch and diff, a support incident, a retrieved document, a memory recall, a tool result, a handoff from another agent, a permission or approval state, a retry or continuation instruction, a hook-generated warning. Dynamic does not mean untrustworthy — it means the run has to record where the instruction came from, when it arrived, what scope it had, and whether it was permitted to change the system’s authority.
OpenClaw describes dynamic prompt assembly, runtime facts, skill snapshots, tool availability, workspace files, and per-run context, and Claude Code documents dynamic context injection inside skills.2122 A reviewer looking only at the final answer cannot tell whether it came from a stable project rule, a freshly retrieved document, a stale memory item, or a tool result produced two minutes earlier, and the run record is the only thing that can preserve that difference. The orchestrator validates the result and analyzes the record of what led up to the decision. The record is the input the orchestrator works with — often using an inference engine of their own — to discover how the system can be made more reliable and more accurate: which instruction was loaded, which memory was recalled, which retrieval fired, which handoff dropped the context that mattered.
Anthropic, “Donating Agent Skills to the Agentic AI Foundation,” October 22, 2026, https://www.anthropic.com/news/donating-agent-skills-to-the-agentic-ai-foundation. Verified October 23, 2026.↩︎