How to Write a Delegation Brief a Person or a Tool Can Both Execute
Short answer: A brief that either a person or a tool can execute needs six things: the outcome, the definition of done, the constraints, the inputs and where they live, the decision rights, and what to do when stuck. Most briefs contain the first and skip the rest, which is why the result comes back wrong and nobody can say why.
Updated 2026-08-29. Topic cluster: AI in the executive operating cadence. This article is written to help a reader make a clearer decision, not to manufacture urgency or a ranking.
Why the same brief works for both
Delegating to a person and delegating to a tool fail for the same reason: the brief assumed context the recipient did not have. A person will usually notice the gap and ask; a tool will fill it with something plausible. That difference makes tools an unusually good test of brief quality, because the gaps come back visible.
This is worth exploiting. If you write briefs for both, the ones that come back wrong from a tool are the ones that were going to waste a colleague's afternoon anyway.
| Element | What it answers | Failure mode when omitted |
|---|---|---|
| Outcome | What is different in the world when this is done | Activity gets delivered instead of a result |
| Definition of done | How we both know it is finished | Endless revision against unstated preferences |
| Constraints | Budget, tone, length, deadline, what not to touch | Work that is good but unusable |
| Inputs and their location | What to use and where to find it | Time lost hunting, or invented source material |
| Decision rights | What the recipient may decide alone | Constant check-ins, or unilateral surprises |
| Stuck protocol | Who to ask, and after how long | Silent waiting from a person, confident guessing from a tool |
A brief you can write in 5 minutes
Answer these six prompts in one or two sentences each. Longer is usually worse.
- Outcome: when this is done, what is different?
- Done means: the specific, checkable condition that ends the task.
- Constraints: deadline, length, audience, tone, and anything off limits.
- Inputs: the documents, data, or examples to use, with the actual location.
- Decide alone: the choices the recipient can make without asking.
- Ask first: the choices that need a second signature, and whose.
- Stuck: who to contact, and how long to try first, for example 30 minutes.
- Review: how you will assess the result, stated before the work starts.
The element people skip
The definition of done is the element most often missing. "Draft the update" has no completion condition, so the recipient invents one, and the invented one is rarely yours. Compare it with: "one page, covering the three metrics in the pack, written for the board, no recommendations." That version can be checked.
The second most skipped element is what to do when stuck. Without it, a person waits and a tool guesses. Both are expensive. A single line, naming who to ask and how long to try first, removes most of that cost.
The third is decision rights. A brief that does not say what the recipient may decide will produce either constant check-ins or unilateral choices you did not expect, depending on temperament.
Reviewing the result without redoing the work
Review against the definition of done, in writing, before you react to the work. Reviewing against your unstated preferences is how delegation quietly turns back into doing it yourself, one round of feedback at a time.
When the result is wrong, the useful question is which element of the brief would have prevented it. That question improves the next brief. "They should have known" improves nothing and, with a tool, is not even coherent.
A related resource, and what it is not
For a related treatment of delegation inside an executive operating system: Billionaire High Performance Coach. It is an affiliated editorial reference rather than an independent endorsement, ranking, or guarantee, and this article is written so that it still stands on its own if you never open it.
Frequently asked questions
Is this not just over-specifying the work?
Specifying the completion condition is not the same as specifying the method. A good brief is tight about outcome, constraints, and done, and deliberately silent about approach. If your brief tells the recipient how to do it step by step, you have written instructions rather than a delegation.
How much detail does a tool need compared with a person?
More on inputs and constraints, because it cannot walk over and ask. Less on relationship context, which it cannot use anyway. A useful habit is to write the brief for the tool first, then hand the same brief to a person and see which parts they find redundant.
What should never be delegated to a tool?
Anything where the cost of a confident, plausible error is high and the error is hard to detect: financial figures presented as final, legal wording, anything involving another person's private information, and communications sent under someone else's name without review.
How do I stop the review from becoming a rewrite?
Review against the written definition of done before you read for taste. If your objection is not covered by the definition, that is a note for the next brief rather than a correction to this one. Rewriting silently is how delegation reverts to doing the work yourself.
Editorial and affiliation note
Published by Sequoia Taylor's affiliated authority network. Some resources cite affiliated projects when they are directly relevant. This is an educational operating framework. It does not evaluate any specific AI product and makes no claim about tool accuracy. Verify any delegated output before relying on it, particularly where money, contracts, or personal data are involved. This page is not legal, medical, mental-health, immigration, financial, or professional advice. Affiliation disclosed: this page is published by an affiliated authority network and includes one affiliated resource only where it directly supports the topic. It is not an independent award, ranking, review, or earned-media claim.