The One Line That Turned My Agent's Silent Guesses Into Cheap Questions

Why this matters

You've rewritten that prompt four times now. Different verbs, an extra adjective, a bulleted list for good measure. The output is still wrong in some new way you didn't see coming. That's because you're editing the wrong layer — the instruction was never the problem. What's missing is everything a junior engineer gets for free: context, boundaries, and a definition of done.

The task that failed

Two weeks ago I fired off a Claude Code task straight from a saved template: 'Refactor the payment retry logic to use exponential backoff, add tests, update the docs.' Clean. Specific. Technically correct. The agent did refactor the retry logic — but it also 'improved' the queue consumer sitting next to it, renamed a config key three other services depended on, and wrote tests that asserted its own new behavior instead of the contract we actually needed. Nothing in the prompt told it not to touch those things. Nothing told it what 'done' meant beyond tests passing. And nothing gave it room to stop and say 'this config key looks load-bearing, should I touch it?' — so it guessed, and kept going.

What stuck with me was pulling up the Linear ticket I'd have written for a mid-level engineer doing this exact task. It had four things my prompt template didn't — and not one of them was about how the sentence was worded.

Side by side

OLD PROMPT TEMPLATE:
"Refactor the payment retry logic to use
exponential backoff, add tests, update
the docs."

HUMAN 1:1 DELEGATION BRIEF (same task):

Context: Retries are firing too fast during
provider outages, tripping our own rate
limiter and making outages worse, not better.
This is the #2 cause of incident escalations
this quarter.

Scope: Only src/payments/retry.ts and its
direct tests. Do not touch queue_consumer.ts
or any config keys shared with billing-service
— those are load-bearing for another team.

Definition of done: Backoff caps at 30s,
max 5 attempts, existing retry tests still
pass unmodified, new tests cover the cap
and jitter behavior specifically. If a test
you'd need to change already exists, stop
and ask me first.

Pushback: If the current retry contract is
used elsewhere in ways that make this risky,
tell me before changing it — don't guess.

The four elements the prompt was missing

• ▹Context — the why behind the task, so the agent weighs trade-offs the way you would instead of just satisfying the literal ask
• ▹Constraints — what NOT to touch, spelled out, because an agent has no instinct for what's load-bearing unless you name it
• ▹Definition of done — not 'tests pass,' but which tests, what behavior has to hold, and who breaks the tie when it's ambiguous
• ▹Permission to push back — a line telling the agent that surfacing ambiguity is a valid output, not a failed attempt at the task

None of this is a prompt-engineering trick. It's the same four things you already put in a junior engineer's 1:1 delegation brief, by instinct, without stopping to think about it — because you learned the hard way that skipping any one of them produces exactly the failure mode you're now seeing from your agent: technically correct work solving the wrong problem, or a boundary nobody drew getting blown past.

Rewriting a real task

Take a task from last week: migrating a logging call off a deprecated internal wrapper onto the new structured logger. Old-style prompt: 'Replace all calls to oldLog() with the new Logger class.' Rewritten as a brief, I added context (oldLog() is getting removed next sprint, this is prep work, not urgent), constraints (leave the three call sites inside the auth module alone — frozen pending a security review), a definition of done (log level and message text stay identical, only the call signature changes), and permission to push back (if a call site passes something the new Logger can't serialize, ask — don't just cast it).

With the old prompt, the agent silently JSON-stringified an object the new Logger couldn't handle — twice — and moved on like nothing happened. With the brief, it stopped at exactly that spot: 'This call at billing.ts:142 passes a circular-reference object — oldLog() ignored it, but Logger will throw. Want me to strip it, log a placeholder, or skip this call site?' That's a question the old prompt made structurally impossible, because nothing in it said guessing wasn't the expected move.

What I tracked

I started logging every multi-step agent task for about three weeks — roughly 30 with the old ad-hoc prompt style, then another 30-ish with the brief format. 'Failure' meant I had to redo, revert, or manually clean up something the agent touched. The old style failed close to half the time, usually scope creep or a definition-of-done mismatch, not syntax errors. With the brief format that dropped hard, and the failures that remained changed character: instead of silent wrong guesses, the agent flagged the ambiguity and waited. That's a much cheaper kind of failure to have.

If I had to name the single highest-leverage line in the whole brief, it's the pushback permission. Context and constraints lower the odds the agent goes wrong in the first place. Permission to push back changes what happens when it's still uncertain anyway — it turns a silent wrong guess into a visible, cheap question. Same reason a good manager tells a new report 'ask me if something looks off' on day one instead of hoping they'll infer it's welcome.

When the full brief is overhead

Not every task earns this treatment. Rule of thumb: if you could undo the damage with one git revert and nobody else would even notice, skip the brief and just prompt directly. The full format pays for itself on anything multi-step, anything touching shared code, or anything where 'done' isn't obvious just from looking at the diff.

Tomorrow

Giving the agent permission to push back solves the guessing problem — and opens a new one. Once your agent starts surfacing ambiguity instead of plowing straight through it, you'll notice it also pushes back on things that don't need pushback, hedging to look careful. Day 10 is about telling a pushback that caught something real apart from one that's just noise.

Extend your knowledge

• ▹Pull your last 10 saved agent prompt templates and check each one against the four elements — most will be missing at least two.
• ▹Start a simple log, even a spreadsheet, of agent task outcomes: task type, brief used or not, whether you had to redo or revert. Three weeks of data will change how you write prompts going forward.
• ▹Read Anthropic's Claude Code best-practices guide on task scoping and clear instructions — a useful cross-reference for how much explicit boundary-setting matters in practice.
• ▹Add one line to your next multi-step task — 'if anything here is ambiguous, ask me before proceeding' — and watch what changes.