What Is Agent Fleet Memory?

Most discussions of “AI memory” quietly assume a single agent talking to a single person. Remember the user’s name. Remember they prefer bullet points. Remember what we agreed last Tuesday. That framing produced a generation of tools that are, essentially, a nicer chat history.

Then teams started running fleets. Not one assistant, but a dozen — or three hundred — agents working the same codebase, the same customer base, the same set of internal systems. And the framing broke, in a specific and expensive way:

The knowledge an agent produces is worth more to the agents that come after it than to the agent itself.

A support agent works out that a particular error code means an expired OAuth token, not a billing failure. That agent is done in ninety seconds and will never see the case again. The next agent, tomorrow, on a different shift, hits the same error and starts from zero. Multiply by three hundred agents and you are paying repeatedly for the same discovery, with no mechanism to notice.

Agent fleet memory is the response to that problem. This is a guide to what it actually consists of.

A working definition

Agent fleet memory is a shared, governed store of durable knowledge that many agents read from and a controlled subset write to — where every item carries scope (who may see it), provenance (where it came from), trust (how much weight it deserves), and validity (when it was true).

Three words in there carry the weight.

• Shared. The default unit is the fleet, not the agent. If knowledge is useful to one agent it is usually useful to its peers, and the architecture should make sharing the path of least resistance.
• Governed. Shared writes without gates are how one hallucination becomes the fleet’s official position. Governance is not bureaucracy bolted on afterwards; it is the thing that makes sharing survivable.
• Durable. Memory is not context. Context is what fits in this call’s window. Memory is what persists between them, across agents, across weeks.

Memory is not one thing

The single most useful move when designing this is to stop treating “memory” as a homogeneous bucket. Different kinds of knowledge have different lifetimes, different write rules, and different retrieval behaviour. A rough taxonomy that holds up in practice:

Failures are the underrated category. Teams instinctively record what worked. In fleets, the negative knowledge — the dead ends, the endpoints that lie, the config that looks right and isn’t — often saves more compute than the positive knowledge does, because it prunes entire branches of exploration before an agent walks down them.

A concrete record looks something like this. Nothing exotic; the value is entirely in the metadata:

{
  "type": "failure",
  "content": "Bulk export endpoint silently truncates at 10k rows; no error returned.",
  "scope": "fleet:data-ops",
  "trust": 2,
  "provenance": {
    "agent": "etl-worker-07",
    "evidence": "run 8812 vs. source row count",
    "corroborated_by": ["etl-worker-03"]
  },
  "valid_from": "2026-05-14",
  "valid_until": null
}

Strip the metadata and you have a sentence in a vector index. Keep it and you have something you can filter, expire, audit, and revoke.

Scope and trust: the two axes

New teams conflate these. They are orthogonal, and keeping them separate is what makes the system tractable.

Scope answers who may see this. It is containment: session inside agent inside fleet inside tenant. The tenant boundary is absolute — cross-tenant leakage is not a bug you recover from with an apology.

Trust answers how much weight does this deserve. It cuts across every scope. A tenant-wide claim can be flimsy; a session note can be gospel.

The top tier deserves special attention. Call them keystones: a small set of non-negotiable statements — policies, hard constraints, house rules — that are not retrieved but injected. They go into the context whether or not the semantic search thinks they are relevant, and writes that contradict them are rejected rather than reconciled. “Never issue a refund above €500 without a human approval” should not be competing for a slot in the top-k. Keep the set small. Ten to thirty items for a whole fleet is a healthy number; if it grows past a hundred, you have started using keystones as a general knowledge base and they will stop working.

The write path

Here is the discipline that separates a memory system from a log file: a write is a proposal, not a fact.

The two gates people skip, and regret:

• Deduplication. Without it, forty agents observing the same thing produce forty records, and your retrieval starts returning the same claim six times, crowding out everything else. Near-duplicate merging at write time is cheap. Cleaning up a million-row store afterwards is not.
• Contradiction handling. When a new claim conflicts with an existing one, “last write wins” is the wrong default, because it silently deletes the more reliable of the two roughly half the time. The right default is to compare trust tiers and time windows first, and to hold the conflict for review when neither dominates.

Which brings up the piece most implementations lack: bi-temporal validity. Two timestamps are not enough. You want to know both when a thing was true in the world and when your system learned it. Without that separation, “our price was €40” and “our price is €55” look like a contradiction rather than a history, and your agents will either fight over it or average it into nonsense.

The read path

Recall is where fleets actually degrade, and the failure is not the one people expect.

