TL;DR for operators
Production-agent prompts can be shortened without a measurable decline in benchmark correctness, but the benchmark must first be trustworthy. A documented optimization failure removed important instructions while passing sampled checks, exposing a risk that aggregate scores can conceal.
A new study addresses this through reproducible evaluation of agents connected to changing business data, followed by correctness-gated prompt optimization. Across three model families, it reports 3.5–7.6% reductions in the complete instruction surface, with a statistically significant correctness improvement for one family.
For teams deciding whether to deploy compressed prompts, the priority is controlling evaluation state, checking actual tool outcomes, and enforcing mandatory business rules. The study provides a credible method for that process, although it does not establish long-term reliability or measured production cost savings.
The instruction disappeared, but the checks still passed
A merchant-facing AI assistant may answer sales questions, retrieve financial information, and modify business records. As capabilities accumulate, its system instructions, skill descriptions, and tool guidance expand. Removing redundant instructions could reduce the number of tokens processed on each request.
The difficult part is determining which instructions are genuinely redundant.
During one prompt-optimization experiment, a candidate lineage passed sampled checks designed to detect harmful changes and missing instructions. A subsequent diagnostic evaluation revealed that its sales-skill score had fallen from 0.90 to 0.00.
The failure, documented in Appendix B of Reproducible Evaluation as the Substrate for Safe Prompt Compression in Production Agents by Prabal Vashisht, Zheng Hu, and Ying Yang, was a diagnostic near-miss rather than evidence that the final optimized prompt was deployed with this defect.1
It demonstrates a specific weakness: instructions can disappear without their behavioral consequences appearing in the sampled evaluations. Checking whether similar wording survives elsewhere in the prompt is insufficient when the surviving text no longer enforces the same requirement.
Another problem arises before optimization begins. If the assistant answers a sales question differently tomorrow, the cause could be a model change, an instruction change, or a change in the underlying merchant records.
Without separating those causes, benchmark comparisons cannot reliably determine whether compression has damaged the agent.
Reproducible evaluation requires controlling business state
The paper’s primary contribution is a sandbox that reproduces the relevant environment encountered by an agent.
Each benchmark datapoint contains three elements: a task, its expected outcome, and the production-state information required to reproduce that outcome.
Rather than copying an entire backend, the framework identifies the state dependencies of individual tool calls.
Section 2.2 distinguishes three cases:
| Tool dependency | Replay mechanism | Evaluation purpose |
|---|---|---|
| Settled reads | Staged clock | Reproduce information associated with a specified time |
| Current-state reads | Frozen tool payloads | Prevent live data changes from altering the expected response |
| Writes | Seeded sandbox state followed by read-back | Compare the actual resulting state with the expected outcome |
The third case changes how agent correctness must be measured.
An assistant that reports a successful record modification has not necessarily performed it correctly. The sandbox checks the resulting record state rather than treating the assistant’s verbal confirmation as sufficient evidence.
This distinction matters for enterprises using agents to change operational data. The consequences of an incorrect action may persist after the conversation ends.
The framework nevertheless has a defined boundary: tool calls outside the staged skill scope may still access unstaged live information. Such calls can produce ordinary evaluation failures without being identified explicitly as replay violations.
Reproducibility therefore depends on accurately identifying the state dependencies exercised by the benchmark.
An executable task is not automatically a valid benchmark
A reproducible environment still needs meaningful questions and expected outcomes.
The paper’s benchmark-generation process restricts a task-generating agent to tools available to the subject agent. Candidate tasks must be supported by successful executable tool-call traces.
This establishes that an expected outcome is achievable through the available capabilities.
It does not independently establish that the task is appropriate or that the expected outcome matches the intended product specification.
For that reason, surviving datapoints undergo human review for validity, capability coverage, and correctness.
The resulting dataset contains 597 datapoints distributed across ten skills:
- 302 training datapoints;
- 99 validation datapoints;
- 196 held-out test datapoints.
The partitions are stratified by skill and task archetype.
An additional feature is the proposed ability to regenerate tasks when production records become stale. Because expected outcomes originate from executable traces against relevant state, the generation process can be rerun against updated information.
This is a benchmark-maintenance mechanism, not a demonstrated longitudinal result. The paper does not report repeated regeneration experiments showing how reliably refreshed benchmarks preserve coverage over time.
GEPA makes compression subordinate to correctness
Once evaluation becomes sufficiently reproducible, the authors apply GEPA, a reflective prompt-evolution method, to reduce instruction length.
The optimization covers the complete textual instruction surface: the base system prompt, ten skill instruction bodies, and shared tool descriptions. This is broader than rewriting a single system message.
Joint optimization can consolidate repeated requirements across components. Appendix C provides a financial-skill example in which redundant display instructions and descriptive wording are shortened without intentionally removing distinct requirements.
The selection procedure places several constraints around this search.
First, a critical-rule gate assigns zero fitness to candidates violating mandatory requirements. Such violations cannot be compensated for by saving tokens.
Second, a per-skill no-harm gate restricts performance declines relative to the original prompt, using a threshold of 0.02 in the reported experiments.
Third, a token-count penalty with coefficient $10^{-6}$ favors shorter candidates only when validation correctness is tied under the specified objective. The optimization also maintains a hybrid Pareto frontier to preserve promising candidates across individual tasks and aggregate performance.
This design differs from accepting a specified amount of correctness loss in return for a shorter prompt. It makes correctness the primary selection criterion.
The Appendix B near-miss explains why the critical-rule gate matters. Sampled per-skill checks and superficial text-presence tests failed to detect a consequential instruction deletion.
However, deterministic checks only cover requirements they are designed to recognize. The resulting safeguard is an implemented eligibility mechanism, not mathematical proof that every mandatory behavior survives compression.
Three model families produce three different results
Section 3, Table 1 compares the original 36,336-token instruction configuration with independently optimized candidates for Anthropic, Gemini, and OpenAI models.
Each optimization received an 800-rollout budget. The held-out evaluation used five rollouts per datapoint and paired bootstrap confidence intervals based on 10,000 resamples.
| Model family | Optimized tokens | Token reduction | Correctness difference (95% CI) |
|---|---|---|---|
| Anthropic | 33,567 | 7.6% | +0.118 [0.073, 0.164] |
| Gemini | 34,380 | 5.4% | +0.016 [-0.001, 0.035] |
| OpenAI | 35,077 | 3.5% | +0.006 [-0.007, 0.021] |
The correctness differences are measured on a 0–1 evaluation scale, with positive values favoring the optimized prompt.
All three families achieved shorter prompts. Only Anthropic’s correctness improvement is statistically distinguishable from zero at the reported 95% confidence level.
For Gemini and OpenAI, the intervals include both zero and small negative differences. The evidence therefore supports compression without a statistically detected regression, but not a formal guarantee of noninferiority.
The model-family variation also prevents treating prompt compression as a transferable configuration improvement. A revision that improves one model’s behavior may produce a different result with another.
These comparisons constitute the study’s main empirical evidence. The financial-skill compression example illustrates the editing mechanism, while the Appendix B failure provides a diagnostic examination of safeguard weaknesses. Neither is a separate controlled ablation establishing the individual effect of a particular framework component.
What an enterprise release decision should require
Cognaptus interprets the research as support for an evaluation-first release process.
For a business operating stateful agents, the immediate implementation sequence is to classify tool dependencies, establish reproducible task environments, verify write outcomes, and define mandatory instructions as explicit eligibility conditions.
Only then does prompt reduction become a meaningful optimization target.
For a release manager deciding whether to replace an existing instruction configuration, the relevant evidence includes held-out correctness, per-skill performance, rule compliance, and the scope of backend state covered by testing.
The economic case also needs separate measurement. A reduction in instruction tokens may lower some inference inputs, but the study does not measure production latency, monetary savings, or downstream business outcomes.
A 7.6% reduction in the evaluated instruction surface should not be represented as a 7.6% reduction in total serving cost.
The remaining uncertainty is production drift
The experiment evaluates one merchant-facing agent, ten skills, and three model families against a frozen benchmark snapshot.
That design supports comparisons between original and optimized prompts under controlled conditions. It does not establish that the performance advantage persists as merchant records change, tools evolve, or task distributions shift.
The 196-point held-out set also cannot exhaustively represent every business rule and interaction. No component-level ablation quantifies how much each safeguard contributes independently.
These boundaries matter most when an organization moves from offline qualification to ongoing production deployment. Regenerating benchmarks and reevaluating compressed instructions are plausible responses to drift, but their long-term effectiveness remains unmeasured here.
The paper’s contribution is consequently more substantial than its modest token reductions suggest. It shows how to make prompt optimization answerable to reproducible evidence, including evidence about actions that change business records.
For production agents, the defensible achievement is not merely a shorter prompt. It is a shorter prompt whose required behavior has survived a clearly specified, reproducible set of tests—and whose untested behavior remains an explicit deployment risk.
Cognaptus: Automate the Present, Incubate the Future.
-
Prabal Vashisht and Zheng Hu and Ying Yang (2026). Reproducible Evaluation as the Substrate for Safe Prompt Compression in Production Agents. arXiv:2610.31972. https://arxiv.org/abs/2610.31972 ↩︎