One brain per client: running GTM delivery on an open-source base

The rebuild problem

If you deliver GTM engineering for clients, the pattern is familiar. Every new engagement starts with an intake where you learn who the client sells to and why they win. Then you write the ICP down somewhere, build a research process, set up enrichment tables, draft outreach and design the campaign steps. Some of that is genuinely client-specific. A lot of it is the same method you used for the last client, rebuilt from a template, a copied prompt or memory.

At the end, the knowledge is in three places: in your team's heads, in your tools' workspaces, and in a handover document that is out of date the week after it is written. The client gets the automations but not the reasoning behind them, and the next person to touch the system, theirs or yours, starts by reconstructing what was decided.

[Leszek to add: one first-hand sentence about rebuilding the same workflow across clients, without client names or numbers.]

The fix is to separate the two things you keep rebuilding. The client's context should be a durable record that belongs to the client. Your method should be a reusable asset that belongs to you and improves with every engagement. GTM Brain, the open-source company brain for Codex (Claude Code support is in beta), happens to be built around exactly that split.

1. One brain per client

A GTM Brain brain is a folder: brain/admin.md for the company, team and tools; brain/contexts/ for topics such as Target customers, Our offer and Strategy, each with a summary, standing rules and an append-only file of dated notes; brain/entities/ for the people, companies and products involved; standing documents such as strategy.md at the top; and playbooks in workflows/.

For a services firm, the natural unit is one brain per client. You can keep several brains on one machine, and when you link a working folder, GTM Brain asks which brain it belongs to. That gives you clean boundaries without any extra tooling. A note about one client's buying committee cannot end up in another client's summary, because it lives in a different folder.

Inside each client brain, the opening work maps onto shipped skills. /gtm-brain-start sets up the brain and drafts the workplace information from the client's website for you to correct and approve. /gtm-brain-strategy runs a 10 to 15 minute strategic intake with the client's founder or head of GTM and fills strategy.md, with each point labelled Confirmed, Hypothesis or Gap. /gtm-brain-document keeps the client's ICP definition, offer, pricing and tone of voice as documents the agent reads before work they apply to. Changes to the client's company information are shown as a diff and only applied when someone types APPROVE.

2. Project folders for the deliverables

The brain is the record. The work happens in project folders: one for the outbound campaign, one for the website copy, one for an event. /gtm-brain-project either creates a new folder inside the client's brain workspace or links an existing one, and asks before it captures any work from it. From then on, every chat in that folder opens with its own loaded contexts and every note it saves is tagged with the project, while everything still lands in the one client brain and stays searchable from there.

Campaigns that run over weeks become workflows: a "Before starting" list (segment, offer, success criteria), numbered steps with a tool category and an optional gate such as after 14 days or when the engaged accounts are known, and a "Learn" list for the read-back at the end. The workflow tracks each run, its dates and its gates. It does not send anything itself. Each step is done in chat through the client's connected tools with their own permissions, or by a person, and then recorded.

3. Your methods as skills, reused across clients

This is where a firm gets leverage. In GTM Brain, a skill of your own is a folder in a brain's .agents/skills/, named gtm-brain-<name>, that tells the agent how to do one kind of work the same way every time. You can say "turn what we just did into a skill" after doing something once, ask for one with /gtm-brain-skill, or wait for the health check: when the same action shows up on three separate days in the last month, it suggests making a skill from it.

To reuse a method across clients, keep your skills in a GitHub repository of your own and install them into each client brain with one sentence: "install the skill / at ". Private repositories work when your git credentials reach them. The installed skill is validated and committed in that client's brain, and GTM Brain plugin updates never touch it.

The discipline that makes this work is keeping client facts out of the skill. The shipped skills do this themselves: the strategic intake, for example, treats names, figures and customer profiles from a session as runtime context that belongs in the brain, never in the reusable SKILL.md. Write your skills the same way, with placeholders such as [customer] and [pricing model], and the method travels while each client's details stay in that client's brain.

[Leszek to add: which of our own delivery methods we would package as a skill first, and why. A method, not a client story.]

4. Handover the client can actually use

When an engagement ends, the client should keep the reasoning, not only the automations. With a brain per client, what you hand over is a folder of plain Markdown and append-only JSONL in git: the approved documents, the decisions with their dates and sources, the open questions, the workflows with the history of every run, and the skills installed for them. Corrections are new records that supersede old ones, so the history of what was believed and when is intact.

Two choices make this clean from the first day. Put the client brain in a git remote the client owns, so each change is already a commit in their repository and handover is a change of who works in it, not an export. And connect the client's CRM, email and calendar with the client's own accounts through the agent host, since connectors are authorized separately per host and per account. Your firm's skills stay in your repository; the copies installed in the client's brain are theirs to keep using.

5. What to prove in a bounded pilot first

None of this is proven for client delivery yet. GTM Brain is open source, version 0.31.2 at the time of writing, and there is no record of a services firm running client work on it. So treat the first engagement as a bounded pilot with three explicit checks.

Permissions. Write down which client tools the agent may read, under whose accounts, and which actions need a person. GTM Brain's own guardrails help: protected workplace changes need APPROVE, the dashboard is read-only, and sends or account changes go through each integration's own permission flow. Your client's IT policy may still decide what you can connect.

Success criteria. Agree before the pilot what would count as better, for example whether a new team member can answer "why is this account on the list" from the brain alone, or whether the second campaign reused the first campaign's skills without rework. Record the criteria as a decision in the client brain so the review at the end reads from the same record.

Maintenance burden. Someone has to update the plugin, answer open questions, approve documents and keep the scheduled summary refresh running. Be honest about the current limits: GTM Brain runs locally through the Codex desktop app, Mac is the recommended setup and Windows has not been verified, Claude Code support is in beta, and multiplayer is coming but not available today. A team shares a brain through git, not through a hosted workspace.

If the client's needs exceed what runs today, reuse turns out to be low, or the upkeep outweighs the value, stop and say so. A pilot that ends in "not yet" is still a useful result.

/gtm-brain-start
This brain is for our client [client name]. Their website is [URL].
After setup, run the strategic intake. I will answer from the notes of
our kickoff call with their founder, so mark anything I am unsure of
as Hypothesis or Gap.

Previously: You can build the pipeline. Here's how to decide what it should do. →