How do you stop an agent from trusting its own stale context?

Something I keep hitting and have not properly solved, so I would rather hear how other people handle it than pretend I have the answer.

I run several coding-agent sessions at the same time. A session will state confidently that a dev server is up, or that a background job is running, because somewhere in its context there is a doc or an older transcript that said so. The process died weeks ago. Nothing in the loop ever contradicts it, so the claim propagates: into the next answer, into a handoff file, occasionally into a commit message.

The shape of it is that model memory behaves like a cache with no invalidation. It is not hallucination exactly. The information was true when it was written. There is just no TTL on it.

What I have tried:

Telling it to check first. Works when I remember to say it, which is not a system.

A rule in the instructions file saying verify before asserting. Better, but an instruction about diligence loses to a confident-looking fact already sitting in context.

Letting it shell out to ps and lsof. It can, and mostly does not, because nothing signals that its own memory is suspect.

What moved the needle for me was making the check a tool the model is told to call at session start, so grounding happens by default instead of depending on my recall. That is the thing I ended up building, so I am obviously biased about that conclusion.

What I am genuinely unsure about:

Is this a tooling problem or a prompting problem? Has anyone got the instruction-only version working reliably over long sessions?

Is there a category of stale state past process, port and daemon that bites you? Stale env vars, stale branch, half-applied migrations?

Interested in being told I over-engineered this.