Your CRM Is a Lie Both Sides Agreed to Keep Telling
Every salesperson knows their CRM is incomplete. Every manager knows it too. The reps enter the minimum to avoid getting flagged. The managers build forecasts on data they know is half-fiction. Both sides maintain the pretense because the alternative — admitting that the real system of record for customer relationships is a mix of LinkedIn DMs, Apple Notes, WhatsApp threads, and human memory — would call into question a $80 billion software category.
It’s time to call the question.
The CRM is not broken in ways that better features can fix. It’s broken in the way its incentives are wired, the way its architecture assumes data should be owned, and — most urgently — in the way the entire industry is responding to AI by baking agents into a product designed for a world without them.
There’s a better path. It starts with a rotating card file from 1956.
The Rolodex Got the Incentives Right
Before CRM was a software category, relationship management was a physical artifact on a desk. The Rolodex wasn’t just an address book — when someone said “she has a strong Rolodex,” they meant she had access. CEOs’ direct lines. Investors who’d take her call. Buyers who returned emails within the hour. A strong Rolodex was career capital, accumulated through years of earning trust, one relationship at a time.
Three design properties made it work. The Rolodex was owned by the individual — the person who built the relationships owned the record of them. The maintainer was the beneficiary — because it was yours, you kept it meticulous, not because anyone mandated it, but because it directly served you. And it was portable — when you changed jobs, it came with you, because everyone understood that a company can own accounts and contracts, but trust between two people belongs to the people who built it.
The CRM software wave of the late 1990s flipped all three properties. Relationship data moved from personal card files to corporate databases. The pitch to executives was compelling: never again will your customer relationships walk out the door when a rep quits. But in solving the institutional memory problem, CRMs created an incentive problem that thirty years of innovation hasn’t fixed.
The person who inputs the data is not the primary beneficiary. The rational response is to input the minimum and keep the real intelligence somewhere personal. Which is exactly what happened — and what continues to happen. The shadow Rolodex never died. It just moved to LinkedIn connections, private notes, and memory. The official CRM became the shadow, and the shadow became the system of record.
The Architecture Is Wrong in Two Ways
Most commentary about AI and CRM focuses on the obvious play: use LLMs to make data entry easier. Auto-log calls. Summarize meetings. Draft follow-ups. Every CRM vendor is shipping some version of this, and it’s all solving the wrong problem — or rather, solving the right problem in the wrong place.
First, the agent shouldn’t live inside the product.
This feels counterintuitive. Why wouldn’t you want your CRM to be AI-native? Because the only thing guaranteed about AI agents right now is that they will get dramatically better, dramatically fast. The model that’s state-of-the-art today will feel primitive in eighteen months. The capabilities available next year — better reasoning, longer context, richer tool use — are unknowable in specifics but certain in direction.
Baking the agent into the CRM product means coupling two things with fundamentally different rates of change. The CRM’s data model, UI patterns, and core workflows evolve slowly — as they should, because stability is a feature for a system of record. The agent layer evolves weekly. Tying them together means either the product can’t keep up with AI capabilities, or the product destabilizes as it chases them. Neither is good.
The better architecture: the CRM is the UI that makes a vast set of relationship data tractable. The agent sits outside it, operating on the data through open interfaces. The CRM provides structure, visualization, and the handful of features stable enough to be product-native. The agent provides intelligence, synthesis, and action — and it’s swappable, upgradeable, and model-agnostic.
Second, the data layer should be files, not a database.
A contact doesn’t need to be a row in Postgres. It can be a markdown file with YAML frontmatter for structured fields and prose for everything else — human-readable, version-controllable, extensible without schema migrations. Links between files create a knowledge graph: a person links to their company, which links to a deal, which links to meeting notes, which link to other people.
This matters because the data layer needs to be legible to two audiences simultaneously: the human who wants to read and edit their notes, and the agent that needs to reason across them. Markdown is the format that’s native to both. A relational database is optimized for machines. A Word document is optimized for humans. Markdown sits exactly at the intersection — structured enough for agents to parse, natural enough for people to write.
It also matters for extensibility. In a schema-based CRM, adding a new data type requires a migration, an admin, and usually a RevOps ticket. In a file-based system, you create a new folder and start writing markdown. Need to track competitive intel? Make a competitive/ folder. Need to add a field to your deal records? Add a line to the YAML frontmatter. The system evolves at the speed of thought, not at the speed of database administration.
What Should Be in the Product (and What Shouldn’t)
If the agent sits outside the CRM, what does the CRM itself actually do?
It handles the steady-state features — the capabilities so well-understood and stable that they won’t change regardless of how AI evolves. These are the things worth building into the product:
Contact and company enrichment. Given a name or domain, pull firmographic data, social profiles, recent news, hiring signals, and org structure. This is a lookup function — it doesn’t require reasoning, and the output is predictable. When a new person enters your vault, the CRM enriches the file automatically: company size, funding stage, tech stack, recent press, LinkedIn profile, common connections. When a company file is created, it fills in the basics so the human (and the agent) have context to work with.
Deduplication and entity resolution. Recognizing that “Dave Liu,” “David Liu,” and “D. Liu (VP Eng, Nexus)” are the same person — and merging their records intelligently. This is a data quality function that should run continuously in the background.
Relationship visualization. Displaying the knowledge graph — who’s connected to whom, which deals involve which people, where the gaps are. This is the UI doing what UIs do best: making complex relational data spatial and scannable.
Timeline and activity views. Showing the history of interactions with a person or company in chronological order. A basic but essential view that doesn’t need AI to be useful.
Everything else — synthesis, strategy, outreach drafting, forecasting, coaching, pattern recognition — belongs in the agent layer, where it can improve independently of the product release cycle.
Skills: The Matrix Upgrade for Knowledge Work
Here’s where the file-based architecture unlocks something genuinely new.
In The Matrix, Neo doesn’t spend months learning kung fu. A program is loaded, and he opens his eyes knowing how to fight. The skill is external to him — packaged, transferable, instantly installed.
Skills in a file-based CRM work the same way. A skill is a package of domain knowledge — markdown files containing methodology, frameworks, playbooks, and instructions — that an agent can read and immediately apply to your vault. Install a competitive-intelligence skill and your agent can suddenly research competitors, build differentiation matrices, and generate talk tracks. Install a deal-qualification skill and it can assess any deal against MEDDIC, BANT, or whatever framework the skill encodes. Install a contract-review skill and it can analyze vendor agreements against your configured playbook.
The critical insight: this only works if the underlying system is open and file-based. The skill is just markdown files. The vault is just markdown files. The agent reads both and combines them. There’s no API integration, no custom object configuration, no app marketplace with proprietary data formats. A domain expert can write a skill by writing a document — describing how to think about a problem, what to look for, how to structure the output. The skill is human-readable before it’s machine-executable.
This creates a composability that traditional CRM platforms can’t match. A sales team installs prospecting, pipeline-management, and forecasting skills. A legal team working from the same vault architecture installs contract-review, nda-triage, and compliance. A customer success team installs health-scoring and renewal-management. Same substrate, same agent, radically different capabilities — swapped in and out like Neo’s training programs.
And because both skills and data are plain files, the upgrade path is frictionless. A better version of the forecasting skill doesn’t require a product update, a database migration, or even a restart. You replace the skill files. The agent reads the new version on its next invocation. Your CRM just got smarter in the time it took to sync a folder.
What This Feels Like in Practice
A rep finishes a discovery call and narrates what happened — ninety seconds of natural language about who was there, what was discussed, what the concerns were. The agent (sitting outside the CRM, reading the vault) structures this into a call summary, creates person files for new contacts, updates the deal record, and drafts a follow-up email.
Then the rep adds a private note — in a .personal/ directory that never syncs to the team:
The CTO reminded me of a buyer at my last company — technically sharp but reflexively skeptical of anything vendor-hosted. Don’t pitch him directly. Let the technical evaluator build the internal case. Get the CTO a 1:1 with our architect so he feels heard, not sold to.
This is the Rolodex, returned. A private, career-spanning record of relationship patterns that belongs to the professional who accumulated it. It exists because the rep knows it’s theirs — and that knowledge changes what they’re willing to invest in the system.
Later, researching a new prospect, the agent cross-references the vault and surfaces a connection: the prospect’s Head of Engineering overlapped at a previous company with one of the rep’s existing contacts. Potential warm introduction. This link exists not because someone entered it into a field, but because the vault is a knowledge graph — and the agent can reason across files to find patterns that were never explicitly structured.
The CRM shows the rep a clean timeline view, an enriched contact card, and a visual map of stakeholders at the target account. The agent provides the synthesis, the strategy, and the suggested next move. Each does what it’s good at. Neither is trying to be the other.
The Portable Graph
This leads to the bold claim: in this architecture, your relationship graph moves with you.
When you leave a company, the separation is clean. The institution keeps what it invested in — deal records, pipeline data, contracts, account strategies, shared meeting notes. You keep what you built — your personal relationship notes, communication preferences, trust signals, network topology, and the career-spanning patterns you’ve recognized.
The conventional objection is that this creates retention risk. The counterargument is that the current model already fails to prevent it — top performers maintain shadow Rolodexes precisely because they know the CRM will lock them out when they leave. Making the personal layer explicitly portable doesn’t create new leakage. It makes the existing reality legible, and in doing so, it produces richer institutional data during employment because the rep isn’t hedging.
The paradox is productive: making relationship data portable makes it more abundant while the person is there.
The Thesis
The CRM category was built on a reasonable premise — organizations need institutional memory — and implemented it through a flawed mechanism that misaligned incentives for the people closest to customers.
The fix isn’t better AI features bolted onto the same architecture. It’s a rethink of the architecture itself:
Files, not databases — so both humans and agents can read and write naturally, and the schema evolves without friction.
Agent outside the product — so the intelligence layer improves at the pace of AI, not at the pace of product releases.
Skills, not features — so capabilities are composable, swappable, and authored by domain experts in plain language.
Personal ownership with institutional memory — so the incentive loop that made the Rolodex work is restored, and the shadow Rolodex comes in from the cold.
The CRM stores information. The individual owns trust. The best system is the one that respects both.
This is part of an ongoing series on rethinking enterprise software from first principles — what changes when we stop optimizing legacy architectures and start from what we now know about AI, files, and how people actually work.