# Briefing: saying what you want _Topics at every level · sourced_ Saying what you want clearly enough that the model does not have to guess. ## Guided worked example · Everyday life Fictional scripted fixture, not a measured run. No model or external actions execute. **Overview:** Follow a short task description into a usable working brief. Inspect which details constrain the work and which can remain open for proposals. **Assumptions:** A brief should supply the goal, relevant context, and success criteria without pretending every preference is already decided. **Design choices:** State hard requirements separately from preferences and invite questions about consequential gaps. Allow the assistant to propose options for genuinely open choices. **Request:** Plan a free repair workshop for 20 people under $300. **Starting evidence:** Saturday; step-free venue required. Unknown: venue availability and borrowed tools. **Action and control:** Separate constraints, preferences, unknowns, and acceptance criteria. Ask consequential questions. **Stage records (authored, not executed):** ### Input record Saturday; step-free venue required. Unknown: venue availability and borrowed tools. What changed: Establish the facts supplied for this version of the task. ### Design note State hard requirements separately from preferences and invite questions about consequential gaps. Allow the assistant to propose options for genuinely open choices. What changed: Choose an approach before treating a proposed result as accepted. ### Proposed work Separate constraints, preferences, unknowns, and acceptance criteria. Ask consequential questions. What changed: Turn the request and evidence into the next action or transformation. ### Result record · illustrative Brief records budget, attendance, access, and open venue/tool questions. Options remain provisional. What changed: Inspect the result of the authored example; this is not an executed model run. ### Verification plan Brief before/after, explicit unknowns, acceptance criteria, and a plan checked against them. If the result falls short: If requirements conflict, ask for a tradeoff rather than an impossible draft. Update the brief when a decision changes so later work uses the same understanding. What changed: Separate what needs checking from what the illustration establishes. ### Adaptation handoff Adapt this to a project, event, analysis, or document. The filename and template are optional; a shared understanding of outcome and constraints is what matters. What changed: Decide which assumptions, tools, and controls should change for your own task. **Sample result:** Brief records budget, attendance, access, and open venue/tool questions. Options remain provisional. **Change something — Omit accessibility from the brief:** A plausible venue may be unusable. Clarify the consequential constraint. **Decision:** Should consequential unknowns be silently filled? **Answer:** No; ask or explicitly keep assumptions provisional. **Why:** Show an incomplete brief, a clarification question, and a resolved assumption; avoid turning every detail into a rigid prescription. **Review criteria:** Brief before/after, explicit unknowns, acceptance criteria, and a plan checked against them. **Recovery:** If requirements conflict, ask for a tradeoff rather than an impossible draft. Update the brief when a decision changes so later work uses the same understanding. **Adapt it:** Adapt this to a project, event, analysis, or document. The filename and template are optional; a shared understanding of outcome and constraints is what matters. ## Guided worked example · Engineering & technical work Fictional scripted fixture, not a measured run. No model or external actions execute. **Overview:** Follow a short task description into a usable working brief. Inspect which details constrain the work and which can remain open for proposals. **Assumptions:** A brief should supply the goal, relevant context, and success criteria without pretending every preference is already decided. **Design choices:** State hard requirements separately from preferences and invite questions about consequential gaps. Allow the assistant to propose options for genuinely open choices. **Request:** Brief an assistant to create a new measurement sequence. **Starting evidence:** Known: DUT revision C, approved framework APIs, archived reference project. Unknown: stimulus amplitude. **Action and control:** State deliverables, reuse requirements, review gates, and the missing amplitude explicitly. **Stage records (authored, not executed):** ### Input record Known: DUT revision C, approved framework APIs, archived reference project. Unknown: stimulus amplitude. What changed: Establish the facts supplied for this version of the task. ### Design note State hard requirements separately from preferences and invite questions about consequential gaps. Allow the assistant to propose options for genuinely open choices. What changed: Choose an approach before treating a proposed result as accepted. ### Proposed work State deliverables, reuse requirements, review gates, and the missing amplitude explicitly. What changed: Turn the request and evidence into the next action or transformation. ### Result record · illustrative Plan can identify structure and questions, but cannot finalize the stimulus setting without clarification. What changed: Inspect the result of the authored example; this is not an executed model run. ### Verification plan Check assumptions, missing requirements, deliverables, and test acceptance criteria. If the result falls short: If requirements conflict, ask for a tradeoff rather than an impossible draft. Update the brief when a decision changes so later work uses the same understanding. What changed: Separate what needs checking from what the illustration establishes. ### Adaptation handoff Adapt this to a project, event, analysis, or document. The filename and template are optional; a shared understanding of outcome and constraints is what matters. What changed: Decide which assumptions, tools, and controls should change for your own task. **Sample result:** Plan can identify structure and questions, but cannot finalize the stimulus setting without clarification. **Change something — Say use whatever worked on the previous board:** The older amplitude is not automatically valid for revision C. Ask for the governing requirement. **Decision:** Does a reference project supply authorization for every reused parameter? **Answer:** No; validate revision-specific requirements. **Why:** A good brief distinguishes reusable conventions from values requiring current approval. **Review criteria:** Check assumptions, missing requirements, deliverables, and test acceptance criteria. **Recovery:** If requirements conflict, ask for a tradeoff rather than an impossible draft. Update the brief when a decision changes so later work uses the same understanding. **Adapt it:** Adapt this to a project, event, analysis, or document. The filename and template are optional; a shared understanding of outcome and constraints is what matters. ## Guided worked example · Business & team operations Fictional scripted fixture, not a measured run. No model or external actions execute. **Overview:** Follow a short task description into a usable working brief. Inspect which details constrain the work and which can remain open for proposals. **Assumptions:** A brief should supply the goal, relevant context, and success criteria without pretending every preference is already decided. **Design choices:** State hard requirements separately from preferences and invite questions about consequential gaps. Allow the assistant to propose options for genuinely open choices. **Request:** Brief an assistant to draft this week's report for executives. **Starting evidence:** Scope: Atlas and Beacon; cutoff Friday noon; one-page summary; confidential staffing details excluded. **Action and control:** Specify audience, time window, source priorities, missing-data treatment, and review-before-send. **Stage records (authored, not executed):** ### Input record Scope: Atlas and Beacon; cutoff Friday noon; one-page summary; confidential staffing details excluded. What changed: Establish the facts supplied for this version of the task. ### Design note State hard requirements separately from preferences and invite questions about consequential gaps. Allow the assistant to propose options for genuinely open choices. What changed: Choose an approach before treating a proposed result as accepted. ### Proposed work Specify audience, time window, source priorities, missing-data treatment, and review-before-send. What changed: Turn the request and evidence into the next action or transformation. ### Result record · illustrative Brief requests supported changes, risks, decisions needed, and unresolved evidence. Recipient list remains part of review. What changed: Inspect the result of the authored example; this is not an executed model run. ### Verification plan Verify source timestamps, project scope, disclosure rules, and the exact approval checkpoint. If the result falls short: If requirements conflict, ask for a tradeoff rather than an impossible draft. Update the brief when a decision changes so later work uses the same understanding. What changed: Separate what needs checking from what the illustration establishes. ### Adaptation handoff Adapt this to a project, event, analysis, or document. The filename and template are optional; a shared understanding of outcome and constraints is what matters. What changed: Decide which assumptions, tools, and controls should change for your own task. **Sample result:** Brief requests supported changes, risks, decisions needed, and unresolved evidence. Recipient list remains part of review. **Change something — Omit the reporting cutoff:** Updates from different periods may be combined into a misleading weekly summary. **Decision:** Is the reporting period just formatting? **Answer:** No; it determines which evidence supports the report. **Why:** Audience and time boundaries are substantive requirements, not just presentation preferences. **Review criteria:** Verify source timestamps, project scope, disclosure rules, and the exact approval checkpoint. **Recovery:** If requirements conflict, ask for a tradeoff rather than an impossible draft. Update the brief when a decision changes so later work uses the same understanding. **Adapt it:** Adapt this to a project, event, analysis, or document. The filename and template are optional; a shared understanding of outcome and constraints is what matters. A brief is everything a model needs in order to act without guessing. Six parts: the goal, the context you have that the model does not, the constraints it has to respect, what a finished result looks like, what to do when something is unclear, and the format to answer in. Leave one out and the model supplies it itself, usually with something plausible rather than a question back to you. Anthropic's own prompting guidance makes the point directly: "Think of Claude as a brilliant but new employee who lacks context on your norms and workflows", and offers a test it calls the golden rule: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too."[1] The six parts are that rule taken apart. This page is about what a request must contain. The moves *inside* a request (worked examples, an assigned role, asking for reasoning first) are [prompt engineering](/gradient_ascent/techniques/prompt-engineering/); how much of the six parts you have to spell out grows with how much the model is left to decide, which is [operator craft](/gradient_ascent/techniques/operator-craft/)'s thesis applied to one skill. This page is sourced, not measured: the advice below is checked against primary sources, but no result file exists for any of it, so no number here is one this site took. ## Practical guidance Here is the same job briefed three ways, from lightest to heaviest. A contracts manager wants renewal dates pulled from supplier agreements. One chat message. Before: "Summarize this contract." After: "List every renewal and termination date in this agreement, one line each, as `date / clause number / what happens on that date`. Quote the clause. If a date depends on a condition, say so instead of picking one. If the agreement does not state a date, write 'not stated' rather than inferring it." That's the whole brief in four sentences: goal, format, constraint, and what to do when unsure. Anthropic's own guidance backs two of these as plain instructions: "Be specific about the desired output format and constraints" and, for research work, "Define what constitutes a successful answer to your research question"[1]. You'll know the brief worked when the reply follows the format on the first try and writes "not stated" instead of guessing at a missing date. If it invents a date instead, the constraint didn't land; fix it by putting that line on its own, not by repeating the same paragraph louder. An agent working for an hour over forty agreements needs everything above, plus what a single message never had to say: which folder, which file types, that it must not modify the source files, and what "done" means, a table with one row per agreement, including the ones it failed on. Skip writing any of this down for a question you're asking once, with nothing to reuse and no one else who has to follow it; that's not what a brief is for. A standing policy, for an assistant that runs every week unasked, has no next message from you to catch a wrong guess, which is exactly why it needs a stated rule for what waits for a person and what doesn't, before the first run rather than after. How much detail suits the model also matters. OpenAI's guidance draws the line by model type: "A reasoning model is like a senior co-worker. You can give them a goal to achieve and trust them to work out the details. A GPT model is like a junior coworker. They'll perform best with explicit instructions to create a specific output."[2] Test which kind you're briefing before assuming more detail always helps, or that it never does. ## Implementation details No runnable example accompanies this page: a brief is a written artifact, not an algorithm with a fixed answer to test against. What a builder decides is whether the six parts get written down at all. A free-text box makes the brief and the request the same blob of prose, so a constraint typed in sentence four is one rewrite away from vanishing without trace. A task input with separate fields (goal, context, constraints, done looks like, what to do when unsure, output format) costs more to build and pays for itself the first time someone can point at the field that was left blank instead of re-reading a paragraph to guess what went missing. Two of those fields deserve default values rather than a blank box: "stop and ask" for uncertainty, and a house format for the output. A default is a policy nobody has to remember to state. The uncertainty field earns its place at exactly the level where a person stops reading every response. An agent that is not told what to do when the brief runs out will pick something, because silence reads as permission rather than as an open question; the checkpoint that catches that is on the [human approval](/gradient_ascent/techniques/human-in-the-loop/) page. For a standing brief (a system prompt, a project's instructions file, a document an agent loads before a task) the same six parts apply, written once and reused. Two things change at that scale. The brief now has versions, so it needs to be stored and diffed like code rather than edited in a settings box nobody can audit; and it can be tested, which is the [evals](/gradient_ascent/techniques/evals/) topic applied to a document instead of a model. The test to run is not "does the model do something reasonable" but the colleague test above, applied to the document: hand it to someone who does not know the task and see whether they can say what the goal is, what they may not do, and when they should stop and ask. This site's own recommendation, from the same reasoning: when a result comes back wrong, find which of the six parts was missing before writing a stronger version of the same words, and fix it in the stored brief rather than in the one message. ## At each level - [Conventional software](/gradient_ascent/levels/0/): nothing to brief; a rule takes an input and produces an output with no instructions to interpret. - [Direct prompting](/gradient_ascent/levels/1/): the brief is the whole interface, and it is cheap to fix: a bad result costs one retry. - [Added context](/gradient_ascent/levels/2/): the brief has to say which material counts, because the retrieval step will otherwise choose for you and the answer will not say it did. - [Workflows](/gradient_ascent/levels/3/): each step carries its own brief, so a vague one in the middle of a chain shows up as a bad result several steps later. - [Tool use](/gradient_ascent/levels/4/): the brief has to name which actions are allowed, not only what answer is wanted: the model is choosing what to do, not only what to say. - [Agent loops](/gradient_ascent/levels/5/): the brief has to define "done" for a loop that decides for itself when to stop, and say what to do when it is unsure, since there is no next message from you mid-run. - [Teams of Agents](/gradient_ascent/levels/6/): a lead agent writes the briefs for the others, so yours now has to say how the work should be split, not only what should come back. - [Always-on agents](/gradient_ascent/levels/7/): the brief becomes a standing policy (what it may decide alone, what always waits) and it is read at moments you are not present for. See [always-on assistants](/gradient_ascent/techniques/agent-teammates/). ## Practices - Write the six parts as separate lines. A missing constraint is invisible inside a paragraph and obvious in a list. - State the output format every time. A model guesses a shape as readily as it guesses a fact. - Say what to do when the brief runs out: stop and ask, or make a stated assumption and flag it. Silence is read as permission to guess. - Include the failures in the definition of done: the list it could not process is part of the result, not an exception to it. - Keep the fix in the brief, not in the retry. A stronger version of the same words fixes one output; the missing part fixes the next hundred. - Judge the result against the brief, not against what you meant. That is where [reviewing](/gradient_ascent/techniques/reviewing/) picks up. ## Run it **What to monitor.** How often a result is rejected for something the brief never said, rather than for something the model got wrong. A rising rate against an unchanged brief means the brief is the thing to fix. **Cost at volume.** Writing a brief costs less over time as a house style forms and the same fields get reused. Skipping it costs more over time, because the same gap is now read by every run: a missing constraint in one chat message is a redo, and in a standing brief it is every result until someone notices. **How it fails in production.** A brief written for a single chat reply is reused unchanged for an agent that now works on its own for an hour. The constraints were enough for one message and say nothing about what may happen on the way to it. **What to log.** The brief as it stood at the time, with a version, next to what came back. Without the version you cannot tell a model regression from an edit somebody made to the instructions last Tuesday. ## Try it 1. **Use it.** Take a request you send a model often. Write the six parts on six lines: goal, context it lacks, constraints, what done looks like, what to do when unsure, format. Send that instead. Which of the six turned out to be missing from what you had been sending? 2. **Build it.** Find a system prompt or task template you rely on, your own or one built into a product. Check whether it says what to do when the model is unsure, and whether it defines done in a way that includes the items the run could not handle. Add whichever line is missing. 3. **Either lane.** Run the colleague test on that brief: give it to someone who does not know the task and ask them what the goal is, what they may not do, and when they should stop and ask. Whatever they cannot answer is what the model is currently guessing. ## Sources 1. [Prompting best practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices) — Anthropic (Claude Platform Docs) (accessed 2026-09-19) 2. [Prompt engineering](https://developers.openai.com/api/docs/guides/prompt-engineering) — OpenAI (API documentation) (accessed 2026-09-19) Last reviewed 2026-09-19.