Brief: How to Ask AI for What You Want
This content was developed with AI assistance and is regularly reviewed for accuracy.
Snapshot: October 2026. Model names, prices, and product features change monthly; What's New in AI is the maintained chronology.
In 2023, people learned prompts: phrasings and templates that squeezed a better answer out of a chatbot. In 2026 the assistant reasons on its own, reads your files, and can carry out multi-step work, so the skill has shifted from clever wording to clear delegation. The unit of that skill is the brief: a short description of the job that a capable new colleague could act on without coming back to ask what you meant. This lesson teaches the brief, keeps the parts of prompting that still earn their place, and retires the parts that do not.
Learning focus
- Write a six-field brief for any task: objective, context, resources, constraints, output, verification
- Keep the prompting fundamentals that still work (specificity, the why, examples for format) and drop the rituals that no longer help
- Ask for structured output and let the assistant improve your brief before it starts
- Understand what changed about "prompt engineering" and why this lesson is dated to a model generation
Why a brief instead of a prompt
Anthropic's current guidance includes a golden rule: show your prompt to a colleague with minimal context on the task and ask them to follow it. If they would be confused, the model will be too. That is the whole philosophy of briefing. The model is not a search box that rewards magic words; it is a very fast, very literal collaborator who knows nothing about your situation until you tell it.
The evidence on what goes wrong has been stable for three years. A 2026 study of more than 900 students found the most common mistake was omitting key details and relying on the AI to infer them. Three newer failure modes come from models being better at following instructions. They are literal, so "can you suggest some changes" may get you suggestions when you wanted the changes made. They are sensitive to contradictions, so a long list of rules that quietly conflict produces worse results than a short consistent one. And they overreact to emphasis written for older models; "CRITICAL: you MUST" now overtriggers rather than helps.
A brief fixes all of these by making you state the information the model lacks, in a structure that is hard to leave half-finished.
The six-field brief
Every field answers a question the assistant would otherwise have to guess.
Objective. What done looks like, in one or two sentences, and why it matters. The why is not decoration: models generalize from it, so "because the board reads only the first page" changes the output more than any formatting instruction.
Context. Who you are, who the output is for, and the situation. Audience and purpose do most of the work that "assign a role" used to do.
Resources. What the assistant should use and which source is authoritative: the attached file, the project folder, the connected drive, a specific URL, or its own search. This is one of the two most-skipped fields, and skipping it is how you get a fluent answer built on the wrong document. The Supply Context lesson covers how to attach rather than paste.
Constraints. Length, tone, what is out of scope, what must not change, deadlines, and which actions need your approval. State what to do rather than what to avoid; "use plain language" beats "don't be technical."
Output. The shape of the result: a table, a two-paragraph email, a slide outline, a file in your drive, a JSON record. If format matters, show one example of it.
Verification. How you or the assistant will know it is right: tests it can run, a checklist it should tick, sources it must cite, or a second pass that compares the result against the brief. This is the other most-skipped field, and the one that turns "trust me" into "show me."
Here is the template in a form you can save:
Objective: [what done looks like, and why it matters]
Context: [who I am, who this is for, the situation]
Resources: [attached files / project / connector / URLs; which one is authoritative]
Constraints: [length, tone, out of scope, do not change, approval needed before...]
Output: [format; one example if format matters]
Verification: [how to check; what to cite; what to show me]
Not every task needs every field written out. A quick rewording needs an objective and an output. Anything you would hand to a new hire with a day's notice needs all six.
A worked example
Before: "Help with my presentation."
After:
Objective: Turn my Q3 notes into a 6-slide update for Thursday's leadership meeting, so the group leaves knowing whether to fund the pilot.
Context: I lead customer support at a 200-person company. The audience is five executives who prefer numbers over narrative and have seen the Q2 version.
Resources: Use the attached q3-notes.docx as the source of record and the Q2 deck in this project for structure. Do not use outside figures.
Constraints: One idea per slide, under 30 words of body text each, neutral tone, no new initiatives beyond the pilot decision.
Output: A slide-by-slide outline with a title, three bullets, and a speaker note per slide, as a document in this project.
Verification: After drafting, list every number you used with the line of the notes it came from, and flag anything you inferred rather than found.
The second version is longer to write and dramatically shorter to fix. Notice that it contains no persona, no "think step by step," and no formatting tricks, only information.
What still works from prompting
Three fundamentals survived every model generation, with small 2026 updates.
Be specific, and say "do," not "suggest." Vague asks are fine when you are exploring and can afford to course-correct. For anything you intend to use, name the outcome and ask for it to be done.
Give the why, not just the what. A sentence of motivation lets the model handle cases your rules did not cover.
Show a sample of the output. Examples remain one of the most reliable ways to steer format, tone, and structure. Try the task once without an example first; if the shape is off, add one to three samples of what you want. Keep them diverse, and do not use examples to teach facts.
Roles have been demoted, not banned. Wharton's Prompting Science research found no consistent accuracy gain from expert personas and occasional harm when the persona did not fit the task (arXiv 2512.05858). Roles still shape tone and perspective, so write the perspective directly: "write this for a skeptical CFO" rather than "you are a CFO." And permit uncertainty: "if the data does not support a conclusion, say so" prevents a confident guess.
What to drop
Retire these from your habits and your saved templates:
- "Think step by step" and other reasoning triggers; choose an effort level or ask for a plan instead
- Acronym frameworks that start with a role and never mention resources or verification
- ALL-CAPS emphasis, "MUST," and repeated warnings; state the instruction once, plainly
- Libraries of clever phrasings; replace them with reusable briefs, projects, and skills
- Platform-specific "tone tips"; the labs' own guides now give the same advice, and it is the brief
Structured output
When the result feeds a spreadsheet, a tracker, or another tool, specify the shape exactly and show it. Put the schema in your brief and tell the model to return only that:
Return one JSON object per inquiry with exactly these fields:
"category": one of "technical", "billing", "feature_request", "other"
"urgency": integer 1-5
"summary": one sentence
"next_action": one sentence
Return nothing else.
The same approach works for tables (give the column headers), outlines (give the heading levels), and files (name the format and where to save it). For extraction tasks, add a verification line: "quote the passage each value came from."
Let the assistant improve the brief
Models are good at finding holes in their own instructions, so use that before the work starts rather than after. Three patterns earn their keep:
- Interview me. "Before you begin, ask me the questions you would need answered to do this well." Answer them, then say go. For large tasks, ask it to write the brief back to you as a spec and only start once you approve.
- Critique your draft. "After drafting, list the three weakest points and fix them, then show me the revised version." Treat the self-review as one more input to your own check, not a replacement for it.
- Multiple perspectives. "Review this plan from the point of view of the customer, the finance lead, and the engineer who will maintain it." This is where perspective instructions still shine: they widen the review, not sharpen the facts.
Writing tasks
Drafting, editing, summarizing, and rewording are still the most common things people ask assistants to do, and they are the easiest place to practice briefing. The Make Things: Writing and Documents page covers the workflow, and the Brief and Prompt Library holds ready-to-adapt briefs for emails, reports, summaries, and more, organized by task rather than by phrasing.
What about prompt engineering?
The phrase has not disappeared, but it means something smaller than it did. Search interest in "prompt engineering" peaked in July 2023 and has fallen steeply since; the standalone job title has declined by a reported 30-40% from its peak, while the underlying skill was absorbed into expectations for everyone and renamed along the way: context engineering, delegation, AI fluency. Anthropic's own AI Fluency course gives prompting one lesson out of roughly fourteen and says its goal is to get learners "past that next prompt engineering fad."
Two things did change for real. First, the labs retired techniques their own models no longer need: manual chain-of-thought, prefilled responses, heavy XML scaffolding, and anti-laziness language. Second, the measurable effect of individual tricks on reasoning models shrank to the margins, while the effect of information (objective, context, resources, constraints, examples) did not. There is still no 2025-2026 trial showing that prompt training alone improves work outcomes, so treat every technique here as what works on the current model generation, to be re-checked on the next. What does not change is that the person who writes the clearest brief, supplies the right context, and checks the result gets the best work. That is the rest of this track.
Key takeaways
- A brief is information the model lacks, in six fields: objective, context, resources, constraints, output, verification
- Resources and verification are the fields people skip, and skipping them produces fluent answers built on the wrong source
- Specificity, the why, and examples for format still work; roles set tone, not accuracy; "think step by step" is retired
- Ask the assistant to interview you or critique its draft before you check it yourself
- Prompting techniques are dated to a model generation; the briefing habit is not
Next steps
Continue to: Supply Context: Files, Projects, Memory, Connectors, Skills
- Grab ready-made briefs by task in the Brief and Prompt Library
- Turn your best briefs into reusable projects and skills with the playbook Build Your Brief and Skill Library