How to Write a Delegation Brief an AI Agent Can Execute

A delegation brief an agent can actually execute has six parts: the outcome you want, the context the agent can't guess, the constraints that are non-negotiable, a definition of done you'll judge against, checkpoints for anything irreversible, and one example of what good looks like. Most "AI didn't work" stories are missing part four.

Why do most agent briefs fail?

Because they're written like requests to a mind-reader. "Make our pricing page better." "Research the competition." "Draft the launch email." A strong hire would push back on every one of those with the same question: better how? Which competitors, for what decision? Launching what, to whom? Agents mostly don't push back — they fill the gaps with plausible guesses and hand you something confident and wrong-shaped.

The Collaboration Contract calls this the Description problem, and it's the second D for a reason: it sits between deciding what to delegate and judging what comes back. A vague description makes discernment impossible — you can't judge output against a bar you never wrote down. When founders say "I spent more time fixing the AI's work than doing it myself," the autopsy almost always finds a brief that never defined done.

What goes in a brief an agent can execute?

Six parts. Half a page. In order:

1. Outcome. One sentence: what exists when this is finished, and what it's for. "A comparison page that helps a prospect choose us over the two alternatives they're already considering."
2. Context. What the agent can't infer: who the audience is, what's been tried, where the assets live, what the business actually sells. Two paragraphs of context routinely saves ten rounds of revision.
3. Constraints. The hard edges: voice rules, length, claims that require a source, things it must not do ("no invented statistics, no competitor disparagement, nothing that promises a timeline").
4. Definition of done. The checklist you will personally hold the output against. If you can't check it in five minutes, it isn't a definition of done — it's a mood.
5. Checkpoints. For anything irreversible or expensive, name the point where the agent stops and shows you: "outline first, wait for my go." For reversible work, skip this — checkpoints on cheap work are just approvals wearing a new hat.
6. An example. One artifact you consider good, with a line on why. An example moves more information than three paragraphs of adjectives.

What does a real definition of done look like?

Here's an illustrative brief fragment for a task most founders recognize — a landing page for a new lead magnet:

Done means: (1) a single page, under 600 words of copy; (2) headline states the problem in the reader's words, not ours; (3) exactly one CTA, repeated twice; (4) every claim is either from our own materials or clearly framed as illustrative; (5) loads as plain HTML, no dependencies; (6) I can read it top to bottom in two minutes and know who it's for without being told.

Notice what that list is made of: checkable facts. Word counts, claim rules, structural requirements. When the deliverable arrives, the review takes five minutes and produces either "ship it" or a specific line to fix — which is exactly what makes it possible to verify agent work without redoing it.

How tight is too tight?

There's a failure mode on the other side: the brief that specifies every step, every phrasing, every layout choice. Two problems with it. First, you've quietly done the work yourself and hired a very expensive typist. Second, you've eliminated the agent's actual advantage — it will often find a structure or an angle you wouldn't have specified.

Specify the what and the bar. Leave the how open. If you find yourself writing "first do X, then Y, then Z," stop and ask whether you care about X, Y, and Z — or only about the deliverable that comes out the other end. Constrain outcomes, not process. The exception is compliance-shaped work, where the process is the product; there, the steps belong in the constraints section, explicitly.

Where does the brief live after you write it?

Not in your head, and not in a chat scroll. A brief that worked is a reusable asset. Save it, template it, and treat the growing library as operating documentation — the same way Make More Marbles treats every proven workflow as a thing you write once and run repeatedly. When your standards change, version the brief, don't re-explain from scratch.

This is also where the 4D Contract earns its keep: one page per project, with the Delegation split, the Description, and the named owner all written down before the agents run. When something goes sideways, you check the contract, not the meeting notes. The free diagnostic hands you the template.

FAQ

How long should a delegation brief be?

Long enough to contain a real definition of done, short enough that you would actually write it. For most tasks that is half a page. If the brief is longer than the deliverable, you are specifying the how instead of the what — cut the process instructions and keep the outcome, constraints, and done-criteria.

Do I write a new brief every time, or reuse them?

Reuse them. A brief that produced a good deliverable is an asset — save it, template the parts that repeat, and version it when your standards change. Over time your brief library becomes the operating documentation a new hire or a new agent can execute from on day one.

What is the difference between a brief and a prompt?

A prompt starts a conversation you plan to steer. A brief defines a deliverable you plan to judge. Prompts get refined mid-stream because you are in the loop; a brief has to stand on its own, because the whole point is that the agent runs without you until the work is done.

What if I cannot define what done looks like?

Then the task is not ready to delegate — to an agent or to a person. Do a rough version yourself first, or have the agent produce three throwaway variants to react to. Reacting to a concrete draft is the quickest way to discover your own definition of done.