This is part of a series on rethinking software categories 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.
This essay focuses on a specific type of sales professional: the salesperson working on a complex B2B deal over months. They navigate stakeholder politics, build trust across a buying committee, and precisely time the right message. Their edge lies in judgement, relationships, and a system of record for customer relationships that includes LinkedIn DMs, Apple Notes, WhatsApp threads, and human memory.
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.
Consider five things about the CRM this person uses, each so deeply embedded in the category that they feel like laws of nature rather than design choices:
-
The data lives on a company server, not on the seller’s machine. Every contact logged, every note written, every relationship mapped — it belongs to the institution the moment it’s entered. The seller builds the relationships. The company owns the record.
-
The intelligence is baked into the product. When a CRM vendor releases an AI feature—such as call summaries, lead scoring, or email drafting—it arrives on their schedule, shaped by their model choices and architectural constraints. Why? when models get smarter every month and you can use plain text to get actual work done.
-
The data lives in tables. Contacts are rows. Opportunities are rows. Activities are rows. The structure was designed around how relational databases store information, not around how a sales professional thinks about a deal. Adding a field requires an admin. Adding nuance — the CFO is skeptical but the VP is championing this internally — requires either a freetext box that no system can reason about, or leaving it in your head.
-
The interface is heavy and rigid. Enterprise CRMs are designed to be everything for everyone — marketing automation, customer service, analytics, configuration engines. The seller navigating a complex deal wants to move fast, see what matters, and act. Instead, they get a system optimized for the administrator who configured it.
-
The structure mirrors the database, not the work. Contacts, Accounts, Opportunities, Activities — these aren’t natural categories for how a skilled seller thinks. They’re normalized database entities. The CRM’s information architecture was designed around storage efficiency, not around the cognitive patterns of someone managing a dozen high-stakes relationships simultaneously.
None of these are bugs. They’re foundational choices made decades ago, when databases were the obvious substrate, when software was the intelligence layer, and when institutional control over customer data was the primary design goal. They were reasonable choices. The question is whether they’re still the right ones — given what we now know about AI agents, file-based systems, and local-first architectures.
What if we started over?
Owning the Record: The Rolodex Principle
Before CRM was a software category, relationship management was a rotating card file 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 who’d take her call. Investors who trusted her judgment. A career’s worth of social capital, encoded on paper cards.
Three properties made it work. The Rolodex was owned by the individual — the person who built the relationships owned the record. The maintainer was the beneficiary — because it was yours, you kept it meticulously. And it was portable — when you changed jobs, it came with you.
CRM software inverted all three. Relationship data moved to corporate databases. The person who inputs the data — the seller — is not the primary beneficiary. The rational response, for three decades running, has been to input the minimum and keep the real intelligence somewhere personal.
The shadow Rolodex is alive and well in 2026. Every experienced B2B seller maintains one — LinkedIn connections curated over years, personal notes on key contacts, WhatsApp threads with trusted colleagues, mental maps of who-knows-who. The official CRM captures the skeleton of a deal. The shadow Rolodex holds the tissue.
The design principle isn’t “give sellers a CRM they like more.” It’s: the only system people voluntarily maintain is one they own. A local-first architecture — where the seller’s data lives on their machine, where personal notes stay personal, where the relationship graph they’ve built over a career travels with them — restores the incentive alignment that made the Rolodex work.
The institution still gets what it needs. Deal records, pipeline data, account strategies, shared meeting notes — these sync to a team layer. But the personal relationship intelligence — communication preferences, trust signals, stakeholder instincts, the pattern recognition that comes from years of selling — belongs to the person who accumulated it.
The paradox is productive: making relationship data portable makes it more abundant while the person is there. A seller who knows their personal insights are truly theirs invests more in the system overall. The institution gets richer data as a side effect of respecting ownership.
Agents Alongside, Not Inside
Every CRM vendor is racing to bake AI into their product. Auto-log calls. Score leads. Summarize meetings. Draft emails. These features are useful. They’re also architecturally misguided.
The issue is rate of change. A CRM’s core — its data model, UI patterns, workflow structures — should evolve slowly. Stability is a feature in a system of record. But AI agents are improving at a pace that makes quarterly product releases look glacial. The model that’s state-of-the-art today will feel limited in a year. The capabilities emerging next — better reasoning, longer context, richer tool use, new modalities — are unknowable in specifics but certain in trajectory.
Coupling these two rates of change means either the product can’t keep up with AI, or the product destabilizes chasing it.
The alternative: the agent works alongside the CRM, not inside it. The CRM provides structure and visualization. The agent provides intelligence and synthesis. They communicate through the data layer — which is where the file-based architecture becomes load-bearing.
An agent that can read and write plain files is an agent you can swap, upgrade, or extend without touching the CRM. A better model comes out — point the agent at it. A new capability emerges — the agent picks it up. The seller’s system gets smarter at the pace of AI progress, not at the pace of their vendor’s roadmap.
This doesn’t mean the CRM is dumb. It means the CRM does what a product does best: the steady, well-understood things that don’t change. Enriching a contact when a new person enters the system — pulling firmographic data, social profiles, recent news, hiring signals. Deduplicating records when “Dave Liu” and “David Liu, VP Eng” turn out to be the same person. Visualizing the relationship graph so the seller can see who’s connected to whom at a glance. Showing a clean timeline of every interaction with a person or company.
These are features stable enough to be built into the product. Everything else — synthesis across dozens of touchpoints, deal strategy coaching, competitive analysis, forecasting that factors in behavioral signals — is better handled by an agent that improves independently.
Files Over Tables
A relational database stores a contact as a row: first name, last name, title, company, phone, email. Each field is typed, constrained, defined by an administrator. Adding a new field requires a migration or a configuration change. Capturing something that doesn’t fit the schema — she’s skeptical of vendor-hosted solutions because of a bad experience three years ago — means either shoehorning it into a “Notes” freetext field that no system can reason about, or not recording it at all.
A file stores a contact as a document:
---
name: David Liu
company: Nexus AI
role: VP Engineering
relationship_owner: alex
last_contact: 2025-01-14
---
# David Liu
Champion for our deal at Nexus AI. Direct communicator,
appreciates specifics. Prefers Tuesday/Thursday calls.
Responds fastest on LinkedIn DMs.
Internally championing our solution against CTO skepticism.
Has CEO backing — spending political capital on this.This is readable by a human in any text editor. It’s parseable by an agent that can extract structured data from natural language. And it’s extensible without anyone’s permission — need to track a new data point, add a line to the frontmatter. Need to capture nuance, write a sentence.
The file-based approach solves two problems simultaneously. For the seller, it removes the friction between how they think about a relationship and how they record it. There’s no form to fill out, no picklist to select from, no required field blocking a save. For the agent, it provides a rich substrate to reason over — not just structured fields, but context, nuance, and the associative links between entities that wiki-style references create naturally.
When files link to each other — a person links to a company, a deal links to people, a meeting note links to all of them — a knowledge graph emerges. The agent can traverse this graph to surface patterns that were never explicitly structured: Rachel Torres at TechFlow overlapped at Stripe with your contact Maria Gonzalez. Potential warm introduction. That connection exists in the data. No one had to enter it into a “Relationships” table.
There’s a deeper point here about why CRM structures look the way they do. Contacts, Accounts, Opportunities, Activities — these aren’t derived from how salespeople think. They’re derived from how relational databases normalize data. The CRM’s information architecture was shaped by its storage layer. A file-first system inverts this: the structure emerges from the work, not from the database schema. If a seller’s mental model puts stakeholder politics at the center of a deal, the files can reflect that. If another seller thinks in terms of technical evaluation milestones, their files reflect that instead. The system molds to the person, not the other way around.
Skills as Capability Upgrades
Here’s where the file-based architecture unlocks something that rigid systems can’t offer.
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 — packaged, transferable, instantly installed.
Skills in a file-based system work the same way. A skill is a package of domain knowledge — markdown files containing methodology, frameworks, heuristics, and instructions — that an agent can read and immediately apply to the vault. Install a competitive-intelligence skill and the agent can research competitors, build differentiation matrices, and generate talk tracks. Install a deal-qualification skill and it assesses any deal against MEDDIC or BANT. Install a contract-review skill and it can analyze vendor agreements against a configured playbook.
The skill is human-readable before it’s machine-executable. A domain expert authors it by writing a document — describing how to think about a problem, what to look for, how to structure the analysis. No API integration, no custom object configuration, no developer required. The skill is just files. The vault is just files. The agent reads both.
This creates a composability that traditional platforms can’t match. A B2B sales team working complex enterprise deals installs account-research, stakeholder-mapping, deal-strategy, and competitive-intel skills. A different team selling to SMBs installs high-velocity-prospecting and pipeline-management. A customer success team working from the same vault architecture installs health-scoring and renewal-playbooks. Same substrate, same agent, radically different capabilities.
And because skills are files, the upgrade path is frictionless. A better version of the forecasting skill doesn’t require a product update, a database migration, or a restart. Replace the files. The agent reads the new version on its next invocation. The system just got smarter in the time it took to sync a folder.
This is what rigid, table-based systems fundamentally can’t do. When your data model and your intelligence layer are both locked inside a product, every change to how the system thinks requires the vendor to ship it. When both are files that an agent reads, the surface area for improvement is open — to the vendor, to the team, to the community, and to the seller themselves.
The Interface: Light and Fast
If the files are the data layer and the agent is the intelligence layer, the CRM product itself becomes something different: a lightweight interface that makes the vault interactable.
Not a platform that does everything. A tool that does a few things extremely well: showing the seller what matters right now, making the relationship graph spatial and navigable, surfacing the agent’s insights where they’re useful, and getting out of the way.
Think of it less like Salesforce and more like the instrument panel of a car. The car’s engine (the agent) does the heavy work. The fuel (the vault) powers it. The dashboard just shows you what you need to see — speed, direction, warnings — clearly enough that you can keep your eyes on the road.
A skilled B2B seller’s day moves fast. They need to glance at their pipeline and know where to focus. Pull up a contact and see the full relationship picture in seconds. Prep for a call without digging through three systems. Fire off a follow-up without context-switching. The interface should match that tempo — fast, opinionated about what matters, and unburdened by the configuration overhead that makes enterprise CRMs feel like they were designed for the administrator, not the seller.
Starting Over
Five design choices, reconsidered:
Local-first, not cloud-first. The seller owns their data. Personal relationship intelligence is portable across their career. The institution gets a sync layer for shared context. The incentive alignment that made the Rolodex work is restored.
Agent alongside, not agent inside. The intelligence layer improves at the pace of AI progress, not at the pace of product releases. The CRM handles the steady-state features. The agent handles everything that benefits from getting smarter over time.
Files, not tables. Human-readable, agent-parseable, extensible without permission. The structure emerges from the work, not from the database schema. A knowledge graph forms from linked documents, not from normalized tables.
Skills, not features. Capabilities are composable, swappable, and authored in plain language. The system molds to the team’s methodology, not the other way around.
Light interface, not heavy platform. A fast, focused tool for making relationship data actionable — not a configuration engine that tries to be everything for everyone.
None of these are new ideas in isolation. Local-first software has a thriving community. File-based knowledge management has millions of users. AI agents are improving weekly. The opportunity is in the combination — and in the willingness to abandon thirty years of assumptions about what a CRM should be.
The skilled B2B seller has always known how to manage relationships. They’ve just never had a system that worked the way they do.