How Do You Write a Brief an AI Agent Can Actually Follow?

How do you write a brief an AI agent can actually follow?

You write it for a competent stranger on their first day, then you add the reasons. Most briefs that fail are not too short, they are too assumed. They carry a decade of your context in three sentences and then act surprised when the output misses the point entirely.

The vendors who build these models publish guidance on this, and it is more useful than most of the prompt advice circulating on social media, because it is written by the people who can see what actually goes wrong.

Here is how I structure a brief, what the documentation says, and the parts people consistently leave out.

What is the test for a good brief?

Anthropic's prompting guidance gives one, and it is the best single sentence on this subject I have read. Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they would be confused, the model will be too.

The same guidance frames the mental model behind it. Think of the model as a brilliant but new employee who lacks context on your norms and workflows. That framing does most of the work, because it tells you exactly what to add: the things a new hire would ask about and you would never think to write down.

I use the test literally. If I am writing a brief that matters, I send it to someone unconnected to the project and ask what they would produce. The gap between what they describe and what I wanted is the part of the brief I have not written yet.

Why does explaining the reason matter?

Because a rule without a reason cannot generalise, and your brief will always be incomplete. Anthropic's documentation makes this point with a small, memorable example. Instead of writing never use ellipses, write that your response will be read aloud by a text to speech engine, so never use ellipses since the engine will not know how to pronounce them.

The documentation's comment on that example is the whole lesson: the model is smart enough to generalise from the explanation. A rule handles the case you thought of. A reason handles the cases you did not.

This is also why briefs written as a list of prohibitions age badly. Every prohibition is a patch for a specific failure, and a brief made entirely of patches tells the model what you are afraid of rather than what you are trying to achieve.

How specific should the instructions be?

Specific about the output, sequential about the process. Anthropic's guidance says to be specific about the desired output format and constraints, and to provide instructions as sequential steps when the order or completeness of steps matters. OpenAI's guidance points the same way, noting that its models benefit from more explicit instructions around how to accomplish tasks.

In practice that means naming the format before you describe the task. Word count, structure, tone, what must be present and what must not. If the brief does not say, the model will choose, and it will choose the most common answer on the internet rather than yours.

It also means being honest about which steps have an order. Plenty of briefs read as sequences when they are actually a set of requirements, and writing those as an ordered list invents a dependency that does not exist.

Where should the context go?

Instructions first, changeable material last. OpenAI's guidance is specific that reference content is usually best positioned near the end of your prompt, because you may include different context for different generation requests. The instruction set stays put while the material underneath it changes.

That ordering has a practical benefit beyond model behaviour. It separates the part of your brief that is stable from the part that changes every run, which means you can version the stable part and template the rest. A brief where the instructions and the data are interleaved is a brief nobody can safely edit.

For content work this maps cleanly. The standing brief holds the voice, the structure, the rules about what may and may not be claimed. The per run context holds this week's topic, source material, and links. I described how I use that split in whether AI should write your first draft.

How do you brief an agent that can take actions?

You write down what it may do without asking and what it must confirm first. Anthropic's guidance includes a sample prompt for exactly this, instructing the model to consider the reversibility and potential impact of its actions, to take local reversible actions freely, and to ask before actions that are hard to reverse, affect shared systems, or could be destructive.

The examples in that sample are worth copying almost word for word. Deleting files or branches, dropping database tables, force pushes, and anything visible to other people such as pushing code, commenting on issues, or sending messages. That list maps onto marketing work more directly than it first appears.

The same guidance adds a line I would put in every agent brief I write: when encountering obstacles, do not use destructive actions as a shortcut. An agent that cannot complete a task cleanly should stop, not clear the obstacle. The permissions side of this deserves its own treatment, which I gave it in giving an agent the narrowest credential that works.

What does a good brief say about finishing?

It says what done means, and it asks for a check. OpenAI's guidance for agentic work is to decompose the query into all required sub-requests and confirm that each is completed, which is a useful instruction to hand to the agent itself rather than keeping it as a private expectation.

So the last section of my briefs is almost always a completion checklist written as questions. Did you produce every section. Did you use only the supplied sources. Did you leave anything unfinished. Asking the model to answer those explicitly catches a class of quiet partial failures.

The useful side effect is that the answers become your review notes. When something is wrong, you can see which check the model believed it had passed, which tells you whether the brief was unclear or the work was.

How do you stop a brief from rotting?

Version it and test it like anything else in production. OpenAI's documentation says to add representative fixtures, tests, and evaluation checks before changing production prompts, and to pin production applications to specific model snapshots to ensure consistent behaviour. Both halves of that advice matter, and most teams do neither.

That advice is aimed at developers and it applies just as much to a marketing team running content through an assistant. If your brief lives in a document that three people edit and nobody dates, you will never be able to explain why last month's output was better.

Keep a small set of real inputs with outputs you accepted, and re-run them whenever the brief changes. It is the only way to tell an improvement from a preference, and it is the same check that catches quality moving underneath you, which I wrote about in what to do when an AI agent's output quality drifts.

What does a finished brief look like?

Five parts, in this order. The job and why it matters, the output format and constraints, the rules with their reasons attached, what the agent may and may not do on its own, and the completion checks. Then the changeable context at the end.

That ordering is not decoration. Everything above the context line is the part you own and maintain, and everything below it is what you supply per run. Keeping the boundary visible is what makes a brief something a team can share rather than something one person keeps rewriting.

Length matters far less than people think. I have written briefs of two hundred words that worked and briefs of two thousand that did not, and the difference was never the word count. It was whether a stranger could have followed it.

What should you do next?

Take the brief you use most often and apply the golden rule to it this week. Hand it to someone who does not know the project and ask what they would produce. Write down every question they ask, because each one is a missing line.

Then go through your rules and add a reason to each one. That single pass usually improves output more than any rewording, and it makes the brief shorter rather than longer, because reasons let you delete the three patches that existed to cover the same gap.

I have written more than 350 articles with a version of this process behind them, and the briefs that lasted were never the clever ones. They were the ones that explained themselves. If you are trying to get an agent to do real work in your business and the output keeps missing, reach out and let's chat about the brief.