Model: openai/gpt-5.4 Generated: 2026-04-01 Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead Chapter: 8 — Configuration and Customization Token Usage: N/A (runtime does not expose per-file token counts)
8.3 Instruction System
If tools are the hands of a coding agent, the instruction system is its nervous system. The system prompt is not merely an introductory paragraph sent to the model. It is a composite artifact assembled from multiple sources: base identity, behavioral policy, tool descriptions, project instructions, memory, and runtime constraints.
Across OpenCode, Claude Code, and OMO, the most important shared pattern is this: the “system prompt” is no longer a single prompt. It is a prompt assembly pipeline.
OpenCode: prompt assembly as layered composition
OpenCode makes this explicit in session/prompt.ts. During prompt creation, it combines environment instructions from session/system.ts with loaded instruction documents from session/instruction.ts. The result is not just a generic role description, but a stitched context bundle.
session/system.ts provides environment facts such as model identity, working directory, platform, date, and repository status. This matters because an agent behaves differently when it knows whether it is inside a git repository, which OS it is running on, and where it is operating.
session/instruction.ts then gathers instruction files like AGENTS.md and CLAUDE.md, both from global locations and by walking upward through the project tree. It also supports config-provided instruction paths and remote URLs. This means OpenCode’s system prompt is partly static and partly discovered.
The rest of the prompt assembly process adds agent prompt material, project context, tool schemas, and MCP-derived capabilities. The effect is a layered prompt architecture: environment, instructions, tools, and active task context each contribute a slice.
This is a very “systems” way to build prompts. Instead of authoring one giant monolithic template, OpenCode composes the final behavior from typed subsystems.
Claude Code: multi-source prompt synthesis
Claude Code follows the same broad pattern, but with a stronger emphasis on memory and policy-rich runtime context.
At a high level, Claude Code’s effective system prompt draws from:
CLAUDE.mdand related rules files- memory files and memory instructions
- MCP prompt/command material
- tool descriptions
- permission context and execution mode
- optional appended system prompt fragments
The file utils/claudemd.ts shows that Claude Code loads managed memory, user memory, project memory, and local memory in a priority-aware order. It also supports @include directives, allowing one memory file to reference other files. This makes the instruction layer compositional and modular.
QueryEngine.ts shows the assembly step clearly: the final system prompt can combine a default system prompt or custom prompt, optional memory-mechanics instructions, and appended policy text. Elsewhere in the codebase, tool descriptions and MCP prompt data are prepared so the model sees not just the user request, but the action vocabulary available to it.
Claude Code also injects permission context. This is easy to underestimate. Permission mode is not just a UI concern; it shapes the agent’s behavioral boundary. An agent running in a strict approval environment should reason differently from one running in a permissive auto mode. In that sense, permission context is part of the prompt, because it changes what the agent believes it is allowed to do.
This is one reason commercial agents often feel more coherent in practice. They do not rely on a single prose identity statement. They encode runtime policy directly into the instruction substrate.
OMO: tailored prompts per agent
OMO pushes the instruction system further toward specialization. In dynamic-agent-prompt-builder.ts, prompts are assembled from modular sections such as tool selection guidance, delegation tables, category-and-skill rules, anti-pattern warnings, and hard behavioral constraints.
This is especially visible in agents like Prometheus and the Sisyphus variants. Rather than giving every agent one universal identity, OMO generates a tailored prompt for each role.
Typical sections include:
- identity and role framing
- interview or task-intake behavior
- plan generation rules
- tool and agent selection tables
- delegation guides
- cost awareness
- anti-patterns and hard blocks
In other words, OMO treats prompt construction almost like compiling a job description. The system does not ask, “What should the model generally be?” It asks, “What exact constraints and affordances should this particular agent instance carry?”
That is a major step beyond standard prompt templates. OMO is essentially doing prompt modularization. A module is a reusable instruction component with a specific responsibility. This resembles software architecture more than classic prompt writing.
System prompt as personality, policy, and perimeter
There is a recurring anti-pattern in AI discourse: people say the system prompt is the agent’s “personality.” That is partly true, but incomplete.
The system prompt actually defines three things at once.
First, it defines personality: tone, initiative level, response style, and collaboration posture.
Second, it defines policy: what the agent should prioritize, what workflows it should follow, and how it should interpret project instructions.
Third, it defines perimeter: what the agent must not do, when it must ask for approval, when it should delegate, and what kinds of reasoning shortcuts are forbidden.
OpenCode emphasizes composition of environment plus instructions. Claude Code emphasizes policy-rich synthesis from memory, tools, MCP, and permission context. OMO emphasizes role-specific prompt specialization.
These are not mutually exclusive; they are different emphases along the same architectural spectrum.
Why modular instruction systems matter
As coding agents grow more powerful, the instruction system becomes a scalability bottleneck. A monolithic prompt is hard to maintain, hard to debug, and hard to localize. Modular assembly solves several problems.
It allows source attribution: a behavior can be traced to AGENTS.md, memory, managed policy, or a generated agent section. It allows selective override: team policy can replace local habit, or project context can override generic defaults. It also allows specialization: different agents can inherit shared foundations while diverging in carefully controlled ways.
This has a direct analogy in computer science. A monolithic prompt is like a giant global variable. A modular instruction system is like dependency injection: behavior is assembled from components with clearer ownership boundaries.
That analogy matters because prompt complexity is now large enough to deserve software engineering discipline.
The road ahead
The likely future is not one giant universal system prompt. It is a prompt graph.
A prompt graph is a network of instruction components activated by scope, role, tool availability, and task type. Some components are always present, such as identity and safety policy. Others are conditional, such as project rules, memory reminders, MCP-specific prompts, or delegation protocols.
OpenCode already hints at this with layered discovery and composition. Claude Code hints at it with memory scopes, permission-aware context, and MCP prompt conversion. OMO makes it most explicit by generating different prompt bodies for different agents.
The key lesson is that an instruction system should not be written like copy. It should be engineered like infrastructure.
The best coding agents of the next generation will therefore be distinguished less by having a more eloquent base prompt and more by having a better instruction assembly architecture: modular, inspectable, scope-aware, role-aware, and tightly coupled to the tool and memory systems around it.
That is when the system prompt stops being a paragraph and becomes what it really is: the software-defined personality boundary of the agent.