The intuition is that the risk is forgetting. In production the dominant risk is the opposite: over-retrieval. An agent pulls thirty marginally relevant memories, burns half its context window on them, and reasons worse than it would have with none — because irrelevant retrieved text does not sit inertly, it actively drags attention. Every memory in the window is competing with the actual task for the model’s attention.

Practical guidance, learned the hard way:

• Hybrid retrieval beats pure vector search. Semantic search misses exact identifiers — error codes, SKUs, service names, ticket numbers — which are precisely the things agents look up. A blend of dense vectors with lexical search (weighted roughly 70/30 in favour of semantic, tuned per corpus) recovers most of that gap.
• Budget by tokens, not by count. “Top 10” is meaningless when one memory is a sentence and another is a runbook.
• Filter before you rank, not after. Scope, tenant, and validity are hard constraints. Applying them post-ranking means your top-k is full of items the agent was never allowed to see.
• Not every turn needs recall. Teaching an agent when not to query is as valuable as improving the query. An agent that reflexively searches memory before every trivial step is slower, more expensive, and less accurate than one that knows the difference.

Then close the loop. If nothing scores memories by what happened after they were used, the store only ever grows. Used-and-worked gets reinforced. Used-and-failed gets demoted. Never-touched-in-a-quarter fades. A memory system without decay is a landfill with an index.

Five failure modes to plan for

1. Poisoning. One agent writes a confident wrong thing; every other agent inherits it, cites it, and reinforces it. Mitigation: trust tiers, corroboration requirements, and the ability to trace every belief back to its origin and revoke the whole subtree.
2. Staleness. Yesterday’s true fact is today’s expensive mistake. Mitigation: validity windows on anything with a shelf life, and explicit supersession instead of silent overwrite.
3. Context bloat. Covered above. Measure retrieved tokens per task; watch it like you watch latency.
4. Cold start. An empty store returns nothing, agents stop querying, the store stays empty. Mitigation: seed it. Import your runbooks, your incident write-ups, your architectural decisions. A fleet memory that begins at zero usually stays near zero.
5. Cross-scope leakage. The one that ends conversations with your security team. Enforce tenancy at the query layer, not in a prompt. Prompts are advisory; queries are not.

What to build first

If you are standing this up, a defensible order:

1. One store, not one per agent. Even a single shared table beats N private ones.
2. Scope and tenant on every record, from day one. Retrofitting isolation is brutal.
3. Provenance on every record. You cannot debug or revoke what you cannot trace.
4. Hybrid retrieval with a token budget.
5. A dozen keystones. Written by a human. Reviewed quarterly.
6. Trust tiers and contradiction checks.
7. Decay and outcome scoring.

Steps 1–3 take an afternoon and prevent most of the pain. Steps 6–7 are what separate a system that survives a year from one that gets quietly abandoned at month four.

If you would rather not build the plumbing, the space now has real options — including open-source implementations of exactly this architecture. But the concepts above are the part that matters, and they are implementation-agnostic. The choice of store is a detail; the choice of whether a write is gated is not.

When you don’t need any of this

Worth saying plainly, because the field has an inflation problem.

If you run one agent, for one user, with no durable stakes, you need conversation history and nothing else. If your agents are stateless transformers of input to output — classify this, translate that — memory adds cost and failure surface for no return. If your knowledge lives in a system of record that is already authoritative and queryable, read it directly instead of copying it into a memory store where it will rot out of sync.

The test is simple: does one agent’s discovery have value to another agent later? If no, skip all of this. If yes, you have a fleet memory problem whether or not you have built anything to address it.

The shape of the thing

The mental model I keep returning to: for a single agent, memory is a convenience. For a fleet, it is the org chart.

It determines what the collective knows, who is allowed to know it, which beliefs are load-bearing, and how a correction propagates. Companies solved a version of this decades ago with documentation, onboarding, and institutional norms — slowly, badly, and mostly through people. Fleets need the same thing at machine speed, and unlike human organisations they will follow whatever rules you actually encode rather than the ones you intended.

Which means the interesting question is no longer can my agent remember. It is what is my fleet allowed to believe, and who decided.

Disclosure: I’m the co-founder of Caura — the memory layer described here, Apache 2.0 and MCP-native: github.com/caura-ai/caura. Obvious skin in the game. Nothing above requires our implementation; the concepts are the part that matters. If you take one thing from this, take the write gate.

If you’re building in this space, I’d like to hear where your model differs. Corrections welcome.