An agent can remember everything that happened and still fail to continue a task correctly.
It can retrieve an old instruction and the instruction that replaced it. It can resume from a perfectly preserved checkpoint while continuing a plan whose assumptions have become false. It can hand work to another agent that receives every relevant fact but not the reason one of those facts limits what may happen next.
These failures are usually treated as three problems: memory, persistence, and coordination. We think they are one. What disappears is not the information. What disappears is the relation between a piece of state and the later work that depends on it. We call that relation reliance, and our hypothesis is simple: long-running agents should maintain reliance, not merely history.
Knowing the current value is half the problem
On Monday, the person who assigned a task tells the agent that nothing may ship to customers outside the EU. The agent designs a rollout around that constraint. On Wednesday the person corrects it: the restriction was a misunderstanding, and US customers are in scope.
By Friday, a system with good retrieval can find both statements. A memory that tracks time can mark Wednesday's as newer. A conflict detector can mark Monday's as superseded. Recent work treats exactly this as the frontier: LongMemEval evaluates knowledge updates, Supersede isolates the failure to replace an obsolete value with its current one, and conflict-aware memories such as MOSAIC validate new information against what is already stored.
All of that answers what is the current value? A second question remains: which work has to change because of the correction? The rollout plan does. A capacity estimate based on EU-only traffic does. A drafted customer announcement does. The visual design of the launch page does not. A system can answer the first question perfectly and leave every conclusion derived from the old value untouched. That is the failure this note is about.
Reliance
Let an agent's durable state contain observations, instructions, assumptions, decisions, artifacts, and external effects. Say that y relies on x when a material change in the validity of x should cause y to be reconsidered.
This is not the kind of relation memory systems usually store. "Paris is in France" is semantic. "B was said after A" is temporal. "This document came from that user" is provenance. "This decision must be revisited if that assumption stops holding" is reliance. Its purpose is not retrieval but repair.
The distinction matters because relevance and dependence come apart. Two statements can be nearly identical while neither depends on the other, and an unremarkable configuration value can sit underneath fifty later decisions. The structure long-running work needs is therefore not only a graph of what is related. It is a graph of what the work currently rests on.
What a piece of state has to carry
To be usable in a long task, a piece of state must answer two questions: may the agent rely on this now? and what else would have to be reconsidered if it could not?
Answering the first requires the properties a recent survey of always-on agents identifies as largely ungoverned in current systems: where the state came from, what authority its source has, what it applies to, and whether it is still valid or has been superseded, disputed, or left unverified. Answering the second requires its reliance edges.
One architectural consequence follows. The historical record and the operative state should not be the same thing. History should remain append-only: Monday's instruction really was given. Operative state is a maintained view over that history, in which Monday's instruction remains on record but no longer governs Friday's action. Retrieval can search the record. Action should consult the maintained state. Confusing the two is how an agent correctly recalls something it should no longer obey.
Revision is repair
The underlying mechanism is old. Truth-maintenance systems recorded the reasons for beliefs in 1979, so that retracting an assumption retracted the conclusions it supported, and assumption-based variants made switching between sets of assumptions cheap. What agents add is an operational dimension: the conclusions are plans, artifacts, and actions in the world, and redoing them has real cost.
Suppose a constraint C supports a plan P, which produced an artifact A. If C is revoked, writing a new value for C is not enough. The system should ask whether P still has a valid justification; if not, P becomes invalid or uncertain, and so does A. A decision D with no reliance path from C should be left alone. We call this the minimum repair principle: when state changes, reconsider all and only the work whose justification may have changed.
"Only" matters as much as "all." Replanning everything whenever anything changes is safe in the crude sense that nothing old is trusted, but it throws away good work, repeats expensive actions, and introduces new errors. Ignoring the change keeps the work and risks stale decisions. Long-running systems need the selective middle.
Real decisions often have more than one justification. A database chosen because it satisfies both a customer requirement and an infrastructure requirement need not be reopened when one of them changes, if the other still suffices. So each piece of state should carry one or more sets of supports, and remain justified while at least one set is intact. Revision then has four steps: find what changed, follow reliance edges forward, test whether each dependent still has a sufficient support set, and reopen only what does not.
Interruption is the same problem
Now stop the task overnight. Checkpointing exists because restarting from scratch is ruinous: if interruptions arrive at random, once every M hours on average, a task needing W hours of uninterrupted work takes on average M(e^(W/M) − 1) hours when every interruption means starting over. That is about 1.7 times its own length when W equals M, and about 30 times when W is five times M. Regular checkpoints turn that exponential cost back into a linear one.
For agents, preserving the context is not the hard part. A resumed agent must also know which parts of that context still justify future action. Suppose yesterday's plan relied on a file at a particular version, and someone edits the file overnight. The checkpoint is intact; the justification is not. On resume, the system should re-check the volatile foundations of its reliance graph – external observations, credentials, prices, files, remote state – and propagate any change forward.
External effects need the same treatment. If an agent sent an invoice just before a crash, the resumed system must know the effect may already have happened, or resume becomes repeat. Recent work has made recovery for long-horizon agents a research area in its own right: AgentRewind restores agent context and environment state together, and Resume Means Resume specifies what exactly-once effects and resume should mean for persistence layers. In the terms used here, a checkpoint should preserve both what the work's conclusions rely on and what the world may already have been changed by.
Delegation is the same problem again
Now hand part of the work to another agent. "Research European payment providers. Only use providers with data residency in the EU." The second sentence is not another fact about the topic. It bounds the acceptable answers.
Recent experiments show that multi-stage agent workflows routinely keep the words of a constraint while weakening its force: a requirement becomes a consideration, and a blocker becomes a caveat. Seen through reliance, that is a failure to transmit what the delegated work depends on. A correct handoff should carry the slice of the reliance structure the receiving agent's decisions rest on – its constraints, assumptions, authority, and acceptance conditions – rather than a summary of everything the sender knew. That slice is usually far smaller than the full history, which gives delegation a principled context boundary instead of a token budget.
Boundary integrity
Revision, interruption, and delegation share a shape. Before the boundary, the system holds operative state and the relations that justify it. Something transforms that state. Afterwards, future work is correct only if the transformation preserved the dependencies that still matter and invalidated the ones that no longer do.
That suggests one property for long-running agent systems. Boundary integrity: a transformation of agent state should not silently change what later actions are entitled to rely on. A summary can violate it. So can a restart, a memory consolidation pass, a handoff, a model upgrade, and even a correct retrieval that surfaces the right statement without its authority, scope, or superseded status.
The closest prior system we know of is BoardroomAI, which maintains a typed decision graph, propagates human interventions through its dependencies, repairs only the affected part, and preserves the rest. It applies this within structured, human-steered deliberation. Our claim is broader: the same reliance structure should govern revision, recovery with external effects, and delegation across the whole runtime, so that memory, persistence, and coordination become three operations over one maintained structure rather than three separate mechanisms.
How to test it
Build tasks around known reliance graphs: ten decisions, some depending on a pricing assumption, some on a user constraint, some on a file, the rest independent. Partway through, change one foundation. The evaluation then knows exactly which completed work should be reopened and which should survive.
That supports measures that recall accuracy cannot. Following BoardroomAI's evaluation of repair coverage and preservation, we would measure repair recall (the share of genuinely affected work the system reconsiders), repair precision (the share of reconsidered work that needed it), work preservation (unaffected work that survives without recomputation), and, for execution, effect duplication (external actions repeated after recovery). A system that replans everything scores well on recall and badly on precision. A system that updates one stored fact scores well on retrieval and badly on repair recall.
We would compare six state architectures under the same model, tools, and budget – full-history context, retrieval with recency, time- and conflict-aware memory, summary-based checkpoints and handoffs, event-sourced history, and reliance-aware state – across six kinds of boundary event: a superseded value, a revoked instruction, a stale observation, a crash just before or after an irreversible action, a change of scope, and a handoff through one or more agents.
Predictions
- Architectures will score alike on what is the current value? and differ substantially on repair. Retrieval benchmarks will understate the value of reliance.
- Updating old memories without tracking their dependents will raise current-value accuracy far more than repair recall.
- Full replanning will approach the correctness of selective repair on many tasks, at substantially higher cost in actions, tokens, and time.
- Summary-based state will degrade as the number of boundaries grows even with the model held fixed; reliance-aware state will degrade mainly with extraction errors.
- Handoff depth will matter less when each handoff carries an explicit reliance slice.
- Once preservation is reliable, the dominant failure will move upstream, to extraction: the system never noticed that one decision depended on another. That would be progress – a better-located failure than silently losing the relation later.
What would change our mind
If time- and conflict-aware retrieval matched reliance-aware state on downstream repair, not only on current-value questions, explicit reliance would not justify its complexity. If replanning from scratch matched selective repair at comparable cost, dependency tracking would be unnecessary in practice. If reliance cannot be extracted from real agent trajectories accurately enough, the idea may be sound and the architecture unusable. And if capable models can reconstruct the right dependencies from compact history after repeated revisions, restarts, and handoffs, explicit reliance may become redundant. These are empirical questions, and we intend to test them rather than assume the answer.
Agent systems are becoming very good at accumulating records. Long-running work needs something harder: knowing which parts of the work would stop making sense if one belief changed. Memory tells an agent what came before. Reliance tells it what still holds.
