A Cached Agent Result Is a Claim With an Expiry

Caching is appealing because it turns repeated work into a faster response.

For an agent, that simple story breaks down quickly.

A prior result is not just text. It is a claim made for a particular task, at a particular time, with a particular set of sources, constraints, permissions, and observed conditions. Reusing it means asserting that those conditions still apply.

That is often true. It is not true by default.

A cached agent result is a claim that it remains relevant, not merely a value that happens to be available.

HTTP has spent decades making this distinction explicit. RFC 9111 permits a cache to reuse a stored response only under matching and freshness conditions, or after validation. Agent systems do not need to copy HTTP semantics. They do need the same habit of thought: identify what made the earlier result applicable, and test whether it remains applicable before presenting it as current work.

The TVCACHE research preprint makes the same point for tool-using agents in a narrower setting. It argues that naive reuse of tool output can be wrong because tool results depend on the environment state created by prior interactions. The details of its training setup do not define production policy, but the premise travels well: a result that looked reusable in isolation may have depended on a state the next task does not share.

Distinguish the kinds of reuse

“Caching” can describe several different mechanisms. Treating them as one thing creates design mistakes.

• Kind of reuse: Prompt or prefix caching — What is reused: Stable input tokens or model-side computation — Primary question: Is the text prefix stable enough to reduce inference cost?
• Kind of reuse: Retrieval caching — What is reused: A prior source lookup or document representation — Primary question: Is the source still current and appropriate for this query?
• Kind of reuse: Tool-result caching — What is reused: Output from a tool call — Primary question: Does the current task share the relevant environment state and parameters?
• Kind of reuse: Artifact reuse — What is reused: A prior draft, report, plan, or analysis — Primary question: Does the earlier artifact still fit this user, objective, and evidence posture?
• Kind of reuse: Decision-template reuse — What is reused: A structure for approaching similar work — Primary question: Is the template still compatible with the current constraints and tools?

Prompt caching is mostly a performance optimization for common, stable request prefixes. OpenAI's model guidance describes it in those terms. It should not be confused with reusing an answer, a recommendation, or an action plan. Those forms of reuse carry semantic commitments that token caching does not.

Research on test-time plan caching likewise treats plan reuse as sensitive to external data and environment context. Its experimental results do not establish a general production policy, but the distinction reinforces why an agent artifact needs semantic eligibility checks beyond a text match.

For example, an earlier report may be well written and still be inappropriate for a new audience. A past tool result may be accurate and still be wrong for the current environment. A plan template may be broadly useful and still contain a dependency that the new task does not have.

The system therefore needs an eligibility decision, not only a cache lookup.

The Reuse Contract

The Reuse Contract is a proposed record for deciding whether an existing agent result may be reused. It is not a universal cache key and it does not make a prior result correct. It creates a visible basis for using a prior artifact as current work, a bounded draft, an input to revalidation, or something to discard.

• Contract element: Purpose and result identity — What it records: What problem the earlier result addressed and what it was intended to be — Why it matters: Prevents a similar-looking answer from being treated as the same task
• Contract element: Applicability dimensions — What it records: The user-relevant scope, audience, objective, constraints, and source class that must match — Why it matters: Makes the hidden variables of “similar enough” reviewable
• Contract element: Evidence and provenance posture — What it records: Which sources, observations, and inferences the result relied on, including known limitations — Why it matters: Prevents an old conclusion from becoming current evidence without support
• Contract element: Environment and task-state assumptions — What it records: The state, dependencies, or prior effects that the result assumed — Why it matters: Captures why tool output and action plans are especially sensitive to context
• Contract element: Freshness and expiry rule — What it records: When the result becomes stale, and whether it needs validation, refresh, or removal — Why it matters: Makes time a first-class applicability condition
• Contract element: Authority and effect posture — What it records: Whether the result is informative, draft-only, approved for a bounded use, or never an authorization to act — Why it matters: Stops cached material from becoming standing permission
• Contract element: Validation and disposition path — What it records: What must be checked before reuse, and whether the outcome is reuse, adapt, quote as historical, or discard — Why it matters: Gives a resumed or different agent a safe next step

The contract treats reuse as a decision with outcomes. “Cache hit” is only one possible result. The system may instead use the artifact as a starting point, present it as historical context, revalidate it, or reject it.

The same question is rarely the same task

Two user requests can look identical while their applicability conditions differ.

“Summarize current recommendations” depends on the word current. “Draft a response for this customer” depends on the customer, the data boundary, the desired tone, and the factual situation. “Run the same analysis again” may depend on data freshness, source availability, and whether the earlier result altered the environment that the later run now observes.

An agent should therefore distinguish between:

• Reuse posture: Exact reuse — When it is appropriate: The purpose, key dimensions, evidence, state, and freshness conditions all match — How to present it: Show it as current output, while retaining its provenance
• Reuse posture: Reuse with adaptation — When it is appropriate: The structure or some evidence remains useful, but task details changed — How to present it: Label the reused material and show what was rechecked or changed
• Reuse posture: Historical reference — When it is appropriate: The result is no longer current but can explain prior reasoning or offer context — How to present it: Mark it as historical rather than as a current answer
• Reuse posture: Revalidation candidate — When it is appropriate: The result may be useful if specified sources or assumptions are refreshed — How to present it: Hold it until the validation conditions are met
• Reuse posture: Rejection — When it is appropriate: Key scope, state, authority, privacy, or freshness conditions no longer match — How to present it: Do not let it influence the current output as if it were valid

