A new strategist joins a client project on Monday. The brief is in Google Drive. The latest feedback is in Slack. The reason you dropped the original offer is somewhere in a call recording. Before they can do useful work, they need someone to explain the client all over again.
An agency brain gives that person a place to start. It holds the context your team keeps rebuilding: who the client is, what you agreed to do, what has changed, and which decisions are still open.
This guide shows a practical way to organize that knowledge on GitHub, keep it current as a team, and use it as context for an AI assistant. You can follow the first version in a browser. You do not need to write application code.
What an agency brain actually is
Think of it as a small, maintained library of your agency’s working knowledge. Some of it applies to everyone: your services, processes, writing standards, and how you review work. Some belongs to a particular client: their audience, offer, project scope, and approved messaging.
The useful part is the shared source. Your strategist, designer, and account manager can work from the same approved information instead of keeping separate versions in their own chats.
GitHub stores the files and their history. An AI tool reads the files you give it access to and helps you find, summarize, or apply the information. Connecting the tool does not train a new model or give every teammate one permanent shared memory. Each conversation still needs the right context.
Why use GitHub for this?
A repository, usually shortened to repo, is a project space containing files and their change history. GitHub is commonly used for software, but a repo can also hold written documents.
- A Markdown file is a text document with simple formatting for headings, lists, and links. A file called client-overview.md is just a readable client overview.
- A commit is a saved change with a short explanation of what changed.
- A branch lets someone work on a proposed update separately from the main version.
- A pull request lets the team inspect and discuss that update before merging it into the main version.
GitHub reference: repositories and how they work
My suggested convention: treat the main branch as the current, reviewed version of the brain. If the team changes a client’s positioning, you should be able to see the change and why it happened.
GitHub is a useful fit when your team values version history and already works with tools that can read repository files. If nobody will maintain it, a well-kept shared document is a better starting point than an elaborate repository nobody opens.
1. Separate agency knowledge from client knowledge
Start with a private agency-brain repository for shared processes. For client information, I recommend a separate private repository per client, such as client-northstar-brain. Northstar is a fictional client used throughout this guide.
This keeps access easier to reason about. A freelancer working on Northstar can receive access to Northstar’s repository without receiving every other client’s documents. A folder inside a repository is not a separate access boundary.
For a team, use an agency-owned GitHub organization. Give people Read access when they only need to consult the material, and Write access when they need to contribute changes. Keep administrator access limited to people managing the repository.
GitHub reference: repository roles in an organization
Keep passwords and API keys in your password manager. Put approved working context in the brain, rather than copying every client file into it. Check that your agency is allowed to put the selected client material into both GitHub and the AI service you intend to use.
2. Create a small structure people can understand
Create a new private repository, give it a clear name, and include a README. For the client brain, start with these files. These names are a suggested structure, not special filenames that make AI work automatically.
- README.md: where to start, who maintains the brain, and which documents cover which questions.
- client-overview.md: what the client sells, who they serve, their business model, and important terminology.
- positioning.md: the audience, offer, approved messages, tone, and claims the team should avoid.
- project-scope.md: the goal, deliverables, exclusions, milestones, and who approves the work.
- current-status.md: what is happening now, what is blocked, and the next decision needed.
- decisions.md: dated decisions, the reason behind each one, who approved it, and what it replaced.
- sources.md: links to original briefs, research, approved assets, and other source material.
- meetings/: dated summaries with decisions, action items, owners, and unresolved questions.
For the shared agency-brain repository, keep a similarly small set of documents covering your services, standard processes, writing guidelines, and review checklists.
Use ordinary language. One file should answer a recognizable group of questions. A 200-page document with no headings is difficult for a teammate to navigate and gives an AI assistant more work to find the relevant parts.
3. Turn a new client kickoff into useful context
Suppose Northstar sells inventory software to independent retailers. Your agency is redesigning its website. After the kickoff, the account manager updates the client overview and scope, then records the decisions that affect the work.
A useful entry might look like this:
Decision: Lead the homepage with fewer stockouts, rather than faster reporting.
Status: Approved.
Approved by: Client marketing lead.
Date: 15 September 2026.
Reason: The kickoff identified stock availability as the main buying trigger.
Source: Kickoff summary, 15 September 2026, section “Buying triggers”.
Replaces: The reporting-led direction in the initial brief.
That gives someone more than a slogan. It tells them whether the direction is approved, why it exists, and where to check the evidence.
Label uncertainty just as clearly. “The client may enter the UK next year” belongs under an open question unless someone has confirmed it. An AI-generated summary is also a draft until a person checks it against the source.
Add an owner and last-reviewed date to important documents. When a decision changes, update the current overview as well as the decision log. Otherwise the repository can contain a correct historical record and an incorrect current answer at the same time.
4. Let the team contribute without losing the thread
A teammate should be able to add what they learn. The account manager records a new client decision. The designer adds an approved visual constraint. The strategist corrects an audience assumption.
For a browser-based update, open the relevant file on GitHub, choose the edit action, make the change, and choose to commit it to a new branch. Use a descriptive commit message, such as “Update Northstar homepage direction after kickoff”. Then open a pull request.
GitHub reference: editing files in the browser
In the pull request, explain what changed, link to the source, and name anything that is still uncertain. Ask the client owner to review it. Once approved, merge it into main. If two people have changed the same passage, resolve the conflict by checking the source rather than guessing which wording should win.
GitHub reference: creating a pull request
You can make review a team convention from day one. If you want GitHub to enforce it, configure branch protection or repository rules supported by your plan. Enforced protection for private repositories depends on the GitHub plan and repository setup.
GitHub reference: protected branches and plan availability
For a simple knowledge edit, a useful review asks: Is this accurate? Is it approved or still a proposal? Does it contradict another current file? Those checks matter more than a complicated contribution process.
5. Connect an AI assistant to the right brain
Start with one supported connection method and prove that it can read the files. A private GitHub URL pasted into an ordinary chat is not enough. The tool needs an authorized integration, an accessible local copy, or files you explicitly attach.
One browser-based route is GitHub Copilot Chat. In the chat interface, use the option to add repositories, files, and spaces, choose Repositories, and select the client repo you can access. Availability depends on your account and organization settings. GitHub also documents repository-page chat, currently described as a public preview.
GitHub reference: selecting repository context in Copilot Chat
That feature is documented for exploring codebases. Using it with your agency’s Markdown knowledge is an application to test, not a promise that every document will be retrieved perfectly. Start with a question whose answer you already know, and check the cited file.
If your team uses an AI workspace tool instead, clone the approved repository into a local folder and open that folder in the tool. Cloning means downloading a working copy with its history. Before a new task, fetch and pull the latest approved changes; an old local copy will still contain old context.
The tool’s instructions determine how to include workspace files. Confirm that it can read README.md and client-overview.md before asking it to work. A generic “brain” filename does not make every AI app load the repository automatically.
To combine agency standards with client facts, explicitly provide both sources in a tool that supports that setup. If it supports only one repository at a time, attach the approved agency guidance needed for the task and record which version you used.
Links in sources.md are signposts. They do not automatically give the assistant access to a private Drive document or make it watch a recording. Include an approved text summary in the repo when that context is needed, and keep the source link for checking.
6. Give a new teammate a first question to ask
Instead of “Tell me everything about this client”, start with a bounded orientation request. Here is a prompt to adapt:
I’m joining the Northstar website project. Read README.md first, then client-overview.md, positioning.md, project-scope.md, current-status.md, and the relevant entries in decisions.md.
Explain who the client serves, what they sell, the project goal, the approved homepage direction, and what is currently blocked. Cite the filename and section for each answer. Separate confirmed decisions from proposals and open questions. If a requested fact is missing or contradictory, say so. Do not edit any files.
Then ask something useful for the actual assignment: “What should I know before drafting the homepage?” or “Which claims need client approval?” The teammate can follow the file references and check the answer before using it.
If the client’s target conversion rate was never recorded, the correct answer is that it is missing. A confident invented number is a failure of the workflow.
7. Keep answers and updates as separate steps
After a call, you can ask AI to suggest changes to the brain. Give it the notes and ask which files need updating, which decisions appear confirmed, and which questions need a person’s answer.
Review those proposed changes before merging them. A client saying “we could try this” should not silently become an approved strategy. Keep the source material distinguishable from instructions to the assistant, especially when copying client emails, webpages, or transcripts.
Have one owner per client brain. A practical starting routine is to update it after a meaningful client decision and review current-status.md before a handoff. Archive outdated material clearly so it is not mistaken for the current plan.
8. Test whether the brain actually helps
Ask someone who was not on the kickoff to use the repository and answer five questions:
- Who is the client’s primary buyer?
- What exactly are we delivering, and what is outside the scope?
- Why did we choose the current direction?
- What needs approval next, and who owns that decision?
- Which important facts are still missing?
Check each answer against the files. Test one deliberately unanswered question as well. You want the assistant to recognize the gap, not complete the story.
If the answers are weak, inspect the documents and retrieval before adding more software. Is the fact written down? Is it current? Can the tool access it? Did it actually cite the relevant file? Repository indexing can help search, but it does not guarantee that every answer uses every file.
GitHub reference: repository indexing for Copilot
Start with one client
Pick a client whose context you keep explaining. Create the private repository, write the overview and current scope, and record a few important decisions. Have one teammate propose an update and another use the brain to prepare for a task.
That first test will show you what is missing. Build from there. The aim is for an authorized teammate to find reliable context, understand what is known, and see what they still need to ask.
This is a suggested agency workflow, illustrated with a fictional client. GitHub features were checked against its documentation on 15 September 2026; interfaces and plan requirements can change.