The Outcome Brief

Use this before you hand a task to a colleague, a contractor or an AI agent. It turns an instruction written as steps into a description of the finished state, plus a check anyone can run without watching the work happen. When the task is going to an agent, four more parts make the brief safe to act on.

The frame

Three parts, in plain text, so it pastes into an email, a ticket or a chat message.

Before: [the instruction as you sent it, unedited]
After: [the state that will be true when the work is finished, with a date or trigger]
Check: [what someone would see if they looked, and where]

Start from a message you’ve already sent, unedited, so the gap between the steps and the outcome is visible.

If the task is going to an AI agent

An agent can’t lean over to your desk and ask what you meant. Whatever it needs to do the job has to be in the brief, and anything missing gets filled with an assumption. Keep the After and the Check, drop the Before, and add four parts:

Outcome: [the After]
Check: [the Check]
Work from: [the inputs to use and where they are, plus anything already decided that it should not reopen]
May do / Must not do: [what it can change or send on its own, and what is off limits]
Ask first if: [the situations where it should stop and ask you instead of carrying on]
Hand back: [what it returns, in what format, with a short note of what it did and assumed]

Have an AI draft it

Describe the task in your own words and let an AI assistant turn it into the right version. One prompt covers both.

I'm going to describe a task I need to hand off. Turn it into a brief.

The task is going to: [a person / an AI agent]

If it's going to a person, write three parts: Before (my description, unchanged), After, Check.
If it's going to an AI agent, write six parts: Outcome, Check, Work from, May do / Must not do, Ask first if, Hand back.

Rules:
- Write the After (or Outcome) as a finished state with a date or trigger, not as steps.
- Write the Check as what someone would see if they looked, and where.
- Do not invent facts, names, files or limits. If a part can't be filled from what I've written, write "MISSING:" and give me the question I need to answer.
- Keep each part to one or two sentences.
- If any step in my description has to stay because the order is itself a requirement, list it under "Steps that must stay" with a one-line reason. Write "none" if there are none.

My description: [paste it here]

Before you paste real project material into a third-party AI tool, check your organisation’s policy on client and commercially sensitive information. Removing names and figures from your description is a quick way to stay on the safe side.

Treat whatever comes back as a first draft. Every “MISSING:” line is a decision only you can make, and the questions further down are the way to test the rest.

Worked examples

A risk register entry

Before: Open the register, go to the risks tab, add a row for the vendor delay, set severity to high, put Sarah down as owner, and save it.
After: By end of Thursday, the risk register holds one entry for the vendor's delayed delivery, severity high, owner Sarah, with a mitigation noted.
Check: Search the register for the vendor's name. One entry appears with all four fields filled.

A Friday status update

Before: Pull the latest from the project channel, summarise it, colour the RAG for each workstream, and send it round on Friday.
After: By 3pm Friday, each of the five stakeholders on the distribution list has a one-page status covering all three workstreams, with a RAG rating per workstream and the top two risks named.
Check: The sent folder shows one message to the full list before 3pm. Each workstream lead can find their own line and agree it matches their latest update.

Steering committee prep

Before: Find last month's steering pack, update the slides, add the new risks and get it to me.
After: By noon Wednesday, the pack for Thursday's steering committee is in the shared folder with this month's budget position, milestone status and both new risks on the agenda, each risk with an owner.
Check: Open the pack. The budget slide shows this month's actuals, and both new risks appear with a name beside them.

The vendor delay, briefed to an agent

The same delay as the first example, this time for an agent that can read the project folder and draft messages.

Outcome: By 4pm Wednesday, the RAID log holds one new risk for the vendor's two-week delivery slip, rated high, owner Priya, with a mitigation drafted. A draft update for the sponsor is in my drafts folder.
Check: Filter the log by today's date and one new entry appears with every field filled. The draft gives the new delivery date and the risk rating.
Work from: The RAID log in the project folder, the call notes saved as vendor-call-notes, and the delivery date on the current plan. Use the log's existing rating scale and columns.
May do / Must not do: May add one entry to the log and create one draft. Must not edit or delete existing entries, send anything, or contact the vendor.
Ask first if: The call notes and the plan disagree on the delay, the vendor's name matches more than one supplier in the log, or the delay touches a milestone marked as contractual.
Hand back: The new entry, the draft, and three lines on what you read and any assumption you made.

What the four agent parts do

Work from names the files, registers or notes to use and where they live. It also settles any word that could be read two ways. If “closed” means one thing to you and another to the tool, the agent will pick one, and the error will look like a finished job.

May do / Must not do closes the gaps an outcome leaves open. An outcome can be met in ways you didn’t intend, so name the actions that are off limits: contacting people outside the team, editing existing entries, deleting anything, spending money. Say what it may do without asking as well, so it doesn’t stall on small things.

Ask first if lists the moments the agent should stop. Missing or contradictory information is the usual one. A required action outside its boundaries is another, and so is a result a stakeholder would see before you have.

Hand back says what comes back, in what format and where it goes. Ask for a short note of what it read and any assumption it made. That note makes your review quicker and shows where the brief was thin.

If you brief the same agent again and again, keep the parts that never change (its boundaries, what it may access, when it must always ask) in its standing instructions. The brief then carries only what is specific to this task. Those standing rules are what an agent governance charter records.

Play it back before the agent starts

Ask the agent to say back what it thinks the job is. A misunderstanding shows up in a minute here, before it shows up in the work.

Before you start, do three things and then wait for my reply:
1. Say in your own words the outcome you are aiming for and how the Check will be run.
2. List every assumption you are making that isn't written in the brief.
3. Ask me any question you need answered before you can start without guessing.

Do not begin the task until I reply.

If the play-back matches what you meant, say go. If it doesn’t, fix the brief rather than only correcting the play-back, so the fix stays with the task.

Check it before you send

Six questions. Every answer should be yes. The last two apply when the task is going to an agent.

• Does the After describe a state rather than an action?
• Could someone confirm it without watching how the work was done?
• Would it still make sense if the tool or the process changed tomorrow?
• Does it carry a date or a trigger, so “done” has a moment?
• Is everything the agent needs written in the brief, with nothing resting on an earlier conversation?
• Is there at least one entry under Must not do?

An After that reads “the register is updated” or “the update has been sent” is still a step with the verb in the past tense. Add what would be visible once it’s done.

When the steps have to stay

Some work has an order that is itself a requirement: approval chains, change control, anything an auditor will read. Keep those steps and put the outcome above them, so the person doing the work knows what the sequence is for.

For work that touches money, access or stakeholders, add one more line naming what must not happen on the way to the outcome.

What this feeds

The Check line is the standard an agent’s output gets verified against, which is the job of the second gate in the agent QA checklist. It also gives each row of an AI delegation register a “done means” line, so the record of what you’ve handed off says what finished looks like. For an agent, the Must not do and Ask first lines are where a governance charter becomes specific to one task.