The OpenClaw system prompt

There is no default system prompt in OpenClaw: the Gateway builds one for every agent run, from explicit inputs, through three layers the docs name. A pure renderer turns inputs into text, a resolver gathers the config-backed knobs for a specific agent, and runtime adapters collect live facts, tools, sandbox state, channel capabilities, context files, and call the facade. Provider plugins can contribute model-family guidance without replacing the prompt. Here is the structure, the boundary that sorts stable from volatile, what the prompt says about long-running work, and the sentence that keeps expectations honest.

OpenClaw builds its own system prompt for every agent run; there is no runtime default prompt.

The sections

• Tooling, execution bias and promised work: the structured-tool reminder, act in-turn and continue until done or blocked, and the rule that promising future or delegated work creates ownership of its completion.
• Safety, runtime context and control: a short guardrail against power-seeking and bypassing oversight, private delivery of login codes in groups, a delimited runtime-context carrier the model must use without describing, and how the agent inspects config and requests changes through the gateway tool, never through chat shell commands.
• Skills, workspace, documentation, injected workspace files, sandbox when enabled, temporal context, output directives, UI presentation, collapsible details, runtime and reasoning: each a compact fixed section.

The cache boundary

Large stable content, including project context and static memory-recall instructions, sits above an internal prompt cache boundary; volatile per-turn sections, presentation, messaging, voice, group context, reactions, runtime, project memory facts, delegation mode and the elevated level, are appended below it, so local backends with prefix caches can reuse the stable prefix across turns. Exec, sub-agent and media facts travel in a later runtime-context carrier to preserve the conversation-history prefix too. The boundary is transport metadata: every section is still system-prompt guidance. Provider contributions can replace three named core sections, interaction style, tool-call style and execution bias, or inject a stable prefix above the boundary and a dynamic suffix below it.

Long-running work

• Use cron for follow-ups, reminders and recurring work, never sleep loops, delay tricks or repeated polling; use exec and process only for commands that start now and continue in the background.
• For larger tasks prefer spawning a sub-agent and follow its completion mode; treat a child’s completion as the end of that run, not proof the user’s goal is done; never poll the sub-agent list in a loop to wait.
• A delegation mode strengthens this: prefer, the default in a main session, adds a section telling the agent to stay responsive and use hidden sub-agents for legwork; at the ultra thinking level an orchestration section asks it to parallelize independent work.

OpenClaw skills explained are loaded on demand from the skills section, and Writing an agent personality that holds up is where the persona text that enters the workspace files gets written.

Advisory, not enforcement

The docs say it in one sentence: safety guardrails in the system prompt are advisory, not enforcement, and hard enforcement is tool policy, exec approvals, sandboxing and channel allowlists; operators can disable prompt guardrails by design. The prompt hardening around internal-context delimiters is described the same way, as hardening rather than a guarantee. OpenClaw and prompt injection is the reading that follows.

On Diali

On Diali the prompt is assembled the same way for every assistant; what you write is the persona and the instructions that enter the workspace files, and what we run is the runtime around it. Hosted OpenClaw on Diali is the assistant.

• Three layers, fixed sections, no default text.
• Stable above the boundary, volatile below it.
• Guardrails advise; policy, approvals and sandboxes enforce.