2.2 The instruction tree — The Instructions Are Part of the System

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.¹¹

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. It often should not be directly visible to end users at all. But if you do it, you have to decide who is allowed to access the system prompt and who is allowed to change it, at every level. 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.¹² ¹³ 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 it is worth saying that plainly before describing it, because 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. For the most part CLAUDE.md and AGENTS.md are compatible — most tools read either — but file compatibility is not behavior compatibility: 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. There is nothing more confusing to an inference engine than context that contains several contradictory statements. The model does not resolve the contradiction; it absorbs it, and the output gets worse in ways that are hard to trace back to the file.

A file can also be an attack, and that is the part most teams have not internalized yet. 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. What belongs in this chapter is the instruction-tree consequence — every context source 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.¹⁴

What that gives the instruction system is a tree rather than a pile:

organization
  └── repository
       ├── service
       │    ├── path-specific rules
       │    └── service skills
       └── documentation
            └── editorial rules

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 closer to universal is not universal: 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 are the current attempts to make context, tools, and instructions portable across vendors. 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 — which is why Maya’s saved-search request counts as one: it says what outcome matters and what evidence has to come back before implementation begins.

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 user request or a task request is a candidate to become a skill. 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. The skill that matters here is noticing when the same thing is being done over and over, and asking what can be turned into code — because 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. Different engines produce different answers for the same input, because they are 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.¹⁵ ¹⁶ The reason to care is entirely practical. 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 is responsible not only for guaranteeing that the right answer was reached with the right inputs, but for being able to do a detailed analysis of a forensic record of what led up to a 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. The run record is the raw material for improving the system, not just the evidence for defending it.

OpenClaw, “System prompt,” https://docs.openclaw.ai/concepts/system-prompt. The documentation describes per-run prompt assembly, fixed and dynamic sections, provider contributions, prompt modes, workspace bootstrap files, and skill snapshots.↩︎
Claude Code, “How Claude remembers your project,” https://code.claude.com/docs/en/memory. The documentation distinguishes managed, user, project, and local instruction files from auto memory containing learned patterns and discoveries.↩︎
OpenAI, “Custom instructions with AGENTS.md,” https://learn.chatgpt.com/docs/agent-configuration/agents-md. The documentation describes instruction discovery across user, repository, and directory scopes, including more specific overrides and fallback filenames.↩︎
OpenClaw, “Skills,” https://docs.openclaw.ai/tools/skills. The documentation describes skill files, load order, per-agent visibility, gating, allowlists, on-demand loading, and plugin-provided skills.↩︎
OpenClaw, “Context,” https://docs.openclaw.ai/concepts/context. The documentation distinguishes current model context from persistent memory and describes runtime-built prompt content, workspace files, tool schemas, skill lists, truncation, and dynamic injections.↩︎
Claude Code, “Extend Claude with skills,” https://code.claude.com/docs/en/skills. The documentation describes reusable workflows, on-demand loading, supporting files, dynamic context injection, subagent execution, and plugin distribution.↩︎