What Is a System Prompt?
A system prompt is the standing instruction block placed ahead of a conversation to fix the role, the scope, the output format and the constraints a run is expected to hold to. It is sent with the request rather than remembered between requests, it occupies the same context the conversation occupies, and in the interfaces that mark it, it arrives under a role distinct from the turns that follow it.
Where the block sits in a request
In a chat-shaped interface a request is a sequence of messages, each carrying a role. The standing block occupies the first position, under a role variously named system, developer or instructions depending on the interface, and the conversation's turns follow behind it. Two properties follow from that arrangement and both are routinely misread. It is re-sent with every request in the ordinary case — nothing on the far side is holding it between calls — so a long block is a cost paid per request rather than once. And it is spending the same context the conversation is spending, so as the conversation lengthens, the block and the turns are drawing on one budget.
The distinct role is not merely a label for the caller's convenience. Post-training establishes a precedence between the roles: material arriving under the system role is treated as having come from the operator of the system, and material in a user turn as having come from whoever is talking to it. That precedence is a learned disposition rather than an enforced permission. Nothing in the format prevents a later turn from contradicting the block, and nothing in the runtime rejects a request in which one does — which is why the injection problem exists at all, and why the durable answers to it are placed outside the prompt.
What goes into the block is conventional rather than specified, and the conventions are stable enough to state: who the system is acting as and on whose behalf, what it is for and what it is not for, the shape of the output, what to do when the input falls outside scope or a tool fails, and what to do rather than only what to avoid. The last of those is a maintenance property rather than a claim about behaviour. A constraint written purely as a prohibition leaves the alternative unspecified, and a block that has accumulated prohibitions is a block nobody can safely edit, because no line in it records the incident that caused the line to be written.
| Placed in the block | What it establishes |
|---|---|
| A role and a scope | A stated frame for the run, present from the first turn and restated on every request. |
| An output format | A request for a shape. Where the shape has to hold, enforcement belongs to a decoder constraint or a validator rather than to the sentence asking for it. |
| A tool-use policy | A stated policy. A registered tool stays callable, and what a call may touch is decided by the code that executes it. |
| A refusal rule | An instruction competing with everything else in the context, including whatever the context acquires later. |
| A credential, or a rule whose secrecy matters | Nothing. The block travels in the request and can be reproduced in the output; no mechanism here makes it confidential. |
| A long body of reference material | A per-request cost drawn from the same budget as the conversation, whether or not the material is used. |
One distinction runs through every row: the block states what should happen, and the layers around it decide what can. Each row where the answer is weak is a row where a stated intention has been asked to do the work of a mechanism, and the repair is the same in every case — move the constraint to the layer that can enforce it, and leave the sentence in the block as documentation of the intent.
What the block does not control
It grants and withholds no access. If a tool is registered for a run, it is callable in that run, and an instruction not to call it is a sentence in the input. The same holds for the data a tool can reach and the actions it can take: an authorisation decided by a paragraph is an authorisation that can be argued with, while the layers that cannot be argued with are the ones actually holding the credential — the tool's own permissions, the account the call runs under, the approval step standing in front of an effect. A run whose safety rests on a paragraph rests on whatever else ends up in its context.
It is neither memory nor state. The block is part of the input, so it holds nothing between requests and observes nothing that happened in an earlier one; anything the system is meant to remember has to be placed into the context by the caller on each request, out of a store the caller maintains. Nor is the block private. It is transmitted, it can be quoted back, and a set of instructions whose publication would embarrass its author should be treated as already published.
Its reach also ends at the edge of what the context holds. As a conversation lengthens the block becomes one span among many, and the content arriving later — retrieved documents, tool results, pasted material — sits in the same context and is written in the same language as the instructions. That is the structural reason the standard practices exist: restating a critical constraint close to where it applies, keeping untrusted material in a clearly separated span, and validating what comes back instead of assuming the format request held. Whether any of those helps on a particular workload is a measurement, and this page publishes none.
How the Registry classifies a standing instruction authoring task
Writing the standing instruction block an agent loads before any user turn and committing it to a repository is filed as a code modification task in this registry's classification. The class is decided by what the task leaves behind rather than by what the block says: the deliverable is a file in version control, opened as a change, reviewed as a change and merged as one, and its contents being sentences rather than statements does not move it elsewhere.
The Registry's canonical brief for this entry is filed as:
Write the standing instruction block an agent loads before any user turn and commit it to the repository.
Submitted for assessment it is
classified as Code modification, and its wording is hashed once — to
d0ea2133338964bf…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/code.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about system prompt
What belongs in a particular block, how long it should be, and whether one wording holds where another gives way are settled against the cases an operator is measuring, and this registry measures none of them. It runs no operator's system prompt, holds no conversation, and has never observed whether an instruction was honoured. The canonical brief above fixes an operation and a deliverable, and its wording is the only part of it that enters the derivation.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about system prompt
- What is a system prompt?
- A system prompt is the standing instruction block placed ahead of a conversation, fixing the role, scope, output format and constraints for the run. It is part of the request rather than something stored between requests, and it occupies the same context the conversation occupies.
- How is a system prompt different from a user message?
- In how it is marked and how it is treated. It arrives under a distinct role that post-training associates with the operator of the system rather than with the person talking to it. The distinction is a learned precedence, not an enforced permission: nothing in the format stops a later message from contradicting it.
- Is a system prompt confidential?
- No. It travels in the request and can be reproduced in the output, and no mechanism in the arrangement keeps it secret. A credential, or a rule whose secrecy is doing real work, does not belong in it.
- Does a system prompt persist between requests?
- Not by itself. In the usual arrangement it is re-sent with every request, which is also why its length is a per-request cost. Anything that must survive between requests is held in a store by the caller and placed back into the context each time.
- Can a system prompt stop an agent from using a tool?
- It can state the policy; it cannot enforce it. A registered tool remains callable, and what a call is permitted to touch is decided by the code that executes it, the credential it runs under, and any approval step placed in front of the effect.
Related entries
Order an assessment for code modification tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.