Pass a task to a colleague and you have to decide what to put in the handoff. A long-running agent faces a similar problem when its surrounding software keeps some turns, summarizes others, and decides which observations can be retrieved again. The model may still be ready to work. The evidence it needs may already have been left out of the handoff.
A preprint on agent harnesses and state distinguishes cases where a missing fact can be looked up again from cases where it cannot. Its experiments show substantial differences under those conditions and examine how summaries and replay affect a small set of benchmark runs. The authors explicitly limit parts of their analysis to narrow configurations and counted runs. The findings support a design question, not a universal ranking of harnesses.
Look ahead to the next decision in the work. What information will it require, and which part of that information could be gone by then? Asking that question gives a context-management policy a concrete job: carry the evidence that the next step cannot safely reconstruct for itself.
Inventory the state a task depends on
Some information is stable and retrievable, such as a versioned reference document. Other information may be temporary: a user’s confirmation, a transient tool response, a decision made during a review, or the state observed before a change. Treating all of it as interchangeable conversation history makes preservation decisions harder to reason about.
Choose a representative task and identify the facts required for its later decisions. Record where each fact comes from, whether it can be obtained again, and whether a later retrieval would return the same version. This gives the harness designer a more useful requirement than a general instruction to keep important context.
Read an approval as carefully as any other task fact. What action did the user approve, within what scope, and under which conditions? Those details belong together in the retained record. A summary that carries the word approved into the next step while dropping its condition hands over a different decision from the one the user actually made.
Test the moment information is compressed
An evaluation should exercise the points where the harness changes the record. Run the task until it has acquired an essential observation, apply the ordinary truncation or summarization behavior, and then test whether the next decision can still be made from the retained evidence.
Include a case where the lost information cannot be re-observed. A benchmark that lets the agent retrieve every fact again may show the cost of extra calls while missing a more consequential failure. Conversely, a failure caused by unavailable evidence should not automatically be attributed to a weak model.
Inspect the retained state directly. A correct final answer in a small test does not establish that the right evidence survived; the agent may have guessed or used an incidental clue. The review should connect the later action to the preserved observation that justifies it.
Preserve the record at the appropriate level
Write the handoff around the decisions the application has to make. A case identifier, an accepted constraint, a source version, or an unresolved question may need an explicit place, with a link back to the evidence. A compact record can do useful work here. Judge it by whether the next step can find and use those facts, rather than by how polished its summary sounds.
Do not assume that a more elaborate summary is always better. Additional prose can obscure the distinction between an observed fact, a proposed step, and an action that actually completed. The state representation should make those categories easy for the next component and a human reviewer to distinguish.
Where the system preserves raw traces, decide how an agent should locate and use them. Keeping a record somewhere does not establish that the agent will retrieve the relevant portion at the right time. Evaluate that handoff as part of the workflow rather than counting retained bytes as a success measure.
Evaluate the system you will operate
Model comparisons should record the harness configuration alongside the model identifier. A change in context management can alter the task that the model effectively receives. If the evaluation changes both at once, an apparent model improvement may be a harness improvement, or the reverse.
Use the same task set to compare the existing policy with a proposed state-preservation change. Measure successful outcomes, recovery calls, unresolved decisions, and the evidence available at completion. Keep narrow or variable results labeled as such rather than promoting a small pilot into a broad capability claim.
Re-observation deserves its own validity check. A record retrieved later may have changed since the original decision, even when the identifier is the same. Preserve a source version or an observation time where that distinction matters, and define when the agent must obtain fresh confirmation. Recovering a current value and recovering the value that justified an earlier action are separate needs. A state policy should specify which one the next step requires.
Choose a fact the agent must carry across a context boundary. Give it a durable place in the record, then test the next step with the original observation unavailable. Can the system still make the decision for the right reason? Keep that case as a check on the handoff. When it fails, you can investigate what was lost and where, with a more useful starting point than saying the model forgot.