Brief an AI like a freelancer, and manage it like one

When you hire a freelancer you do not send them a sentence. You send the background, the audience, the deliverable, the deadline, one piece of past work you liked, and the two things they must never say. Then you read the draft against what you asked for before it goes to anyone. With an AI assistant most people skip every part of that, type one line, get something plausible, spend fifteen minutes repairing it, and start again from nothing the next morning.

The repair work is not a wording problem. It is a management problem, and the fixes are the boring ones you already use on human contractors: write the briefing down once instead of retyping it, keep it somewhere the tool can reach, decide what finished looks like before you read anything, decide what the contractor is allowed to see, and keep the sign-off with a person. Every mainstream assistant now has a place to store a standing brief [1][2][3], which means retyping your context is optional and most people are still doing it. This guide is for a solo operator or a small team working in the chat products. If you run prompts inside an application, with version control and an evaluation suite, you have a different job and the vendor docs are your manual.

The briefing is an asset, not a message

The context you type at the top of a chat barely changes between tasks. What the business does, who buys from it, the voice, the standing constraints, the two documents you would be happy to sign again. Retyping that is the single largest waste in most people’s AI use, and all three major assistants have a place to put it.

In Claude, that place is a Project. The help documentation describes Projects as self-contained workspaces with their own chat histories and knowledge bases, where you upload documents, text, code or other files to a knowledge base that Claude uses to understand the context, and set project instructions to tailor responses [1]. Free users can create a maximum of five projects, and on the paid plans Claude enables RAG mode when project knowledge approaches context limits, expanding capacity by up to 10 times [1]. In ChatGPT, the equivalent is a project, which holds chats, files and instructions together, and the help page is explicit about precedence: project instructions apply only inside that project and override your global custom instructions [2]. Projects are available on all free and paid subscription types, with a file cap that scales by plan at 5 files on Free, 25 on Go and Plus, and 40 on Edu, Pro, Business and Enterprise [2]. In Gemini, it is a Gem: open Explore Gems, click New Gem, name it, write the instructions, and add files under Knowledge [3].

The mechanics differ. The move does not. Write the pack once, put it in the container, and every chat inside that container starts with a contractor who has read the file. At $20 a month billed monthly for Claude Pro, or $17 a month on annual billing [8], the subscription is the cheap part of this arrangement. The expensive part is your time explaining yourself, and that is the part you only have to spend once.

Four parts, the same four a freelancer would ask for

A good brief answers the situation, the deliverable, the constraints and the definition of done. Anthropic’s guidance frames the reason plainly: think of the model as a brilliant but new employee who lacks context on your norms and workflows, and the more precisely you explain what you want, the better the result [4]. Google’s guidance for writing a Gem’s instructions names four ingredients that map onto the same thing, persona, task, context and format, and adds that you do not need all four but a few will help [3].

Two details are worth more than the rest. First, give the reason behind a rule, not just the rule. Anthropic’s own example contrasts “NEVER use ellipses” with an instruction that explains the output will be read aloud by a text-to-speech engine that cannot pronounce them, because the model generalises from the explanation [4]. A reason covers the cases you forgot to list. The same page recommends telling the model what to do rather than what not to do, replacing “do not use markdown” with a description of the prose you want instead [4].

Second, attach work rather than adjectives. Anthropic suggests 3 to 5 examples for best results, chosen to mirror your actual use case, varied enough that the model does not latch onto an accidental pattern, and wrapped in tags so it can tell your samples from your instructions [4]. This is the section people skip because it feels like homework. It is the section that transmits the hundred preferences you would never think to write down.

Write the acceptance test before you read the draft

The difference between a client and a hopeful is that the client knows what they will check. Before you send the brief, write 3 or 4 statements you could verify in under a minute. Under 200 words. No claim about delivery dates. British spelling. One call to action, at the end, not in the middle. Anthropic’s research guidance puts the same instruction in one line: provide clear success criteria, defining what counts as a successful answer [4].

Checkable is the whole test. “Under 200 words” is checkable and “concise” is not. “No pricing figures” is checkable and “on brand” is not, unless brand is attached as an example. Put the criteria in the brief itself, then ask for a self-check against them before you read a word. You will still catch things, but you stop catching the boring things.

When a draft fails, the failure tells you which part of the brief was thin, and that is the repair you make. Wrong facts mean the knowledge base was missing the document. Wrong shape means the deliverable spec was vague. Wrong voice means no example was attached, or the one attached was the wrong sample. Fixing the brief compounds; regenerating does not, because the next draft comes from the same defective instruction.

A freelancer asks before starting, so tell yours it may

The default behaviour of a chat assistant is to guess and keep going, confidently. The default behaviour of a competent contractor is to send you three questions first. You get the second behaviour by asking for it, and OpenAI’s own worked example of project instructions ends with exactly that request: act like my marketing mentor, be concise, use bullet points, ask clarifying questions [2].

