DEV Community

Yuhai Xia
Yuhai Xia

Posted on

Your agents share state. How does the next one know it's still true?


Most of the writing about agent memory is about getting information in — what to store, how to chunk it, which embedding model. I want to ask about the other end, because that's where it broke for us.

An agent reads a piece of shared state. How does it know that state is still true?

The failure looks like success
We keep a task canvas that agents read at the start of a session and update as they work. Plan, current step, what's done, what's next. Another agent picks up where the last one stopped. When it works it feels like magic.

Here's the failure mode I didn't design for. An agent opens a canvas that was last written six days ago. It says current step: API integration. That was true when it was written. Since then a human changed direction, a different agent did unrelated work, and the API integration was abandoned.

The agent reads it and confidently continues. Nothing is corrupt. Nothing throws. The state is stale, and a stale read is byte-identical to a fresh one.

My first instinct was to fix the write side: make agents update state before they stop. That doesn't work, and I think the reason generalises. The failure is an absence. An agent that quits without writing — because it crashed, hit a quota, or simply decided it was done — leaves nothing to intercept. You cannot validate a write that never happened.

So we moved the check to the read. Every read carries its own age:

[canvas: last updated 6 days ago, 40 memory writes since.
Treat completed/next as unverified.]
It helps. The agent hedges instead of charging ahead. But it's a nudge, not a guarantee — I'm handing a probabilistic system a warning label and hoping it reads it.

What I actually want to ask
I've been assuming this is a solved problem somewhere and I just haven't found the right vocabulary for it. A few specific things I'd like to hear how others handle:

  1. Is age even the right signal? Six days old and untouched might be perfectly valid for a slow project. Six minutes old is worthless if three agents wrote in between. I use "writes since" as a proxy for drift, but it counts unrelated writes too. Has anyone found a signal that actually correlates with "this is no longer true"?

  2. Who is allowed to invalidate? We let agents propose that a decision is superseded, but a human confirms anything that overwrites an earlier decision. I honestly don't know whether that's good judgment or just fear. If you let agents invalidate each other's state freely, does it converge or does it thrash?

  3. Concurrent writers. Two agents update the same state within seconds of each other. We use locks with leases, which prevents corruption and does nothing about the semantic conflict — both writes are individually valid and jointly incoherent. Is there a pattern better than last-write-wins plus a human noticing later?

  4. Does the model actually respect the hedge? This is the one I have least data on. I put a staleness warning in the read output and I observe better behaviour, but I have not built an eval that isolates it. If you've measured whether a caution in tool output changes what the model does, I'd genuinely like to know how you set that up.

  5. Is any of this different from cache invalidation? Some days I think this is just cache invalidation wearing an AI hat and I should go read distributed-systems literature instead of inventing vocabulary. Other days the fact that the consumer is a language model — something that will happily fill gaps with plausible fiction — feels like it changes the problem. I can't decide.

The part I keep coming back to
Traditional software fails loudly when it reads something wrong. Types don't match, a parse fails, an assertion trips. An agent reading stale state does the opposite: it produces confident, coherent, entirely reasonable work based on a world that no longer exists. The output looks more trustworthy than a crash would.

That inversion is what makes it hard. Every instinct I have as an engineer is tuned to catch things that break. This doesn't break. It just quietly stops being right.

If you're running more than one agent against shared state, I'd like to know what you do about this — even if the answer is "nothing yet, and it hasn't bitten us." That's a useful data point too.

Disclosure: this post was drafted with AI assistance from my own notes, then edited and fact-checked by me before publishing.

Top comments (0)