How to Write a Task Brief for an AI Agent

You ask an agent to “clean up the customer list and send the follow-up emails,” and it does exactly that, sending forty emails to people who had already unsubscribed, because nothing told it to check. The work looks confident and complete. It is also wrong, and you find out after it has already gone out, not before.

That failure did not come from a weak model. It came from a brief that assumed shared context the agent did not have. An agent will fill gaps in your instructions with something plausible, and plausible is not the same as correct.

Vague Instructions Produce Confident Wrong Work

A human collaborator fills gaps with judgment shaped by years of working with you: they know which list is stale, which client is touchy, what “clean up” usually means in your team’s vocabulary. An agent fills the same gap with whatever is statistically likely given the words you used, and it states the result with exactly the same confidence whether it guessed right or wrong. That confidence is the actual danger. A human who is unsure usually sounds unsure. An agent rarely does.

Five Things A Working Brief States Explicitly

A brief that holds up has five parts, and skipping any one of them is where the gaps come from.

The goal, stated as an outcome, not a task. “Reduce the list to active subscribers only” is a goal; “clean up the list” is not.

The constraints, meaning what must stay true no matter what: field formats, tools allowed, systems not to touch.

What done looks like, concretely enough that someone other than you could check it: a count, a format, a specific file or state.

What not to do, which matters as much as what to do. If sending emails is out of scope for this pass, say so, do not assume “clean the list” implies “and don’t send anything.”

Where to stop and ask, the specific situations where the agent should pause for a human rather than proceed on its own judgment.

The Difference A Real Brief Makes

Before:

Clean up the customer list and follow up with anyone who hasn’t responded.

After:

Goal: remove duplicate and unsubscribed rows from the customer list export, output a new CSV with the same columns. Constraints: do not modify the source file, do not send any emails or messages, do not merge records that only partially match. Done means: a new file named customers_cleaned.csv with a row count summary of what was removed and why. Do not: contact anyone on the list. If you find rows that look like duplicates but do not match exactly on email address, stop and list them for me instead of deciding.

The second version cannot produce the forty-email mistake, because sending anything was explicitly out of scope and the agent had a named condition under which to stop.

The Stop-And-Ask Line Is The One Most Briefs Skip

Every other part of a brief describes what the agent should do. This one describes what it should not decide alone. Without it, an agent treats every ambiguous case as something to resolve on its own, because resolving things is what it is optimized to do. Naming two or three specific stopping conditions, not a vague “ask if unsure,” is what actually gets honored, because the agent has a concrete trigger to check against rather than a judgment call about its own uncertainty.

Anthropic’s own engineering guidance on building agents makes a related point about instructions generally: an agent performs closer to how a careful new hire would if you tell it exactly what you would tell that hire, including the parts that feel obvious to you. See their notes on building effective agents for the fuller argument. For the human side of the same handoff, see how to write a clear task handoff and writing documentation an AI agent can follow.

The Review Gate Belongs In The Brief, Not After It

Write the review step into the brief itself: who checks the output, against what, before it goes anywhere real. “I will review the CSV before anything downstream uses it” is one sentence, and it changes how you treat the agent’s output, as a draft rather than a finished action. See how to review work an AI agent finished for what that check should actually cover.

A Wrivio Context For A Reusable Brief Scaffold

Keep the five-part shape as a standing instruction so you are filling in specifics, not reinventing the structure each time.

Rewrite this rough task description into a structured brief for an AI agent with five labeled sections: Goal, Constraints, Done means, Do not, and Stop and ask if. Keep the sections short and concrete, favoring specific, checkable statements over general ones. Keep every name, date, figure, and commitment exactly as written in my draft.

Press Ctrl+Shift+Space, paste your rough task description, and check the diff before handing the brief to an agent, since a missing constraint here is the kind of gap that only shows up after the work is already done.

Common Questions

What is the single most common mistake in an agent brief?

Stating the goal as a task rather than an outcome, which leaves the agent to guess at the scope instead of checking its work against a defined result.

How specific should the stop-and-ask conditions be?

Specific enough to check against, two or three named situations rather than a general “ask if unsure,” since a vague trigger rarely gets honored.

Does a good brief remove the need for human review?

No, a clear brief reduces the number of things that go wrong, but the review step is still what catches the ones a brief could not anticipate.

Should I write a new brief every time, or reuse a template?

Reuse a structure for the recurring parts of the job and write the specifics fresh each time, which is faster and more consistent than starting from a blank page.

How long should a task brief be?

Long enough to cover all five parts concretely, usually well under a page; length is not the goal, checkable specificity is.

Turn a rough task description into a structured brief in seconds: Download Wrivio for Windows.