The memory store every agent in my fleet writes to

I run more than one agent. I run a fleet of them, each with a name, a role, and its own history with me. The question that breaks most people building this way is simple: where does all of that memory actually live. If every agent keeps its own private notes in its own head, you have not built a team, you have built a room full of strangers who happen to share a Slack channel.

What I picked and what I killed

I went through an evaluation before landing on the current stack. The decision record from that pass is blunt about it: the stack is Hindsight, self-hosted at zero cost with Hindsight Cloud as backup, plus Master Brain, plus our own graph visualization on top. Hindsight Cloud came back cheap to run, something like two to three dollars for a full sync, which mattered because I was not going to bolt an expensive managed memory layer onto every agent call.

The same record names what got cut. Remembra was in the mix, got tested, got rejected, got removed. I do not think that failure is worth dwelling on in detail, but I do think it is worth saying out loud, because most write-ups about a tech stack only show you the winner. The honest version shows you the thing you tried and walked away from, and why.

The design goal behind the whole exercise was one line: every agent, gino included, remembers its own work, and that memory gets injected automatically. Not fetched on request. Not something an agent has to remember to ask for. Injected, by default, every time.

Proof it is not just a plan

A stack decision on paper is easy to write and easy to ignore. What convinces me a system is real is watching it operate on itself, so here is that proof. Memz, the agent I built to own memory hygiene across the fleet, writes its own entries into a real agent_memories table inside the shared Master Brain store. I can point at specific rows: one created at 17:17:57 UTC, another at 15:17:54, another at 15:07:54, all on the same two-day window in June. Those are not sample records I generated to illustrate a concept. They are Memz doing its job, logging its own work, the same way every other agent in the fleet is supposed to.

That is the test I use now when someone pitches me a new memory architecture. Not "does it sound right on the whiteboard." Does the agent that owns it actually write to it, unprompted, as a side effect of doing its job.

Why a shared store, not a pile of private notebooks

The instinct when you start running multiple agents is to give each one its own memory file and call it done. That works until agent A does something agent B needs to know about, and the only place that fact lives is inside A's private notes that B never reads. A shared store fixes that structurally. Every agent writes into the same backing system, tagged by who wrote it, and any agent that needs context can pull it, not just the one that generated it.

I also did not want to pretend this stack sprang out of nowhere. Before I landed on Hindsight plus Master Brain, the fleet had run on a mix that included Mem0 alongside Hindsight. That is not a footnote I am hiding. It is the honest shape of how you get to a good architecture: you run more than one system in parallel for a while, you watch which one actually gets used and which one quietly stops getting written to, and you consolidate around the one that survived contact with real work.

What this actually buys me

The practical effect, day to day, is that I do not have to re-explain context to an agent I have not talked to in three weeks. It already knows what it did last time, because that record was injected before it ever saw my prompt. Multiply that across a dozen-plus named agents and the alternative, me re-briefing every one of them from scratch every session, is not a workflow. It is a part-time job I do not want.

If you are standing up something similar, the lesson from my own build is not "use Hindsight" specifically. It is: pick a store cheap enough that you never hesitate to write to it, make the injection automatic instead of optional, and be willing to name and kill the option that did not earn its place.