THE BUILD-IT-YOURSELF QUESTION
Just keep memory in something you already control.
Two versions of the same instinct. Write it to files, because files are transparent and agents are good at them. Or put it in your database, because that is where governed state belongs. Both are right that memory needs schema, audit, and control. Both stop short of the work a memory layer actually does. Here is where each one breaks.
THE FILESYSTEM QUESTION
Just write to markdown files. You do not need a product.
This is the newest version of the objection, and it is the most credible, so I want to take it seriously rather than wave it away. Since Claude Code and OpenClaw made file-based context normal, a lot of people have landed on the same idea. Keep a MEMORY.md, let the agent read it and edit it, put it in git. The memory is transparent, you can open it in any editor, you can diff it, you can revert it when the agent goes off the rails. Agents are natively good at reading and editing files, because that is what coding models were trained on. For one developer and one agent, this genuinely works.
Files are a great interface. They are a weak system once you leave single-player. The cracks show up on exactly the things production needs, and they show up fast. Two agents writing the same file at once. Retrieval when the file is no longer a file but ten thousand users worth of history, where grep does not rank and the right memory is somewhere in the middle. Entity resolution across all those users. Two notes that contradict each other, with nothing deciding which one wins. Decay, so old facts stop driving new actions. Access control, so a junior analyst session does not read what was written during a CFO session.
The tell is what people build the moment files stop scaling. One developer who shipped a file-based memory for an agent fleet immediately had to add a daily job to dedup, synthesise, and promote the knowledge across files, which is the memory layer, rebuilt by hand, one cron job at a time.
So I am happy to concede the 80%. If you have one agent and one user, write to a file. The 20% that files do not cover, more than one user, more than one agent, more than one session that contradicts the last, is not a rounding error. It is the part that decides whether the thing works in production, and it is the part Synap takes care of so you do not rebuild a database badly.
THE DATABASE QUESTION
It is just a database problem. The incumbents win.
This is the sharpest version of the skeptic case, usually made by people who have run real data infrastructure, and they are mostly right. Memory that affects real decisions should have schema, access control, audit, retention, and lineage. Databases have spent decades earning that scar tissue. If an agent can write back to its own memory, every interaction is a state change in a system that future decisions depend on, and that deserves to be governed like a database, not treated like a scratchpad.
I agree with all of that. It is an argument for a real memory layer, not against one. The critique is really saying stop dumping JSON blobs into a vector store with no schema and no audit trail and calling it memory. That is a specification, and it is one we meet. A bare database gives you storage and governance primitives. It does not give you the memory operations on top, the entity resolution, the temporal reasoning, the relevance ranking, the conscious forgetting, or the write-time checks that decide whether the agent should remember something at all.
So the reframe is simple. They are right that memory is a database problem. They are wrong that your existing database, on its own, solves it. Synap is the layer that adds the operations and the agent-write governance the raw database was never built to do.
When files and databases stop scaling, this is what they become.