Claude Code Agent Memory for Prospects, The Operator's Three Level Playbook

Claude code agent memory for prospects means durable state the agent reads and writes across runs. The context window forgets after one session. CLAUDE.md reloads static rules on startup. Only a queryable store, a markdown log, a SQLite file, or your CRM, lets the agent skip a lead you already emailed.

The three things people conflate as memory

An agent has three surfaces you can put information on and only one of them actually remembers your prospects. Mixing them up is why teams ship a Claude Code sales agent that greets the same person for the fifth time this quarter.

The context window is the scratchpad inside a single run. Close the session, open a new one, and the agent knows nothing about the prospect it just messaged. Sonnet 4.6 and Opus 4.7 both carry large context windows, and it does not change this fact. A scratchpad is still a scratchpad.

Project files are the second surface. CLAUDE.md sits in the repo, Claude Code reads it at the start of every session, and it reloads the same static rules every time. It is the right place for the playbook, the ICP definition, the objection handling, the do not use list of words. It is the wrong place for the fact that Julia at Segment replied "not now, try Q2" on the last run.

Durable memory is the third surface, and it is the only one that stores prospect state. It lives outside the context window, gets read on the way in, gets written on the way out. It can be a markdown log the agent appends to, a SQLite file on disk, or a CRM the agent reads through an API. Once you give an agent this surface, it stops paying to enrich the same lead twice and stops emailing people who already replied.

Claude Code shipped its own version of this in v2.1.59 with auto memory. It works. It is also capped at 200 lines or 25KB with exact match retrieval, which is fine for coding preferences and small for a real prospect book. Two hundred lines is roughly fifty prospects if you write one line each.

What breaks in GTM when your agent forgets

Software forgetting has a real dollar cost in outbound. Every enrichment call has a per contact price. FullEnrich and Crustdata both bill per row. Run a nightly job that hits the same 500 rows a second time because the agent did not know it ran them last week, and you have quietly torched a month of your data budget.

The relational damage is worse. An agent that cannot see reply history will send a first touch to someone who booked a call with you six weeks ago. It will pitch a new feature to a paying customer. It will follow up on a warm thread as if it were cold. Every one of those messages was avoidable, and every one of them costs a domain reputation point you cannot buy back.

Deliverability picks up the tab. Google and Yahoo cap the spam complaint rate at 0.3 percent for senders above 5,000 messages a day, per Google's bulk sender guidelines. An agent that emails already opted out prospects because it lost the state runs your complaint rate up in a week. There is no better way to break your own domain than to hand a stateless agent a big list and a Send button.

This is the specific reason Claude Code for SDRs fails without a memory layer. The volume looks impressive in the demo. In week three the domain is throttled and half the replies are irritated repeat contacts asking to be removed.

The fix is a three level progression. Start with markdown files inside the project. Move to a local store when the folder scan slows down. Move to a shared CRM once more than one agent needs to read the same state.

Level 1, markdown files the agent reloads

The cheapest working memory is a markdown file the agent reads on startup and appends to at the end of the run.

You keep a contacts/ folder inside the project. One file per prospect, named by domain or LinkedIn slug. Each file holds the last five interactions, the reply verdict, the current stage, and any specific facts the agent should remember. The agent reads the file at the start of a run, uses what is in it, and writes an update at the end.

Under the hood this is the same idea Claude Code auto memory uses, just larger and organized by prospect instead of by session. It works because markdown is a first class citizen for Claude Code. The Read, Write, and Edit tools are already wired, no MCP required, no vector database, no vendor.

The cutoff is around a few hundred active prospects. At that size the agent can grep the folder in a couple of seconds. Past that the folder starts to feel slow, retrieval gets fuzzy, and you begin to want an index rather than a scan. Auto memory itself hits the same wall, because it only surfaces exact keyword matches. Ask about "the fintech CTO I emailed" when the file records "Julia at Segment" and you get nothing back.

Even so, this is the level almost every solo operator should start at. It runs today with no new tools, it fits in git, and it removes every failure mode above for the first six months of running outbound from Claude Code.

Level 2, a local store for prospect state

Once you have a few thousand rows, the markdown scan breaks. You move to a queryable store the agent can read and write with real filters.

The simplest working pattern is a single SQLite file inside the project. One table for contacts, one for interactions, one for enrichment cache. The agent uses the Bash tool to run a small Python or Node script that reads and writes. Nothing hosted, no vendor to pay, and you can inspect the whole thing in a text editor. Sensitive fields stay on your disk, not on a third party.

