AI agent state between turns: what does not carry over

You told the agent to install a package. It said it had. Two messages later it cannot find the tool, and the obvious conclusion is that the model forgot. It did not. Understanding AI agent state between turns means separating three things that get conflated constantly: what the model holds in context, what the process holds in memory, and what is actually on disk.

A great many failures that look like model errors are environment errors, and they are diagnosable in about a minute once you know which store you are asking about.

AI agent state between turns lives in three stores

The model context is the conversation. It is large, it is lossy at the edges, and it is summarised or truncated as it grows. What it contains is a record of what was said, not a record of what happened.

The process state is the working directory, environment variables, loaded libraries and open handles of whatever shell or runtime executed the last command. It survives exactly as long as that process does, which on many agent platforms is one turn.

The filesystem is the only one of the three that persists by default, and only if the machine underneath it does. On a disposable sandbox it does not.

Almost every confusing agent failure is a mismatch between which store you assumed and which one you were actually using.

The confusion is understandable, because the conversation presents all three as one continuous thing. You typed a command, you saw output, the transcript still shows both — so it feels like a session. It is not a session. It is a log of several short-lived sessions stitched together by a context window, and the stitching is the illusion.

Five things that do not carry over

A piece published on 14 September works through these with executable probes rather than assertions, which is the right instinct — each is checkable on your own platform in under a minute.

Your shell did not stay put. A cd or an export changes the state of one process. If the next turn spawns a fresh process, that change is gone, and the agent will run your next command from wherever the new process starts.

An install is not a guarantee. pip install writes to a filesystem. Whether the tool is there next turn depends on whether that filesystem persists, which on remote or disposable sandboxes it frequently does not — and the installation genuinely succeeded, so nothing errored.

Typing export in chat is performative. Writing an environment variable into a prompt does not put it into any process's environment. A child process reads the environment it was given. Worse, a secret pasted into a prompt is now in the transcript, in whatever logging the platform does, and in the context window for the rest of the session.

A node_modules belongs to the machine that built it. Native modules compile against a specific Node version and system libraries. Copying the folder somewhere else produces a directory that looks right and fails at require time.

The model remembering a file is not the file existing. Context gets summarised, and a summary of a file is a description, not the bytes. If it was not written and the write not verified, it is not there.

The common thread is that each of these fails silently. Nothing raises an exception when a process ends, an install evaporates or a summary replaces a file's contents with a description of them. The agent proceeds on a false premise and produces a confident, wrong result several steps later, which is why the eventual symptom rarely points anywhere near the cause.

Why this got harder, not easier

The trend in agent platforms is toward statelessness, for good reasons that make this worse in practice.

The 2026-07-28 MCP specification removed protocol-level sessions entirely, which is what lets a server run behind a plain load balancer instead of sticky routing. That is a genuine operational win, and we covered what it changes in the MCP breaking changes.

But statelessness at the protocol layer means state has to live somewhere explicit. The documented pattern is handles — the model calls create_basket, gets a basket_id, and passes that identifier back on later calls. That is the correct design, and it is exactly the opposite of assuming your shell survived.

The same holds for managed sandboxes generally. A sandbox that spins up per session and terminates afterwards is better for security and cost, and it means the filesystem is not a place to keep anything you need tomorrow.

There is an evaluation consequence too. If your eval suite runs each case in a fresh environment but your production agent runs in a long-lived one — or the reverse — you are testing a different system from the one you ship. Environment lifetime belongs in the test fixture, stated explicitly, rather than inherited from whatever the harness happened to do.

It is worth asking your platform vendor two questions directly, because the answers are rarely in the marketing. Does a turn reuse the previous process, and under what conditions does it not? And how long does the filesystem survive after the last message — until the session closes, until an idle timeout, or until some capacity threshold nobody documents? Teams routinely design around an assumption on both and discover the real answer during an incident.

Build for it instead of hoping

Four practices, in the order we would introduce them.

Make every command self-contained. Absolute paths, explicit environment on the command, no reliance on a previous cd. It is more verbose and it works regardless of process lifetime.

Verify writes, do not assume them. After a step that produces a file, check it exists and hash it. This is the same discipline as hashing behaviour before a refactor — the snapshot is the authority, not the claim that the work was done.

Put durable state outside the sandbox. Object storage, a database, a repository. If losing it would matter, the sandbox is the wrong place, and it will be reclaimed without warning.

Never put secrets in prompts. Inject them into the execution environment, or better, do not give the agent a credential at all — the reasoning behind granting access by identity rather than by key.

None of these is exotic engineering. They are the same properties you would want from any job that might be retried on a different worker — idempotent, self-describing, with durable state held deliberately rather than incidentally. Agent platforms have simply made a long-standing distributed-systems discipline compulsory for teams who previously did not need it.

Cheap and worth doing once: run the probes above on whichever platform you use, write the answers into your repository, and date them. Platform behaviour changes between releases without announcement, and a dated note is the difference between a five-minute re-check and a week of confused debugging next time something moves.

How to diagnose it in a minute

When an agent behaves as though it has forgotten something, the question is which store you are asking about.

Have it print the working directory, the process ID and the relevant environment variable at the start of consecutive turns. If the process ID changes, process state is not surviving and every conclusion built on it is wrong. If the ID is stable but a file is missing, the filesystem is the problem. If both are stable and the agent still behaves as though something is absent, then it is a context problem, and only then is the model the thing to look at.

That ordering matters because it is the reverse of what teams do. The instinct is to rewrite the prompt first, which is the most expensive intervention and the least likely to help — and, because prompt changes are hard to evaluate, it is also the one most likely to introduce a regression nobody notices. Prove the environment before touching the instructions.

Attribution note: the write-up prompting this was published by an individual account carrying a product disclosure, not by the organisation its username suggests. The probes are sound regardless, and they are worth running against your own stack rather than taken on trust — which is the general posture we would take on any AI engineering platform decision, and the reason this belongs in the architecture conversation rather than in prompt tuning.