Righthand
← All posts

How to Write a Task Brief for an AI Assistant

Write an AI assistant task brief with the desired outcome, sources, constraints, authority, deadline, and completion evidence.

Quick answer

A good task brief tells an AI assistant what outcome you need, which sources to use, what constraints matter, and what it may do. Include a deadline and a concrete completion rule. Add an example when quality or tone is subjective. The brief should make the next action clear without requiring the assistant to invent authority or missing facts.

You do not need an elaborate prompt for routine work. You do need the few details that change the result. “Handle this” can mean summarize, draft, contact someone, or complete a transaction. Naming the intended output prevents those different interpretations from becoming accidental scope.

The six fields that matter

Outcome

Describe what should exist or happen. “Prepare a decision brief comparing these options” is more useful than “look into this.” State who will use the output and what decision it supports.

Sources

Provide the current documents, threads, or account records. Mark examples as examples and outdated information as outdated. Tell the assistant what to do when sources disagree.

Constraints

List budget, timing, format, audience, and exclusions that affect suitability. Keep mandatory requirements separate from preferences so the assistant can explain trade-offs.

Authority

Specify which actions are allowed and which need approval. Access to an account does not automatically authorize every action available through it. Name recipients and sender identity when communication is involved.

Deadline

Use an exact date and time zone when timing matters. Include intermediate review points for tasks with dependencies. A final deadline alone may leave no room to correct a draft.

Completion

State what counts as done and how you will verify it. A draft prepared, message sent, and result confirmed are different outcomes. Choose the one your task actually requires.

Worked example: a client update

In an illustrative consulting project, the owner wants a Friday client update. The assistant has a project register and two approved status messages. One deliverable is submitted for review, and another is waiting for client materials.

The brief should require a draft that preserves those states, explains the next actions, and avoids new commitments. The assistant should not announce completion of the submitted deliverable or promise a date for work blocked by missing inputs.

Provide one previously approved update as a tone example. That helps the assistant match the relationship without copying confidential details into unrelated tasks. Review the initial draft before authorizing the send workflow.

A task brief you can adapt

Outcome: prepare a concise Friday client update for my review. Sources: the current project register and approved status messages linked below. Include progress, pending client inputs, and next steps with owners. Preserve the distinction between submitted and approved work. Match the tone of the supplied example. Do not promise new dates, change scope, or send the message. Deliver the draft by Friday 10 AM Pacific. Completion means I have a reviewable draft with source links and any unresolved questions clearly flagged.

For a simpler task, compress the same fields into a few sentences. The point is clarity, not a mandatory form.

Review the first interpretation

Ask the assistant to surface only material missing information. It should not ask about details that do not affect the outcome, but it should pause before an ambiguous external action or consequential decision.

Inspect the first result against the brief. If the output misses a requirement, add a precise correction and a reusable example when helpful. “Be better” does not explain the difference; “lead with the decision needed and keep background below it” does.

When the scope changes, explicitly replace the old instruction. A new deadline or recipient list should not coexist ambiguously with an earlier version. State what remains valid and what changed so the assistant can resume the task coherently.

Frequently asked questions

How long should the brief be?

As short as possible while preserving the information that affects the outcome. A small internal summary may need three sentences; a multi-step external task needs more explicit boundaries.

Should I provide a sample output?

Yes when tone, format, or quality is difficult to describe. Mark it as a sample and identify which features the assistant should follow.

What if I do not know the full plan?

Delegate planning first. Ask for a proposed sequence, missing information, and approval points. Approve specific execution steps after reviewing the plan.

Righthand's task delegation, natural language requests, and workflows are relevant starting points for brief-driven work.