The value is not the database. It is that the agent can ask specific questions before it acts. "Have we contacted anyone at this company in the last 60 days" is a five millisecond query. "Do we already have a verified email for this LinkedIn ID" is another. Both questions save an enrichment call, and both prevent the domain poisoning behavior above.

If you want semantic recall on top of that, Mem0 plugs in as an MCP server with a free tier of 10,000 add requests and 1,000 retrievals per month, a Starter plan at 19 dollars per month, and a Pro plan at 249 dollars per month for graph memory and 500,000 add requests, per Mem0's pricing page. Fetched on the day this article was written. This is the layer where you stop losing "the founder we spoke to at DevDay who wanted the API version" and start finding them back with a semantic query. That said, most GTM state is structured, not semantic. A relational schema wins for anything you can express as a WHERE clause.

At this level the agent starts to feel like a colleague. The data enrichment agent pattern uses this exact store to cache people, waterfall enrich only what is missing, and never repeat a paid lookup twice.

Level 3, shared state across agents and runs

The last level is where multiple agents write into the same store and read each other's updates. This is what a real GTM stack looks like once more than one person is involved.

Your source of truth is the CRM. HubSpot, Salesforce, Attio, or Folk. The agents read and write through the HubSpot MCP or the equivalent for whichever CRM you run. A research agent enriches the contact, a signal agent flags a hiring event, a drafting agent writes the touch, a sender agent queues it in the outbound tool, and a reply classifier logs the outcome back. Every one of them reads the same contact record before it acts, and every one of them writes back to it.

The trick that keeps this from becoming another integration graveyard is to treat the CRM as memory, not as the workflow engine. The CRM stores state. The agents run the reasoning. When a new signal arrives, the agent does not fire a Zapier rule that runs a hidden playbook. It fetches the contact, checks history, decides the next action, and takes it. This is the design that makes a fleet of agents feel like one team member instead of five confused ones talking over each other.

For teams doing this today, Notion plus HubSpot is a common pattern. Notion holds the operator context, the ICP definitions, the qualification rubrics. HubSpot holds the contact records and history. The agent reads both, decides, writes back to HubSpot, and updates Notion with any learned pattern. This mirrors the ways operators are using Claude Code for GTM once they move past one off scripts and start running a real fleet.

Where Yalc runs the memory layer for you

Yalc is the GTM operating system that runs on top of this stack. It ships the memory layer already wired, so a Claude Code agent can query prospect history, reply state, enrichment cache, and CRM records from one prompt without you writing the plumbing.

The pattern is the same as above. Yalc keeps your data provider, your sender, and your CRM as the source of truth. What it adds is the shared memory graph the agents read before they act, the lead qualification skill as the gate before any outbound, and the write back path that keeps HubSpot in sync between runs. If you are already using Claude Code for GTM, Yalc is the layer that turns a folder of scripts into a fleet of agents that remember what happened last Tuesday.

The suppression test, would it email someone who already replied

One question separates a memory system that works from one that does not. Take the agent, disconnect it from the internet, hand it a list of 200 prospects, and ask it to draft the next touch. Read the drafts.

If a single draft is a first touch to someone who replied in the last 30 days, the memory layer is broken. If a single draft is a "just checking in" to a booked meeting, the memory layer is broken. If a single draft is a cold pitch to a paying customer, the memory layer is broken.

This is the test I run on every Claude Code prospect agent before it sends anything live. It catches the failures a demo hides. Suppression lists live in every mature outbound stack, and yet stateless agents blow past them every week because the agent does not know they exist. The agentic GTM operating system pattern only compounds when the agent respects prior state, and this test is the cheapest way to prove it does.

Wire it into your test harness. Every new agent, every new prompt, every new signal integration gets the suppression test before it touches production. Two minutes, catches nine out of ten of the worst possible sends.

What to do this week

Pick one prospect and walk through your current agent by hand. Ask it to draft the next touch. Watch what it does and does not know.

If it enriches a contact you already have on file, add a JSON enrichment cache in the project folder and give the agent a Read tool over it. If it drafts a first touch to a booked meeting, add a suppression log and require the agent to read it before drafting. If it forgets which sequence a prospect is in, add a state file per contact.

Start at level one with markdown files. Move to level two the moment you feel the folder scan slow down. Move to level three when a second person joins the team and needs to read from the same store. Do not skip levels, and do not build a vector database before you have felt the pain a folder cannot solve.

For teams already writing agents in Claude Code, the operator guide to building your own GTM agent walks through the memory schema most solo operators land on after two months of iteration. Copy it, run it for a week, and iterate.