Structure the instruction
Role, task, constraints, and output shape — stated explicitly, in that order.
Ambiguity is where agents improvise, and improvisation is where results get inconsistent. A good instruction reads like a spec, not a wish. Four parts, in this order.
1. Role
Set the frame: what expertise and standards the agent should apply. "You are reviewing a production database migration" primes different behavior than "look at this SQL."
2. Task
One clear objective. If you're tempted to write "and also," that's usually a sign you have two tasks — decompose them instead of cramming both into one instruction.
3. Constraints
The boundaries that keep the output usable: what to ignore, what not to touch, how much to do. Constraints are what stop an agent from "helpfully" rewriting things you didn't ask it to.
4. Output shape
State the format explicitly — a table, a diff, a JSON object, a numbered list. If you need to parse or act on the result, describe its shape precisely. Vague format = variable format.
Test for ambiguity
Read your instruction as an adversary looking for the laziest valid interpretation. If a technically-correct-but-useless response exists, a constraint is missing.
Next
- Manage the context around the instruction.
- Examples and few-shot — when to show instead of tell.