Structuring Agent Instructions
2 min read
A prompt is not just the sentence a user types. By the time a model acts, its instructions combine the system prompt, user request, injected files, tool results, and structural cues that organise them. In an agentic system, machinery assembles that material. Prompting is therefore an engineering activity with defined inputs, failure modes, and expected outputs.
Five parts of an executable instruction
Section titled “Five parts of an executable instruction”The reliable core of a working agent prompt is boring and repeatable:
- Purpose: state one responsibility once. The agent should be able to distinguish its job from the jobs of surrounding systems.
- Instructions: describe required behaviour explicitly and in execution order. Replace “handle errors appropriately” with the actual recovery or escalation behaviour.
- Constraints: define the boundaries of acceptable action. A bounded space lets the agent proceed confidently without inventing authority.
- Output format: the exact shape of an acceptable answer, ideally with one correct and one incorrect example. Use examples to pin format, not content; models over-anchor on example content.
- Stopping conditions: when to stop. Verified success, a bounded number of failed attempts at the same error, missing information only a human can supply, or scope exceeded. Agents without stopping conditions either quit early or churn forever.
Define when to ask
Section titled “Define when to ask”Stopping is not the only boundary. The agent also needs an explicit rule for asking versus proceeding.
Ask when the request has multiple materially different interpretations, when an action is difficult to reverse, or when critical context is unavailable. Proceed when the remaining choice is stylistic, reversible, or cheap to verify. This maps directly to the risk tiers in Controls & Autonomy.
Treat the assembled prompt as the interface
Section titled “Treat the assembled prompt as the interface”An instruction can be clear in isolation and still fail after the harness combines it with retrieved context and tool output. Review the complete assembled prompt, not only the template you authored. Look for duplicated rules, conflicting priorities, buried requirements, and examples that accidentally steer content.
Structure provides the stable foundation. The next chapter examines which prompt-writing claims have empirical support.