We moved our own agent's memory onto the platform we sell

From the first line of this project, the goal was simple: run our own agent's memory on the same tier we sell, not a demo's. The first post built the tier. The second built the recall loop that feeds it to the agent. This post is the part we were walking toward the whole time: moving our memory onto it for good.

We had let it sprawl first, which is the honest part. By the time we moved it, the private notes our agents kept had grown to a couple hundred files, and recall could see almost none of them. We had built the tier and the loop and then left the actual memory in an un-curated pile the loop could not reach. A memory you never curate is not a memory. It is a hoard, and a hoard is invisible. So the move was also a cleanup, and the cleanup taught us more than the move did.

One home per fact

Moving the memory was not "copy the files into the database." It was a decision, made once per note: where does this actually belong? A hand-written pile of notes turns out to hold at least three different kinds of thing, and they belong in different places.

• A durable lesson that others should know, another engineer or another agent, belongs in a reviewed team document, not in one agent's private memory. In a document it shows up in a diff and gets reviewed. In private memory it is invisible the moment it is written.
• A genuinely private, changing piece of context, the state of a project or a standing preference, belongs in the memory tier.
• And a lot of it belonged nowhere. It was already known, already written down elsewhere, or no longer true.

We sorted every note that way. A couple hundred files became four. The rest became a small set of private memory records and a larger set of shared documents, and a good share was simply retired. What is left on disk is a handful of pointers. Everything else is recalled by meaning, when it is relevant, instead of loaded in bulk and hoped over.

The rule underneath is the one that makes it hold: a fact has exactly one home, and which home is not a matter of taste. The moment a fact lives in two places, both copies rot, because one gets updated and the other does not, and now recall can surface the stale one just as easily as the current one.

The score finds it, judgment decides

The trap we kept falling into was rebuilding a second copy of something the knowledge base already held. So every note ran one search against the existing knowledge first, to check for a duplicate. And the rule we learned is the same one the recall post kept running into: the similarity score can point you at the candidates, but it cannot make the call.

A high score against a nearby-but-different lesson is not a duplicate. A low score against the same lesson in different words still is. Our own memory records score only moderately similar to their real matches, well below any line you would draw for "these are the same," so a number could never be the gate. When we re-checked the whole set after the shared knowledge base shifted under us, out of thirty-nine notes we had marked as new, only two turned out to be already covered. The staleness we were bracing for did not show up, and checking cost far less than assuming would have. Similarity is a good way to find the candidates a person or an agent should look at. It is a bad way to decide among them. The decision is a read, not a number.

It made us fix our docs too

Here is the part we did not see coming. The same rule, "one home per fact, decided on purpose," turned around and pointed at our own documentation, which had the same disease the memory pile did.

Our hardest-won notes on sharp edges lived in one big file that only ever grew, with a hundred or so numbered entries referenced by number. That is the memory-file problem again in a new place. It clashes whenever two branches both add to it, its numbers break the moment anything is renumbered, and one small edit reprocesses the whole file. The fix is the same one the memory tier already was: one entry per unit, each with a stable id that does not move when its neighbors change, and an index generated over the top. We split that file that way, and deliberately left a second, larger one alone, because it was referenced thousands of times and splitting it in the same change would have meant an unreviewable sweep. Measure the blast radius before you commit to the sweep.

What we would tell you

• A memory you never curate becomes a liability. Ours grew until recall could not see most of it. Curation is not optional upkeep. It is the difference between a memory and a hoard.
• One home per fact. The moment a fact can live in two places, both rot. Decide the home by a rule, not by whichever file you had open.
• Dedup on judgment, not a cutoff. Similarity finds the candidates. It cannot make the call. The same-fact decision is a read.
• Migrate on evidence. We split one file and left another because a few dozen references is not a few thousand. Measure before you sweep.

That is the whole point of the agentic-SDLC blueprint: the durable few, put on purpose in their one right home, and everything else recalled by meaning when it matters. We built Vectros to be the secure back-end an AI product runs on, and the truest test we can give it is the one we now depend on every day: our own agent's memory, curated and running on the platform we sell.