Part 1 of 5
Identity, built from a metaphor, not a job title
"You are a code reviewer" describes an output. It says nothing about how much benefit of the doubt to give, when to push back, or what counts as done. A metaphor compresses a whole posture into a sentence a model can actually act from, turn after turn, without re-deriving it.
Weak version
You are a helpful orchestrator agent that manages other agents.
Working version
You cue sections in. You don't play an instrument yourself. Every part is trusted to play correctly once cued, never micromanaged mid-performance.
The metaphor is the instruction. Everything else in the prompt is just working out its implications.
A firm identity is also what holds up under pushback: see Sycophancy in the failure catalog, the model folding when challenged even when it was right, a posture failure a real identity is built specifically to resist.
Part 2 of 5
What it cannot do, spelled out, not implied
Remember the test-fixing agent from the top of this page? It didn't lack instructions. "Fix the failing test" is a perfectly clear instruction. What it lacked was a single line saying what it couldn't touch while doing that. Here's the whole fix:
The one line that was missing
Does not modify anything beyond what's needed to make the failing test pass. Does not rename, refactor, or reorganize as a side effect, even improvements nobody would object to.
Positive instructions describe the job an agent already wants to do. The failures that actually happen in production don't look like refusing to help, they look like quietly doing more than was asked, deciding an ambiguous case on its own, or trusting an unverified claim. A model straining to be helpful will always find a way to satisfy a positive instruction, even the wrong way. Only an explicit prohibition catches that.
The prohibitions are usually more load-bearing than the instructions.
The two failure modes an explicit boundary list guards against most directly: Scope Creep, unrequested work arriving because more output reads as more help, and Destructive Action Without State Check, an overwrite that never checked what it was replacing.
Part 3 of 5
A procedure with real steps, not a vibe
A real procedure names every stage, what it needs before starting, what it produces when it's done, and what to check before moving to the next one. The single biggest gap between a prompt that works reliably and one that "usually works" is whether "confirm the output actually exists" is a literal, numbered step, or something quietly assumed.
Weak version
Work through the pipeline stages and hand off to the next agent when ready.
Working version
After the agent completes, confirm the expected output file actually exists before treating the stage as finished. If it doesn't, ask what happened rather than assuming success.
"Assume it worked" is where a procedure quietly turns into a vibe.
This is the direct fix for Claimed Execution, "I've tested this and it works" with no test run, and for Premature Closure, committing to the first plausible answer before an alternative was ever generated.
Part 4 of 5
Voice shown as an example, never described as an adjective
"Be concise" gets reinterpreted differently every single turn across a long session, because it's an instruction the model has to keep re-satisfying from scratch. A literal example message is something to pattern-match against directly, which holds up under pressure in a way an adjective never does.
Weak version
Keep responses short and to the point.
Working version
"Round 1 verdict: needs work. Blocking finding: [category], one line description. Routing back for round 2." Nothing else. The reports have the detail; the message doesn't repeat it.
Show the message. Don't describe the message.
This is exactly what Instruction Drift describes: tone and format, specified early, quietly reverting to model defaults over a long session. A shown example resists that decay in a way a described adjective doesn't.
Part 5 of 5
A structured self-report, not a free-form reflection
"Explain your reasoning at the end" produces prose nobody downstream can actually use. The stronger version is a fixed, small taxonomy: what was assumed and why, where the agent struggled, what it would flag as a gap in its own knowledge, each logged as its own tagged category, not folded into one paragraph.
Weak version
Briefly explain any assumptions you made at the end of your work.
Working version
Log an assumption the moment it happens, tagged by type, with what would need to change if it's wrong. A vague reflection at the end is easy to skip; a tagged entry in the moment isn't.
Structure turns one run into data. Prose turns it into a paragraph nobody reads twice.
This is the structural fix for Silent Assumption-Filling, picking an interpretation without saying which, and it gives Overconfident First Answer somewhere to go: a register for stating what's actually still uncertain.