Your CRM is a folder of markdown files — here's how it actually works.

I've been a CRM consultant for 15 years. In that time, I've watched more CRM implementations fail than succeed. And the reason is almost never the technology. It's that nobody uses the thing.

After a sales call, the last thing anyone wants to do is update five different fields in Salesforce. So they don't. Data goes stale. Pipelines become fiction. The CRM slowly dies — not from a scaling problem, but from an adoption problem.

Then I came across Andrej Karpathy's “LLM Wiki” gist, and it changed how I think about this entirely.

What if the CRM is literally just a bunch of markdown files? And an LLM sits on top, takes whatever you write in natural language, and turns it into structure — linking contacts to companies, deals to interactions, tasks to follow-ups — automatically?

I built it. It's open source. And it's weirdly usable.

The problem with every CRM you've used

We don't think in fields. We think in sentences. “Spoke to Rahul. Interested in WhatsApp automation. Follow up next Tuesday.”

That's everything you need. But CRMs force you to break that into pieces — open the contact record, update the “last contacted” field, change the deal stage dropdown, create a task with a due date, add an activity note. Five clicks minimum, across three screens.

The friction isn't a UX problem. It's a fundamental mismatch between how humans communicate and how databases store information.

When LLMs got good enough, my first instinct was the same as everyone else's — RAG pipelines, graph databases, natural-language querying on top of existing CRM schemas. I even looked at Neo4j.

But then I saw Karpathy's LLM Wiki idea, and I paused.

What if we're overcomplicating this? What if the storage layer itself is just text files, and the LLM is the intelligence layer that creates and maintains the structure?

How the LLM Wiki CRM actually works

The architecture is almost aggressively simple:

├── CLAUDE.md              # LLM instruction set (the "brain")
├── _templates/            # Entity templates with YAML frontmatter
├── _inbox/                # Drop raw notes here
├── _dashboards/           # Dataview queries for reporting
├── contacts/              # One markdown file per contact
├── companies/             # One markdown file per company
├── deals/                 # One markdown file per deal
├── interactions/          # Meeting/call/email records
├── tasks/                 # Follow-up action items
└── wiki/                  # Index and activity log

Every entity is a markdown file with YAML frontmatter (queryable metadata) and [[wikilinks]] for cross-referencing. Contacts link to companies. Deals link to contacts. Interactions link to everything.

The four workflows

1. Ingest — Drop a meeting note into _inbox/. Tell the LLM to process it. It extracts contacts, companies, deals, interactions and tasks — creating or updating files automatically. A single meeting note typically generates 5–10 linked pages.

2. Query — Ask “What's our pipeline value?” or “Who are our warmest leads?” The LLM synthesises answers across all your markdown files with citations.

3. Update — Say “Move the Acme deal to negotiation” or “Mark Jane as inactive.” The LLM finds the right file, updates the frontmatter, and logs the change.

4. Lint — Request a health check. The system scans for stale deals, missing data, broken links, overdue tasks, and orphan pages — generates a report with suggested fixes.

What surprised me: I actually keep it updated

I actually use this CRM. I'm not “doing data entry.” I'm just writing things down. The same notes I'd write anyway after a call. And because everything is linked, context builds itself. Things start connecting on their own instead of being forced into fields.

At some point it stops feeling like a CRM and more like a system that just… understands what's going on. For managing 30–50 clients as a solo operator or small team, it genuinely works.

The objections (I've heard them all)

“LLMs aren't deterministic. This is a compliance nightmare.”

Fair. An LLM processing the same input twice might produce slightly different output. For a regulated financial services firm, that's a non-starter.

But most CRM failures I've seen weren't compliance problems. They were nobody-enters-data problems. If you're choosing between a perfectly structured CRM with stale data and a markdown CRM with current data — which one is actually more useful?

“This doesn't scale. What about hundreds of files?”

Context-window question. For the size where most CRMs actually fail (5–50 users, a few hundred contacts), you're nowhere near the limit. The architecture is also designed to evolve — you can add a RAG retrieval layer or a structured backend underneath without changing the input experience.

“Two people editing the same deal record = chaos.”

This is the real limit. The moment you need multi-user access with permissions, audit trails and conflict resolution, you're building an application whether you planned to or not.

I'm not pretending this replaces a properly implemented SuiteCRM for a 50-person sales team. What it does is serve the huge gap below that — solo operators, founders, small teams — who need pipeline visibility but won't maintain a traditional CRM.

“You'll end up rebuilding a CRM anyway.”

Probably. But the question isn't whether you'll eventually need structure. It's: can you get a really strong capture layer before you hit that complexity wall?

Once you have clean, current data — even in markdown — migrating it into a structured system is trivial. The hard part was always getting people to enter the data in the first place.

The tech stack

• Obsidian — local-first markdown editor with relationship visualisation.
• Dataview plugin — query engine for YAML frontmatter.
• Templater plugin — dynamic page templates for consistency.
• Any LLM agent — Claude Code reads CLAUDE.md, Cursor uses the same file. Model-agnostic.
• Git — version control. Every change tracked. You can diff your pipeline over time.

Who this is for

• Solo consultants and founders managing 20–50 client relationships.
• Small sales teams who tried Salesforce/HubSpot and abandoned it within 3 months.
• Developers who want a CRM they can inspect, version-control, and extend.
• Anyone whose “CRM” is actually a spreadsheet or scattered notes.

If you have 50+ users and need RBAC, audit logs, and compliance reporting — you need a real CRM system. We build those too.

The bigger idea

The future of CRM isn't more dashboards, more fields, more automation rules. It's a system where the input is completely natural language, the structure emerges automatically, and the human never has to think about “updating the CRM.”

The human's job: source leads, build relationships, close deals, think strategically. The LLM's job: everything else.

It's not AI on top of a CRM. It's a CRM that only exists because of AI.

FAQ

Can this replace Salesforce?

No. If you have 50+ users, complex workflows, compliance requirements, and reporting needs — you need a production CRM. This is for the gap below that.

What LLM does it work with?

Any LLM agent that reads instruction files. Claude Code reads CLAUDE.md, Cursor uses the same file. Model-agnostic.

Is my data safe?

Your data never leaves your machine. Everything is local markdown files. No cloud sync, no third-party servers, no API calls to external services. Version control via Git gives you full history.

How many contacts can it handle?

Tested with 50+ contacts, 30+ companies, and 100+ interactions without issues. Practical limit depends on your LLM's context window.

Can I migrate to a real CRM later?

Yes. Because all data is structured YAML frontmatter, exporting to CSV or importing into SuiteCRM, HubSpot or any other system is straightforward.

Is this just “Notion as a CRM” again?

No. Notion-as-CRM still requires manual data entry into databases. This inverts the model: you write natural language, the LLM creates and maintains the structure. The input experience is fundamentally different.