How to Write an AI Agent Brief

An agent can now work for hours on a single request, searching, writing, and making changes with no one watching each step. Whatever you leave unsaid, it fills in with its own guesses, and those guesses add up over dozens of steps. A vague request that would earn a quick clarifying question from a colleague can send an agent confidently down the wrong path.

That makes the written handoff your main point of control. Writing a strong brief draws on skills people have used for decades to delegate to each other, in military orders, product requirements, and project scopes. It isn't about clever wording or magic phrases. It's about saying what the work is for, what the agent may and may not touch, what background it can't find on its own, and what finished looks like. Leave out anything the agent could work out by reading, and keep everything it couldn't.

A brief that describes the destination lets the agent find another route when its first plan stops working. A brief that only lists steps leaves it stuck the moment reality changes. A checkable definition of done also tells the agent when to stop, so it neither quits early nor keeps going forever. Describe the end state and the limits clearly, then let the agent choose the path.

The agent brief

An agent brief is the written handoff a person gives an agent before multi-step work. A chat prompt asks for one reply and waits for the next message. A brief sets up a run that may take dozens of actions and hours of work, so it has to say where the agent is headed and how to tell when it has arrived.

Ethan Mollick, a Wharton professor who studies AI at work, noticed that delegation documents in every field, from product requirements documents to the Marines' Five Paragraph Orders, ask the same questions: "What are we trying to accomplish, and why? Where are the limits of the delegated authority? What does 'done' look like? What specific outputs do I need? What interim outputs do I need to follow your progress? And what should you check before telling me you're finished?" ^[1]

AI labs arrived at the same shape. OpenAI's 2026 guide for its GPT-5.5 model recommends prompts built around a goal, success criteria, constraints, output, and stop rules, and says the model "is strongest when the prompt defines the target outcome, success criteria, constraints, and available context, then lets the model choose the path." ^[2] A brief describes the destination and the boundaries. It isn't a longer, politer prompt, and it isn't a list of every step.

Management as a superpower

Directing an agent well depends less on clever prompt wording and more on the skills of a good manager. Mollick argued in January 2026 that these are "management 101 skills. If you can explain what you need, give effective feedback, and design ways of evaluating work, you are going to be able to work with agents." As he put it, "The skills that are so often dismissed as 'soft' turned out to be the hard ones." ^[3]

His evidence came from his own classroom. In an experimental 4-day class at the University of Pennsylvania, executive MBA students, few of whom had ever coded, used AI agents to build startup prototypes that Mollick judged far ahead of what students had managed over a full semester before AI. He credits their years of learning to scope problems, define deliverables, and spot when a financial model or medical report was off.

The responsibility transfers along with the skills. Andy Grove argued in High Output Management (1983) that delegating a task never releases the manager from responsibility for it, and that holds when the delegate is software. Companies are starting to make this a job: in February 2026, Harvard Business Review described the role of the agent manager, with Salesforce as an example ^[4].

Stating the goal

The goal in a brief states the purpose of the work and its end state: what should be true when it's finished, and why that matters. Military planners have long relied on the same idea. American joint military doctrine describes commander's intent as a short statement of an operation's purpose and desired end state, so that subordinates can keep working toward it without new orders, even when events don't go as planned.

Agents face that problem mid-task. A search returns nothing useful, a file isn't where the person expected, or a website has changed. An agent holding only a list of steps either stalls or keeps following steps that no longer make sense, while one that knows the end state can find another route. OpenAI's GPT-5.5 guide puts it in one line: "Describe the destination rather than every step." ^[5]

The why matters as much as the what. Anthropic's prompting guide shows that a reason works better than a bare rule: telling Claude a response will be read aloud by a text-to-speech engine beats simply writing "NEVER use ellipses," because the reason helps the model understand the goal behind the rule ^[6]. Spelled-out steps still belong in a brief when the order itself is a requirement, such as a compliance process that must run in a fixed sequence.

Background the agent lacks

An agent starts every task knowing only what's in its brief and what it can find on its own. Everything else in the person's head, from who the work is for to what was already tried, stays there unless the brief hands it over. Anthropic's Claude Code documentation puts it plainly: "Claude can infer intent, but it can't read your mind." ^[7]

Background worth handing over includes:

• Who the work is for and how it will be used
• Preferences, such as tone, format, or sources to trust
• Decisions already made, so the agent doesn't reopen them
• What's been tried and why it didn't work
• Where the relevant files, documents, or data live

Access isn't the same as background. An agent that can open a person's files sees what exists, but not why it exists or what the person wants next. That's why the same guidance says to write down project-specific decisions and known pitfalls, and to leave out anything the agent can work out by reading. Thin briefs cause real failures: when Anthropic's research system had a lead agent give helper agents short instructions like "research the semiconductor shortage," one "explored the 2021 automotive chip crisis while 2 others duplicated work investigating current 2025 supply chains." ^[8]

Pro Tip! Before keeping a line of background, ask whether removing it would cause the agent to make a mistake, and cut it if not, since overloaded instructions get ignored.

Setting constraints

Constraints mark where the agent's authority ends: what's in scope and what isn't, what it may change and what it must leave alone, and how much time, money, or effort it can spend. Ethan Mollick's list of delegation questions includes this one, about the limits of the delegated authority, and it's easy to leave out, because human colleagues usually infer scope from context.

Capable agents left without limits tend to do more than asked. Anthropic's guide for Claude Opus 5 warns that the model "can also expand the scope of a task, adding steps that weren't requested," and its suggested instruction opens with "Deliver what was asked, at the scope intended." ^[9] A brief can also say what's out of scope outright and cap the effort, for example a limit on searches, hours, or spending for the run.

A written constraint is guidance, not a lock. Claude Code's documentation calls its instruction files "advisory," in contrast to automated rules that run every time ^[10]. A brief that says "don't touch the billing settings" makes that action unlikely, not impossible. A limit that must hold needs enforcing in software, through permissions or a blocked tool.

Defining done

A definition of done is a set of checkable conditions, written before the work starts, that say when the task is finished. "Make it good" or "research X" can't be checked. "All 12 links work" or "a summary under 300 words with a source for every number" can, by the agent along the way and by the person afterward.

Without one, agents fail in opposite directions. Some stop too early: in Anthropic's experiments with long coding projects, a later agent session "would look around, see that progress had been made, and declare the job done." ^[11] The fix was a requirements file listing over 200 features, each marked as failing until it actually worked. Others never stop: Claude Code's documentation warns that asking the agent to "investigate" something without scoping it can send it reading hundreds of files ^[12].

Criteria work best alongside the purpose behind them, because narrow criteria can be met to the letter while the real goal is missed. Anthropic's guidance on automated code tests makes the point: "Tests are there to verify correctness, not to define the solution." ^[13]

Breaking down big tasks

Some tasks should go to an agent as one brief, and some work better as several. The default for a capable agent is one: Anthropic's guide for Claude Opus 5 says the model "performs best when given the complete task specification up front and left to run." ^[14] Chopping a task the agent could finish in one go only adds handoffs and waiting.

Split the work when:

• An intermediate result needs review before the next part builds on it
• Later steps depend on a decision only the person can make
• The task is long enough that the agent tends to take on too much at once

That last case showed up in Anthropic's long-running coding experiments, where the agent kept trying to build everything in a single pass until each session was asked to work on "only one feature at a time" ^[15]. Anthropic's prompting guide likewise keeps chained, step-by-step requests for cases where someone needs to inspect intermediate outputs ^[16]. Where the agent should pause for approval along the way is a separate choice from how the work is split.