It's 1:45pm. You have a discovery call with Acme Corp at 2pm.

Your CRM tells you Acme is Stage 2, owner is Jane, ARR band is $25-50M. Useful. And not what you actually need walking into that room.

What you need is the story. Why you reached out the first time. What the contact said two quarters ago. Which signal made you score them a 9. Who else at the company you've touched, and what they said. What changed at Acme between January and now.

That intel exists. It's in last campaign's reply log, a Notion page someone wrote in March, a Fathom transcript from a discovery that went sideways, a Slack thread two operators remember, and the head of an AE who left in April. So you spend the next twenty minutes Frankensteining it back together from six tabs. Then you walk in.

Every AE does this. Every RevOps lead has watched it happen. The CRM was supposed to fix it; it doesn't. Notion was supposed to fix it; it didn't. Adding a tenth tool to the stack will not fix it either.

The thing that's actually missing is a place for the story of an account to live. One file per account, in plain markdown, that every agent in your stack can read before it acts. Every signal that fires gets appended. Six months in, the file is sharper than any human could rebuild from scratch — because the work of remembering was distributed across every interaction instead of crammed into the 20 minutes before the call.

That's the system this week's drop ships.

Before I show you what we built, here's what doesn't work.

The CRM notes field. Every CRM has one. It is where intel goes to die. No structure, no chronology, no agent access, no search beyond keyword grep. Nobody updates it because nobody reads it. Nobody reads it because nobody updates it. It is a chicken-and-egg problem the CRM was not designed to solve.

A Notion page per account. This is the place most teams land second. Better than the CRM notes field for humans — you can have headings, embed Fathom clips, link to Slack threads. Worse for agents — Notion's API is slow and rate-limited, page reads cost real latency, and there's no clean write protocol that doesn't end with agents clobbering each other's edits. We tried it. It works for 50 accounts. It melts at 500.

A vector database over your CRM. Plenty of "AI sales assistant" tools sell this. The pitch is good — embed every account interaction, retrieve the relevant ones at query time. The problem is opacity. You can't grep what was retrieved. You can't diff what changed. You can't open the vector DB and read "what does our team actually know about Acme?" The database is a black box, which means it's brittle, and the moment one retrieval goes sideways nobody can debug why.

Stuffing it into CLAUDE.md. This is the developer's instinct — just dump everything into the project context file. It works until your CLAUDE.md hits 12K tokens and Claude burns half its context window before you say hello. Not a memory architecture. A landfill.

None of these are wrong, exactly. They're partial answers to a problem that needs the right primitive. The right primitive is the one Andrej Karpathy described back in April with his LLM Wiki idea: a persistent knowledge artifact that the model maintains, growing richer over time, queryable as plain text, diff-able in git. Apply that to GTM — one wiki page per account — and the architecture falls out.

Drop the repo onto any agent that supports the Claude Code Skill spec — Claude Code, Cursor, Cline, Windsurf, anything that reads markdown skills — and four things become true.

One markdown file per target account at vault/accounts/<domain>.md. Filename is the apex domain. That is your join key against everything else. YAML frontmatter at the top mirrors the CRM (account id, status, tier, owners, ARR band). Body is the narrative — a Summary block, Firmographics (human-maintained), a Buying signals log, a People graph with wikilinks, an Interaction log, Open questions, and an Agent notes scratch pad.

Five slash commands via the account-vault skill. /account-vault new acme.com scaffolds a new file from the template. /account-vault dossier acme.com returns a 5-bullet brief in about 4 seconds — that's the 1:45pm pre-call lever. /account-vault append acme.com leadership-change "VP Sales hired" writes a new signal under the right marker. /account-vault summary acme.com regenerates the top-of-file summary block. /account-vault list tier=A status=active walks frontmatter across the whole vault and returns a filtered table without touching file bodies.

A heartbeat.py job that runs on a schedule. For every active account, it polls each registered signal adapter (Trigify saved searches, RSS feeds, manual CSV drops — three stubs ship, you add yours), appends new signals to the right account file, and regenerates the Summary block via Anthropic Haiku when material changes. Cost is roughly half a cent per refreshed account per week. Cron, launchd, n8n, GitHub Actions — your call where it runs.

Two one-shot CLI scripts. ingest_signal.py lets a webhook or one-off observation drop a single signal into the right file with the right schema. summarize_account.py produces the same 5-bullet dossier as the slash command, but from a shell — useful for Slack bots, calendar hooks, or anywhere outside your editor.

