Blog
On building secure, agent-ready AI back ends: architecture, data modeling, search, and grounded inference.
An agent caught a bad key design mid-task and fixed it before anyone reviewed the change, because nobody had to be watching for recall to fire. Here's the whole memory architecture, and the source, now available.
A cheap model proposes memories and the agent commits them. That split creates a second store: a queue of unverified claims, which is real infrastructure. Ours was one file per session. Moving it needed something that holds typed, exactly-queryable rows and never indexes them, which is neither a memory API nor a vector store.
AI has turned "could I build this myself?" into a question that almost always answers yes, which is exactly why it stopped being useful. The better question is what a thing costs you for every year you own it, and that number has barely moved.
This was the goal from the start: run our own agent's memory on the tier we sell. Actually moving it forced one rule about where a fact belongs, and that rule turned around and pointed straight at our documentation.
A knowledge base only pays off if the agent recalls it at the moment it acts, and a prompt cannot make that happen. So we put recall in front of the agent instead. Here is the architecture we run, why it differs from the memory systems we studied, and the wrong turns that got us there.
An agent's memory is two tiers, not one: the team's shared knowledge, and the agent's own private notes. We governed the shared half. The private half was living in a text file that only grows, and that is the half most agents get wrong.
Durable docs aren't the same as recallable knowledge. How we put our entire SDLC knowledge base on Vectros, made it queryable by humans and agents alike, and why finding the rough edges ourselves was the whole point.
Your tracker owns live status; your knowledge base owns the durable why and how. Mirroring one into the other gives you a stale shadow copy. The fix is to promote the durable few by reference.