Your agent forgets who you sell to

How the ICP drifts

Picture a founder who sells to mid-sized logistics companies. In March she writes down who she sells to in a chat with her AI assistant, and the answer is good. In April she builds a list in Clay and, because the first filter returns too few companies, she widens the employee range a little. The list goes into Attio as a new list with its own name. In May a teammate copies a slice of it into HeyReach for a LinkedIn campaign and removes two industries that did not reply. In June she opens a new chat, asks the agent to draft a campaign for "our ICP", and pastes the version she has to hand, which is the one from March.

Nobody made a mistake. Each change was reasonable at the time. The problem is that the decision to widen the range, the evidence that two industries do not reply, and the reason the list was built the way it was all live inside tools that store records, not decisions. The CRM knows which companies are on a list. It does not know that the list is a test of a wider ICP that was meant to be reviewed after a month.

[Needs Artur's OK before publishing.] Artur, who builds GTM Brain, described this from his own work: a report downloaded into Attio, a separate list built in Clay, and over time the hypotheses behind both getting lost. He also found that the memory of his AI assistant was being overwritten without him seeing what the decision had been. That experience is where GTM Brain started.

If you hold GTM together alone or in a small team, you probably recognise the symptoms: two lists that should be the same and are not, a contact who appears twice with different notes, an outreach sequence whose targeting nobody can explain, and an agent that writes confidently from whatever you pasted last.

Why chat memory is not a GTM system of record

AI agent memory, as most assistants offer it, is designed to make the next conversation smoother. It keeps preferences and facts it thinks will help, and it updates them as you talk. That is useful for tone and for not repeating yourself. It is the wrong shape for go-to-market decisions, for three reasons.

First, a GTM decision needs a date and a source. "We stopped targeting retail" is only useful if you can see that it was decided on a specific call, by a specific person, because of specific replies, so that you can revisit it when the evidence changes. A memory that says "user does not target retail" has lost all of that.

Second, a decision has to stay visible after it is replaced. If you widen the ICP in April and narrow it again in June, the history is the useful part: it tells you what you tried and what it taught you. A memory that is rewritten in place keeps only the latest belief.

Third, the agent should not resolve ambiguity on its own. If one note says the buyer is the head of operations and another says the CFO signs, a good record keeps both and asks you which is true. A memory that quietly picks one gives you a confident answer that may be wrong.

None of this is a criticism of chat assistants. They are built for conversations. A GTM record is built for decisions that have to survive many conversations, many tools and, eventually, more than one person. Context engineering for GTM is mostly about that second job: deciding what the agent must always know, what it should look up, and what it must ask you.

What a durable GTM record needs

If you were designing a company knowledge base for an agent that does GTM work, you would end up with roughly five parts.

Topics with standing rules. Most work happens inside a topic: target customers, the offer, a strategy, a market you are entering. Each topic needs a short current summary and a few rules for how to work there, for example "only companies with a dedicated operations team" or "never discount below list in the first call". GTM Brain calls this a Context.

Dated evidence with sources. Inside each topic you need records of what happened: a buyer described a handoff problem, you decided not to discount for one account, a question is still open. Each record needs a date, an author, the people and tools involved, and a pointer to where the evidence lives, such as the call notes or the CRM record. GTM Brain calls one such record a Memory.

Stable identities. The same person shows up as "Chris" in a call note and "Krzysztof Pawlak" in the CRM. The same company appears with and without its legal suffix. The record needs one identity per person, organization or product, with aliases, so that everything you know about them can be found together. GTM Brain calls this an Entity.

Corrections that supersede. When a fact changes, you add a new record that points to the old one and says it replaces it. The old one leaves the current view but stays in the file. When you withdraw a note because it was wrong, that withdrawal is also a record. Nothing is edited in place, so you can always reconstruct what you believed at any point.

Questions for a human. When the evidence conflicts or something is missing, the record should hold an open question until a person answers it, and the agent should bring it up at the right moment instead of guessing.

Two more things make the record usable in practice. Standing documents, such as an approved ICP definition or a pricing guide, are written by people and followed by the agent, not rewritten by it. And the whole record has to be inspectable by a person without asking the agent, because the point is to see the decision yourself.

How GTM Brain keeps that record

GTM Brain is an open-source plugin for Codex, MIT licensed, with Claude Code support in beta. It gives your agent a persistent, structured workspace for GTM work: a folder on your computer with plain files that the agent reads and writes through a local MCP server.

Each Context is a folder under brain/contexts/ with a context.md for the summary and rules and a memories.jsonl file of records. Memory writes are appended immediately. A correction is a new record with supersedes; a withdrawal or an answered question uses retracts. Entities live in brain/entities/, and their briefs are compiled from the memories that mention them, with citations back to each one. Standing documents such as strategy.md carry a kind: document marker; the agent reads them in full before work they apply to and says which one it followed. A local SQLite FTS5 index makes search practical, and it is a cache you can rebuild, not the source of truth.

In everyday use you just talk. "Open Target customers" loads that topic. "We decided not to discount for Bergstrom" becomes a decision record. "Open question: is the CFO a standing committee member?" becomes a question that stays visible until you close it. "Correct memory m_9a1c02d4e5f6: the meeting is 12.09, not 10.09" adds a correction and keeps the original. Changes to company information are shown as a diff and only applied when you type APPROVE.

The dashboard is a read-only view of the same files: contexts, evidence, people and companies, decisions, open questions and workflow progress. It does not edit anything. Summaries refresh in the background, by default after ten minutes without a new note.

It is worth being exact about what it does not do. Your CRM stays the source for deals and contacts; GTM Brain keeps evidence and decisions, not a copy of every record. Connectors to your CRM, email and calendar come from your agent host and are authorized separately. The files live on your machine, but your AI provider still processes the context you give it, so local storage does not mean offline inference. In the Claude Code beta, background summaries still need Codex on the same machine, and connector checks and the dashboard's chat buttons are Codex-only.

Open Target customers. Here is how we define our ICP today: [paste it].
Remember it as a decision, with today's date and this chat as the source.
Then list anything in it that contradicts what you already know, and save
each contradiction as an open question for me.

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