When people talk about “prompting”, it can sound like the skill is writing clever English.
But when you’re giving instructions to an agent that’s meant to do real work reliably, it feels much closer to programming than copywriting.
You’re not just asking for an answer. You’re specifying behaviour.
That changes what “good” looks like.
Good agent instructions aren’t poetic. They’re operational. They define:
- what happens first, second, third
- what to do when information is missing
- when to retry vs when to stop
- how to handle edge cases
- what the output must look like
If that sounds familiar, it’s because it’s the same thinking we use when we write software.
The people who often do well at this quickly are engineers, because we naturally think in:
Sequencing
Do A, then B, then C.
Do A, then B, then C.
Conditionals
If X is true, do Y. Otherwise do Z.
Loops and retries
Repeat until a condition is met. Back off. Try again. Give up safely.
Stop conditions
Don’t keep going forever. If you can’t do it reliably, stop and escalate.
If X is true, do Y. Otherwise do Z.
Loops and retries
Repeat until a condition is met. Back off. Try again. Give up safely.
Stop conditions
Don’t keep going forever. If you can’t do it reliably, stop and escalate.
Edge cases
What happens when inputs are weird, incomplete, contradictory, or stale?
That’s not “prompting”. That’s programming.
And if you’ve ever seen an agent behave inconsistently, it’s usually because the instructions don’t cover one of those fundamentals. The happy path is clear, but the messy real world isn’t.
And if you’ve ever seen an agent behave inconsistently, it’s usually because the instructions don’t cover one of those fundamentals. The happy path is clear, but the messy real world isn’t.
A simple way to write agent instructions
When I’m writing instructions for an agent, I tend to start with a structure like this:
When I’m writing instructions for an agent, I tend to start with a structure like this:
- Goal
- What outcome are we trying to achieve?
- Inputs
- What data is available? What data is not available?
- Constraints
- What must be true? What must never happen?
- Steps
- What’s the sequence of work?
- Failure handling
- What happens if something is missing or ambiguous? When do we stop?
- Output format
- What should the response look like, exactly?
This is basically a lightweight spec.
It removes ambiguity, makes behaviour predictable, and makes it easier to improve the instructions over time. If the agent fails, you can usually point to which section of the “spec” wasn’t defined clearly enough.
It removes ambiguity, makes behaviour predictable, and makes it easier to improve the instructions over time. If the agent fails, you can usually point to which section of the “spec” wasn’t defined clearly enough.
The biggest mistake: instructions that are all intent, no control flow
A lot of agent instructions are written like this:
“Be helpful. Be accurate. Be concise. Don’t hallucinate.”
That’s good intent. But it’s not enough.
A lot of agent instructions are written like this:
“Be helpful. Be accurate. Be concise. Don’t hallucinate.”
That’s good intent. But it’s not enough.
Real reliability comes from control flow: the boring bits engineers obsess over. What happens when X occurs. What happens when Y is missing. How to decide between two options. When to refuse.
That’s why writing agent instructions feels like programming.
Because it is.
That’s why writing agent instructions feels like programming.
Because it is.
If you treat agent instructions as a spec and think in sequences, conditionals, loops, and stop conditions, you’ll get a much more reliable agent.
And you’ll also start to notice something else:
The “language” is the easy part.
The hard part is the logic.
The hard part is the logic.