# 5.6 Adapt the brief to the task type (/managing-ai-workers/the-four-part-brief/task-type) --- type: Document title: "5.6 Adapt the brief to the task type" description: "What to set tightly and what to leave open for research, analysis, drafting, extraction and brainstorming, and which jobs need a full brief." status: stable order: 205.6 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-05T19:16:47Z chapter: "05" part: II expert_status: required concepts: [ "5.6" ] last_verified: 2026-10-06 sources: - id: v1-ai-prompting title: "AI Prompting in 2026 (Panaversity, first edition, verified 2026-10-06)" resource: https://agentfactory1.panaversity.org/docs/ai-prompting-2026 - id: mdn-working-with-json title: "Working with JSON (MDN Web Docs, Mozilla, verified 2026-11-05)" resource: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/JSON generated: at: 2026-11-05T19:16:47Z by: process:panaversity trust_tier: unverified build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e dirty: true ksor_version: 0.0.60 --- **In everyday life.** Asking friends for vacation ideas is different from booking the flight you chose. **At work.** Asking for ways to avoid late fees needs a loose brief, but pulling the fields out of invoices needs the tightest one. The four parts never change. What changes is how tightly you set them. A tight brief fixes exactly what the answer must look like. A loose one leaves room for the worker's own ideas. Either way, give the worker the context and constraints the task needs, every time. Only the shape of the answer gets tighter or looser. | Task type | Tighten | Leave open | If you do the opposite | | --- | --- | --- | --- | | Research | Scope (what to cover), source types, dates | The answer | Your own assumptions, handed back to you | | Analysis | The data, the definitions, the exact question | The conclusion | An analysis that just agrees with the question | | Drafting | Audience, length, structure, facts, voice | Wording and order within the structure | A well-written draft of the wrong thing | | Extraction | Every field, its type, how to mark a missing value | Nothing | Invented values that look real | | Brainstorming | The problem, the audience, what to avoid | Structure, tone, length | Five rewordings of one idea | Two more rules go with the table. For research and analysis, never present the conclusion you hope for as already true, because a worker that sees it tends to find it. If you have a hypothesis, a guess of your own, state it as something to test, and ask for evidence for and against.[^v1-ai-prompting] For extraction, tell the worker to leave a field blank and flag it instead of guessing. A guessed invoice number looks exactly like a real one. Technical tasks follow the same rows. Turning invoices into JSON records that a system checks is extraction at its tightest. JSON is a file format that programs read.[^mdn-working-with-json] Name the schema (the fields the system expects and the type of each), and what to return when a value is missing. **At Brightline.** Maria needs two things in the same week. The first is ideas for avoiding late fees. That is brainstorming, so her brief stays loose. It names the problem, the team and what to avoid, and leaves the shape open: "Suggest five different ways a small AP team that pays weekly could avoid late fees. Avoid anything that needs new software." The second is this week's invoices as JSON records for the accounting system's import check. That is extraction, so every part is tight: ```markdown Outcome: One JSON record for each invoice in this week's batch, ready for the accounting system's import check. Context: Only the invoice PDFs in this week's batch folder. Format: The fields vendor, invoice number, invoice date as YYYY-MM-DD, total in USD with two decimals, and currency. Nothing else in the file. Constraints: When an invoice does not show a field, leave it empty and list the invoice and the field at the end. Never guess a value. ``` The brainstorm brings back ideas Maria had not thought of. The extraction brings back clean records and two flagged invoices, each without a date. Swap the two styles and both fail. A tight brainstorm returns five rewordings of one idea, and a loose extraction returns dates that look real but are not. **A note to a supplier.** Drafting sits between the two. The facts and the promises must be tight, and the wording can stay loose. Maria's note to Lakeshore Janitorial (5.5) ends up like this: ```markdown Outcome: Draft a note to Lakeshore Janitorial saying that invoice 5131 is overdue and under review. Done when a saved draft says it is overdue and under review. Context: For Lakeshore's billing contact. Dave approves it before it goes out. Payment terms come from the vendor record, not the terms printed on the invoice. Format: An email draft. Constraints: Under 150 words, polite and plain. Quote the invoice number and amount exactly as recorded. Say it is under review, without a payment date. Leave out the terms question until Dave confirms it. Save it as a draft and send nothing. ``` Its content rules are tight, and the words between them are the worker's to choose. **How big the brief should be.** A job needs a full brief when it runs while you are away, runs on a schedule, or would cost a lot to redo (5.1). Maria's brainstorm is an ask: she reads the ideas at once and can ask again. The JSON records are read by a system, not a person, and a guessed value looks exactly like a real one, so they need a full brief. [^v1-ai-prompting]: AI Prompting in 2026, Panaversity, first edition. [^mdn-working-with-json]: Working with JSON, MDN Web Docs, Mozilla.