Skip to content

Instructing an Agent

A prompt is not the sentence you type. By the time a model acts, its instruction is the union of a system prompt, your message, injected files and tool outputs, and the structural cues that organise them. In an agentic system that union is assembled by machinery, which makes prompting an engineering artifact: something with structure, versions, tests, and failure modes, not a knack.

The reliable core of a working agent prompt is boring and repeatable:

  • Purpose: one responsibility, stated once.
  • Instructions: numbered, explicit, in execution order. Replace every “handle errors appropriately” with the actual numbered behaviour you want.
  • Constraints: what the agent cannot do, stated as hard boundaries. Counter-intuitively, an explicit list of prohibitions makes agents act more confidently within them; the bounded space is what enables autonomy.
  • 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.

Alongside stopping conditions, give the agent an explicit ask-versus-proceed rule: ask when the request is ambiguous with multiple valid readings, when consequences are hard to reverse, or when critical context is missing; proceed when the choice is stylistic, easily verified, or reversible. This maps directly onto the risk-tier thinking in Controls & Autonomy.

Prompt advice is folklore-rich; a small set of findings replicates well enough to build on. All figures below are the cited papers’ claims.

  • Mood matters by task. Declarative statements of the desired end state outperform imperative step lists on complex reasoning (roughly a 23 percent gap in SatLM, arXiv:2305.09656); imperative wins for sequential tool execution. Describe outcomes for thinking work, steps for mechanical work.
  • Specificity is task-dependent. Added detail helps math (+0.47 accuracy delta) and code (+0.31), does nothing for decision-making, and hurts creative work (DETAIL, arXiv:2512.02246). Specify output format, boundaries, and success criteria; stay loose on approach.
  • Negative constraints backfire at scale. “NEVER use global state” semantically activates the forbidden thing (the pink-elephant effect). Reformulate prohibitions as the desired positive behaviour: “use dependency injection.”
  • Personas mostly do not work. Across 162 personas and 2,410 questions, role-play backstories produced no factual or reasoning gains and reduced accuracy in about 30 percent of cases (arXiv:2311.10054). A minimal focus statement (“focus on security implications”) does the useful part.
  • Chain-of-thought is a mode switch, not a logic upgrade. It moved early benchmarks dramatically, but invalid reasoning exemplars work almost as well as valid ones, and on modern reasoning models forced step-by-step adds 20 to 80 percent latency for little or no accuracy gain (Wharton Prompting Science, 2025). Use it for debugging and mandated-transparency formats, not as a default.
  • Position and order matter. Earlier content is weighted more, so order constraints critical-first; ends of long prompts get more attention than middles, so restate load-bearing constraints near the end.

Prompts have a growth path, and knowing where you are on it prevents both under- and over-engineering. There are seven proposed levels; compressed, the ladder runs:

  1. Static text, then parameterized templates, then conditional branching.
  2. Contextual prompts that read project state, then composed prompts that invoke other prompts. This is where prompting starts to shade into orchestration.
  3. Self-modifying prompts that update their own content from results, and finally meta-cognitive prompts that improve other prompts. These two demand the disciplines of Skills and the update hygiene covered in the Knowledge Base: preserve what works, append with dates and provenance, remove only on repeated contradicting evidence, and gate self-modification behind approval.

Start at the lowest level that solves the problem. The signal to climb: you are copy-pasting the same prompt with small edits, or hand-tweaking every output the same way. The signal you have climbed too far: debugging the prompt costs more than the work it saves.

Treat prompts at level 2 and above as code: version-controlled, with recorded rationales for changes and a small set of known inputs you re-run after every edit. That habit, generalised, becomes the Evaluation Harness later in the book.