How to Reuse Agent Work Without Serving Stale Data

The answer changes. The way you find it may not.

Imagine an agent that prepares a daily account brief. It checks the customer record, finds recent support tickets, looks for an open incident, and summarizes what changed.

The information is different every day. The work is not.

Many production agents repeatedly spend model time deciding which read-only systems to consult and in what order. Teams often assume they have only two choices: pay for fresh reasoning every time, or cache an answer that may become stale. There is a third choice. Reuse the proven plan, then perform the reads again.

That distinction matters because the most reusable part of an agent run is often not its final sentence. It is the dependable process that leads to the sentence.

Why final-answer caching is often the wrong tool

Caching a final response can be excellent for fully stable work. If the same input should produce the same output and freshness is not a concern, there is little value in paying a model to repeat itself.

Operational work is rarely that simple.

A support queue changes by the minute. A CRM contact is updated. A payment status changes. An incident is resolved. A pricing page is revised. The request may look identical while the correct answer depends on the current state of another system.

Serving an old answer in those situations is not optimization. It is a freshness failure.

The mistake is treating “do not cache the answer” as “nothing can be reused.” An agent can still avoid rediscovering a stable read-only process.

Reuse the map, not yesterday’s destination

Plan reuse is like following a familiar route with a new errand.

The steps might be:

Read the authorized account record.

Search the account’s open tickets.

Check whether any active incident affects the account.

Return the current records to the answering step.

The agent does not need a new strategic insight to choose those sources every time. If enough real runs show that the same request family reliably uses the same declared tools, a reusable plan can replace the repeated planning call. The tools still run. The data still comes from the source system. The answer is still built from current information.

This can improve cost and speed without pretending that yesterday’s record remains true today.

Freshness is still a decision

Re-running a tool does not automatically make a workflow safe.

The runtime must still know which identity is making the request, what data that identity may access, and whether the tool is genuinely read-only. Arguments must be derived correctly. Tool schemas can change. An external system can fail. Some reads have their own caching rules and time-to-live requirements. Punk's tool observability and caching guide explains why declared behavior, scope, and freshness belong in that decision.

A qualified plan therefore needs conditions:

It applies to a defined request family.

It references declared tools with known behavior.

It remains inside the same tenant, app, and subject boundaries.

Its arguments can be derived without guesswork.

Its source reads are current enough for the task.

It has a live-model fallback when the pattern no longer fits.

The plan is reusable only while those conditions remain true.

Read-only work is the right place to start

There is a meaningful difference between looking up an account and changing it.

A read-only plan can fetch fresh information without creating an external consequence. A plan that sends a customer message, issues a refund, edits a record, or changes access has a different risk profile. Repeating that plan may also repeat a mistake.

That does not mean write workflows can never be improved. It means they need stronger controls: explicit policy, dry-run or suppressed effects during evaluation, appropriate approval, idempotency, and a rollback story.

For a first use case, choose work where the plan reads and the human or existing live system decides what happens next.

A narrow public result

Punk published a dated benchmark using historical public vLLM GitHub issue identifiers. In the held-out treatment described on the proof page, Punk produced 50 exact reusable artifact plans, made zero treatment model-planning calls, and still performed 50 live GitHub reads.

The important part is not only the absence of treatment model calls. The source records were still read live. The reusable element was the tool plan.

The result is deliberately narrow. It was a Punk-sponsored benchmark, not customer production traffic. vLLM is not a Punk customer. The study does not show that all agent plans can be reused, that every output was optimized, or that a production customer achieved a particular savings rate. Its value is demonstrating the distinction between repeated planning and fresh retrieval with inspectable scope and denominators.

Where Punk fits

Punk observes supported model traffic and declared or instrumented tool behavior, then looks for work that repeats. Depending on the workload, the reusable unit might be an exact answer, a safe tool result, a plan that still performs fresh reads, or a tested declarative workflow. The cost optimization playbook puts those options in a broader workload-level framework.

That hierarchy matters. The runtime should not force every repeated request into the same cache. It should choose the simplest path that remains eligible for the current identity, freshness need, policy, and risk.

For teams, the practical question becomes more useful than “Can we cache this agent?”

Ask instead:

Which part of this run needs to be new, and which part has already been learned?

A good first candidate

Look for a recurring internal question with a clear sequence of read-only sources:

“Summarize this account’s current support state.”

“Find the latest approved policy for this request.”

“Check whether this customer is affected by an open incident.”

“Collect the current billing and renewal facts for this review.”

Then review the traces. Does the agent use the same sources? Are tool arguments predictable? Does the sequence remain within one permission scope? Is there a person who can judge whether the result is complete?

If the answer is yes, the planning step may be a stronger optimization candidate than the final answer.

The boundary

Plan reuse does not guarantee correctness, freshness, or savings. A plan can become stale when tools, schemas, policies, or workload behavior change. A live read can still return incomplete or erroneous information. Novel requests should remain live.

The approach is useful because it narrows the claim: reuse a qualified method while continuing to consult the current source of truth.

What to remember

Fresh information does not always require fresh planning.

Reusing a read-only plan is different from caching a final answer.

Identity, tool declarations, freshness, policy, and fallback remain part of the route.