An agent can appear to remember a great deal. It can refer to an earlier decision, explain why it chose one file over another, and continue a task across many messages. That experience is useful, but it can conceal a fragile assumption: that the model's current context is the system of record.

It is not.

Context is an instrument for reasoning in the present. It may be trimmed, summarized, replaced with a different model, or lost when a session ends. It cannot be the only place where a task's state, an organization's policy, or a product's operating history exists.

The difference becomes obvious during a handoff. If a new engineer cannot determine the active branch, the confirmed facts, the unresolved question, and the evidence already gathered without asking the agent to retell its history, then the work has not been stored in a usable system. It has been stored in a conversation.

What should persist

Not everything deserves durable storage. An exhaustive trace of every model token is expensive and difficult to read. A good system preserves the artifacts that affect future action.

For a software task, that generally includes:

• the objective and the constraints that shaped it;
• the workspace, revision, and files that were materially changed;
• the plans or decisions that were adopted and the assumptions behind them;
• the outputs of checks that still describe the current state;
• outstanding failures, risks, and approvals;
• a clear boundary between a proposal and an accepted change.

These objects can live in familiar places. Code belongs in a repository. A durable decision can live beside the work it governs. A test result belongs to a revision and command. A production action needs an audit record with an identity and policy decision. The important point is that these records remain available even if the model that produced them is gone.

The case against the infinite transcript

The obvious response to lost context is to preserve everything. That trades one problem for another. A task that stores every tool result, every noisy log line, and every rejected thought becomes difficult to resume because the important facts are buried in exhaust.

Selective memory is not a loss of rigor. It is a design decision. The system should retain the state that changes the next decision and summarize or discard the rest. A failed command is valuable when it revealed an environmental constraint. It is less valuable when it was a typo immediately corrected. A review comment is valuable when it changes the accepted design. It is less valuable when it only repeats a resolved question.

This is why durable state needs provenance. A stored fact should have a source, a time, and a relationship to the system it describes. A test result from yesterday's branch may no longer be relevant after a dependency upgrade. A permission granted for one task should not silently travel to another. A user preference should not be mistaken for a production policy.

The model proposes; the system persists

An agent can write a task note, update a plan, create a branch, or propose a change to a configuration file. It should not be the sole authority that decides which of those outputs become organizational state.

This division of labor is healthy. The model is good at synthesizing information, generating alternatives, and interpreting local context. A trusted subsystem is better suited to persist records, enforce schemas, attach identities, validate permissions, and preserve history. The model proposes; the system persists.

That separation also improves correction. If a model makes a wrong inference, the team can amend a decision record or reject a change without trying to erase the fact that the model once held a different idea. If a new model is adopted, it can read the durable artifacts and continue the task without inheriting hidden assumptions from a previous context window.

Memory is not one thing

"Memory" is often used as though it named a single feature. In real work, several different things are being remembered:

• Working context: temporary details needed to complete the current task.
• Project knowledge: stable information about a codebase, product, or research program.
• Operational history: what happened in a particular run, including approvals and external actions.
• Policy: rules about who may do what, which should be explicit and reviewable.
• Human preference: choices about style or workflow that should not be confused with system truth.

These categories have different lifetimes and different risks. A working note may expire after a task. A security policy must remain explicit until it is deliberately changed. A production audit record may need to be preserved even if the work itself is removed. Treating all of them as chunks in a generic retrieval index creates confusion that a more fluent model cannot reliably repair.

The infrastructure around an agent should respect those distinctions. It should know the difference between recalling a prior decision, retrieving a reference document, and granting an action. Those are not interchangeable operations.

State is what makes work portable

When the relevant work state is outside the model, a team gains options. It can change model providers. It can run a smaller model for routine analysis and a stronger model for a difficult review. It can move execution into a different environment. It can invite another engineer to take over. It can inspect what happened without treating one vendor's transcript as the canonical record.

Portability is not only an exit strategy. It is a day-to-day property of a system that can survive interruption and change. A task does not become valuable because one model remembers it. It becomes valuable when the work remains legible after the model has moved on.

The context window will continue to grow, and models will become better at maintaining an internal picture of a task. That is welcome. The underlying principle remains: use context for intelligence, and use the system for memory.