The install is five commands. Clone the repo, pip install -r scripts/requirements.txt, drop the SKILL.md into ~/.claude/skills/account-vault/, cd vault && claude, and run /account-vault new <domain>. Done.

Three patterns explain why this changes how the day works.

Pre-call dossier. It's 1:45pm again. You type /account-vault dossier acme.com. Four seconds later the agent has read 50 tokens of frontmatter, 300 tokens of Summary, and the three most recent signals plus two most recent interactions — about 750 tokens total — and produces a 5-bullet brief: who they are, the most recent signal and its implication, the most recent interaction and outcome, the top open question, and a concrete recommended next action. Your CRM tab is still loading. You read the brief, walk in, and open the call with the Stripe-to-Acme stack-rebuild lens instead of "tell me about Acme."

Outbound pre-send check. You're about to send a 50-row cold email batch all anchored on "your Series B funding." You ask the agent to run /account-vault dossier against every row and flag any account where the planned angle is now wrong. About a minute later you have a table — three accounts where the angle should change (one replied positively last week and needs follow-up instead of net-new outreach, one announced layoffs, one was disqualified in March). The cost of catching one duplicate-touch is the entire cost of running the check. The vault paid for itself before the batch went out.

Weekly account review. Monday morning, you type /account-vault list tier=A status=active and ask the agent to summarize anything that changed in the past 7 days. Ten seconds later you see exactly four accounts had material changes — a new VP Sales here, a layoffs announcement there, a LinkedIn post about a CRM migration, a new "Head of RevOps" job posting. Fourteen tier-A accounts had nothing happen and are safely off your radar for the week. You plan Monday in front of a table, not a flood of dashboards.

None of those interactions took more than a minute. None of them required you to collect any data in the moment. The data accumulated into the right files over the previous week because every signal source pointed at the vault.

Three places to edit. The rest of the repo is generic.

The signal taxonomy at vault/signals/signal-catalog.md ships with ten common B2B signals — leadership change, funding, hiring surge, product launch, partnership, layoffs, post engagement, conference appearance, competitor mention, technographic change. Add yours. If your buying motion fires on "they spun up a Snowflake instance" or "the founder posted about hiring an SDR for the first time," put those in. The taxonomy is the vocabulary your agents and scripts route off.

The per-account schema at vault/_templates/account.md is where you add ICP-specific frontmatter. If your scoring depends on compliance certifications, vertical specialization, or an ARR band, add those fields. The skill auto-detects them and surfaces them in dossiers.

The signal adapters in scripts/heartbeat.py are where stack-specific glue lives. Stubs ship for Trigify saved searches, RSS feeds, and a manual CSV drop. Add your stack — an Apify scrape, an Apollo enrichment call, your CRM webhook, a custom Trigify search you've already saved. The skill itself never touches your stack. The scripts do.

A flat-markdown vault is a real architecture choice with real limits. The docs/failure-modes.md doc inside the repo is the long version. The short version: it works cleanly for your active book — the accounts you actually touch with intent. For most operators that's 100 to 500. The first thing to creak is not disk or grep — it's the weekly heartbeat run (around 500 active accounts it becomes a 20-30 minute job rather than a "schedule and forget" one), then human comprehension (past a few hundred active accounts, a single operator can't sanity-check what the agent is writing), then "show me everything across the whole vault" queries (because the agent can't read every file in one prompt — you have to filter first). Past about 1,000 active accounts under weekly cadence, start planning the migration. Past 2,000-3,000 it's overdue.

The migration path is not "throw the vault out." It is "move frontmatter and filtering into Postgres, keep the markdown bodies as the narrative store, the skill schema stays the same." Most operators never hit the wall. If you do, the doc tells you exactly which threshold breaks first and what to move when.

This is the foundational layer. The same primitive — one markdown file per thing, agents read it before they act, every observation gets appended, the file compounds — produces equally useful vaults for replies, deal rooms, customer success, and ICP refinement. Ship this first; the others build on top, because once your AE is in the habit of asking the vault before opening the CRM, the same instinct rewires every adjacent workflow.

The repo is public, MIT licensed, and the entire walkthrough above is in the README. There is no gate. Clone it, drop the skill into your Claude Code, and your next pre-call dossier should take four seconds.

The next two patterns in this series — the Reply Intelligence Wiki (every cold-email reply gets parsed into a markdown wiki agents read before drafting) and the Compounding ICP Vault (every account ever scored becomes a row your agent searches before scoring the next one) — drop in the coming weeks. If you'd rather not check back, the subscribe link below pushes each one to your inbox the day it ships.