Add one line to any brief for work that matters: before drafting, ask up to 3 questions that would most improve the result. The questions are the useful part even when the answers are obvious. A question you cannot answer is a hole in your own thinking that would otherwise have shipped inside a deliverable. A question about something you already covered tells you the pack is buried or unclear.

You can also let the tool draft its own brief. Gemini offers a “Use Gemini to re-write instructions” button that expands a short description of what you want into a fuller set of instructions [3]. Treat the result the way you would treat a scope of work written by the contractor: a reasonable starting point, approved by you, edited where it flatters itself.

Scope what it can see and what it carries between jobs

A knowledge base is not a filing cabinet. It is the folder you hand a contractor on day one, and everything in it is fair game for every answer they give you. That has two consequences worth deciding on purpose rather than by accident.

The first is confidentiality. If your pack contains one client’s pricing, their margins are in the room for every draft that project produces. Separate projects per client is the cheap fix, and it is the same instinct that stops you forwarding one client’s proposal to another. The file caps push you the same way, since 25 files on ChatGPT Plus or 40 on Pro and Business [2] are a curation budget rather than a limit you should try to fill.

The second is memory. ChatGPT projects can run with project-only memory, in which chats cannot reference conversations outside the project, including general ChatGPT conversations or conversations in another project, and shared projects are automatically set to project-only memory and cannot be switched back [2]. That is the setting that decides whether your assistant carries context between clients or leaves it at the door. Pick it deliberately at the start of each engagement, the same way you decide which shared drive a freelancer gets.

Sign-off is the part you cannot hand over

You can delegate the drafting. You cannot delegate the consequence, and in some fields the vendor’s own rules say so. Anthropic’s Usage Policy, effective 15 September 2025, lists high-risk domains that include legal interpretation, healthcare decisions, insurance underwriting, financial decisions, employment and housing determinations, and academic testing and admissions, and requires that a qualified professional in that field review the content or decision prior to dissemination or finalisation [5]. The same policy requires you to disclose to the affected person that you are using AI to help produce the advice, decision or recommendation, at a minimum at the beginning of each session [5].

Outside those domains nobody makes you do it, and the invoice still has your name on it. So price the review into the job. A useful rule for a small business: if checking the output would take longer than producing it yourself, that task is not ready to delegate, to a model or to a new freelancer. The tasks worth handing over are the ones where verification is fast and the drafting is slow, which is most writing, most summarising, most first passes at structure, and almost none of the work where a single wrong number costs you the client.

What still goes wrong

The contractor gets replaced without asking you. Models are retired on a published schedule, and Anthropic’s deprecation page sets out the lifecycle states, promises at least 60 days’ notice before retirement for publicly released models, and tells you to migrate all usage to a replacement before the retirement date [6]. Claude Opus 4.1 reached its retirement date on 5 August 2026, and the current lineup is Claude Fable 5.1, Claude Opus 5, Claude Sonnet 5 and Claude Haiku 4.5 [6][7]. A brief written as a brief survives that transition, because the information in it was never model-specific. What does not survive is a prompt tuned to one model’s habits. When the lineup changes, run your 3 or 4 standing briefs again and read the output properly instead of assuming continuity.

The pack goes stale, quietly. Prices change, a service is dropped, the positioning gets sharper, and the knowledge base keeps repeating last year’s version with total confidence, because nothing in the system knows it is out of date. Put a review date at the top of the pack and reread it quarterly. This is the failure mode nobody notices for months, since the output looks exactly as fluent as it did when it was correct.

More context is not automatically better context. A knowledge base of 40 half-relevant documents gives the model more chances to answer from the wrong one, and the answer will not be labelled as coming from the wrong one. Keep the pack small enough that you could name every file in it. And none of this removes the review step or makes invented detail impossible, which is why the last item on the checklist is a person and not a setting.

Prompts from this guide

standing-brief

STANDING BRIEF — {business_name}
Last reviewed: {review_date}

The business, in two sentences:
{what_we_do}

Who we serve and what they care about:
{audience}

Voice: match the attached examples, not a generic professional tone.
Never say: {forbidden_claims}
Always: {standing_rules}

When a fact is missing from the material I paste, write TBC. Do not
estimate, and do not fill it from general knowledge about this industry.

Before drafting anything non-trivial, ask me up to 3 questions that
would most improve the result.

Attached under knowledge: {gold_standard_examples}

acceptance-check

Here is the deliverable you just produced.

Check it against these acceptance criteria, one at a time, and answer
PASS or FAIL for each with the specific line that fails:

1. {criterion_one}
2. {criterion_two}
3. {criterion_three}
4. Every factual claim comes from the material I pasted, not from
   general knowledge. List any claim that does not.

Then give me the corrected version. Do not change anything that passed.