This is not unnecessary caution. It is an honest representation of how long-running agent systems behave in a changing world.

Reuse needs both matching and invalidation

RFC 9111 provides a useful analogy: a response is not reusable just because it was stored. It must match the current request and be fresh, explicitly permitted to be stale, or validated. In an agent system, the matching dimensions are richer than a URI and method. They may include task identity, audience, policy version, source snapshot, location, time, and effect boundary.

The analogy has limits. Agent artifacts are not HTTP responses, and teams should not import protocol directives mechanically. The transferable principle is that reusability requires a declared match and a declared invalidation path.

Common invalidation triggers include:

• a source used as evidence has changed or crossed its freshness threshold;
• the user's objective, audience, or constraints differ materially;
• the relevant environment or task state changed;
• a prior effect makes the old recommendation no longer appropriate;
• the authority or approval condition expired or was revoked;
• a tool, model, or policy change changes the meaning of the earlier result; or
• the result cannot establish what it assumed when it was created.

Teams often focus on cache keys because they are convenient to implement. The harder and more valuable question is invalidation: what event makes this result unsafe to reuse without a new check?

Do not confuse cost savings with epistemic savings

A cached response can reduce latency and compute costs even when it should not be trusted as a current answer. That distinction matters.

Prompt caching, for example, can make a model call cheaper when a request begins with stable instructions and tool definitions. It does not make the response's factual claims current, and it does not preserve approval or task-state validity. Likewise, a cached research artifact can save a new agent time by providing a starting point, but it should not bypass source verification for a time-sensitive claim.

This yields a useful policy:

• reuse stable structures aggressively when they do not claim new facts or authorize effects;
• reuse evidence conditionally when sources and freshness requirements still match;
• reuse tool outputs only when relevant state equivalence can be established;
• reuse decisions only when authority, scope, and downstream effects remain bounded; and
• always disclose when a current output relies materially on earlier work.

The policy does not eliminate reuse. It directs reuse toward the cases where it saves work without hiding a stale assertion.

Make cached results visibly aged and attributed

If a result was not generated for the current interaction, its age and origin are part of the answer.

The user may not need raw internal identifiers. They do need enough context to decide whether a result still serves their purpose:

• when it was generated or last validated;
• what it was originally for;
• which sources or environment it depended on;
• what changed, if anything, for this use;
• what has not been rechecked; and
• whether it is a proposal, historical reference, or current answer.

This display layer is a trust feature. It prevents a system from presenting a recycled result with the confidence of a fresh observation.

It also helps in handoffs. A different agent can see whether it should treat an artifact as reusable evidence, a draft to adapt, or a stale record to ignore.

Evaluate cache correctness, not only hit rate

Hit rate and saved latency are valuable, but they can reward dangerous behavior if reused answers are out of date or out of scope.

Add outcome measures such as:

• Applicable-hit rate: What share of cache hits were still valid for the current task after matching and validation?
• Stale-reuse rate: How often did a reused result need material correction because an assumption, source, or environment state changed?
• Invalidation latency: How long did it take for a known changing condition to prevent future reuse?
• Disclosure coverage: How often did users see the age and reuse posture of a material prior artifact?
• Adaptation cost: When a near match was reused as a draft, how much work was required to make it current and correct?
• False-miss rate: How often did the system recompute work that a contract would have shown was safely reusable?

The aim is balance. A perfect system that never reuses anything wastes resources; a fast system that reuses without condition loses trust. The contract makes that tradeoff measurable.

A practical adoption path

1. Inventory the kinds of material your agent already reuses: prompts, source retrievals, tool outputs, reports, plans, or templates.
2. Separate performance caching from semantic reuse in the architecture and the user interface.
3. For one high-value artifact type, define the seven Reuse Contract elements.
4. Name the invalidation events before optimizing the cache key.
5. Show users when a current output relies on material from a prior run, without exposing private implementation details.
6. Test same-looking tasks that differ in source freshness, audience, environment state, authority, and effect scope.
7. Track applicable-hit rate alongside cost and latency, then expand reuse only where the quality signal remains strong.

The useful rule is concise: reuse a result because it is still applicable, not merely because it is nearby.

What we are learning building Virillio Code

Virillio Code is in development. High-level work around durable task state, context handling, and recoverable execution suggests that reuse should preserve the reason a prior result is relevant to the current task. The Reuse Contract is a proposed educational framework, not a description of a released caching system.

Sources and further reading

• RFC 9111: HTTP Caching — Reuse in HTTP depends on request matching, freshness, permitted stale behavior, or successful validation.
• TVCACHE: A Stateful Tool-Value Cache for Post-Training LLM Agents — Naively caching tool output can be incorrect when tool outputs depend on environment state induced by prior agent interactions.
• OpenAI Model Guidance — Prompt caching is a performance mechanism for stable prompt prefixes and is distinct from semantically reusing an agent result.
• Agentic Plan Caching: Test-Time Memory for Fast and Cost-Efficient LLM Agents — Agent-plan reuse has different constraints from ordinary chatbot caching because plans depend on external data and environment context.

Editorial disclosure

This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.