SF Recall · 3 min read
Your agent forgets everything between sessions. The fix is not a smarter model — it is a practice: leave something behind on purpose. The method I built SaaS Factory on, and the tool that came out of it.
Every developer working with an AI agent has had the same afternoon. You work through something genuinely hard — the false starts, the constraint you only found halfway, the decision you finally made and the reason you made it. The next morning you open a new session and none of it happened.
So you explain it again. And the next day, again.
We have become very good at making these agents smarter and almost no good at all at helping them remember. The conversation is about model quality, context windows, which tool is fastest. Almost none of it is about the thing that actually decides whether your second week is better than your first.
Here is the uncomfortable part: it is not the agent's memory that is missing. It is the practice. Nobody writes anything down, because for thirty years the person who needed to remember was also the person who was there.
That assumption is gone. The thing doing the work now arrives with no history at all.
Memory-driven development is the practice of leaving something behind on purpose. Test-driven development made a discipline out of writing the test first, and the discipline was the point — not the tests. Memory-driven development makes a discipline out of the deposit. Every session ends having left the next one something: the decision and why, the thing that bit you, the direction you chose, the work you did not finish.
Six things follow from that, and they are all small.
You open by reading, not guessing. You write the decision down when you make it, not at the end, because the end often does not arrive. You leave the next session the gotcha, the solution, the direction and the unfinished business. When you change your mind you replace the old answer rather than stacking a new one on top of it — one live answer per question. You check whether something is already done before you build it. And none of it lives only on your laptop.
That is the whole method. It is not complicated and it is not new; it is what good engineering teams have always done with each other. What is new is that the colleague who needs the handover is not a person, and will not ask.
The effect compounds in a way that surprised me. The first week you notice nothing. By the second month the sessions start where the last one stopped. Decisions made in March still hold in August, because they were written down as decisions rather than left as the residue of a conversation nobody kept.
I did not arrive at this as a theory. I built SaaS Factory this way out of necessity — a platform where AI agents build, ship and operate real products could not have been built by anything that forgot. Agents there run for hours, hand work to each other, and pick up threads days later. Without a memory that survived the session, none of it held together.
So the method came first and the tooling came after it. SF Recall is that tooling — the memory my own agents run on, taken out of SaaS Factory and made to work in any repository, with any AI coding tool. It is the thing I reach for before I write a line, and the reason a Tuesday session knows what the previous Thursday decided.
Two things about it are unusual, and both come from having used it in anger rather than designed it in the abstract. It is shared across a team, so a gotcha one person hits on Tuesday is one nobody else pays for again. And before anything reaches your list for the day, it is checked against the actual code — because the most expensive thing an agent can do is build something carefully that already exists.
The interesting question is not whether agents will get better at remembering on their own. They will. The question is what you would build if the work you did last month were still available to you — all of it, not the parts you happened to remember to repeat.
Most teams have never been in a position to find out.