How to write a prompt your agent will actually follow

Start from the call, not the prompt

Before writing anything, sit with whoever currently handles these calls and get them to talk through a real one end to end. Not a typical one — a recent one. Then ask, at every point where they made a choice, what would have made them choose differently.

That second question is the whole exercise. People describe their jobs as linear because that is how memory works, and the branches only surface when you interrupt them. "I'd book them in" becomes "well, unless they're outside our area, or it's a warranty job, or they've got an outstanding balance" — three branches that were never going to appear in a written SOP.

Write those down as they come. The output you want from this session is not prose; it is a list of decisions and the conditions that drive them.

Write the decisions, not the personality

Tone takes a sentence. The bulk of a good prompt is the decision tree: what to collect, in what order, what to do when a field is missing, and when to stop and transfer.

If two people on your team would handle a call differently, the prompt is underspecified. Resolve it with them before writing it down. This is uncomfortable because it surfaces disagreements that have been quietly coexisting for years, but an agent cannot hold two contradictory procedures at once and will pick one arbitrarily per call.

A rough allocation for a prompt that works: a sentence or two on tone, a short paragraph on what the agent is and isn't for, and then the great majority of the length on the procedure and its branches. Prompts that invert that ratio — three paragraphs of persona, one line of process — are the ones that improvise.

A test for whether a prompt is specific enough: hand it to someone who has never done the job and ask them to role-play the call. Where they hesitate is where the agent will too.

Be explicit about what you don't want

Positive instructions describe the intended path. They say nothing about the plausible-but-wrong behaviours a model will otherwise fall into, and those are where the complaints come from.

The prohibitions worth stating outright:

• Never quote a price, date or figure that isn't in the retrieved material or the caller's own words.
• Never confirm anything as booked, cancelled or processed until the system has actually returned success.
• Never re-ask for something the caller has already given, even if the flow arrives back at that step.
• Never speculate about why something happened — an outage, a delay, a charge — beyond what the record says.
• Never agree to an exception. Route it instead.

Name the stopping conditions

Explicit escalation rules do more for quality than any amount of stylistic guidance. State the conditions under which the agent must hand off to a person, and it will stop trying to solve things it shouldn't.

The instinct is to make the agent maximally capable, which quietly turns every hard case into an improvisation. Naming the stopping conditions does the opposite: it makes the boundary of competence a stated feature rather than an emergent property, and it means the failure mode is a transfer instead of a wrong answer.

Conditions that are usually worth an immediate handoff, whatever the vertical:

• The caller asks twice for a person. Once can be reflex; twice is a decision.
• Anything involving a complaint about harm, money already lost, or legal language.
• A request for an exception to a stated policy.
• Any point where the agent has failed the same step twice.
• Distress in the caller — the agent's job at that point is to get them to someone, quickly.

Test against your worst calls

Replay the calls that went badly, not the ones that went well. The edge cases in your recordings are the specification.

Happy-path testing tells you almost nothing, because the happy path is what the prompt was written from. The calls where a human struggled are the ones that contain the branches nobody documented, and every one you replay either passes — in which case you have evidence — or fails in a way you can fix before a caller finds it.

Build the set deliberately, and keep it. A dozen genuinely awkward recordings, re-run after every prompt change, will catch more regressions than any amount of re-reading the prompt. It also stops the most common failure in prompt iteration: fixing today's complaint by adding a line that breaks something you fixed last month.

Change one thing at a time

Prompts degrade through accretion. Each individual addition is defensible; the twentieth turns the whole thing into a pile of special cases that contradict each other, and nobody can say which line is responsible for any given behaviour.

Two habits prevent most of it. Make one change per iteration and re-run your awkward-call set before making another. And when adding a rule, check whether it contradicts one already there — if it does, the fix is editing the original, not stacking a qualifier on top.

When a prompt gets long enough that this is hard to do, that is usually the signal that part of it wants to be structure rather than instruction. Sequencing, mandatory fields and hard gates are more reliably enforced as workflow steps than as sentences a model is asked to remember.