You’ve probably nodded along when someone says “Markdown is the answer for agent memory.” Karpathy says it. Google says it. The guy who writes 37,000 lines of code a day says it. And you — yes, you, the engineer who just wants something that works — you’re about to cargo-cult a solution that doesn’t match your problem.
Markdown isn’t a solution. It’s a lowest-common-denominator format that works precisely because it avoids solving the hard parts of structured data management.
The real story isn’t who’s right. It’s that everyone is solving a different problem and calling it the same name. Karpathy uses Markdown to serialize agent thoughts into a readable log. Google uses it as a lightweight data interchange layer between microservices. Tan uses it to generate entire web apps from scratch. They all say “Markdown works” — but the work it does is fundamentally different in each case.
Here’s the twist: the false consensus is more dangerous than any single wrong decision. When you hear “Markdown is the answer,” your brain shuts off. You stop asking what problem you’re actually trying to solve. You start copying patterns that belong to someone else’s architecture.
Let’s get specific. I’ve seen teams build agent memory systems using Markdown as a flat-file store. They hit a wall at 10,000 entries. Why? Because Markdown has no schema enforcement, no indexing, no versioning. It’s a string with some syntax. You wouldn’t use a text file as your production database. Why are you using Markdown as the brain of your AI?
The comment about Tan writing 37,000 lines of code a day isn’t a flex — it’s a distraction. It taps into your status anxiety. You feel like you have to pick a side in a tech celebrity rivalry, so you stop evaluating the actual technical trade-offs. That’s how cults form, not how engineers build reliable systems.
What should you do instead? Start by defining your real constraints: Do you need human readability? Machine parseability? Low latency? High durability? If you need all three, Markdown isn’t your answer — it’s your starting point for a conversion problem. Use a structured format for the machine part (protocol buffers, JSON, binary) and render to Markdown only for human consumption. Don’t confuse the presentation layer with the storage layer. That’s a mistake that scales into a disaster.
The smartest engineers I know are the ones who resist the urge to agree with everyone. They see consensus as a red flag. When Karpathy, Google, and Tan all say the same thing, it means they’re all talking about different things. Your job is to find the problem you’re actually solving — and then choose the tool that fits it, not the tool that has the most famous fans.
Markdown is a hammer. But not every AI memory is a nail. Stop glazing. Start thinking.
FAQ
Q: If Markdown is so bad, why do so many smart people recommend it?
A: They don't all recommend it for the same reason. Karpathy uses it for debugging logs, Google for lightweight serialization, Tan for code generation. The consensus is an illusion — each expert is solving a different problem. Don't copy their tool without understanding their constraints.
Q: What's the practical implication for my agent memory system?
A: Stop treating Markdown as a universal storage format. Use it only as a human-readable output layer. For actual persistence and retrieval, pick a structured format with schema, indexing, and versioning — like SQLite, Protocol Buffers, or a vector database. Your agent's memory deserves more than a text file.
Q: Isn't the 'Markdown is a trap' argument just contrarian for the sake of it?
A: No, because the trap is real: false consensus causes cargo-cult engineering. The contrarian take is actually the pragmatic one. If you evaluate Markdown against your actual needs—latency, reliability, parseability—you'll quickly see it fails under pressure. The real contrarians are the ones nodding along without asking what problem they're solving.