Agent Memory: Short-Term, Long-Term, and Shared

A single agent needs a good memory; multiple agents also need to “share memory.” Shared memory lets a group of agents pass context along like one team, instead of each keeping its own notes and stepping in the same pits repeatedly.

Short-term and long-term, quickly reviewed

Short-term memory handles the current task, using a rolling window or step-by-step summaries — don’t blindly re-feed the whole conversation. Long-term memory stores stable, repeatedly useful information, split into three media types: vector store, structured store, and user profiles. These two layers are the base of single-agent memory. This article focuses on the third layer: shared memory. When multiple agents collaborate, if each accumulates from zero, the same lesson gets learned multiple times and none of them knows about the pits the others stepped in. Adding a shared-memory layer is exactly what cancels out that repetition.

What shared memory is

Shared memory is a public space multiple agents can all read and write, storing “group experience”: that a certain tool loves erroring, the best steps for a certain task type, the shared preferences of a user group. Whatever any agent learns becomes immediately available to all. It’s like the team’s shared document, not a personal notebook. A new agent joins and already has the veterans’ experience instead of starting from trial and error. Sharing turns individual learning into an organizational asset, and the bigger the collaboration, the more worthwhile it is.

Why sharing is worth doing

Without sharing, ten agents each explore the same territory, wasting ten times the compute, and possibly ending with ten conclusions that contradict each other. With sharing, one exploration’s results persist and everyone reuses them, raising efficiency and consistency at once. Another value is consistency. A user runs into different agents over time yet gets responses grounded in the same experience, so the experience feels continuous. What users feel is “one team,” not “a bunch of stragglers.”

Writes need to avoid conflicts

Multiple agents writing to one shared memory will collide: A just wrote a conclusion, B writes a contradictory one — who overwrites whom? The fix is versions and locks: key entries carry version numbers, read the latest version before appending, or take a short write lock to avoid concurrent overwrites. Also guard against an “echo chamber”: multiple agents confirm each other based on each other’s wrong memories, and the error gets amplified into “consensus.” Do conflict detection before writing, keep contradictory entries coexisting pending review instead of overwriting directly, and errors won’t snowball.

Reads need isolation

Sharing doesn’t mean reading everything indiscriminately. Each agent takes what it should see by identity and task: customer-service agents read user preferences, analysis agents read metric definitions, none overstepping. Read isolation is the precondition for sharing without leaking. Reads should also carry relevance — don’t dump the whole shared memory onto one agent, which both blows the window and burns money. Treat sharing as an on-demand archive, not a dump you empty all at once.

The boundary between shared and private

Not all memory should be shared. Anything involving a single user’s privacy, or temporary conclusions in a specific agent’s experiment, should stay private; only reusable, verifiable, privacy-stripped group experience goes into the shared layer. Draw the boundary and you get both security and utility. In practice set two tiers: private memory follows the agent lifecycle, shared memory enters the store after review. Write “what can be shared” as explicit rules rather than relying on agent discretion. With the boundary held, shared memory keeps running long-term.

Expiry and correction

Errors in shared memory spread wider than in private memory, so maintenance has to be harsher: review expired entries more often, and mark sources and timeliness more strictly. One expired shared entry can steer ten agents wrong at once. Correction has to “broadcast”: when an entry is disproven, don’t just delete your own copy — notify the agents depending on it to refresh. Treat correction as a thing to follow through to the end, or errors won’t stop haunting the shared layer.

A small-step path to rollout

Don’t rush to share everything. Let the two agents that collaborate most tightly share one memory, get read/write and conflict handling running, then expand the scope gradually. Small scope means small conflict surface and low pit-stepping cost. Set up a “shared-memory spec” alongside: what can be written, how to version, who reviews, how often to clean. When the spec comes first, expansion doesn’t turn into a tangle. Shared memory depends on both technology and institutions.

Compared with single-agent memory

Single-agent memory cares about “I don’t forget.” Shared memory cares about “we don’t each forget our own things.” The former solves individual continuity; the latter solves group consistency. They don’t replace each other; stacked together they form a complete memory system. In design, single-agent memory can stay lightweight, while shared memory needs heavy governance because its impact surface is large. Keep the weight distinction clear, and the memory system stays both flexible and controllable — not spiraling out of control because of sharing.

Measuring whether shared memory pays off

Watch two things: whether repeated exploration drops (how many times the same lesson gets learned), and whether cross-agent consistency rises (how well different agents’ conclusions agree on similar problems). Both improving means sharing is actually working. Then count the cost: is the compute and human effort of maintaining shared memory less than the repeated exploration it saves? Sharing isn’t a free lunch; governance carries overhead, and only by doing that accounting do you know how far sharing should go.

Technical choices in practice

Shared memory’s storage medium should be picked by read/write frequency: high-frequency short-lifecycle entries go in memory-type stores; low-frequency persistent ones go in vector or document stores. Wrong selection makes concurrent reads and writes bottleneck, and the sharing dividend gets dragged down before you even enjoy it. There also needs to be a unified interface so every agent uses the same read/write protocol instead of each wiring its own. With a unified interface, adding a new agent is zero-cost, and the shared layer truly becomes the team’s “common infrastructure” rather than yet another island.