There's a quiet panic happening in SaaS right now. Valuations are compressing, usage-based pricing is replacing seats, and every founder in the space is asking the same question: what happens when AI agents can do the work my product charges humans to do?
Most of the conversation has centered on vertical SaaS and point solutions -the low-hanging fruit. The conventional wisdom is that systems of record are safe. Nobody is going to vibe-code a CRM. Nobody is going to prompt their way into an ERP.
@akothari put it well in a recent post: "You're right that most companies will not vibe code their system of record."
But then he makes the more interesting point -the question isn't whether companies replace Salesforce. It's whether your software can exist in the agentic ecosystem at all. Can agents read from it? Write to it? Operate autonomously within it? If not, your customers will eventually go somewhere they can.
Meanwhile, @karpathy coined "agentic engineering" the idea that the new default is you're not writing code directly, you're orchestrating agents and acting as oversight.
He's talking about software development, but the pattern applies everywhere. The CLI is having a moment. Terminal-first, agent-operated workflows are becoming a legitimate way to build and run systems. Not just for coding , for everything.
I didn't set out to prove any of this. I set out to solve a much smaller problem. I run a small venture fund, and the operational chaos of fund management: emails from founders, intro calls, pitch decks, WhatsApp threads, meeting notes, follow-ups was scattered across a CRM, Google Docs, email, and my head. The moment I wanted AI to help me reason over any of it, I hit a wall. The CRM had an API, sure, but getting an agent to authenticate, paginate, map fields, and handle rate limits for what amounts to "read this contact record" was absurd. So I tried something different.
I built the whole system on flat files and git. And it worked. And now I don't use the CRM at all.
Why Markdown Is the Agent Interface
Here's something that doesn't get talked about enough: the best interface between a human and an AI agent isn't a GUI and it isn't an API. It's a plain text file.
Think about it. Every operating system in history has been built on the same primitive: files and processes. Unix got this right 50 years ago. Agents are just processes. And the most natural thing for a process to do is read a file, do some work, and write a file.
Markdown specifically is the sweet spot. It's structured enough that an agent can parse it reliably. It's readable enough that a human can open it and immediately understand what they're looking at. And it's flexible enough to hold everything from a structured YAML header to freeform meeting notes.
In my system, every entity, every person, company, deal, project is a folder. Inside that folder:
The `meta.yaml` is the structured record. It looks like this:
That's it. That's the "database record." An agent can read it with `cat`. Search across all entities with `grep`. Update a field by editing a text file. No SDK, no auth tokens, no field mapping, no pagination. The entire knowledge base is just files in a directory.
Compare that to the CRM workflow: authenticate with OAuth, call the contacts API, paginate through results, map their proprietary field schema to something useful, handle rate limits, write back through another API call. For what? To read a name and a status.
Git as the Database
This is where it gets interesting. Once your data is in flat files, git gives you a complete database layer for free.
Every commit is a transaction. When an agent processes an inbound email and creates three new entities, links them together, and logs the meeting notes, that's one atomic commit. It either all lands or none of it does.
Every diff is an audit log. Want to know who changed a deal's status from "evaluating" to "passed" and when? `git blame`. Want to see the full history of every interaction with a founder? `git log entities/jane-doe-2025/`. The audit trail isn't a feature you bolt on it IS the system.
Branch protection is access control. Human-instructed actions commit directly to main. Agent-inferred actions, things the agent decided to do on its own must open a pull request. Destructive actions like deleting an entity or merging duplicates? Pullrequest, always, even if a human asked for it. The decision tree is simple:
That's your RBAC. That's your destructive-action guardrail. That's your compliance audit. And it's all built into git a tool that's been battle-tested for 20 years.
Schema validation runs on every commit. A pre-commit hook checks every `meta.yaml` against the schema: required fields present, status values valid for the entity type, relationship references pointing to entities that actually exist, dates in ISO format. Invalid data gets rejected before it lands. This is the equivalent of database constraints, except the "migration" is editing a Python script and the "schema" is a YAML template in a markdown file.
Here's what the commit log looks like in practice:
Every commit is typed and tagged. You can reconstruct the entire history of a deal from the git log.
Ingest: Where This Gets Powerful
This morning I had a 45-minute intro call with a founder. Afterward, he sent me a pitch deck, a research paper, and an FAQ document. Here's what happened next.
I handed the call transcript, the email thread, and the three PDFs to the agent. In a single session, it:
1. Ran entity resolution -searched every existing entity for matching names, emails, and domains to avoid creating duplicates
2. Created 6 new entities -the founder, his co-founder, the company, the deal, and two referral sources
3. Cross-linked all relationships -the deal points to the company, the company's `founded_by` points to the founders, the referral source is captured as a person entity linked to the deal
4. Logged the full meeting notes with a structured summary, key observations, and next steps
5. Saved the email thread as an email log with contact information extracted
6. Extracted text from all three PDFs and saved them as searchable markdown in `docs/`
7. Uploaded the original PDFs to S3 with a standardized naming convention
8. Updated every `meta.yaml` with asset references and `last_activity` timestamps
9. Committed everything in one atomic commit and pushed
That entire workflow -entity creation, relationship mapping, document processing, asset management, and data entry -took about 90 seconds. In a CRM, the data entry alone would have taken 20-30 minutes. And nobody wanted to do it, which is why CRM data is always stale and incomplete.
The key insight: ingest is easy when the target format is markdown. The agent doesn't need to learn an API. It doesn't need custom integrations for each intake channel. It reads the input (email, transcript, PDF), extracts the structured data, and writes files. That's it.
Materialized Views: The AI Generates Its Own Summaries
Every entity accumulates raw materials over time -meeting notes, email threads, document extracts, status changes. Reading through all of that for every deal review would be brutal. So the system generates its own summaries.
A GitHub Actions cron job runs daily, calling the Claude API for each active entity. It reads all the raw files -`meta.yaml`, every note, every email, every doc -and generates a `summary.md` in the entity's `materialized/` directory. These summaries are never hand-edited. They're regenerated from scratch every time, so they're always fresh and always reflect the complete picture.
Here's what an auto-generated deal summary looks like:
The system tells me what I need to pay attention to. It flags missing follow-ups, pending uploads, stale entities. The materialized views aren't just summaries -they're an AI-generated operational dashboard, rebuilt from raw data every day.
Could this run after every commit instead of daily? Yes -you can trigger the GitHub Action on push. The trade-off is cost (an API call per entity per update), but architecturally there's nothing stopping real-time materialization.
The Hard Part: You Need a Good Agent
Here's the honest section. Everything above sounds clean and elegant. But the system's integrity depends entirely on the agent following the rules. And getting those rules right was the hardest part of the whole build.
We wrote a file called `CONVENTIONS.md`. It's the soul of the system. It defines:
Slug naming rules -people get `firstname-lastname-YYYY`, deals get `company-name-round`, companies never get a year suffix. Slugs are permanent. Never rename them. They're the foreign keys that hold the entire relationship graph together.
Schema rules -every entity type has specific allowed status values. A deal can be `sourced | evaluating | terms | closed | passed`. A company can be `tracking | inbound | active-diligence | passed | invested | exited`. Invent a new status value? The pre-commit hook rejects your commit.
Entity resolution protocol -before creating any entity, the agent must search for matching signals (email address, domain, name) across existing entities. Two signals match? Route to the existing entity. One signal match? Stop and ask the human. Zero? Create new. A bad merge is worse than a delayed record.
Commit format -every commit is typed: `[intake]`, `[meta]`, `[enrichment]`, `[materialized]`, `[admin]`. The em-dash is required, not a hyphen. This matters because you reconstruct deal history from the git log.
The PR decision tree -when to commit directly vs. when to open a PR. This is the access control layer, and it's defined in natural language, not in IAM policies.
The conventions file is about 600 lines. It took multiple iterations to get right. Every time the agent made a mistake -created a duplicate, used a wrong status value, forgot to update a cross-reference -we added a rule. The file evolved the same way database constraints evolve: through failure.
This is the thing I'd emphasize to anyone building an agent-native system: the conventions file IS the schema. It's the equivalent of your DDL, your constraints, your triggers, and your access policies -all expressed in natural language that an agent can read and follow. Writing it well is the difference between a system that works and one that slowly corrupts.
The pre-commit hook catches the mechanical stuff -invalid YAML, wrong status values, broken references. But the agent's judgment calls -should this be a new entity or an update to an existing one? Is this a `tracking` or `inbound` company? -those depend on how clearly you've written the rules.
What This Means for Systems of Record
Back to the tweet, and the question everyone's debating: are systems of record safe?
The conventional wisdom says yes. CRMs are too complex. ERPs are too entrenched. Nobody's going to vibe-code their way to replacing Salesforce.
And that's true. But it's also the wrong framing. The threat to systems of record isn't that someone builds a replacement. It's that agent-native architectures make certain categories of software unnecessary.
When your AI agent can read a markdown file faster than it can authenticate to an API -the data format matters. When git gives you versioning, audit trails, access control, and atomic transactions -the database becomes optional. When the agent can generate its own summaries and dashboards from raw files -the reporting layer becomes a commodity.
My system has real limitations. The interaction layer is a terminal and a code editor -there are no dashboards and no drag-and-drop. That's fine for a two-person fund; it's a non-starter for a 500-person sales org today. But a UI is just an engineering layer on top of the same flat files. The architecture doesn't care how you access it.
The deeper point is this: we've spent 25 years building software that helps humans interact with data. The next era is software that helps agents interact with data. And agents don't need a GUI. They don't need a beautiful pipeline view. They need files they can read, rules they can follow, and a version control system they can commit to.
The companies that figure this out -that position themselves as the data layer in an agentic stack rather than the human interface on top of a database -those are the ones that will thrive. The ones that are just a UI sitting on top of a proprietary data store, charging per seat for access that an agent doesn't need? They have a problem. Not today. But soon.
---
_I gave a talk on this yesterday @AITinkerers titled `rm -rf salesforce`. The system is real, it's running in production, and it processes every deal, meeting, and relationship in our fund. If you're building something similar or thinking about agent-native architectures, I'd love to hear about it._
_P.S. Yes, I am aware that I built a system where the agent is the primary user and I'm the second-class citizen who occasionally gets to type things into a terminal. I'm fine with it. The agent does better data entry than I ever did._