Most agent demos are amnesiacs. They're brilliant for the length of one conversation and then the window closes and everything they knew about you, about the work, about the mistake they made an hour ago, is gone. People paper over this with bigger context windows, but a bigger window is just a longer leash on the same dog. The moment the session ends, the dog forgets your name.
I ran into this the first week I started building seriously, and I decided early that I didn't want a smarter chatbot. I wanted a system that woke up tomorrow knowing what it learned today. That one decision shaped almost everything I've built since.
Memory belongs outside the model
The mistake I see most often is trying to keep memory inside the model. In-context memory, fine-tuning, clever prompt-stuffing. It feels right because the model is the smart part, so surely the memory should live next to the intelligence. It's backwards. The model is the part you want to be able to swap out. If your system's memory dies the day a better model ships, you don't have a system. You have a dependency.
So I moved the memory out. The agents in my system read and write durable state through plain files under version control, retrieve older knowledge from a vector database I run myself, and reach the model through a gateway I can repoint at a different provider in an afternoon. The intelligence is rented. The memory is owned. Swap the model tomorrow and everything the system has learned is still sitting right where I left it.
Append-only beats overwrite
The second thing I learned is that you almost never want an agent to edit its own history in place. Overwriting state is how you lose the thread. If an agent rewrites a fact and gets it wrong, the old truth is gone and you can't tell what happened.
The fix is boring and it works: append, don't overwrite. The session log is a ledger, not a whiteboard. Every meaningful change gets committed, so I can read back exactly what the system believed and when it changed its mind. When it learns the wrong lesson, and it does, I can roll it back to the commit before it went sideways. The whole thing becomes legible instead of mysterious.
Verify the state, not the report
Here's the one that cost me the most hours before I caught it. When one part of the system tells another what it did, that's a report, not the truth. A note that says "I updated the config" is a claim. The config file is the fact. Early on I trusted the reports, built work on top of them, and spent whole evenings chasing a problem that a single check of the actual file would have caught in ten seconds.
Now the rule is simple. Before acting on a report of state, read the state. It's usually one command. The cost of skipping it scales with everything you build on top of the lie.
Why this is the FDE problem in miniature
A forward-deployed engineer doesn't get to leave a demo behind. The whole job is building something that keeps running after you walk out of the room. That's continuity. That's an agent that remembers the customer's domain next week as well as it did the day you wired it up.
I've been solving that on my own infrastructure for about a year, because I was my own first customer and I'm a demanding one. The memory layer is the part I'm proudest of. It's the difference between a clever script and a system with a past.
← More field notes · Want to talk it through? Get in touch →