How to give your AI agent a client brief it won't forget
Give Claude Code a client brief that lasts between sessions, the base of AI agents for client work: what goes in it, where it lives and how to keep it current.
The owner of a one-person AI agency is halfway through a site for a dog groomer. On Monday she tells her agent the business name is spelled with a hyphen, that the owner hates the word "pamper", and that prices stay off the site because they depend on the dog. The work goes well. On Wednesday she opens a new session, asks for the services page, and gets "Pamper your pooch" above a price list.
Nothing broke. The agent simply never saw Monday's conversation.
The fix is a client brief the agent reads every time it starts: one short text file, kept in the client's project folder, that holds what you'd otherwise explain again. In Claude Code that file is called CLAUDE.md. This guide covers what goes in it, where it lives and how to keep it true.
How do I give Claude Code context about a client?
Put the brief in a file named CLAUDE.md at the top of the client's project folder. Claude Code's documentation says it reads CLAUDE.md files at the start of every session, so whatever is in that file is part of the conversation before you type a word.
Three habits make it work:
- One folder per client. The site files, the brief and any reference files for that business sit together. When you start the agent in that folder, it reads that client's brief and no one else's.
- Write it like a note to a new helper. Plain sentences, short headings, facts that can be checked. "Hours: Tuesday to Saturday, 8am to 4pm" beats "check the hours are right".
- Change the file, not the chat. When the client decides something, update the brief first. A decision that lives only in a chat is gone next session.
If you're setting up a new project, Claude Code has an /init command that drafts a starting CLAUDE.md by looking at the files already there. It's a useful start for the technical side. The client side (tone, decisions, limits) is yours to write, because the agent can't read it from the code.
Why does the agent forget between sessions?
Because each session starts with an empty conversation. The agent doesn't remember Monday; it rereads whatever files it's given on Wednesday. That's a good thing for client work: nothing leaks from one client's chat into another's, and the file is the one version of the truth.
It does mean pasting is a trap. A brief pasted into a chat is used once. If you paste an old copy next week, the agent works from the old copy, and you won't know until something wrong appears on a page.
Where should the client brief live?
In the client's project folder, next to the work, where both you and the agent can open it. Claude Code gives you a few places for these files, and each has a job:
| File | Where it sits | Use it for |
|---|---|---|
CLAUDE.md |
The client's project folder | The client brief: the business, its facts, decisions and limits |
CLAUDE.local.md |
The same folder, kept out of anything you share | Your own notes for this project, such as a test address |
~/.claude/CLAUDE.md |
Your home folder | How you work on every project: your spelling, your review steps |
Keep the parts apart. Your personal way of working goes in the home folder file, so you write it once. The client's facts go in the project file, so they never mix with another client's.
A brief can also point to other files. The documentation shows an @ followed by a file path inside CLAUDE.md, which pulls that file in too. That's handy for a long menu or a list of service areas: keep it in its own file and reference it, instead of making the brief long.
What goes in a client brief for an AI agent?
Start with what goes wrong most often: the facts that must be exact, and the decisions already made. Here's a shape you can copy:
- The business in two lines. What they do, where, and for whom. "Mobile dog grooming across the north suburbs. Most customers are busy families with large breeds."
- Exact facts. Business name with its exact spelling, address, phone, email, hours, service area. Say where each fact came from and when, such as "confirmed by the owner on the kickoff call, 12 January".
- How it sounds. Three or four plain rules. "Friendly, not cute. No 'pamper'. Short sentences." Include a sentence the owner liked, if you have one.
- Decisions, with dates. "No prices on the site (owner, 14 January)." "Logo stays as is." Decisions stop the agent reopening questions you've closed.
- Out of scope. What this project doesn't include: an online shop, a booking system, a blog. The agent will happily build extras if nobody says not to.
- Accounts. Who owns the domain, the hosting and the Google listing, and who has access. No passwords, ever.
- What needs you. Anything the client will see, such as an email, a published page or an invoice, waits for your approval.
- Where the rest lives. Links to the research notes, the approved copy and any longer reference files.
If you researched the business before you pitched, most of this already exists in your notes. Copy the facts across; don't rewrite them from memory.
How long should the brief be?
Short. The documentation's advice is that specific, well-organised instructions are followed more reliably than long, loose ones, and every line in the file is read at the start of every session.
A good test: would you read the whole thing before a call with the client? If not, cut it. Move long reference material into its own file and point to it. Delete anything that stopped being true. One screen, maybe two, is plenty for a local business site.
Write instructions the agent can act on. "Keep headings under eight words" works. "Make it look professional" doesn't, because nobody can check it.
How do I keep the brief up to date?
Treat the brief like the one list you'd hand a colleague covering for you. Three moments call for an update:
- After every client conversation. Anything decided goes into "Decisions" with a date, before you close the laptop.
- When the agent makes the same mistake twice. That's a missing line. Add it, in plain words.
- Before you hand over or pause the project. Reread the brief top to bottom and delete anything stale.
You can ask the agent to propose changes to the brief at the end of a session. Read what it suggests before you accept it. The brief is your record of what the client agreed, so it's yours to approve.
What else should the agent read besides the brief?
The brief says who the client is. The agent also needs the latest version of the work and the reference material behind it. In a well-kept folder that's all in one place.
- The approved copy. The words the client signed off, in a file, so the agent doesn't write new ones.
- Your research notes. Reviews, competitors, questions from the first call.
- Skills. If you repeat a process on every site, such as a pre-launch check or a way of writing service pages, a Claude Code skill (a folder of instructions the agent loads when a task needs it) keeps that process out of each client's brief. The guide to Claude Code skills and plugins explains how they fit.
- Connected programs. Some information lives outside the folder: your client list, messages, the calendar. MCP is the standard way for an agent to reach those; the short definition of MCP explains it in a paragraph.
The same idea holds outside coding. If you do client work in Claude Cowork, a brief in a folder the agent can open beats one typed into a chat. And if you build whole sites with your agent, the walkthrough on using Claude Code to build a website for a client shows where the brief fits in the build.
What should the brief say about sending things?
Write one line near the top: nothing goes to the client, their customers or the live site without your approval. Agents follow what they're told, and a brief that says "publish when ready" means exactly that.
Approval is worth building into your tools as well as your brief. Approving what your agent sends covers how that works in practice: you see the exact message or page, and it only goes out once you say yes.
If you're a developer who builds client sites this way, the page for developers building client sites with an AI agent shows the rest of the working day around the brief.
Where Volant fits
Volant keeps each client's details, notes and decisions in one place, and your agent connects to it directly, so it reads the current record instead of an old pasted copy. It works with Claude Code today. A CLAUDE.md in the project folder still does its job for the site itself; Volant holds the agency side around it.
Whatever you use, the rule is the same: if you'd have to say it again next week, write it in the brief today.