Agent Trajectory Caches Need Contracts, Not Just Speed

The obvious way to make AI agents faster is to buy a faster model. The more interesting way is to stop asking the model to rediscover the same path every time.

That is where production agent infrastructure is heading. Instead of treating every request as a brand-new ReAct loop, teams are beginning to reuse prior trajectories, substitute new parameters into familiar tool paths, cache agent skills, and even pre-execute likely future actions in isolated snapshots. This is not just prompt engineering. It is a new serving layer for agent work.

The promise is real. A recent paper, TRIAGE, proposes a three-level routing system for agents: directly reuse identical historical queries, substitute parameters into similar trajectories, or fall back to full ReAct for novel work. Its abstract reports 62.3% token savings across 1,007 security-monitoring queries and 76.3% token reduction on ToolBench validation. Another recent paper, Speculative Macro Commit, describes a two-tier runtime in which a faster drafter model predicts and executes future action chains on an isolated environment snapshot while a larger actor model remains authoritative. When the actor’s next action matches the drafted path, the runtime can commit the remaining pre-executed steps. The abstract reports matched accuracy with materially lower latency on evaluated tool-use tasks.

For anyone operating agents at scale, those results point toward an unavoidable conclusion: trajectory reuse will become part of the economics of agent deployment. If an agent answers the same alert class, support workflow, data-cleaning task, or internal operations request thousands of times, forcing it through a fresh reasoning loop on every run is wasteful.

But the shortcut changes the system. A cached trajectory is not a snippet. It is a claim.

It claims that an old path still applies to a new situation. It claims that the tools have the same meaning, the environment has not drifted, the user’s authority is comparable, the inputs are close enough, and any skipped reasoning would not have changed the outcome. If the cached route includes tool calls, it also claims that replaying, substituting, or pre-committing those calls is safe under the current side-effect boundary.

That is too much responsibility for a cache key alone.

The better framing is a trajectory contract. Every reusable agent path should carry a small, inspectable agreement about when it may be used, what evidence it depends on, how it fails closed, and how its benefit is measured.

Start with the route reason. Was this path selected because the query was identical, because a similarity model found a match, because a deterministic parameter substitution succeeded, or because a drafter model predicted the same first action as the authoritative model? Those are different trust levels. “Direct reuse” and “speculative continuation” should not appear identical in logs, dashboards, or incident reviews.

Then define preconditions. A reused workflow should declare the stable inputs it expects: entity type, task class, policy version, tool version, account scope, region, data freshness, and any required permissions. This does not need to be heavy. A compact manifest is enough. The important part is making the runtime prove that the current request still fits the shape of the old trajectory before it skips deliberation.

Evidence matters next. If a trajectory was learned from a historical execution, what observations made that execution valid? Were they live API responses, static documentation, a database schema, a user-provided file, or a policy page that may have changed? The more external facts the path depends on, the shorter its expiration window should be. Teams already set TTLs on ordinary application caches; agent trajectory caches deserve the same discipline, with stronger defaults for anything involving compliance, identity, money, customer messaging, or operational side effects.

Side effects are the hard boundary. It is one thing to reuse a read-only diagnostic sequence. It is another to reuse a path that sends an email, changes a configuration, approves an order, modifies a record, or escalates an incident. Speculative Macro Commit is careful to describe isolated environment snapshots. That distinction is crucial. Speculation is an optimization only when the pre-executed work cannot leak into the real world until an explicit commit point. Without that boundary, “faster” becomes “acted before we knew.”

A useful contract labels every trajectory by side-effect class: read-only, reversible write, externally visible write, privileged action, or irreversible action. The higher the class, the more the system should require fresh model confirmation, human approval, dry-run comparison, or rollback preparation before commit. Some routes should never be cached for automatic execution, no matter how repetitive they look.

Measurement also has to become more honest. The Skill Following paper introduces a warning that applies directly to trajectory caches: aggregate retrieval lift can hide whether a retrieved skill actually helped on the tasks where it was used. In its abstract, the authors describe models that appear to benefit system-wide while showing negative actual-use effect on the specific tasks where retrieval occurred. That is the metric trap for cached agent paths. A dashboard that only reports token savings and overall success can make a harmful route look efficient.

For trajectory reuse, the operational metric should be per-route actual-use benefit. When the cache fires, did it improve the matched task compared with a fresh execution path? Did it reduce cost without increasing correction rate, escalation rate, stale-evidence incidents, or user-visible failures? If not, the cache is not an optimization. It is a hidden defect with a good latency chart.

Long-horizon degradation raises the stakes. The paper How Fast Do Agents Rot? argues that production workflows fail partly because success compounds across dependent steps: even a high per-step reliability eventually collapses over long horizons. Trajectory reuse can help by compressing known-good paths, but it can also concentrate error. If step three is wrong and the system skips straight to step twelve, the failure is faster, cheaper, and harder to notice.

This is why reusable agent infrastructure needs expiration and drift monitoring. A trajectory that worked last week should not be immortal. Tool schemas change. Policies change. Websites change. Customer states change. Even if the model stays fixed, the world around the agent does not. Contracts should include renewal conditions: rerun the full path after a number of uses, after a tool version change, after a policy update, after anomalous downstream results, or after a time-based TTL.

None of this argues against trajectory caches. The opposite is true. Reuse is one of the most practical ways to make agents viable in real operations. Anthropic’s guidance on effective agents has repeatedly emphasized simple, composable patterns over magical autonomy. Trajectory contracts are an extension of that philosophy: keep the shortcut, but make the boundary legible.

The teams that benefit most will not be the ones that cache the most aggressively. They will be the ones that can answer basic operational questions when a cached path fires: Why did we reuse this? What changed since the original run? What evidence was skipped? What side effects were committed? What would a fresh run have done? When does this route expire? Who can disable it?

Agent speed is no longer just a model-serving problem. It is a control-plane problem. The next generation of production agents will route between fresh reasoning, deterministic substitution, skill reuse, and speculative execution. Each route can be valuable. Each route can also be wrong in a different way.

So the standard should be simple: no reusable trajectory without a contract. Speed is welcome when it remains inspectable. Cost savings are useful when they do not erase evidence. And a cached agent path should never be allowed to become an unreviewed policy hiding inside the runtime.