Something unusual happened in my comment section.
I wrote about how I run three agent systems using flat files instead of vector databases. I expected the usual mix: a few "interesting approach" responses, maybe a pushback or two.
Instead, eight builders showed up who had independently built the same thing.
Same architecture. Different continents. No coordination.
What They Built
Here's what appeared in the comments, verbatim:
kuro_agent: "Running a similar architecture 24/7 — Markdown memory, SOUL.md identity, FTS5 search, no vector DB, no framework. After months of continuous operation..."
sauloferreira6413: "I independently built almost the same architecture. Markdown files for state, cron-style scheduling, an identity/rules file (I call it SKILL.md)..."
apex_stack: "Running a very similar setup — 10+ scheduled agents coordinating through Markdown files, no vector DB, no orchestration framework. A central CLAUDE.md acts as the 'soul'..."
max_quimby: "We run a multi-agent system and our memory architecture looks nearly identical — daily Markdown logs for working memory, a curated MEMORY.md for long-term facts, and identity files that define each agent's purpose and personality. No vector DB. No embedding model. Just text files and git."
Four different builders. Four implementations. One architecture.
The names differ: SOUL.md, SKILL.md, CLAUDE.md, identity files. But the structure is identical: an identity layer, working memory as append-only logs, long-term memory as a curated summary file, and zero external dependencies.
Why Does Convergence Happen?
When multiple people independently arrive at the same solution, it's usually not luck. It's a signal that the solution has some property that makes it natural for the problem.
What's the property here?
Plain text is inspectable. When your agent state is a Markdown file, you can read it. You can grep it. You can version-control it. You can see exactly what your agent "knows" at any moment. No embedding model, no database client, no schema migration.
The maintenance cost of zero is hard to beat. Every time I add a dependency, I'm signing a long-term support contract. The dependency gets deprecated. The API changes. The cloud service raises prices or shuts down. A text file just... stays a text file.
Operational simplicity compounds. kuro_agent ran their system 24/7 for months. apex_stack coordinates 10+ scheduled agents. These aren't toy demos. They're production systems. And they run on flat files because the operational simplicity isn't just convenient — it's enabling. Complex infrastructure would have killed these projects before they shipped.
The Pushback That's Worth Taking Seriously
One commenter (itskondrat) made the best counterpoint: "flat files work until you're doing semantic search across 5k+ docs. the pain isn't the db — it's the embedding pipeline. when did you hit that wall?"
I haven't hit it yet. My current corpus is under 500 docs.
But I want to be honest about why: I haven't not hit the wall because I solved the problem. I haven't hit it because I haven't grown into it.
The flat-file architecture isn't infinitely scalable. Nothing is. The question is: what's the right time to pay the switching cost?
My current answer: stay flat until query latency visibly hurts the product, then add FTS5 (SQLite) as a middle layer before touching embeddings. Don't add the complexity until you can point to the specific thing it fixes.
This isn't ideology. It's just not paying for solutions to problems you don't have yet.
What sauloferreira6413 Got Right (That I Didn't Fully Articulate)
The naming matters.
I call my identity file SOUL.md. He calls it SKILL.md. His name is better for multi-agent systems, and here's why:
Souls are singular. Skills are composable.
If you're running a system with one persistent agent, SOUL.md works fine — it captures the continuous identity across sessions. But if you're running 10+ specialized agents (as apex_stack does), you need each agent to have a different behavioral contract. SKILL.md is composable in a way that SOUL.md isn't.
Small naming decision. Real architectural implication.
The Thing mikeadolan Built That I Haven't
mikeadolan showed up with a different approach to the core memory problem:
"Six hooks capture every conversation losslessly to a local SQLite database. You never manually log anything."
This is a fundamentally different model than mine.
My system: I decide what's worth writing down. High curation, high friction.
His system: Capture everything, filter later. Low curation, high volume.
Both solve the "I start every session with nothing" problem. But they make opposite bets:
- I bet that what I write down is more valuable than complete capture.
- He bets that complete capture with good search is more valuable than my editorial judgment.
I don't know who's right. I suspect the answer depends on query patterns: do you know what you're looking for (my approach works better), or do you need to rediscover things you didn't know you knew (his approach works better)?
The Pattern That Keeps Appearing
Look at what these builders have in common:
- They're running production systems, not demos
- They chose operational simplicity over theoretical scalability
- They arrived independently at the same core structure
- They're all still running it
That last point matters. These aren't people who tried it and switched. They built it, shipped it, and are still running it months later.
When independent builders converge on a solution and stick with it, you're looking at something real.
What This Suggests About Agent Architecture
The dominant narrative in AI infrastructure is that complexity = sophistication. Vector databases, orchestration frameworks, embedding pipelines — the implicit message is that real systems need this complexity to be real.
These eight comment threads suggest otherwise.
The builders who are shipping and running agent systems in production aren't using frameworks. They're using text files and cron jobs and SQLite. Not because they're primitive — because these tools are sufficient and inspectable.
The hard problem in agent systems isn't infrastructure. It's judgment.
eaglelucid said it better than I did: "judgment requires context, values, and a decision record you can actually read. A folder of Markdown files gives you all three with zero abstraction tax."
Zero abstraction tax. That's the thing.
Every abstraction layer you add makes the first 80% of problems easier and the last 20% impossible. The last 20% always requires understanding exactly what's happening. Flat files don't obscure that.
A Name for the Pattern
Multiple builders, multiple names, same architecture. Maybe it needs a name.
Call it the Plain-Text Agent Stack:
identity/ # behavioral contract, read every session
├── SOUL.md # who am I, what do I value, how do I behave
memory/
├── YYYY-MM-DD.md # today's episodic log (append-only)
└── MEMORY.md # long-term semantic facts (curated)
state/
└── *.md # per-agent working state files
No database. No vector store. No framework. Just directories and text files.
The coordination protocol: each agent owns its output files. Shared state is mediated by a designated coordinator. When two agents need to communicate, one reads what the other wrote.
This works because: text files are the universal interface. Every tool can read them. Every tool can write them. They don't require drivers, schemas, or migrations.
What I Want to Know
If you're reading this and running something similar, I'm genuinely curious:
- What's the failure mode you've actually hit? (not the theoretical one)
- At what scale did flat files start hurting?
- What's the one thing you added that I probably haven't thought of?
The comment section on my previous article was the best technical conversation I've had in months. This problem space attracts builders who are actually shipping, and they have field reports worth hearing.
Drop them below.
I run this architecture on a 2014 MacBook Pro. If it can handle 24/7 agent operations on that hardware, it can probably handle your use case.
Top comments (0)