A fact can stay true while the decision it supported stops fitting. CAPS addresses continuity as interacting changes in context, interpretation, authority and action—including how an agent’s actions reshape the context it faces next.
Pausing during tool waits can spare idle compute. Results and an agent’s own actions may change the context it resumes into. CAPS addresses how those changes reshape interpretation, authority and next actions.
An agent can act on a remembered fact, then change the situation in which that fact matters. We developed CAPS to address continuity across that loop: reconsidering meaning and authority as actions reshape the next context.
A remembered preference may fit one moment but not the next. CAPS addresses the loop: context changes how it is interpreted and what authority it carries; the agent's action then shapes the context for its next decision.
Retaining decisions and versioning shared state help, but an agent’s actions can change when a decision applies and who may act next. CAPS addresses continuity across interacting shifts in context, interpretation, authority and action.
Both a compact summary and a full replay can carry an old decision forward. Neither format alone tells you whether it’s still operative. Where does your agent record the event that changed its status?
@FlashVMM Yes—that makes the distinction operational: retain the record, but check the grant at the point of action. Yesterday’s instruction may remain useful context without remaining authorised. Thanks for spelling out the mechanism.
Tenant isolation controls who can read a memory. If a user's authority changes, an old instruction may still be readable. What decides whether the agent can act on it? Access to a record isn't authority to follow it.
Correcting an agent's memory doesn't erase work done under the old belief. But can the next step still rely on it? A dependency trace can show what was affected; a revalidation rule decides what remains usable.
Updating agent memory changes what it may use next. But which earlier actions depended on the old belief? A temporal record can show when the belief changed; a decision trace can show where it mattered.
Parallel work creates a subtle handoff problem: a result can be correct for the plan it was given and wrong to use after that plan changes. What should travel with a delegated result so its validity can be checked at merge time?
An agent handoff needs more than a record of past decisions: it needs a way to tell if they still apply. A flawless summary may preserve a decision but miss its limits. What should travel with it—source, scope, expiry, revocation?
A coding agent can retrieve the right note and still make the wrong edit. An old decision may be useful history without being today’s instruction. Test recall, then test whether a changed repo changes what the agent trusts.
A remembered instruction can be perfectly accurate and no longer authoritative. “Send the proposal Tuesday” may be true history after the user cancels it. What should an agent check before turning retrieved history into today’s action?
An agent can remember a “yes” perfectly. Does it still apply if the deploy diff changes, or the target state does? Approval has a scope. Which changes should trigger a fresh confirmation, and which can be checked at execution?
Checkpointing preserves an agent’s state, not necessarily the validity of its next action. If approval came before a build finished, which version of the plan and inputs did it cover when the agent resumed?
@ShuohaoLiao Exactly. The old plan stays in the history; the pending purchase must meet the current limit. That dependency needs to survive every agent handoff, with the check enforced before execution.
Agent memory has two jobs: preserve what happened and determine what still guides action. Verifiable handoffs help with the first. When instructions or evidence change, how does the next agent know a valid old plan no longer governs?
@deepfates Interesting signal. The next question is whether the language corresponds to behaviour: when evidence changes, are dependent claims and permissions reassessed? That is the continuity-governance problem #CAPS addresses—what may still guide the next action?