{"slug": "giving-a-fleet-of-ai-agents-one-shared-memory-when-each-agent-runs-a-different", "title": "Giving a fleet of AI agents one shared memory — when each agent runs a different model", "summary": "A developer detailed a design for giving a fleet of AI agents a shared memory when each agent runs a different model. The approach separates an append-only event log from a derived index, ensuring the index depends on the log and not vice versa, which allows for easy retrieval strategy changes. The developer emphasized scoping search per agent and storing raw events rather than summaries to avoid costly re-derivations.", "body_md": "Most agent frameworks give each agent its own context window and call it memory. That works right up\n\nuntil you run more than one agent, and then it quietly becomes the most expensive design decision in\n\nthe system.\n\nWe run a fleet where different agents are deliberately backed by **different models** — one family\n\nhandles long-form drafting, another handles structured extraction, a couple run on a local path with\n\nno external inference at all. Routing by capability is the easy part. The hard part is that an agent\n\nwhich learns something has learned it *alone*.\n\nThis is a writeup of what broke, and the design we ended up with.\n\nThe symptom shows up as repeated work.\n\nAn extraction agent determines that a particular vendor's invoices put the tax line above the\n\nsubtotal. Useful. Two days later a different agent — different model, different prompt, same\n\npipeline — hits the same vendor and re-derives it from scratch. Then a third does it again.\n\nNothing is *wrong*. Every agent behaves correctly. The system as a whole just has no way to\n\naccumulate anything, because knowledge lives inside whichever context window happened to be open at\n\nthe time. You are paying inference costs to rediscover facts you already own.\n\nThe naive fix is to pass more history. That fails for a specific reason worth naming: **context\nwindows are per-invocation and per-model.** A 200k window on one model does not help an agent\n\nOnce you accept that memory has to live *outside* the agents, the requirements get concrete:\n\nPoint 3 is the one people skip, and it is the one that hurts. A shared memory store with no\n\nprovenance turns every bad output into an unbounded investigation.\n\nTwo layers, deliberately separated:\n\n**An append-only event log** is the source of truth. Every memory write is an event with the agent\n\nidentity, session identity, channel, and timestamp attached. It is never mutated. If a fact turns\n\nout to be wrong, you append a correction — you do not edit history. This is the layer that makes\n\npoint 3 and point 5 possible, and it is boring on purpose.\n\n**A derived index** is what agents actually query. It is rebuilt from the log, which means it is\n\ndisposable. Change your embedding model, change your chunking, decide semantic search was the wrong\n\ncall for a given path — rebuild the index, the log is untouched.\n\nThe important property is the direction of the dependency. **The index depends on the log. Nothing\ndepends on the index.** That is what lets you swap retrieval strategies without a migration, and it\n\nOur current implementation runs a document-indexing backend over configured paths with a scheduled\n\nembed cycle, plus session export with a retention window. The specific backend matters much less\n\nthan the split — we have changed it once already and the log made that a non-event.\n\nThe instinct is to make retrieval smarter. Better embeddings, reranking, hybrid search.\n\nIn practice the wins came from **narrowing what is searchable per agent** before ranking anything.\n\nAn agent asking about invoice formats should not be searching across support transcripts. Not for\n\nquality reasons — for correctness reasons. Cross-domain semantic neighbours are exactly the kind of\n\nplausible-but-wrong context that produces confident nonsense.\n\nScope first, then rank. A small correctly-scoped candidate set beats a large well-ranked one, and it\n\nis dramatically cheaper.\n\n**We stored summaries too early.** Summarising a session into memory at write time felt efficient\n\nand destroyed the ability to re-derive anything later when we changed our minds about what mattered.\n\nStore the raw event; summarise at read time if you need to.\n\n**We under-specified identity.** Early on, \"which agent wrote this\" meant an agent *name*, which we\n\nthen renamed. Use a stable identifier that survives renaming, and record the model separately —\n\nyou will want to answer \"did the model change when the quality dropped?\"\n\n**We assumed retrieval failures were retrieval failures.** Most were scoping failures wearing a\n\ncostume.\n\nHonestly: it depends on fleet size. With one or two agents, per-agent context is fine and this\n\narchitecture is overhead you do not need. The crossover came for us somewhere around five or six\n\nagents sharing a domain, where the rediscovery cost and the \"why did it do that\" investigations\n\nstarted dominating.\n\nThe clearest signal that you have crossed it: you find yourself explaining the same fact to\n\ndifferent agents, or you cannot answer why an agent produced a given output without reading raw\n\nlogs. Both are memory-architecture problems presenting as prompt problems.\n\n*We build and deploy governed AI agents for Singapore businesses at\nVYR — every agent runs with a human approval gate on any action that writes,\nsends or pays, plus a full execution log. If you are working on multi-agent memory, I would genuinely\nlike to compare notes in the comments.*", "url": "https://wpnews.pro/news/giving-a-fleet-of-ai-agents-one-shared-memory-when-each-agent-runs-a-different", "canonical_source": "https://dev.to/dextee/giving-a-fleet-of-ai-agents-one-shared-memory-when-each-agent-runs-a-different-model-1c4k", "published_at": "2026-08-11 21:05:49+00:00", "updated_at": "2026-08-11 21:17:30.809050+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "mlops"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/giving-a-fleet-of-ai-agents-one-shared-memory-when-each-agent-runs-a-different", "markdown": "https://wpnews.pro/news/giving-a-fleet-of-ai-agents-one-shared-memory-when-each-agent-runs-a-different.md", "text": "https://wpnews.pro/news/giving-a-fleet-of-ai-agents-one-shared-memory-when-each-agent-runs-a-different.txt", "jsonld": "https://wpnews.pro/news/giving-a-fleet-of-ai-agents-one-shared-memory-when-each-agent-runs-a-different.jsonld"}}