Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models

ArXiv: 2510.04618

🎯 Pitch

Conventional prompt optimization systematically erases domain-critical details in pursuit of brevity, inducing a 'context collapse' that sees iterative rewrites degrade into generic instructions. ACE instead treats context as an evolving, structured playbook that accumulates and refines strategies, achieving a 10.6% average accuracy boost on agents and matching a top production system while using a smaller open-source model.

---

1. Executive Summary

This paper introduces ACE (Agentic Context Engineering), a framework that treats LLM input contexts as evolving playbooks that accumulate, refine, and organize strategies through a modular process of generation, reflection, and curation — rather than compressing them into concise summaries. Evaluating across agent benchmarks (AppWorld with DeepSeek-V3.1) and domain-specific reasoning tasks (FiNER and Formula for financial analysis), ACE consistently outperforms strong baselines by an average of 10.6% on agents and 8.6% on domain-specific benchmarks, while reducing adaptation latency by 86.9% and achieving up to 4× compute efficiency gains through incremental delta updates that avoid costly monolithic context rewrites. On the AppWorld leaderboard, ACE matches the top-ranked production-level agent on overall average and surpasses it on the harder test-challenge split despite using a smaller open-source model, establishing that comprehensive, evolving contexts enable scalable self-improvement yet depend critically on the availability of reliable execution feedback or ground-truth signals to guide the Reflector's judgments.

2. Context and Motivation

The Core Problem: Context Adaptation Works, But Systematically Sheds Useful Information

The fundamental tension this paper tackles is that modern LLM systems increasingly depend on context adaptation — improving model behavior by modifying inputs (system prompts, memory, evidence) rather than updating weights — yet existing adaptation methods exhibit a systematic failure mode: they optimize for concision at the expense of comprehensiveness. This matters because in complex applications like multi-turn agents and domain-specific reasoning, success hinges on retaining detailed, task-specific knowledge that generalized summaries simply cannot capture.

The paper frames its contribution around two specific, named failure phenomena that prior work either overlooked or implicitly encouraged (Section 2.2):

Brevity Bias. Many prompt optimizers explicitly prioritize concise, general-purpose instructions over accumulating detailed domain knowledge. The authors cite GEPA (Agrawal et al., 2025) as a representative example — its genetic Pareto search maintains a frontier of high-performing prompts and explicitly treats brevity as a strength. But such abstraction "can omit domain-specific heuristics, tool-use guidelines, or common failure modes that matter in practice" (Section 1). The paper further documents evidence from Gao et al. (2025), who observed that iterative prompt optimization for test generation repeatedly collapsed toward near-identical generic instructions (e.g., "Create unit tests to ensure methods behave as expected"), sacrificing diversity and propagating recurring errors across iterations.

This is not merely a theoretical concern. In domains like financial analysis with XBRL data (FiNER, Formula) or multi-step agent interactions with APIs (AppWorld), the difference between correct and incorrect behavior often turns on specific rules, edge cases, and procedural knowledge — the precise kind of detail that brevity-optimizing methods systematically discard.

Context Collapse. The second, more dramatic failure is context collapse: when an LLM is tasked with fully rewriting accumulated context at each adaptation step, large contexts tend to collapse into much shorter, less informative summaries, causing sudden and severe performance degradation. The paper provides a concrete case study on AppWorld (Section 2.2): at adaptation step 60, the context contained 18,282 tokens and achieved 66.7% accuracy; at step 61, monolithic rewriting collapsed it to just 122 tokens with accuracy dropping to 57.1% — worse than the 63.7% baseline without any adaptation at all. The paper emphasizes that while this case study is demonstrated through Dynamic Cheatsheet, "the issue is not specific to that method; rather, it reflects a fundamental risk of end-to-end context rewriting with LLMs, where accumulated knowledge can be abruptly erased instead of preserved."

The underlying mechanism is straightforward: as context grows large, the LLM performing the rewrite — which has a finite attention budget and a tendency toward summarization — compresses it. But the compression is lossy in exactly the wrong way: it drops the specific, granular insights that made the accumulated context valuable in the first place. This is analogous to catastrophic forgetting in neural networks, but operating at the context level rather than the weight level.

Why This Problem Matters: The Shift Toward Context-Rich AI Systems

The paper situates its motivation within a broader architectural shift in AI systems. Three converging trends make context adaptation increasingly central — and the need for comprehensive contexts increasingly acute:

1. The rise of compound AI systems and agents. Modern LLM applications are rarely single-turn prompt-response interactions. They are compound systems (Zaharia et al., 2024) where the LLM interacts with tools, APIs, databases, and other models across multiple turns. In these settings, context serves multiple critical functions simultaneously: system prompts that guide task execution, memory that carries past facts and experiences (Suzgun et al., 2025; Xu et al., 2025), and factual evidence that reduces hallucination (Asai et al., 2024). An agent navigating AppWorld's simulated environment needs to remember API-specific pagination rules, identity resolution strategies (e.g., "use Phone contacts, not Venmo descriptions to find roommates"), and common failure modes — all of which are too numerous and too specific to compress into a concise instruction without performance loss.

2. Long-context LLMs enable richer inputs. Advances in context window extension (Peng et al., 2024), long-context fine-tuning (Mao et al., 2024), and context-efficient inference through KV cache reuse (Gim et al., 2024; Yao et al., 2025) have made it increasingly practical to deploy systems with very long contexts. This enables a paradigm shift: rather than carefully curating minimal prompts, practitioners can saturate contexts with abundant, potentially useful information and let the LLM distill relevance autonomously at inference time (Jiang et al., 2025; Chung et al., 2025; Chen et al., 2025). The paper explicitly argues that "LLMs are more effective when provided with long, detailed contexts and can distill relevance autonomously" (Section 1) — a claim supported by recent empirical evidence (Liu et al., 2025b; Suzgun et al., 2025).

3. Context adaptation is cheaper and more interpretable than weight updates. Adapting through contexts rather than model weights offers several practical advantages:

• Interpretability: contexts are human-readable, enabling developers to inspect, debug, and manually curate what the model sees (Wei et al., 2022; Wang et al., 2023)
• Rapid integration: new knowledge can be incorporated at runtime without retraining (Lewis et al., 2020; Borgeaud et al., 2022)
• Cross-model sharing: well-crafted contexts can be shared across different models or modules in a compound system (Khot et al., 2023)
• Selective unlearning: when context entries need to be removed for privacy or legal reasons, context-based approaches enable surgical deletion rather than costly model retraining (Section 5)

These advantages make context adaptation "a central paradigm for building capable, scalable, and self-improving AI systems" (Section 1). But realizing this potential requires solving the brevity bias and context collapse problems — otherwise, adaptation methods that start with rich context will inevitably converge toward impoverished summaries.

Where Existing Approaches Fall Short

The paper evaluates its contributions against a carefully chosen set of baselines that span the current landscape of context adaptation methods. Their limitations provide the direct motivation for ACE's design choices:

Prompt optimization methods (GEPA, MIPROv2). These treat context adaptation as a search over instruction prompts, using evolutionary algorithms (GEPA) or Bayesian optimization (MIPROv2) to find prompts that maximize validation performance. Their fundamental limitation is representational: they optimize a single monolithic instruction. This representation cannot express the hundreds of granular strategies, API-specific rules, and common-failure-mode warnings that an agent or domain reasoner needs.

A concrete example illustrates the gap. GEPA's optimized prompt for AppWorld (Figure 8, Appendix F) contains high-level domain strategies like "When splitting bills among roommates, remember to: first identify roommates using phone app's search_contacts with 'roommate' relationship query..." This is useful but compressed — it condenses multiple specific tactics into a single paragraph and inevitably omits edge cases, alternative approaches, and details about pagination, error handling, and identity resolution that only a more comprehensive playbook can capture.

The paper provides quantitative evidence of this limitation in Table 1: on AppWorld, GEPA achieves 46.4% average accuracy (a 4.0% improvement over the base ReAct agent), while ACE achieves 59.4% (a 17.0% improvement). For domain-specific tasks (Table 2), GEPA achieves 72.5% average on FiNER and Formula combined (a 3.4% gain), while ACE achieves 81.9% (a 12.8% gain). These gaps — 11.9 and 9.4 percentage points respectively — reflect the difference between a single optimized instruction and a comprehensive, structured playbook.

Test-time memory methods (Dynamic Cheatsheet). Dynamic Cheatsheet (DC) is the most directly comparable baseline because it shares ACE's agentic architecture: an external memory is continuously updated with reusable strategies and code snippets during inference. The paper uses DC's cumulative mode (DC-CU) as its primary adaptive baseline, which "rewrites the cheatsheet as a whole" at each update step.

The critical limitation is the monolithic rewrite mechanism. Because DC regenerates the entire memory from scratch at each step, it inherits the context collapse vulnerability. The paper's ablation study in Appendix §A.5 quantifies the impact: running ACE without incremental updates (i.e., with monolithic rewrites similar to DC) drops AppWorld test-normal performance from 70.3% to 56.9% average — a 13.4-point gap. This confirms that incremental updates are not merely an efficiency optimization but are essential for preserving accumulated knowledge.

Additionally, DC is "mainly evaluated on single-turn reasoning benchmarks (e.g., AIME, Game-of-24, GPQA) where each query is independent" (Appendix §C.2). In these settings, the benefit of memory comes primarily from saving short, reusable heuristics and executable code artifacts. ACE targets the more demanding regime where multiple distinct strategies, domain rules, and procedural guidance must coexist — settings where monolithic rewriting is especially prone to collapse.

In-context learning (ICL). Many-shot ICL (Agarwal et al., 2024) provides the model with task demonstrations in the input prompt but does not actively curate or update the context. The demonstrations are static — they don't evolve based on execution feedback, don't capture strategies that emerge across multiple episodes, and don't reflect lessons learned from failures. On AppWorld (Table 1), ICL provides only a modest 3.6% improvement over the base agent, compared to ACE's 17.0% — demonstrating that static demonstrations cannot substitute for actively accumulated and curated experience.

How ACE Positions Itself

The paper frames ACE as addressing a specific gap that sits between two established approaches:

• Prompt optimizers produce concise, general instructions but lose domain-specific detail
• Test-time memory methods accumulate experience but suffer context collapse from monolithic rewriting
• ACE accumulates comprehensive, structured contexts through incremental updates, preventing collapse while retaining the rich detail that agents and domain reasoners require

The paper's central thesis is stated explicitly in Section 1:

"We argue that contexts should function not as concise summaries, but as comprehensive, structured playbooks that are detailed, inclusive, and rich with domain insights. Unlike humans, who often benefit from concise generalization, LLMs are more effective when provided with long, detailed contexts and can distill relevance autonomously."

This positioning implies a different optimization objective: rather than maximizing a validation metric with minimal context length, ACE maximizes performance by preserving and organizing as much useful information as possible, working within the LLM's context window as a budget rather than treating context length as a cost to minimize. The "playbook" metaphor — borrowed implicitly from Dynamic Cheatsheet but implemented with a fundamentally different update mechanism — captures this philosophy: a sports playbook doesn't compress all strategies into one paragraph; it maintains a structured catalog of plays, each addressing specific situations, that the team can reference as needed.

The paper explicitly connects its design choices to the two identified failure modes: incremental delta updates directly address context collapse by "replacing costly monolithic rewrites with localized edits" (§3), and the grow-and-refine mechanism addresses one potential downside of comprehensiveness — unbounded growth — through periodic de-duplication and pruning (§3.2). Together, these mechanisms enable the system to accumulate knowledge without either compressing it away or growing endlessly.

Finally, the paper positions its contribution within a broader vision of self-improving LLM systems that learn from execution feedback without requiring labeled supervision. Section 4.3 demonstrates that ACE achieves a 14.8% improvement over the base agent on AppWorld without access to ground-truth labels — it leverages only naturally available execution signals (code execution success/failure, API responses, unit test results) to guide the Reflector and Curator. This is significant because labeled data is scarce and expensive in many deployment settings, making feedback-driven adaptation a more practical path to continuous improvement than supervised fine-tuning.

3. Technical Approach

3.1 Reader Orientation

The ACE framework is a system that improves how language models solve complex tasks by automatically building and maintaining a detailed, structured reference guide (a "playbook") from execution experience, rather than relying on short, generic instructions. It solves the problem of context collapse and brevity bias by decomposing the context-update workflow into three specialized LLM roles that work together to extract insights from successes and failures and then carefully append those insights to the playbook through small, localized edits instead of rewriting the entire thing from scratch.

3.2 Big-Picture Architecture (Diagram in Words)

The system has four major components organized in a loop:

1. The Playbook (context): A structured, itemized collection of "bullets" — small, self-contained units of knowledge (strategies, API rules, common mistakes, domain concepts). Each bullet has metadata (a unique ID, counters for how often it was marked helpful or harmful) and content. This is what gets fed to the Generator as context, and it is what gets updated based on execution feedback.

2. The Generator: An LLM that receives a task query plus the current Playbook as context, produces a reasoning trajectory and a final answer, and simultaneously annotates which Playbook bullets were helpful or harmful during execution. This is the "worker" component that actually solves the task.

3. The Reflector: An LLM that receives the full execution trajectory (model reasoning, environment feedback, ground truth when available, unit test results), critiques what went wrong (or right), identifies root causes of errors, and distills these into concrete, actionable insights. It also tags each Playbook bullet as helpful, harmful, or neutral based on the current execution.

4. The Curator: An LLM that receives the Reflector's insights plus the current Playbook. It identifies which insights are genuinely new (not already captured in existing bullets) and proposes compact "delta" entries — small additions or modifications to the Playbook. A lightweight, non-LLM merger then integrates these deltas deterministically into the Playbook, handling de-duplication via semantic embeddings and updating metadata counters.

Information flow: A task query enters → Generator reads the current Playbook and produces a trajectory+answer → Reflector analyzes the trajectory against execution feedback and produces structured insights + bullet tags → Curator filters for novelty and proposes delta context items → Merger applies these deltas to the Playbook (de-duplicating, pruning). The updated Playbook is available for the next query. This loop operates both offline (processing a fixed training split iteratively, potentially for multiple epochs) and online (updating after each test sample sequentially).

3.3 Roadmap for the Deep Dive

• First, the Playbook data structure and the bullet abstraction — since all three agentic roles (Generator, Reflector, Curator) read from and write to this shared context representation, its design constraints dictate everything else.
• Second, the Generator's mechanics — what it receives, how it uses the Playbook, what feedback it produces (bullet helpful/harmful tags), and how this feedback flows into the adaptation loop.
• Third, the Reflector — the core diagnostic component that converts execution traces into structured insights and bullet evaluations. This is where the paper's division of labor most diverges from prior work like Dynamic Cheatsheet.
• Fourth, the Curator and the merge mechanism — how ACE achieves incremental delta updates, why this prevents context collapse, and the deterministic, non-LLM logic that handles de-duplication and pruning.
• Fifth, the grow-and-refine mechanism — how ACE balances accumulating detail against unbounded context growth.
• Sixth, the offline and online adaptation protocols — how these components are orchestrated in practice, including multi-epoch training, hyperparameter choices, and the feedback signal requirements.

3.4 Detailed, Sentence-Based Technical Breakdown

This is primarily a systems-design paper whose core idea is that context adaptation should be decomposed into specialized roles (generation, reflection, curation) operating on a structured, itemized representation with incremental updates, rather than performed as end-to-end monolithic rewriting by a single LLM call.

---

The Playbook: Structured Bullet-Based Context Representation

The central data structure underlying ACE is the Playbook, a collection of structured, itemized "bullets" that collectively constitute the context passed to the Generator at inference time. The concept of a bullet builds on the "memory entry" abstraction from Dynamic Cheatsheet and A-MEM but extends it with explicit metadata for tracking and feedback (Section 3.1).

Bullet structure. Each bullet consists of two parts:

1. Metadata, which includes:

   • A unique identifier (bullet_id), enabling fine-grained reference and targeted updates.
   • Helpful and harmful counters — integers tracking how many times the Generator has flagged this bullet as helpful or harmful during execution. These counters serve as a lightweight quality signal without requiring explicit human labels.

2. Content, which captures a single, self-contained unit of knowledge. The paper gives examples across domains: a reusable strategy (e.g., "always use while True loops for pagination, not fixed range"), a domain concept (e.g., specific XBRL entity types in finance), a common failure mode (e.g., "do not identify roommates from Venmo descriptions; use Phone contacts"), or an API-specific rule (e.g., "the show_contents() API returns a list of content_ids, not content objects"). Critically, each bullet is meant to be atomic — conveying one coherent insight — so that it can be independently evaluated, updated, or removed without affecting other bullets.

Why itemized bullets instead of free-form text. The itemized representation enables three properties that free-form contexts lack:

• Localization: when an error occurs, the Reflector can point to specific bullets that were misleading or missing, and the Curator can add or update exactly those entries without touching unrelated content. This is what makes incremental delta updates possible — if the context were monolithic prose, any modification would require rewriting the entire thing.

• Fine-grained retrieval: at inference time, the Generator can explicitly annotate which bullets it used and whether they helped or hurt (Section 3.1: "When solving new problems, the Generator highlights which bullets were useful or misleading"). This provides a learning signal — over time, bullets that are consistently flagged as harmful can be pruned, and bullets that are consistently helpful accumulate positive counters that prevent accidental deletion.

• Incremental adaptation: because bullets are independent units, multiple deltas (new bullets, counter updates) can be merged in parallel by non-LLM deterministic logic, bypassing the need for the LLM to see and process the entire context during updates.

The Playbook as a "comprehensive playbook" rather than a concise summary. The paper deliberately contrasts ACE's bullet philosophy with the brevity bias of prompt optimizers. Rather than treating context length as a cost to minimize, ACE treats the LLM's context window as a budget to fill with potentially useful information. The rationale is the empirical observation (Section 1) that "LLMs are more effective when provided with long, detailed contexts and can distill relevance autonomously." The Playbook is intended to be "detailed, inclusive, and rich with domain insights" — the model itself decides which bullets matter for a given query during inference, rather than having a human or an optimizer pre-filter what's "important."

---

The Generator: Task Execution with Playbook-Guided Reasoning

The Generator is the component that actually solves tasks. It receives two inputs at each invocation (see Figure 9 in Appendix F for the full prompt):

1. The task query — specific to the benchmark (AppWorld task description, FiNER financial entity recognition query, Formula numerical reasoning problem, etc.)
2. The current Playbook — formatted as a structured block of bullets, each with its ID and metadata.

Generator responsibilities. The Generator performs two functions simultaneously:

1. Task execution: it reasons about the query, referencing relevant Playbook bullets where applicable, and produces a final answer. For AppWorld, this involves multi-turn code generation with environment interaction (API calls, file system operations). For domain-specific benchmarks like FiNER, it produces a structured analysis and final prediction. The prompt explicitly instructs the Generator to "Read the Playbook first, then execute the task by explicitly leveraging each relevant section."

2. Bullet feedback: the Generator annotates which bullets it actually used during reasoning and whether each was helpful, harmful, or neutral for producing the correct answer. In the FiNER prompt (Figure 12, Appendix F), this is an explicit output field: bullet_ids — a list of IDs for bullets that were "relevant, helpful for you to answer this question." In AppWorld, the feedback is implicit in the Reflector's analysis but originates from the Generator's trajectory.

Why this dual output matters. The bullet feedback creates a learning loop without requiring ground-truth labels. For online adaptation (where the correct answer is unknown), the Generator can still report which bullets it found helpful based on execution signals (e.g., code ran successfully, API returned expected format). Over many queries, this feedback accumulates in the metadata counters, enabling the Curator and grow-and-refine mechanisms to make data-driven decisions about which bullets to retain, refine, or prune — even in the absence of ground truth.

Concrete example from AppWorld. The Generator prompt (Figure 9, Appendix F) includes the instruction: "Treat the cheatsheet as a tool. Use only the parts that are relevant and applicable to your specific situation and task context, otherwise use your own judgement." This is important: ACE does not force the Generator to use every bullet. The Generator is the expert at inference time that decides relevance, while the Reflector and Curator are the experts at adaptation time that decide what knowledge the Playbook should contain.

---

The Reflector: Diagnostic Reflection and Insight Extraction

The Reflector is the diagnostic component that analyzes execution trajectories and distills them into structured insights. This is the paper's most significant architectural addition beyond Dynamic Cheatsheet, which conflates evaluation, insight extraction, and curation into a single LLM call that rewrites the entire memory.

Inputs to the Reflector. The Reflector receives a rich set of signals designed to provide full context for diagnosis (Figure 10, Appendix F for the AppWorld prompt; Figure 13 for FiNER):

• The model's reasoning trace: the complete step-by-step thought process and actions the Generator took, including intermediate outputs, code snippets, and decisions.
• Environment feedback: execution results, API responses, error messages, unit test reports. For AppWorld, this includes the test report (showing which unit tests passed/failed) and the full agent-environment trajectory. For FiNER, it includes the ground truth answer (when available) and the raw model output.
• The current Playbook bullets used by the Generator: the Reflector evaluates whether each bullet was genuinely helpful or whether it contributed to an error.
• Ground truth code or answer (optional): when available in the supervised setting, the Reflector compares the Generator's output to the ground truth to identify conceptual gaps. Critically, the paper shows that ACE remains effective even without this signal (Section 4.3), because execution feedback (code failure, API error responses, unit test results) often provides sufficient diagnostic information.

Reflector responsibilities. The Reflector produces a structured analysis with several specific fields (explicitly defined in the prompt):

1. Error identification: "what specifically went wrong in the reasoning?" This is not a generic assessment but a concrete diagnosis grounded in the execution trace. For example (from the AppWorld Reflector prompt example): "The agent used unreliable heuristics (keyword matching in transaction descriptions) to identify roommates instead of the correct API (Phone contacts)."

2. Root cause analysis: "why did this error occur? What concept was misunderstood?" This pushes beyond surface-level error description to identify the conceptual gap. Example: "The agent misunderstood the data architecture — it assumed transaction descriptions contained reliable relationship information, when the Phone app is the authoritative source for contact relationships."

3. Correct approach: "what should the model have done instead?" A concrete, step-by-step alternative path. Example: "First authenticate with Phone app, use apis.phone.search_contacts() to identify contacts with 'roommate' relationship, then filter Venmo transactions by those specific contact emails/phone numbers."

4. Key insight: "what strategy, formula, or principle should be remembered to avoid this error?" This is the distillate — the reusable lesson that should be added to the Playbook. Example: "Always resolve identities from the correct source app — Phone app for relationships, never rely on transaction descriptions or other indirect heuristics which are unreliable."

5. Bullet tags: a list mapping each Playbook bullet used by the Generator to one of ["helpful", "harmful", "neutral"]. This is the feedback signal that updates the Playbook's metadata counters. A bullet tagged "harmful" will have its harmful counter incremented; over time, consistently harmful bullets can be identified and pruned.

Why the Reflector is separate from the Curator. The paper's ablation study in Section 4.6 (Table 3) quantifies the importance of this architectural choice. Removing the Reflector entirely (and presumably having the Curator operate directly on execution traces) drops AppWorld offline adaptation performance from 59.4% to 55.1% average (a 4.3-point gap). The paper argues that this separation prevents overloading a single model with both evaluation and curation — two cognitively distinct tasks that are better performed by specialized prompts. The Reflector focuses on "what went wrong and why," while the Curator focuses on "what new knowledge should we add to the Playbook."

Iterative refinement within the Reflector. The Reflector supports multiple rounds of self-refinement, controlled by a hyperparameter (default: 5 rounds per the Section 3 description). After producing an initial analysis, the Reflector can revisit and polish its insights before handing them to the Curator. Section 4.6 and Appendix §A.6 (Table 19) show that performance is sensitive to this hyperparameter: 1 round under-extracts insights, 3–5 rounds provide good balance, and 10 rounds can degrade performance (likely due to "overthinking" that introduces noisy or contradictory refinements).

Robustness to reflection quality. Appendix §A.4 provides two important robustness findings:

• Weaker Reflector models still provide gains: when using GPT-OSS-120B (a weaker model) as the Reflector while keeping the Generator and Curator fixed at DeepSeek-V3.1, ACE still achieves 76.6% accuracy on FiNER versus 78.3% with the same-model Reflector — a drop of only 1.7 percentage points while still substantially above the 70.7% base model. With an even stronger Reflector (GPT-5.1), performance rises to 78.5%, showing modest additional returns.

• Harmful reflections are tolerated up to a point: when deliberately injecting harmful (adversarial) reflections every N steps, ACE's performance degrades gracefully. With harmful injections every 50 steps, accuracy is 78.2% versus 78.3% with no harmful reflections. Even with injections every 10 steps, accuracy is 77.0% — still well above the base model. Only fully adversarial updates every single iteration cause degradation below the base model (66.7%). This robustness comes from the bullet-based architecture: since each harmful reflection only adds a few bad bullets, the overall Playbook weight of accumulated good knowledge outweighs occasional noise, and the helpful/harmful counters enable subsequent identification of harmful entries.

---

The Curator and Incremental Delta Updates

The Curator is the component that converts Reflector insights into specific modifications to the Playbook. This is where ACE's core technical contribution — incremental delta updates — is implemented.

Curator responsibilities. Given the current Playbook and the Reflector's structured insights, the Curator (Figure 11, Appendix F for AppWorld; Figure 14 for FiNER):

1. Identifies genuinely new knowledge: it compares the Reflector's key insights against the existing Playbook to determine which insights are already captured (in which case they are redundant) and which represent new, missing knowledge.

2. Produces delta context items: for each new insight, the Curator writes a compact, self-contained bullet — formatted exactly like existing Playbook bullets — together with a section tag indicating which category it belongs to (e.g., "strategies_and_hard_rules", "apis_to_use_for_specific_information", "formulas_and_calculations", "verification_checklist").

3. Outputs operations: the Curator's output is a list of operations, where each operation is of type ADD (creating a new bullet with the system-assigned ID) or, implicitly, UPDATE (modifying the helpful/harmful counters of existing bullets based on the Reflector's tags). The paper notes: "For any operation if no new content to add, return an empty list for the operations field" — the Curator is explicitly instructed to avoid redundancy and only add genuinely new content.

The non-LLM merge mechanism. A critical design choice is that the actual integration of Curator-produced deltas into the Playbook is performed by deterministic, non-LLM logic — not by another LLM call. This is what distinguishes ACE from monolithic rewriting approaches:

• Adding new bullets: new bullets with fresh IDs are appended to the Playbook in the specified section.
• Updating metadata: bullets referenced in the Reflector's tags have their helpful or harmful counters incremented.
• De-duplication: semantic embeddings of new bullets are compared against existing bullets. If a new bullet is highly similar to an existing one (controlled by a configurable threshold, with 50%, 70%, and 90% tested in Appendix §A.6, Table 20), it is merged with the existing bullet rather than creating a near-duplicate. This prevents unbounded growth from repeated similar insights.

Why deterministic merging. The paper identifies this as essential for preventing context collapse. When an LLM performs the merge (as in Dynamic Cheatsheet's cumulative mode, which regenerates the entire cheatsheet at each step), the model's tendency toward summarization causes progressive compression. Deterministic merging, by contrast, guarantees that existing bullets are preserved verbatim — only new bullets are added, and metadata is updated. The model never sees the full Playbook during the update process, so it never has the opportunity to compress it.

Incremental vs. monolithic update ablation. Appendix §A.5 (Table 18) provides the key evidence: running ACE offline adaptation on AppWorld without incremental updates (i.e., presumably rewriting the full Playbook each step, analogous to Dynamic Cheatsheet) yields 67.3% TGC and 46.4% SGC on test-normal, averaging 56.9%. With incremental updates, performance jumps to 76.2% TGC and 64.3% SGC, averaging 70.3% — a 13.4-point gap on test-normal alone. This ablation confirms that incremental delta updates are not merely an efficiency optimization but are functionally necessary for preserving accumulated knowledge in long-horizon adaptation.

Cost implications of incremental updates. Section 4.7 and Appendix §A.3 quantify the efficiency benefits. During offline adaptation on AppWorld (Table 12), ACE uses 80.8% fewer input tokens than GEPA (39.3M vs. 204.1M) and 83.6% fewer output tokens (307K vs. 1.87M), because ACE avoids GEPA's repeated prompt-validation cycles and full-prompt rewrites. During online adaptation on FiNER (Table 4b), ACE reduces adaptation latency by 91.5% compared to DC (5,503s vs. 65,104s) and token dollar cost by 83.6% ($2.9 vs.$17.7).

---

The Grow-and-Refine Mechanism

The incremental delta approach naturally causes the Playbook to grow over time as new bullets accumulate. ACE addresses this through a grow-and-refine mechanism (Section 3.2) that balances accumulating detail against maintaining a usable context size.

What grow-and-refine does. The mechanism operates on two axes:

1. Grow: new bullets with fresh IDs are appended to the Playbook. Existing bullets' counters are updated in place when they are referenced and tagged. This ensures that the Playbook continuously accumulates new knowledge.

2. Refine: the system periodically or lazily prunes redundancy and low-quality bullets. Specifically:

   • De-duplication: semantically similar bullets (measured by semantic embedding similarity) are merged. The deduplication threshold is configurable; Appendix §A.6 (Table 20) shows that performance is stable across thresholds of 50%, 70%, and 90%, with FiNER accuracy ranging from 73.9% to 78.6%. The paper recommends 70–90% as a default range.
   • Pruning: when the Playbook exceeds a maximum context length (configurable from 10K to 100K tokens), bullets with consistently high harmful counters or low helpful counters are removed. Table 21 shows that performance is stable across this range on FiNER, indicating ACE is not sensitive to the exact pruning trigger — the pruning logic successfully removes stale or harmful bullets while preserving core reusable strategies.

When refinement occurs. The paper describes two modes:

• Proactive refinement: performed after each delta merge, which keeps the Playbook consistently compact at the cost of more frequent computation.
• Lazy refinement: performed only when the context window is exceeded (e.g., when total token count surpasses some preset threshold), which amortizes the cost over longer periods at the expense of occasionally carrying outdated bullets.

The choice depends on application requirements for latency versus context quality.

Why this matters for scalability. Without grow-and-refine, incremental adaptation would eventually hit the LLM's context window limit. With it, the Playbook asymptotically approaches a stable size — new bullets are added, but old, redundant, or harmful bullets are pruned. The mechanism acts as a "forgetting" function that prevents unbounded memory growth while preserving the most valuable accumulated knowledge.

---

Offline and Online Adaptation Protocols

ACE supports two modes of operation that share the same core components but differ in when and how adaptation occurs (Section 3, evaluated in Tables 1 and 2).

Offline adaptation. This is the "system prompt optimization" scenario: the Playbook is constructed and refined on a training split before being deployed. The protocol proceeds as follows:

1. Initialization: the Playbook starts empty (or with a minimal seed, though the paper does not detail seeding).
2. Training loop: for each sample in the training split, the Generator produces an answer → the Reflector analyzes the trajectory (with access to ground truth labels when available) → the Curator proposes deltas → the merger integrates them.
3. Multi-epoch adaptation (controlled by a maximum epoch hyperparameter, default: 5): the same training samples are revisited multiple times. This allows the Playbook to be progressively strengthened — early epochs capture the most obvious patterns; later epochs refine nuances as the Playbook grows. The ablation in Table 3 shows that multi-epoch adaptation improves AppWorld offline performance from 56.8% to 59.4% (a 2.6-point gain) by enabling deeper refinement.
4. Evaluation: the final Playbook is frozen and used as the context for all test samples. The Generator receives the Playbook but no further adaptation occurs during evaluation.

Online adaptation. This is the "test-time memory adaptation" scenario: the Playbook is updated continuously as the system encounters new test samples. The protocol:

1. Initialization: the Playbook may start empty or be pre-initialized through offline adaptation (a setting called "offline warmup" in Table 3).
2. Sequential evaluation: the test split is shuffled and processed one sample at a time. For each sample: the Generator predicts with the current Playbook → the Reflector analyzes → the Curator updates → the updated Playbook is used for the next sample.
3. Critical constraint: in online adaptation, ground truth labels are not available during the update step (since the system is being evaluated on unseen test data). The Reflector must rely solely on execution feedback (code execution success/failure, API responses, unit test results, model confidence signals) to diagnose errors and extract insights.
4. Offline warmup (optional): pre-initializing the Playbook through offline adaptation on a training split before beginning online adaptation on the test split. Table 3 shows this improves AppWorld online performance from 56.1% to 59.5% average — the initial Playbook provides a strong foundation, and online adaptation further refines it with test-time-specific insights.

Batch size. The paper states (Section 3): "We adopt a batch size of 1 (constructing a delta context from each sample)." This means each sample is processed individually, with the Playbook updated after every single query. This is important for online adaptation (where the system must adapt in real-time) and ensures that the feedback loop is tight — each error immediately informs the next attempt.

Same LLM for all roles. To "isolate the benefit of context construction itself" and "prevent knowledge transfer from a stronger Reflector or Curator to a weaker Generator" (Section 3), the paper uses the same LLM (non-thinking mode of DeepSeek-V3.1-671B) for all three roles in the main experiments. This means the Generator, Reflector, and Curator have identical base capabilities — the performance gains come purely from the structured adaptation process, not from a stronger evaluator guiding a weaker executor.

---

Feedback Signals and the Dependence on Execution Feedback Quality

A critical practical consideration is what feedback signals the Reflector uses, since the quality of adaptation hinges on the quality of these signals (Section 5, "Limitations and Challenges").

When ground truth labels are available (supervised setting, indicated by ✓ in the "GT Labels" column of Tables 1–2 and marked "✓" in the paper): the Reflector receives the correct answer or code directly and can compare the Generator's output against it. This provides the strongest possible signal for identifying errors and extracting insights.

When ground truth labels are unavailable (unsupervised setting, ✗ in tables): the Reflector must rely on execution feedback — signals that are naturally available during task execution without requiring labeled data. These include:

• For AppWorld: code execution success or failure, API return values, unit test results (the benchmark provides a test report after each task), Python error traces, assertion failures. The paper notes that "ACE leverages signals naturally available during execution (e.g., code execution success or failure) to guide the Reflector and Curator in forming structured lessons of successes and failures" (Section 4.3).
• For Formula (numerical reasoning): the Reflector can check whether the computational steps produce internally consistent results, even without knowing the ground truth answer. The paper shows that ACE achieves 83.0% accuracy on Formula without GT labels (Table 2, offline adaptation) — a 15.5-point gain over the base model, remarkably close to the 85.5% with GT labels (an 18.0-point gain).
• For FiNER (entity recognition): the feedback signal is much weaker without GT labels because there is no natural "execution feedback" — the model simply produces entity tags, and there's no runtime environment to validate them. The paper observes that without GT labels, ACE actually degrades slightly on FiNER (from 70.7% base to 67.3% online accuracy), because "the constructed context can be polluted by spurious or misleading signals" (Section 4.4). This is the key failure mode: when the Reflector cannot reliably distinguish correct from incorrect outputs, it may add harmful bullets to the Playbook.

The dependence on feedback quality is a fundamental limitation. The paper is explicit about this (Section 5): "A limitation of ACE is its reliance on a reasonably strong Reflector: if the Reflector fails to extract meaningful insights from generated traces or outcomes, the constructed context may become noisy or even harmful. In domain-specific tasks where no model can extract useful insights, the resulting context will naturally lack them." This limitation is shared with Dynamic Cheatsheet and indeed with any feedback-driven adaptation method.

Concrete distinction between tasks that provide rich versus poor feedback:

This distinction is practically important: ACE is most valuable for tasks that provide natural execution feedback (agents, code generation, numerical reasoning) and should be used with GT labels or human supervision for tasks that lack such signals (classification, open-ended generation).

---

Summary of Design Choices and Their Justifications

• Itemized bullet representation over monolithic prose: enables localization (update individual bullets without touching others), fine-grained retrieval feedback (bullet-level helpful/harmful tags), and incremental adaptation without full rewrites. Without this, every update would require regenerating the entire context — the exact failure mode that causes context collapse.

• Three-role decomposition (Generator, Reflector, Curator) over single-model adaptation: separates task execution (Generator), error diagnosis (Reflector), and knowledge curation (Curator) into specialized prompts with distinct objectives. This prevents the cognitive overload of asking one model to simultaneously solve the task, identify what went wrong, and write the corrective update — each of which requires different reasoning patterns.

• Incremental delta updates over monolithic rewriting: directly addresses context collapse by ensuring that existing knowledge is preserved verbatim across updates. The non-LLM merge mechanism guarantees that the model performing the update never sees the full Playbook, so it cannot compress or drop information. The ablation in Appendix §A.5 (13.4-point gap on AppWorld) provides strong evidence that this is a causal mechanism, not merely a correlation.

• Grow-and-refine over unbounded accumulation: balances comprehensiveness against context window limits. Without refinement, incremental updates would eventually exceed the model's context window; without growth, the Playbook would stagnate. The mechanism uses semantic de-duplication (not exact matching) to catch paraphrased redundant insights, and counter-based pruning to remove consistently harmful bullets.

• Separate Reflector model over having the Generator self-reflect: the ablation in Table 3 shows that adding the Reflector (as an explicit, separate component) to the agentic architecture improves AppWorld offline performance from 55.1% to 56.8%, and adding iterative refinement within the Reflector further improves to 59.4%. The paper argues this separation enables the Reflector to focus entirely on diagnosis without the distraction of also producing the answer, and the Reflector can invest multiple refinement rounds in polishing its insights before they enter the Playbook.

• Deterministic, non-LLM merging over LLM-based integration: prevents the merge step from becoming another source of context collapse. If the merge were performed by an LLM, it would face the same summarization pressure that causes collapse in monolithic approaches — the model would naturally attempt to compress the expanded Playbook. Deterministic merging guarantees preservation.

• Using the same LLM for all roles (by default) over using a stronger model for reflection/curation: isolates the contribution of the architecture itself. If a stronger model served as Reflector, gains might be attributed to capability transfer rather than the framework. The paper does explore varying Reflector strength (Appendix §A.4) and finds that even weaker Reflectors provide substantial gains — confirming that the architecture, not just model quality, drives improvement.

• Offline warmup for online adaptation: pre-initializing the Playbook through offline adaptation provides a strong foundation that reduces the noise from early online updates (when the Playbook is empty and the system has no accumulated experience). The 3.4-point gain on AppWorld (Table 3: 56.1% → 59.5%) suggests that the initial quality of the Playbook significantly impacts the stability of subsequent online learning.

4. Key Insights and Innovations

Innovation 1: Naming and Diagnosing Context Collapse as a First-Class Failure Mode of Iterative Rewriting

The most conceptually important contribution of this paper is not any individual architectural component of ACE, but rather the identification and explicit diagnosis of context collapse as a systematic failure mode that explains why prior adaptive memory methods plateau or degrade over time. Before this work, the dominant assumption in test-time memory approaches (Dynamic Cheatsheet, Reflexion, and related agent memory frameworks) was that iterative rewriting of accumulated experience would progressively improve context quality — that each rewrite would produce a more refined, more useful version of the memory. The paper demonstrates that this assumption is fundamentally wrong for long-horizon adaptation: monolithic LLM rewriting does not refine context; it destroys it, and does so abruptly.

The diagnostic move is what distinguishes this from a routine empirical observation of poor performance. The paper doesn't merely report that Dynamic Cheatsheet underperforms ACE on certain benchmarks — it isolates a specific mechanism (full-context rewriting by an LLM) and a specific symptom (catastrophic compression from thousands of tokens to hundreds in a single step, with corresponding accuracy collapse). The case study in Figure 2 is deceptively simple but methodologically precise: at step 60, the context contained 18,282 tokens and the system achieved 66.7% accuracy; at step 61, after a single monolithic rewrite, the context collapsed to 122 tokens and accuracy dropped to 57.1% — below the base model without any context at all. The paper explicitly frames this as not a bug in Dynamic Cheatsheet's implementation but a "fundamental risk of end-to-end context rewriting" that applies to any method using that pattern.

This is a conceptual reframing, not an incremental improvement. The field previously understood context adaptation through the lens of optimization — each rewriting step should produce a "better" prompt. ACE reorients the problem around preservation: the primary challenge is not improving context but preventing its destruction. The practical implication is that update mechanisms must guarantee that existing knowledge survives the update process, which leads directly to ACE's incremental delta design — but the intellectual contribution is the diagnostic framing itself, which generalizes beyond ACE to any future method that accumulates knowledge in LLM contexts.

Significance beyond performance. Even if ACE's specific mechanism were replaced by a different approach in future work, the concept of context collapse provides a vocabulary and a diagnostic tool that the field previously lacked. Researchers building iterative memory systems can now explicitly test for collapse by tracking context length and information density over time, rather than attributing performance plateaus to vague notions of "noise accumulation" or "capacity limits." The paper also connects this implicitly to the catastrophic forgetting literature in continual learning — but operating at the context level rather than the weight level, opening a rich analogy that future work can exploit.

Innovation 2: The Bullet-Grained Representation as an Enabling Abstraction for Cumulative Adaptation

ACE's second fundamental contribution is the itemized bullet representation — decomposing context into independently addressable, metadata-annotated units rather than treating it as monolithic prose. While the concept of "memory entries" existed in prior work (Dynamic Cheatsheet, A-MEM), ACE elevates this from an implementation detail to a first-class design principle with specific properties that collectively enable cumulative adaptation without collapse.

The field's default representation for context — whether in prompt optimizers like GEPA and MIPROv2 or in memory systems like Dynamic Cheatsheet — treats context as a single document to be rewritten, refined, or selected. This representation choice forces a tradeoff: either accept context collapse from full rewrites (Dynamic Cheatsheet), or limit context to a single compressed instruction (GEPA). The bullet representation breaks this tradeoff by enabling three properties that monolithic text cannot support simultaneously:

• Update localization: individual bullets can be modified, added, or removed without regenerating the entire context. This is the architectural foundation for incremental delta updates — it's what makes the non-LLM merge mechanism possible. Without localization, every update would require the LLM to process and potentially corrupt the full Playbook.

• Fine-grained feedback: by annotating specific bullets as helpful or harmful, the Generator provides a learning signal at the granularity of individual knowledge units. This enables data-driven decisions about which bullets to retain or prune over time, without requiring human labels or ground truth. Prior memory systems that used unstructured text could not collect or exploit this signal because there was no unit-level attribution.

• Deterministic merging: because bullets are independent, the merge step can be performed by simple, non-LLM logic — append new bullets, update counters, compute semantic similarity for de-duplication. This is the critical defense against context collapse: the LLM never sees the full Playbook during updates, so it has no opportunity to compress it. In contrast, Dynamic Cheatsheet's cumulative mode requires the LLM to regenerate the entire cheatsheet, which is exactly what triggers collapse.

The paper quantifies the causal importance of this representation through the ablation in Appendix §A.5 (Table 18): removing incremental updates (i.e., using bullet-structured context but still rewriting it monolithically) drops AppWorld test-normal performance by 13.4 points. This demonstrates that the bullet representation is necessary but not sufficient — it enables incremental updates, but only when paired with a merge mechanism that actually exploits the representation's properties.

Why this is fundamental rather than incremental. The key insight is that representation choices are not neutral — they constrain which update mechanisms are possible. Monolithic text representations make collapse inevitable because any update that modifies the context must process it in its entirety. Bullet-grained representations make preservation possible because updates can be localized. This is analogous to the distinction between full-model fine-tuning versus parameter-efficient methods: the representation of what gets updated determines what can be preserved. ACE's contribution is identifying that this same principle governs context-level adaptation, and designing a representation that aligns the update mechanism (deterministic merging) with the preservation objective.

Innovation 3: The Reflector as an Explicit, Specialized Diagnostic Role Separating Evaluation from Curation

ACE's third distinctive contribution is the architectural decision to separate the diagnostic function (Reflector) from the curation function (Curator) into two specialized LLM roles, rather than having a single model simultaneously evaluate execution traces and produce context updates. This division of labor addresses a specific cognitive bottleneck that the paper identifies as limiting prior approaches: the LLM tasked with updating memory must simultaneously diagnose what went wrong, extract generalizable lessons, decide what's genuinely novel, and write the update — four distinct cognitive operations that compete for the model's attention and reasoning capacity.

Prior work in natural language feedback (Reflexion, TextGrad, GEPA) and test-time memory (Dynamic Cheatsheet) typically assigns all of these responsibilities to a single LLM call. The model receives the execution trace, reflects on failures, and produces an updated prompt or memory entry in one step. ACE's innovation is recognizing that this conflation of diagnosis and curation is a bottleneck, not merely an implementation convenience — and that separating these functions into specialized prompts with different objectives and different input contexts enables each to perform better than any single model could.

The Reflector's specialization is depth of diagnosis: it receives the full execution trajectory, ground truth (when available), unit test reports, and the specific Playbook bullets the Generator used. Its output is a structured analysis with distinct fields for error identification, root cause analysis, correct approach, and key insight — each demanding different reasoning patterns. The Reflector also supports iterative self-refinement, re-reading and polishing its diagnosis over multiple rounds before handing it to the Curator. This depth-focused specialization would be impractical if the same model also had to simultaneously write the Playbook update.

The Curator's specialization is knowledge management: given polished, pre-digested insights from the Reflector, it focuses exclusively on comparing these against the existing Playbook to identify genuine novelty, avoid redundancy, and produce clean, self-contained bullet additions. The Curator doesn't need to re-derive the lesson from raw execution traces — it works with the Reflector's distilled output.

The ablation evidence (Table 3) supports this design: removing the Reflector entirely and presumably having the Curator operate directly on execution traces drops AppWorld offline performance from 59.4% to 55.1% on average. Adding iterative refinement within the Reflector further improves from 56.8% to 59.4%. The paper also shows (Appendix §A.4) that the Reflector can be a weaker model than the Generator and Curator and still provide substantial gains — indicating that the separation itself, not just having a "strong evaluator," is what matters.

Significance as a design principle. This contribution generalizes beyond context adaptation: it suggests that agentic systems with learning components should decompose cognitive labor by function (execution, diagnosis, curation), rather than expecting a single unified model to span all these activities. The parallel to human expertise is deliberate — the paper explicitly frames the three-role architecture as mirroring "how humans learn: experimenting, reflecting, and consolidating, while avoiding the bottleneck of overloading a single model with all responsibilities." Whether this analogy holds in other domains is an open question, but ACE provides a concrete, empirically validated template for separation of diagnostic and curatorial reasoning in LLM systems.

Innovation 4: The Dependence on Execution Feedback Quality as a Boundary Condition for Self-Improvement

The paper's fourth contribution is less a design choice than an empirical characterization of where context-based self-improvement works and where it fails, establishing that the availability and quality of execution feedback is the key boundary condition. This finding is significant because it provides a principled framework for predicting whether ACE (or any feedback-driven adaptation method) will succeed on a given task, converting what might appear to be inconsistent results across benchmarks into a coherent pattern.

The data tells a clear story. On tasks with rich, naturally available execution feedback — AppWorld agent tasks (code execution traces, unit test results, API error messages) and Formula numerical reasoning (internal consistency of computations) — ACE achieves large gains without ground truth labels: +14.8% on AppWorld and +15.5% on Formula. On tasks where execution provides no validation signal — FiNER financial entity recognition, where the model produces tags with no runtime environment to check them — ACE degrades without ground truth labels, from 70.7% base accuracy to 67.3% in online adaptation. The mechanism is straightforward: without reliable feedback, the Reflector cannot distinguish correct from incorrect outputs, so the Playbook accumulates spurious or misleading bullets that actively harm performance.

This may seem like an obvious limitation in retrospect, but it was not obvious in the prior literature. Dynamic Cheatsheet was evaluated on reasoning benchmarks (AIME, Game-of-24, GPQA) where correctness is either verifiable through computation or can be inferred from format, and the method's dependence on feedback quality was never isolated as a variable. GEPA uses validation-set performance as feedback, which provides a clean signal but at high computational cost (repeated re-evaluation on a held-out set). ACE's contribution is making the feedback-dependence explicit and characterizing it across task types, enabling practitioners to anticipate whether the method will succeed without expensive trial-and-error.

The negative result as a scientific contribution. The FiNER degradation in the unsupervised setting is a genuinely informative negative result. It demonstrates that context adaptation is not "free" — it can increase error rates if the feedback signal is unreliable, a risk that prior work largely did not discuss. The paper's recommendation is implicit but clear: for tasks without natural execution feedback, ACE should be used with ground truth supervision or human-in-the-loop validation. For tasks with rich execution signals, ACE can operate autonomously. This boundary is crisp, empirically grounded, and provides actionable guidance for deployment.

Connection to broader self-improvement research. This finding echoes a pattern observed in the self-play and RL literature — that algorithmic improvements in self-training often fail when the reward signal is noisy or uninformative — but translates it to the context-adaptation domain. It suggests that the future of test-time self-improvement depends as much on feedback engineering (designing tasks and environments to produce rich execution signals) as on better adaptation algorithms. Tasks that can be instrumented with unit tests, runtime checks, or consistency constraints become natural candidates for autonomous ACE-style adaptation; tasks that produce only binary correct/incorrect signals (like most classification benchmarks) require supervised approaches or fundamentally different reflection mechanisms.

Tying back to the Reflector robustness results. The finding that ACE tolerates noisy but not fully absent feedback (Appendix §A.4: harmful reflections every 10 steps still yield 77.0% accuracy vs. 78.3% clean) refines this boundary further. Occasional misdiagnoses are absorbed by the bullet-based architecture because harmful bullets accumulate negative counters over time and get pruned. But when every feedback cycle is unreliable (as in FiNER without GT labels), the Playbook gets systematically degraded. The boundary is not binary — it's a continuum of feedback reliability — but the practical implication is the same: invest in feedback quality before investing in adaptation algorithms.

5. Experimental Analysis

Evaluation Methodology

• Dataset. The paper evaluates on two categories of benchmarks. For LLM agents, it uses AppWorld (Trivedi et al., 2024) — a suite of autonomous agent tasks involving API understanding, code generation, and environment interaction with two difficulty levels (normal and challenge), evaluated on the official test-normal and test-challenge splits. For domain-specific reasoning, the primary case study is financial analysis using FiNER (Loukas et al., 2022) and Formula (Wang et al., 2025a). FiNER requires labeling tokens in XBRL financial documents with one of 139 fine-grained entity types; Formula focuses on applying financial concepts and performing numerical computations. Additional domain tasks include DDXPlus (Fansi Tchango et al., 2022) for medical reasoning and BIRD-SQL (Li et al., 2023) for text-to-SQL generation, both from StreamBench (Wu et al., 2024). All datasets follow their original train/validation/test splits.

• Base model(s). The primary backbone is DeepSeek-V3.1-671B (Liu et al., 2024a), used in non-thinking mode for all three ACE roles (Generator, Reflector, Curator) to isolate the benefit of context construction itself rather than capability transfer from a stronger evaluator to a weaker executor. Additional generalization experiments are conducted with GPT-OSS-120B, GPT-5.1, and Llama-3.3-70B-Instruct (Appendix §A.1). For AppWorld, all methods build on the official ReAct implementation (Yao et al., 2023). The paper argues DeepSeek-V3.1 is representative of contemporary LLM capabilities while being open-source, enabling reproducibility.

• Metrics. For AppWorld, the paper reports Task Goal Completion (TGC) and Scenario Goal Completion (SGC) on both test-normal and test-challenge splits, following the official benchmark protocol. For FiNER, Formula, and DDXPlus, accuracy is measured as the proportion of predicted answers that exactly match the ground truth (pass@1 accuracy). For BIRD-SQL, the paper uses GPT-4o-mini under an LLM-as-a-judge framework (Zheng et al., 2023) to evaluate generated SQL queries. Average accuracy across splits or tasks is reported as the primary aggregate metric.

• Baselines. Five baselines are evaluated: (1) Base LLM — the model evaluated directly without any context engineering, using default prompts provided by dataset authors; (2) In-Context Learning (ICL) (Agarwal et al., 2024) — providing the model with as many task demonstrations as fit within its context window; (3) MIPROv2 (Opsahl-Ong et al., 2024) — a prompt optimizer that jointly optimizes system instructions and in-context demonstrations via Bayesian optimization, using the official DSPy implementation with auto="heavy"; (4) GEPA (Agrawal et al., 2025) — a reflective prompt optimizer based on genetic Pareto search with natural-language reflection on execution traces, using the official DSPy implementation with auto="heavy"; (5) Dynamic Cheatsheet (DC) (Suzgun et al., 2025) — a test-time learning approach with adaptive external memory, using the official implementation in cumulative mode (DC-CU).

• Generation budget / compute accounting. The paper measures adaptation cost through several metrics: adaptation latency (wall-clock time in seconds for the entire adaptation process), number of rollouts (total LLM calls across all queries during adaptation), and token dollar cost (input and output tokens consumed, with separate accounting for adaptation and evaluation stages in Appendix §A.3). For online adaptation, each method processes the test split sequentially with batch size 1. For offline adaptation, the paper reports total rollouts on the training split. The cost analysis in Section 4.7 and Appendix §A.3 provides fine-grained token breakdowns comparing ACE against GEPA and DC.

• Cross-validation / statistical protocol. For offline adaptation, methods are optimized on the training split and evaluated on the test split with pass@1 accuracy. For online adaptation, methods are evaluated sequentially on the test split: for each sample, the model first predicts with the current context, then updates its context based on that sample. The same shuffled test split is used across all methods to ensure fairness. The paper reports results from a single run (no multiple-seed confidence intervals), but the diversity of benchmarks and models provides cross-validation.

---

Main Quantitative Results

Agent Benchmark: AppWorld Results

ACE substantially outperforms all baselines on AppWorld, achieving an average improvement of 10.6% over the strongest baseline (GEPA) in offline adaptation, and maintains large gains even without ground truth labels.

Table 1 presents the core comparison. The base ReAct agent with DeepSeek-V3.1 achieves 42.4% average accuracy across both difficulty splits. In the offline adaptation setting with ground truth labels available:

• ReAct + ICL achieves 46.0% average (+3.6%), showing that static demonstrations provide limited benefit for complex multi-turn agent tasks.
• ReAct + GEPA achieves 46.4% average (+4.0%), indicating that even sophisticated prompt optimization with evolutionary search and execution-trace reflection produces only modest gains — consistent with the paper's argument that a single optimized instruction cannot capture the hundreds of granular strategies agents require.
• ReAct + ACE achieves 59.4% average (+17.0%) , more than 3× the improvement over GEPA relative to the base model. The gains are particularly pronounced on the harder test-challenge split: ACE achieves 57.3% TGC and 39.6% SGC (versus 46.0% and 30.2% for GEPA), demonstrating that comprehensive playbook-style contexts provide the most value precisely where simple instructions and demonstrations are insufficient.

Critically, ReAct + ACE without ground truth labels (unsupervised setting) achieves 57.2% average (+14.8%), only 2.2 points below the supervised variant. This validates the paper's claim that ACE can self-improve from natural execution feedback alone — code execution traces, API errors, and unit test results provide sufficient signal for the Reflector to diagnose errors and extract actionable insights.

In the online adaptation setting, where the context is updated sequentially on the test split without ground truth labels:

• ReAct + DC (CU) achieves 51.9% average (+9.5%), showing that cumulative memory accumulation helps but is limited by monolithic rewriting.
• ReAct + ACE achieves 59.5% average (+17.1%) , a 7.6-point advantage over DC. This gap directly quantifies the benefit of incremental delta updates and structured reflection over monolithic memory rewriting — in the online setting where collapse is most likely, ACE's architectural choices prevent degradation.

The difficulty-dependent pattern is striking. On test-normal (easier tasks), ACE's TGC improves from 63.7% (base) to 76.2% offline and 69.6% online. On test-challenge (harder tasks), TGC jumps from 41.5% to 57.3% offline and 66.0% online — the online adaptation variant actually outperforms offline on challenge tasks, suggesting that test-time-specific insights accumulated during online adaptation are particularly valuable for hard problems that require environment-specific strategies not captured in training data.

AppWorld leaderboard comparison. The paper notes one external reference point but explicitly cautions against direct comparison: IBM CUGA (Marreed et al., 2025), a production-level GPT-4.1-based agent, achieves 60.3% average on the leaderboard. ReAct + ACE offline (59.4%) matches this despite using the much smaller open-source DeepSeek-V3.1. ReAct + ACE online surpasses CUGA on test-challenge (66.0% TGC and 48.9% SGC vs. CUGA's corresponding scores, an 8.4% TGC advantage per the paper). The paper correctly frames this as a "rough contextual reference" rather than a methodological baseline, since CUGA uses a different model, different internal design, and different engineering optimizations. The significance is that ACE's context-adaptation approach achieves comparable or superior performance to a heavily engineered production system through a general, lightweight framework.

Domain-Specific Benchmark: Financial Analysis Results

ACE delivers an average gain of 8.6% over the strongest baseline on financial reasoning benchmarks, but its performance without ground truth labels reveals an important boundary condition: on tasks without natural execution feedback, adaptation can degrade performance.

Table 2 presents results on FiNER (entity recognition) and Formula (numerical reasoning). The base DeepSeek-V3.1 achieves 70.7% on FiNER and 67.5% on Formula (69.1% average). In offline adaptation with ground truth labels:

• ICL provides negligible benefit: 72.3% on FiNER but 67.0% on Formula (actually a −0.5% regression), averaging 69.6% (+0.5%). Static demonstrations help slightly for entity tagging but hurt for numerical reasoning — likely because seeing past examples biases the model toward common answer patterns at the expense of case-specific computation.
• MIPROv2 achieves 70.9% average (+1.8%), with modest gains on FiNER (72.4%) and Formula (69.5%). Bayesian optimization over instructions provides some benefit but is fundamentally limited by the single-prompt representation.
• GEPA achieves 72.5% average (+3.4%), with Formula (71.5%, +4.0%) benefiting more than FiNER (73.5%, +2.8%). The reflective prompt evolution with execution traces helps more on tasks with rich feedback signals.
• ACE achieves 81.9% average (+12.8%) , with Formula showing an extraordinary gain: from 67.5% to 85.5% (+18.0 points) . FiNER improves to 78.3% (+7.6 points). The 11.9-point aggregate gap over GEPA (versus 3.4 points for GEPA over the base model) demonstrates that on knowledge-intensive tasks requiring many specific rules and domain concepts, a comprehensive evolving playbook dramatically outperforms any single optimized instruction.

The Formula vs. FiNER disparity is instructive. Formula involves numerical computation with XBRL financial concepts — tasks where the base model knows the mathematics but needs guidance on which financial formulas to apply, how to interpret XBRL-specific notation, and common pitfalls in financial calculations. The Playbook accumulates exactly this granular knowledge. FiNER involves entity classification where the boundary between correct and incorrect predictions is fuzzy and where the base model's errors are more fundamental (misunderstanding rare entity types) rather than tactical (applying the wrong formula).

In offline adaptation without ground truth labels:

• ACE on Formula achieves 83.0% (+15.5%), only 2.5 points below the supervised variant. Numerical reasoning provides natural execution feedback — even without knowing the correct answer, the Reflector can detect inconsistencies in computational steps, implausible intermediate values, or arithmetic errors. This feedback is sufficient for effective adaptation.
• ACE on FiNER achieves only 71.1% (+0.4%), essentially flat. Entity tagging has no natural execution feedback — the model produces tags, there's no runtime to validate them, and the Reflector cannot reliably distinguish correct from incorrect predictions. Without ground truth, the adaptation adds negligible value.

In online adaptation, the pattern intensifies:

• DC (CU) with ground truth: 74.2% FiNER, 69.5% Formula, 71.8% average (+2.7%). The cumulative memory helps modestly.
• DC (CU) without ground truth: FiNER drops to 68.3% (−2.4% vs. base) , Formula drops to 62.5% (−5.0%) . Without reliable feedback, DC's monolithic rewriting actively degrades performance — the model accumulates noise that corrupts its memory.
• ACE with ground truth: 76.7% FiNER, 76.5% Formula, 76.6% average (+7.5%). The gap over DC (4.8 points) again quantifies the benefit of incremental updates.
• ACE without ground truth: FiNER drops to 67.3% (−3.4% vs. base) but Formula improves to 78.5% (+11.0%) . This split is the paper's most important result for understanding ACE's limitations: on FiNER, the absence of any execution feedback means the Reflector adds spurious or misleading bullets to the Playbook, causing degradation below the base model. On Formula, the natural computational feedback provides sufficient signal for substantial gains even without labels.

The paper explicitly acknowledges this limitation (Section 5): "when ground-truth supervision or reliable execution signals are absent, both ACE and DC may degrade in performance. In such cases, the constructed context can be polluted by spurious or misleading signals." This is not a failure of ACE specifically — it's a fundamental constraint on any feedback-driven adaptation — but the paper's empirical characterization of which tasks cross this threshold is a valuable contribution.

Additional Domain Tasks: Medical and Text-to-SQL

The paper further evaluates ACE on two domain tasks beyond finance (Appendix §A.2, Tables 10–11):

DDXPlus (medical reasoning): ACE offline adaptation achieves 90.2% accuracy versus 75.2% for the base model (+15.0%), while GEPA achieves only 76.4% (+1.2%). This 13.8-point gap underscores that multi-step diagnostic reasoning benefits dramatically from accumulated domain-specific context. The base DeepSeek-V3.1 already knows medical concepts; ACE's Playbook captures the reasoning patterns, common diagnostic pitfalls, and differential diagnosis strategies that distinguish correct from incorrect diagnoses.

BIRD-SQL (text-to-SQL): ACE achieves 52.9% average across difficulty splits (+5.1% over base), splitting into 53.5% Simple (+7.1%), 50.7% Moderate (+2.5%), and 56.6% Challenging (+1.5%). GEPA achieves 52.2% average (+4.4%), with 51.6% Simple (+5.2%), 51.9% Moderate (+3.7%), and 57.2% Challenging (+2.1%). ACE outperforms GEPA on Simple but GEPA edges ahead on Moderate and Challenging. The paper doesn't explain this reversal but it likely reflects that SQL generation for simple queries benefits more from accumulated schema-specific rules (which the Playbook captures well), while moderate and challenging queries benefit more from precise instruction about query patterns (which GEPA's optimized single-prompt captures more concisely). This is a rare case where the comprehensive-playbook approach shows diminishing returns relative to instruction optimization.

Generalization Across LLMs

Appendix §A.1 evaluates ACE with three additional model families (Tables 5–9), using the same architecture and prompts across all models.

On AppWorld with GPT-OSS-120B (Table 5): The base ReAct achieves only 34.6% average, reflecting the model's weaker agent capabilities. ACE offline with GT labels achieves 40.5% (+5.9%), and ACE online without GT labels achieves 42.2% (+7.6%). The relative gain over GEPA (37.7%) is modest (2.8 points offline) compared to DeepSeek-V3.1 (11.9 points), suggesting that weaker Generators produce lower-quality execution traces, which in turn limits the Reflector's ability to extract high-quality insights — the entire pipeline's quality depends on the Generator's baseline competence.

On AppWorld with GPT-5.1 (Table 6): The base ReAct achieves 54.2% average. ACE offline with GT labels achieves 60.2% (+6.0%), and ACE online without GT labels achieves 65.8% (+11.6%). The online variant outperforming offline is notable — GPT-5.1's strong base capabilities produce high-quality execution traces, enabling the Reflector to extract exceptionally valuable test-time-specific insights. The gap over GEPA (56.2%, +2.0%) is 6.0 points offline, smaller than DeepSeek-V3.1's 11.9-point gap — possibly because GEPA benefits more than ACE from a stronger base model's ability to produce higher-quality reflection and prompt candidates.

On financial benchmarks with GPT-OSS-120B (Table 7): ACE offline with GT achieves 81.2% average (+12.1% over base 69.1%), comparable to DeepSeek-V3.1's 81.9% (+12.8%). The base model is weaker (69.1% vs. 69.1% — actually identical, suggesting GPT-OSS-120B and DeepSeek-V3.1 have similar financial reasoning capabilities despite their agent capability gap). GEPA achieves only 69.7% (+0.6%), confirming that domain-specific knowledge tasks resist compression into single instructions regardless of base model strength.

On financial benchmarks with GPT-5.1 (Table 8): ACE offline with GT achieves 82.8% average (+9.5% over base 73.3%). The improvement is slightly smaller than with weaker models, partly because the base model is already stronger (73.3% vs. 69.1%).

On FiNER with Llama-3.3-70B-Instruct (Table 9): The base model achieves 62.5%. GEPA actually degrades to 59.41% (−3.09%), a worse-than-baseline result that the paper does not explain but likely reflects overfitting to the training split. ACE offline with GT achieves 64.9% (+2.4%), a modest but consistent gain — the weaker base model limits both the quality of execution traces and the potential ceiling for adaptation gains. ACE online without GT achieves 63.6% (+1.1%), while DC without GT achieves 59.0% (−3.5%). Even with a weaker model, ACE's incremental updates prevent the degradation that DC's monolithic rewriting causes.

Cross-model pattern. ACE provides consistent gains across all four model families (DeepSeek-V3.1, GPT-OSS-120B, GPT-5.1, Llama-3.3-70B), with magnitude varying by base model capability. The relative gap over GEPA is largest for medium-capability models (DeepSeek-V3.1, GPT-OSS-120B) and smaller for the strongest (GPT-5.1) — suggesting that instruction optimization partially catches up when the base model is already very strong, but comprehensive playbooks remain superior. Critically, ACE never degrades below the base model in the offline supervised setting, establishing a safety floor that GEPA occasionally violates (Llama-3.3-70B on FiNER).

Cost and Speed Analysis

ACE achieves dramatic efficiency advantages over both prompt optimization (GEPA) and memory accumulation (DC) baselines through incremental delta updates and non-LLM merging, reducing adaptation latency by 82–92% while using fewer total tokens.

Section 4.7 and Tables 4(a)–4(b) present headline comparisons:

Offline adaptation on AppWorld (ACE vs. GEPA): ACE completes adaptation in 9,517 seconds versus 53,898 seconds for GEPA — an 82.3% reduction in latency — using only 357 rollouts versus 1,434 for GEPA (75.1% reduction). GEPA's cost is dominated by its prompt-validation loop, which repeatedly evaluates candidate prompts on a held-out validation set (57 queries, 1,026 additional rollouts), while ACE's incremental updates avoid this entirely.

Online adaptation on FiNER (ACE vs. DC): ACE completes adaptation in 5,503 seconds versus 65,104 seconds for DC — a 91.5% reduction in latency — with token dollar cost of $2.9 versus$17.7 for DC (83.6% reduction). DC's cost comes from repeatedly regenerating the full cheatsheet at each step, which requires processing and generating on the entire accumulated memory. ACE only generates compact delta bullets.

Fine-grained token analysis (Appendix §A.3). The detailed breakdown on AppWorld (Tables 12–15) reveals where savings come from:

• Adaptation stage (Table 12): ACE uses 39.3M input tokens (−80.8% vs. GEPA's 204.1M) and 307K output tokens (−83.6% vs. GEPA's 1.87M). GEPA's cost splits into 65M tokens for prompt generation (429 rollouts × 90 training queries) and 139M tokens for prompt validation (1,026 rollouts × 57 validation queries). ACE's costs break down as 31M Generator tokens (1,790 rollouts), 4.7M Reflector tokens (161 rollouts), and 3.6M Curator tokens (124 rollouts).

• Per-query adaptation cost (Table 13): GEPA averages 1,387,538 input tokens and 12,722 output tokens per query (training + validation combined). ACE averages 436,121 input tokens (−68.6%) and 3,413 output tokens (−73.2%) per query.

• Evaluation stage (Table 14): ACE uses 58.6M input tokens for evaluating 160 test queries versus GEPA's 27.0M — ACE uses more input tokens at evaluation (+117.4%) because the Playbook is much longer than GEPA's single optimized prompt. Output tokens are similar (270K vs. 251K). However, as the paper emphasizes, this raw token count does not translate to proportionally higher serving cost because 91.8% of ACE's input tokens are served from KV cache under OpenAI's default prompt caching, yielding an 82.6% reduction in billed input-token cost relative to counting raw tokens. This is a crucial practical point: rich, long contexts have much lower amortized serving cost than their raw token counts suggest in modern caching infrastructures.

Number of queries trade-off. GEPA processes 147 total queries during adaptation (90 training + 57 validation), while ACE processes only 90 training queries (−38.8%). This is possible because ACE does not require a separate validation set — the Reflector analyzes execution traces directly, and the Curator determines what to add without comparing candidate prompts on held-out data.

---

Ablation Studies and Robustness Checks

Reflector presence and iterative refinement (Table 3): Removing the Reflector entirely (ACE w/o Reflector or multi-epoch) reduces AppWorld offline performance from 59.4% to 55.1% average (−4.3 points). Removing only multi-epoch adaptation but keeping the Reflector yields 56.8% (−2.6 points). The two contributions are additive: the Reflector provides better diagnosis (separation of evaluation from curation), and multi-epoch adaptation allows progressive refinement as the Playbook grows. Adding offline warmup before online adaptation improves performance from 56.1% to 59.5% (+3.4 points), confirming that starting with a strong initial Playbook stabilizes subsequent online learning.

Incremental context updates (Appendix §A.5, Table 18): Running ACE offline on AppWorld with bullet-structured context but without incremental updates (i.e., presumably rewriting the full Playbook monolithically at each step, analogous to DC's cumulative mode) yields 67.3% TGC and 46.4% SGC on test-normal (56.9% average), versus 76.2% TGC and 64.3% SGC (70.3% average) with incremental updates — a 13.4-point gap. This is the single most important ablation: it demonstrates that the bullet representation alone is insufficient; the incremental update mechanism (deterministic merging rather than LLM-based rewriting) is the causal driver of performance preservation. This directly validates the paper's claim that monolithic rewriting causes context collapse.

Robustness to reflection quality (Appendix §A.4):

• Weaker Reflector models (Table 16): Using GPT-OSS-120B as Reflector while keeping Generator and Curator at DeepSeek-V3.1 yields 76.6% FiNER accuracy versus 78.3% with same-model Reflector (−1.7 points, still +5.9 over base 70.7%). Using GPT-5.1 as Reflector yields 78.5% (+0.2 over same-model). The substantial gain even with a much weaker Reflector confirms that the separation of roles is more important than the Reflector's absolute capability — even a weaker model, when specialized for diagnosis, extracts useful insights.

• Harmful/adversarial reflections (Table 17): Injecting harmful reflections every N adaptation steps shows graceful degradation: every 100 steps → 78.2% (same as clean), every 50 steps → 78.2%, every 25 steps → 77.8% (+7.1 over base), every 10 steps → 77.0% (+6.3), every 5 steps → 76.1% (+5.4), every 1 step (fully adversarial) → 66.7% (−4.0, below base). This is a strong result: ACE tolerates corruption rates up to 20% (every 5 steps) while remaining substantially above the base model, and only degrades below base when every single update is adversarial. The mechanism is the bullet-based metadata counters — harmful bullets accumulate negative counters and get pruned, while the mass of accumulated good knowledge outweighs occasional noise.

Hyperparameter sensitivity (Appendix §A.6):

• Reflection iterations (Table 19): On AppWorld, 1 iteration yields 61.3% test-normal average (+8.0 over base), 3 iterations yields 65.8% (+12.5), 5 iterations yields 67.6% (+14.3), and 10 iterations degrades to 65.2% (+11.9). The paper attributes the 10-iteration degradation to "overthinking" — excessive refinement introduces noisy, contradictory, or over-specific insights that pollute the Playbook. The sweet spot is 3–5 iterations.

• Deduplication threshold (Table 20): On FiNER, 50% threshold yields 77.0% (+6.3), 70% yields 73.9% (+3.2), and 90% yields 78.6% (+7.9). Performance is relatively stable, with 90% (aggressive deduplication) performing best — suggesting that avoiding near-duplicates is more important than preserving every slight variant of an insight.

• Pruning trigger / maximum context length (Table 21): On FiNER, 10K tokens yields 78.6% (+7.9), 50K yields 78.4% (+7.7), and 100K yields 78.3% (+7.6). Performance is essentially flat across a 10× range, indicating that the pruning logic effectively removes stale/harmful bullets while preserving core strategies regardless of the exact threshold. This is a practically important result: practitioners don't need to tune this hyperparameter carefully.

Multi-epoch adaptation (Table 3): Adding multi-epoch refinement to ACE's offline adaptation improves AppWorld performance from 56.8% (single epoch) to 59.4% (+2.6 points). This is a moderate but consistent gain — revisiting the same training samples with an already-populated Playbook allows the Reflector to extract more nuanced insights that were missed in the first pass, and allows the Curator to identify redundancies that only become apparent after the Playbook has grown.

Offline warmup for online adaptation (Table 3): Adding offline warmup (pre-initializing the Playbook via offline adaptation before starting online adaptation on the test split) improves AppWorld online performance from 56.1% to 59.5% (+3.4 points). The paper argues this works because the initial Playbook provides a strong foundation — early online updates, when the Playbook is empty and every error generates a new bullet with no counterbalancing history, are the noisiest. Offline warmup essentially provides a "burn-in" period on labeled data before the system switches to unsupervised online adaptation.

Generator/Reflector/Curator model separation (implicit in design): While not presented as a formal ablation, the paper's core design choice of using three separate LLM calls with specialized prompts (rather than one call performing all three functions) is validated by the Reflector-removal ablation (Table 3: −4.3 points) and the iterative-refinement ablation (Table 19: 1 vs. 5 rounds → +6.3 points). The gains from adding iterative refinement to the Reflector specifically — which would be impractical if diagnosis and curation were performed in a single call — demonstrate the value of separating these cognitive functions.

---

Critical Assessment

Claim 1: "ACE consistently outperforms strong baselines, yielding average gains of 10.6% on agents and 8.6% on domain-specific benchmarks."

This claim is supported but requires careful parsing. The 10.6% figure for agents is computed as ACE's 59.4% average minus the best baseline's (GEPA) 46.4% — a 13.0-point absolute gain expressed as a relative percentage over 100? The paper's actual computation appears to be averaging the gaps across the four AppWorld metrics (TGC+normal, SGC+normal, TGC+challenge, SGC+challenge): ACE outperforms GEPA by 17.0% average across all four metrics, and the difference between 17.0% and "10.6%" likely reflects different aggregations. Looking at Table 1 directly: the offline ACE (✓ GT) vs. next-best baseline (GEPA) yields 59.4% − 46.4% = 13.0 points absolute, which is a 28% relative improvement, not 10.6%. The "10.6%" figure may be computed differently, or may be AVERAGE improvement across offline and online settings versus baselines aggregated. The paper's headline numbers are somewhat opaque in their derivation, but the underlying table data (Table 1) unambiguously shows large absolute gains: 13.0 points over GEPA offline, 7.6 points over DC online.

For domain-specific benchmarks, the 8.6% figure is also unclear: ACE offline with GT (81.9%) minus GEPA (72.5%) = 9.4 points absolute — a 13.0% relative improvement. With online included, the gaps are smaller.

More important than the aggregate percentage is the pattern of where gains concentrate. On AppWorld, ACE provides massive gains on the harder challenge split (TGC +15.8 offline, +24.5 online — far exceeding improvements on normal). On financial benchmarks, Formula benefits enormously (+18.0 offline) while FiNER benefits modestly (+7.6). This heterogeneity is genuinely informative, and the paper's difficulty-bin-free presentation (unlike some scaling papers) means the reader must infer from per-task results where ACE helps most.

Claim 2: "ACE is able to construct effective contexts without labeled supervision, instead leveraging execution feedback and environment signals."

This claim is supported with an important caveat that the paper itself documents. On AppWorld and Formula — tasks with rich execution feedback — ACE achieves 14.8% and 15.5% improvements without GT labels, respectively (Tables 1–2), approximately matching supervised performance. On FiNER — a task with no execution feedback — ACE degrades to 67.3% (online, no GT) from the base model's 70.7%. The paper acknowledges this (Section 4.4): "when ground-truth supervision or reliable execution signals are absent, both ACE and DC may degrade in performance." The claim is therefore conditionally true: ACE works without labels when execution feedback is available and informative. For classification tasks without runtime validation, ACE requires labels or degrades. This is not a weakness of the paper's reporting — the paper is transparent about this — but the headline "construct effective contexts without labeled supervision" abstracts away the conditional nature of the finding.

The broader implication is that the field's interest in unsupervised self-improvement depends on task instrumentation: tasks designed to produce rich execution signals (unit tests, API responses, consistency checks, runtime errors) are natural candidates for autonomous adaptation; tasks that produce only binary correct/incorrect judgments require either labels or a fundamentally different reflection mechanism (e.g., confidence-based gating, anomaly detection in the output space).

Claim 3: "On the AppWorld leaderboard, ACE matches the top-1-ranked production-level agent on the overall average and surpasses it on the harder test-challenge split."

The paper appropriately hedges this claim: "We mention IBM CUGA as a rough contextual reference... It is not used as a methodological baseline, and we do not make direct comparisons." This is correct framing. CUGA (60.3% average) uses GPT-4.1 versus ACE's DeepSeek-V3.1, and CUGA's internal design involves substantial agent-engineering choices beyond context adaptation. The comparison shows that ACE's approach is competitive with heavily engineered production systems, not that it "beats" them in a controlled experiment. The online variant's 8.4% TGC advantage on test-challenge is impressive but should be interpreted as demonstrating the value of test-time-specific context adaptation for hard tasks, not as ACE outperforming CUGA's architecture.

Claim 4: "ACE requires significantly fewer rollouts and achieves lower adaptation latency than existing adaptive methods."

Strongly supported. The cost comparisons in Section 4.7 and Appendix §A.3 are thorough and transparent. ACE's 82.3% latency reduction vs. GEPA offline (Table 4a) and 91.5% latency reduction vs. DC online (Table 4b) are large and mechanistically well-explained: GEPA's cost is dominated by its prompt-validation loop, DC's by repeated full-context regeneration. The fine-grained token breakdowns (Tables 12–15) enable independent verification of the claimed savings.

A caveat on evaluation-time cost: ACE uses more input tokens at evaluation (+117.4% vs. GEPA) due to the richer Playbook. The paper's KV-cache argument (91.8% cache reuse, 82.6% reduction in billed cost) is plausible based on the OpenAI API study but depends on the caching infrastructure. In deployments without KV cache reuse, the evaluation-time cost advantage shrinks or reverses. The paper acknowledges this by discussing ongoing advances in KV cache optimization (Gim et al., 2024; Yao et al., 2025) — but these are not universally available.

Critical weaknesses in the experimental design:

• Single-run results with no confidence intervals. The paper reports single-run accuracy across all experiments. With 500 test questions per split, the variance in a single run could be substantial (a 2–3 point difference could easily arise from sampling noise in a 500-question test set). The absence of multiple seeds or bootstrapped confidence intervals means the reported gains — especially the smaller ones (2–4 points) — should be interpreted with appropriate uncertainty. The ablation studies showing 1–2 point differences (e.g., Table 20: 73.9% vs. 78.6% across dedup thresholds) are particularly vulnerable to this concern.

• No held-out validation set for ACE. ACE does not use a validation set — it adapts directly on the training split, with the Curator determining what to add based on the Reflector's analysis of each training sample. This means there is no out-of-sample validation of whether added bullets generalize. GEPA, by contrast, uses a 57-query validation set. This design choice is consistent with ACE's philosophy (the Playbook accumulates everything potentially useful, letting the Generator decide relevance at inference time) but means that overfitting to the training split is possible — the Reflector might extract insights that are specific to training samples and don't transfer. The paper does not investigate this.

• AppWorld test set size. AppWorld test-normal has 160 queries and test-challenge has a similar count (not explicitly stated but implied by the 500 total across the benchmark). This is a modest evaluation set for measuring percentage-point accuracy differences — a 5-point gap on test-challenge corresponds to approximately 8 queries, which could be influenced by outliers with unusual API configurations or edge cases.

• Baseline fairness: GEPA and MIPROv2 use validation sets; ACE does not. ACE's offline adaptation processes only training queries (90 for AppWorld), while GEPA processes training queries plus a separate 57-query validation set. This gives GEPA access to additional data (the validation queries themselves) that ACE does not see — yet ACE still substantially outperforms. However, for this to be a "fair" comparison, one would need to account for the total information available. ACE's advantage is architectural (it uses fewer queries more effectively), but the comparison would be more controlled if both methods were given the same total queries (e.g., give ACE the validation queries as additional training, or restrict GEPA to training queries only for validation). The paper does not perform this ablation.

• Missing combination of search and revisions (analogous to the reference paper). While ACE is evaluated in both offline and online settings, the paper does not experiment with combining offline-optimized Playbooks with online updates that use a different strategy (e.g., offline = accumulate comprehensive knowledge, online = selectively prune for the test distribution). The offline-warmup experiment (Table 3) touches on this but doesn't explore whether the online update strategy should differ from the offline one.

• No ablation on the role of the Playbook's sectioning. The Curator assigns bullets to sections ("strategies_and_hard_rules", "apis_to_use_for_specific_information", etc.), but the paper does not evaluate whether this sectioning matters or whether a flat list of bullets would perform equivalently. If sectioning improves retrieval or Generator attention allocation, this would be a meaningful design insight.

• Model-specific prompt engineering. The paper provides all prompts in Appendix F, which is exemplary for reproducibility. However, the prompts are extensive and carefully structured — it is possible that performance is sensitive to prompt quality in ways that don't transfer across models. The cross-model experiments (Appendix §A.1) partially address this by using the same prompts across models, but they don't test whether model-specific prompt tuning would change the baseline-to-ACE gap.

• No comparison to fine-tuning-based adaptation. The paper positions ACE as an alternative to weight updates (Section 5: "adapting contexts is generally cheaper than updating model weights") but doesn't empirically compare against fine-tuning approaches like LoRA adaptation on the training split. For tasks where execution feedback is available, it would be informative to know how ACE's test-time gains compare to parameter-efficient fine-tuning on the same training data — both in terms of accuracy and total compute cost (training + inference). This is a significant missing baseline given the paper's positioning.

• The KV-cache cost argument is compelling but unvalidated. The paper reports a 91.8% cache hit rate with OpenAI's GPT-5.1 API but doesn't provide details on the experimental setup (how many queries, what cache TTL, whether the high hit rate generalizes across sequences). KV cache reuse rates depend heavily on batching, request interleaving, and cache eviction policies — a 91.8% rate in a controlled sequential evaluation may not generalize to production settings with concurrent requests.

Summary of experimental support for central narrative:

The paper's core narrative — that comprehensive, evolving playbooks with incremental updates outperform concise instruction optimization and avoid context collapse — is well-supported by the primary results (Tables 1–2), the cost analysis (Tables 4, 12–15), the incrementality ablation (Table 18), and the context-collapse case study (Figure 2). The feedback-dependence boundary condition is also well-established through the FiNER degradation without GT (Table 2) and the harmful-reflection robustness study (Table 17).

The strongest experimental evidence is the combination of Table 18 (incremental updates contribute 13.4 points on AppWorld) with Figure 2 (context collapse case study) and Table 12 (80.8% input token reduction vs. GEPA) — these three results together validate the paper's central technical claim that incremental delta updates are both functionally necessary (preventing collapse) and practically efficient (reducing cost).

The weakest areas are the absence of multiple-seed statistical validation, the modest size of some test splits (particularly AppWorld), the missing fine-tuning comparison, and the somewhat opaque derivation of the headline percentage improvements (10.6%, 8.6%) from the raw table data. None of these fundamentally undermine the paper's conclusions, but they add variance to the smaller reported gains and leave open the question of whether context adaptation dominates fine-tuning or is better viewed as a complementary approach for settings where weight updates are impractical.

6. Limitations and Trade-offs

The Reflector Requires Execution Feedback That Is Not Universally Available, and the Method Degrades When Feedback Is Absent

The assumption or constraint. ACE's Reflector — the diagnostic component that converts execution traces into structured insights — fundamentally depends on signals that distinguish correct behavior from incorrect behavior. The paper explicitly acknowledges this dependency (Section 5):

"A limitation of ACE is its reliance on a reasonably strong Reflector: if the Reflector fails to extract meaningful insights from generated traces or outcomes, the constructed context may become noisy or even harmful."

More precisely, the dependence is not on the Reflector's raw capability but on the availability of informative execution feedback. When ground-truth labels are unavailable, the Reflector must infer correctness from naturally occurring signals: code execution success/failure, API return values, unit test results, numerical consistency checks, error traces. These signals vary dramatically in informativeness across task types.

The consequence. When execution feedback is rich and diagnostic (code execution, unit tests, computational consistency), ACE achieves large gains without ground truth: +14.8% on AppWorld (Table 1) and +15.5% on Formula (Table 2). When feedback is absent — as in FiNER, where entity classification produces no runtime validation — ACE degrades below the base model: to 67.3% in online adaptation versus the 70.7% base model (Table 2, −3.4%). The mechanism is clear: without reliable feedback, the Reflector cannot distinguish correct from incorrect outputs, so it adds spurious or actively misleading bullets to the Playbook, which then guide the Generator toward errors on subsequent queries.

This creates a sharp deployment constraint. Many important applications — classification, open-ended generation, summarization, most NLP benchmarks — lack natural execution feedback. For these tasks, ACE either requires ground-truth labels (defeating the self-improvement narrative), human-in-the-loop validation (expensive at scale), or a fundamentally different reflection mechanism that the paper does not develop. The paper's headline claim of "self-improving" is therefore conditional: the system improves itself when the environment provides diagnostic signals, but degrades otherwise. Practitioners evaluating ACE for a new task must first determine whether their execution environment produces feedback informative enough to distinguish correct from incorrect behavior — a non-trivial assessment.

What evidence exists in the paper. The FiNER vs. Formula contrast in Table 2 is the key evidence. Both are financial reasoning tasks using the same base model, but Formula (numerical reasoning with computational consistency signals) shows +15.5% without GT while FiNER (entity classification without runtime validation) shows +0.4% offline and −3.4% online. The Dynamic Cheatsheet baseline shows the same pattern: on Formula without GT, DC degrades from 67.5% to 62.5% (−5.0%), demonstrating that the feedback-dependence is intrinsic to feedback-driven adaptation, not specific to ACE. The harmful-reflection robustness study (Appendix §A.4, Table 17) provides further evidence: performance degrades gracefully as harmful reflections become more frequent, dropping below the base model only when every single update is adversarial — but in FiNER without GT, every update is implicitly "adversarial" because the Reflector cannot distinguish signal from noise.

Mitigation status. The paper is unusually transparent about this limitation, explicitly discussing it in Section 5 ("Limitations and Challenges") and framing it as shared with Dynamic Cheatsheet: "This dependency is similar to Dynamic Cheatsheet, where the quality of adaptation hinges on the underlying model's ability to curate memory." It does not propose a solution. The implicit mitigation is task selection — use ACE for tasks with rich execution feedback, use supervised methods or human-in-the-loop for tasks without. The paper also notes that "bullet-point analyzer ('grow-and-refine'), which merges and deduplicates semantically similar bullets and can filter entries flagged as potentially harmful via metadata, serves as a first line of defense against context noise" (Appendix §A.4), and suggests "contradiction detection, prompting the Curator to prioritize high-confidence updates, or periodic pruning of outdated entries" as compatible extensions. However, none of these mitigations are implemented or evaluated, and they all assume that the harmful-to-helpful bullet ratio remains manageable — which is exactly what fails when every reflection cycle is unreliable (as in FiNER without GT).

---

The Playbook's Growth and Pruning Mechanisms Are Underspecified, Creating Two Unresolved Risks: Over-Pruning Valuable Knowledge and Saturating the Context Window

The assumption or constraint. ACE's grow-and-refine mechanism (Section 3.2) is designed to balance accumulating detail against maintaining a usable context size. The refinement side relies on two operations: (1) semantic de-duplication — merging bullets whose embedding similarity exceeds a threshold — and (2) pruning — removing bullets with high harmful-to-helpful counter ratios or low total helpful counts when the Playbook exceeds a maximum context length. Both of these operations are controlled by hyperparameters (dedup threshold, max context length) that the paper demonstrates are robust in a narrow experimental regime (Tables 20–21) but whose behavior in longer-horizon, higher-volume deployments is entirely uncharacterized.

The deeper issue is that the Playbook has no mechanism for intentional forgetting of outdated but not "harmful" knowledge. The metadata counters track helpful/harmful flags from the Generator's annotations, but these flags indicate whether a bullet was used in a particular attempt and whether the attempt succeeded — they do not indicate whether the knowledge encoded in the bullet is still valid. In a dynamic environment where APIs change, domain concepts evolve, or task distributions shift, bullets that were historically helpful may become actively misleading, yet their counters would still reflect past utility rather than current irrelevance.

The consequence. Two distinct failure modes are possible, neither of which the paper measures:

1. Over-pruning / premature pruning: If the max context length is set too aggressively relative to the accumulation rate, the pruning mechanism may delete valuable bullets that happened to have low helpful counts (because they address rare but important edge cases) or that were added recently and haven't had time to accumulate positive feedback. The paper's sensitivity analysis (Table 21) tests max context lengths of 10K, 50K, and 100K tokens — all on FiNER offline with a single epoch of adaptation. For a deployment running online adaptation over thousands or millions of queries, the relationship between context budget, accumulation rate, and pruning aggressiveness is unexplored. A practitioner has no guidance on how to set the max context length for a new task, and getting it wrong could silently delete the most valuable (but infrequently referenced) bullets.

2. Conceptual staleness / distribution shift: Counters track past utility but not current relevance. If an API endpoint's behavior changes, a bullet documenting the old behavior would have high helpful counters (from past successful use) but be actively harmful for current queries. The Generator would flag it as harmful after it causes failures, but in online adaptation with rare API changes, the accumulation of new negative counters might lag behind the damage caused. The paper makes no attempt to evaluate this failure mode — the AppWorld, FiNER, and Formula benchmarks are static; APIs don't change; domain concepts don't evolve during evaluation.

What evidence exists in the paper. The hyperparameter sensitivity analysis (Tables 20–21) shows that performance is stable across a wide range of dedup thresholds (50–90%) and max context lengths (10K–100K) — but only for FiNER offline adaptation. This is reassuring for the static-benchmark regime but tells us nothing about longer-horizon or distribution-shift scenarios. The paper does not report how many bullets are pruned versus retained at different thresholds, what fraction of the Playbook is active versus stale, or whether performance degrades if the max context length is set below the size at which all useful information fits. There is no ablation on the counter mechanism itself (e.g., comparing counter-based pruning to recency-based pruning or random pruning).

Mitigation status. The paper acknowledges the pruning-control problem only indirectly — by providing sensitivity analysis that shows insensitivity to the tested hyperparameters. It does not discuss the staleness problem, temporal distribution shift, or conceptual drift. The grow-and-refine mechanism is presented as a solved sub-problem (Section 3.2: "ACE ensures that contexts remain compact and relevant through periodic or lazy refinement"), but the empirical evidence for "compact and relevant" is limited to single-epoch offline adaptation on static benchmarks. For any deployment where the task environment evolves over time, the grow-and-refine mechanism as described is insufficient — it needs either temporal decay of counters, recency weighting, or explicit versioning that the paper does not provide.

---

The Framework Has Only Been Demonstrated on a Narrow Slice of Tasks — All Reasoning-Heavy, Most with Verifiable Outputs — and the Paper Provides No Evidence for Broader Applicability

The assumption or constraint. All experiments in the paper use benchmarks where correctness is either exact-match verifiable (MATH-like accuracy for FiNER/Formula, TGC/SGC for AppWorld, LLM-as-judge for BIRD-SQL) or execution-verifiable (AppWorld's code execution and unit tests). The LLM's primary task in every case is to produce a discrete, evaluable output — a classification label, a numerical answer, a SQL query, or an agent action sequence. The paper provides no experiments on open-ended generation, dialogue, creative writing, summarization, or any task where "correctness" is ambiguous, multi-dimensional, or subjective.

The paper acknowledges a milder version of this limitation in Section 5:

"We also note that not all applications require rich or detailed contexts. Tasks like HotPotQA often benefit more from concise, high-level instructions than from long contexts. Similarly, games with fixed strategies such as Game of 24 may only need a single reusable rule, rendering additional context redundant."

But this acknowledgment addresses the necessity of ACE's comprehensive-playbook approach, not the feasibility of extending it to tasks without clean correctness signals. The distinction matters: HotPotQA doesn't need a long context — but could ACE work on HotPotQA if one were desired? The paper doesn't answer this.

The consequence. Two separate concerns arise:

1. Verifier-dependent tasks. The AppWorld, Formula, BIRD-SQL, and DDXPlus experiments all involve tasks where the environment provides verifiable feedback — code execution traces, numerical computation checks, SQL execution results, or diagnostic agreement. This feedback is what powers the Reflector, which converts correctness signals into structured insights. On tasks without such feedback (factual QA, summarization, translation, open-ended dialogue), the Reflector would need to rely on the Generator's own confidence estimates or on heuristic quality signals (fluency, coherence) — neither of which is evaluated. The FiNER-without-GT degradation (67.3% vs. 70.7% base) demonstrates that when the Reflector lacks reliable feedback, ACE actively harms performance. This suggests that the current Reflector design is fundamentally coupled to verifiability — it doesn't just benefit from execution feedback; it requires it.

2. Generality of the playbook abstraction. The paper's central metaphor is that contexts should function as "comprehensive, structured playbooks." This metaphor is compelling for agent tasks (where the playbook accumulates API usage rules, common failure modes, and reusable code patterns) and domain-specific reasoning (where it accumulates financial concepts, medical diagnostic heuristics, or SQL schema rules). But for tasks where "strategies" are harder to formalize — creative writing (what makes a good story?), negotiation (what makes a persuasive argument?), or subjective QA (what makes a satisfying explanation?) — it is unclear what the bullets would contain. The paper provides no experiments or even speculative discussion on whether the playbook abstraction transfers to these domains.

What evidence exists in the paper. The paper evaluates on five benchmarks: AppWorld (agent), FiNER (entity recognition), Formula (numerical reasoning), DDXPlus (medical diagnosis), and BIRD-SQL (text-to-SQL). All are verifiable-reasoning tasks. There is no experiment on HotPotQA, MMLU, TruthfulQA, summarization benchmarks, or any open-ended generation task. The cross-model generalization experiments (Appendix §A.1) use the same task categories (AppWorld + finance), varying only the model. There is no cross-task-type generalization experiment. The paper's claim of "scalable, efficient, and self-improving LLM systems" (Abstract) is based entirely on this reasoning-heavy, verification-friendly slice of the task space.

Mitigation status. The paper acknowledges in Section 5 that "not all applications require rich or detailed contexts" and gives examples (HotPotQA, Game of 24) where concise instructions suffice. But this is framed as a statement about when ACE is unnecessary, not about when it fails. The fundamental limitation — that ACE's Reflector requires verifiable feedback and the playbook abstraction may not transfer to subjective or open-ended domains — is not discussed. No future work is suggested for extending ACE to tasks without clean correctness signals (e.g., training a learned quality estimator as a synthetic Reflector, or using LLM-as-judge for reflection in a loop). A practitioner considering ACE for a customer-support chatbot, a creative writing assistant, or a summarization pipeline has no experimental evidence to guide their decision.

---

The Cost Analysis Assumes KV Cache Reuse That May Not Generalize Across Deployment Scenarios, and the Evaluation-Time Token Overhead Is Under-Discussed

The assumption or constraint. Section 4.7 reports that ACE uses 117.4% more raw input tokens at evaluation time than GEPA (58.6M vs. 27.0M for 160 AppWorld test queries, Table 14), because the Playbook is much longer than GEPA's single optimized instruction. The paper argues this overhead is largely amortized by KV cache reuse, reporting that "91.8% of ACE's input tokens are served from cache" in an OpenAI GPT-5.1 experiment, yielding an "82.6% reduction in billed input-token cost relative to counting raw context tokens."

This argument rests on several implicit assumptions: (1) the serving infrastructure supports KV cache reuse with sufficiently long TTL to span sequential requests; (2) the Playbook — the long, static portion of the context — appears at a consistent position in the prompt so its KV representations can be reused; (3) requests are not interleaved with other users' requests in a way that evicts the cached Playbook; and (4) the cache hit rate observed in a controlled sequential evaluation (one sample at a time, no concurrent users) generalizes to production serving with batching, multiple concurrent sessions, and cache eviction under memory pressure.

The consequence. If KV cache reuse is unavailable or substantially lower than 91.8% — which is likely in high-throughput, multi-tenant deployments where many different Playbooks (one per application or per user) compete for cache space — the evaluation-time token cost of ACE could be roughly double that of GEPA (117.4% more input tokens, similar output tokens). The adaptation-time savings (80.8% fewer input tokens during offline training, Table 12) would partially offset this, but the net cost advantage depends on the ratio of evaluation queries to adaptation queries. For a system that adapts once and then serves millions of queries, the evaluation-time overhead dominates the total cost, and the adaptation savings become negligible.

This matters because the paper's efficiency narrative — "lower cost and adaptation latency" (Section 4.7) — could mislead practitioners into underestimating serving costs. A deployment engineer reading the paper might reasonably conclude that ACE is strictly cheaper than GEPA or DC, when in fact it may be cheaper at adaptation time but more expensive at serving time unless the specific KV-caching conditions hold.

What evidence exists in the paper. The KV-cache reuse experiment is mentioned briefly (Section 4.7, one paragraph) without experimental details: the number of queries, the cache TTL setting, whether requests were sequential or batched, or whether the experiment was repeated. The fine-grained token breakdowns (Tables 12–15) are thorough for raw token counts but do not include a parallel breakdown showing billed cost under different cache-hit assumptions. The paper does not report the Playbook's actual token length for different tasks, so a practitioner cannot estimate their own cache-hit-adjusted costs.

The paper acknowledges in passing that the evaluation stage uses more raw tokens (Table 14: "ACE uses more raw input tokens per query than GEPA due to its richer, more actionable playbook") but immediately defers to the caching argument. There is no sensitivity analysis: "What is ACE's evaluation cost at 50% cache hit rate? 0% cache hit rate?" This would be straightforward to compute from the raw token data but is not provided.

Mitigation status. The paper partially addresses this by citing the broader KV-cache optimization literature (Gim et al., 2024; Yao et al., 2025; Lee et al., 2024; Li et al., 2025) and arguing that "ongoing advances in ML systems suggest that the amortized cost of handling long contexts is likely to decrease" (Section 4.7). But this is a forward-looking argument, not a mitigation. The caching experiment is with a specific API (OpenAI GPT-5.1) under unspecified conditions, and the paper does not claim to have evaluated ACE under other caching regimes or with other serving infrastructures. A practitioner running ACE on self-hosted models without prompt caching, or in a high-concurrency setting where KV cache is frequently evicted, receives no guidance on expected costs. The paper could have — but did not — provide a simple table showing total cost (adaptation + evaluation) as a function of cache hit rate, which would make the tradeoff transparent.

---

The Reflector's Quality Depends on the Generator's Base Competence, Creating a "Rich Get Richer" Dynamic That Magnifies Initial Capability Gaps

The assumption or constraint. ACE's three-role architecture uses the same LLM (DeepSeek-V3.1 by default) for the Generator, Reflector, and Curator. The Reflector's ability to diagnose errors and extract insights depends critically on the quality of the execution traces produced by the Generator. A weak Generator produces trajectories that are confusing, incomplete, or trivially wrong — and the Reflector, working with these trajectories, may extract spurious or overly simplistic lessons that fail to capture the nuances a stronger Generator would need.

The paper assumes that the base model's competence is sufficient for the Reflector to extract useful insights from its own errors. This is plausible for models like DeepSeek-V3.1 on tasks like AppWorld and Formula, where the base accuracy is non-trivial (~42% on AppWorld, ~68–71% on finance). But the assumption weakens dramatically as base competence drops — if the Generator succeeds only 10% of the time, most trajectories are failures, and the Reflector's task of distinguishing "informative failure" from "random noise" becomes fundamentally harder.

The consequence. ACE's relative improvement over baselines should scale with base model capability, not remain constant. A weaker Generator produces lower-quality traces → the Reflector extracts lower-quality insights → the Playbook accumulates lower-quality knowledge → the adaptation yield (points gained per unit of adaptation compute) decreases. At some threshold of base incompetence, ACE may provide no benefit at all — or may even degrade performance (as seen on FiNER without GT, where the base model's 70.7% accuracy proved insufficient for the Reflector to extract useful unsupervised insights).

This creates a deployment dynamic where ACE widens the gap between strong and weak models: a GPT-5.1-based system gains more from ACE adaptation (in absolute terms) than a Llama-3.3-70B-based system, not because the framework discriminates but because the feedback loop's efficiency depends on initial signal quality. The paper's cross-model experiments provide partial evidence: GPT-5.1 + ACE online achieves 65.8% on AppWorld (Table 6, +11.6% over base 54.2%), while GPT-OSS-120B + ACE online achieves only 42.2% (Table 5, +7.6% over base 34.6%). The absolute base-to-ACE gap for GPT-5.1 (11.6 points) is larger than for GPT-OSS-120B (7.6 points), consistent with the "rich get richer" hypothesis — though the gap is modest and confounded by task difficulty (GPT-OSS-120B's base is much lower, suggesting a harder absolute regime).

What evidence exists in the paper. The cross-model experiments (Tables 5–9) provide suggestive but not conclusive evidence. Across AppWorld (offline, with GT labels): DeepSeek-V3.1 gains +17.0% over base (from 42.4% to 59.4%), while GPT-OSS-120B gains +5.9% (from 34.6% to 40.5%). The relative improvement is much larger for the stronger model, but the base accuracy difference (42.4% vs. 34.6%) confounds model capability with task difficulty. On finance (offline, with GT): DeepSeek-V3.1 gains +12.8% over base (69.1% to 81.9%), GPT-OSS-120B gains +12.1% (69.1% to 81.2%), and GPT-5.1 gains +9.5% (73.3% to 82.8%). Here the gains are remarkably consistent despite base capability differences, suggesting the "rich get richer" dynamic may be task-dependent or saturated at high base accuracies. The Llama-3.3-70B results (Table 9) are the most telling: base 62.5%, ACE offline +2.4% to 64.9%, ACE online +1.1% to 63.6% — very small gains from a weaker model, consistent with the hypothesis that the Reflector struggles to extract useful insights from lower-quality traces.

The paper does not systematically ablate Generator quality while holding Reflector quality constant. The weaker-Reflector experiment (Appendix §A.4, Table 16) varies the Reflector but keeps the Generator at DeepSeek-V3.1; the cross-model experiments (Tables 5–9) vary both Generator and Reflector simultaneously. Neither isolates the Generator's contribution to adaptation quality. A controlled experiment — using the same Reflector (e.g., GPT-5.1) with different Generator strengths — would directly test the "rich get richer" hypothesis but is not performed.

Mitigation status. The paper does not discuss this limitation explicitly. It acknowledges that "in domain-specific tasks where no model can extract useful insights, the resulting context will naturally lack them" (Section 5), but frames this as a limitation of the task domain, not of the Generator-Reflector capability gap. The implicit recommendation is that ACE should be used with models that have non-trivial base performance on the target task — but no threshold is suggested, and no guidance is provided for estimating whether a given base accuracy is "sufficient" for the Reflector to bootstrap useful adaptation.

7. Implications and Future Directions

How This Work Changes the Landscape

ACE reorients the conversation around LLM context adaptation from an optimization framing toward a preservation framing. Before this work, the dominant assumption — implicit in prompt optimizers like GEPA and MIPROv2, and in memory systems like Dynamic Cheatsheet — was that iterative rewriting of context would progressively refine it: each rewrite would produce a "better," more distilled version of accumulated knowledge. ACE demonstrates that this assumption is not merely sometimes wrong, but structurally wrong for long-horizon adaptation. Monolithic rewriting does not refine context; it destroys it, abruptly and catastrophically, through the mechanism the paper names as context collapse (Figure 2: 18,282 tokens → 122 tokens, 66.7% accuracy → 57.1% accuracy in a single step).

This is a conceptual shift, not an incremental improvement. The practical implication is that the primary design challenge for adaptive context systems is no longer "how do we make the context better at each step?" but rather "how do we guarantee that existing knowledge survives the update process?" The field's default approach — having an LLM regenerate the entire context from scratch at each adaptation step — is now a known anti-pattern. Future work on test-time memory, agent memory, and prompt optimization must either adopt incremental update mechanisms (as ACE does) or provide evidence that their rewriting procedure avoids collapse. The burden of proof has shifted: methods that use full-context rewrites must now demonstrate that they do not silently compress away accumulated knowledge, rather than assuming each rewrite is an improvement.

Equally important is ACE's empirical characterization of where context-based self-improvement works and where it fails, establishing feedback quality as the central boundary condition. Prior work studied adaptation methods on individual benchmarks without systematically varying feedback availability. ACE demonstrates a crisp pattern (Tables 1–2): on tasks with rich execution feedback (AppWorld: +14.8% without GT labels; Formula: +15.5% without GT labels), the Reflector extracts useful insights from naturally available signals; on tasks without execution feedback (FiNER without GT: −3.4% online), adaptation degrades performance because the Reflector cannot distinguish correct from incorrect outputs. This converts what appeared to be inconsistent results across prior papers into a coherent, testable framework: the success of feedback-driven adaptation on a given task can be predicted by asking whether the execution environment provides diagnostic signals.

This finding redirects research attention toward feedback engineering as a first-order concern. The field has focused heavily on adaptation algorithms (how to update the context given feedback) while treating the feedback signal as a given. ACE's results suggest that feedback quality may be the binding constraint — improving the Reflector's diagnostic capability matters less if the execution traces provide no signal to diagnose. Tasks that can be instrumented with unit tests, runtime checks, or consistency constraints become natural candidates for autonomous self-improvement; tasks that produce only binary correct/incorrect judgments require fundamentally different approaches (supervised adaptation, human-in-the-loop, or learned quality estimators that the paper does not develop).

The work also reconciles a latent tension in the prompt engineering literature. Prompt optimizers like GEPA prioritize concision and achieve strong results on benchmarks where a single well-crafted instruction suffices (the paper cites HotPotQA and Game of 24 as examples). ACE shows that on tasks requiring many granular strategies — multi-turn agents, domain-specific reasoning, knowledge-intensive applications — comprehensive, evolving playbooks dramatically outperform concise instructions (11.9-point gap over GEPA on AppWorld, 9.4-point gap on finance, Tables 1–2). These are not competing claims; they are correct for different task regimes. The reconciliation is that context representations have a capacity-performance frontier: single-instruction prompts saturate quickly with information, while structured playbooks scale to hold hundreds of distinct insights. The optimal representation depends on how many distinct pieces of knowledge the task requires — a quantity the paper does not formalize but makes empirically visible.

Finally, ACE establishes that the separation of cognitive labor in agentic systems — decomposing execution, diagnosis, and curation into specialized roles with distinct prompts — provides gains beyond what any single unified model call can achieve. The ablation showing that removing the Reflector costs 4.3 points on AppWorld (Table 3) and that adding iterative refinement within the Reflector yields an additional 2.6 points demonstrates that specialization matters independently of model capability. This provides a template for future agentic learning systems: rather than asking one LLM to simultaneously solve the task, diagnose what went wrong, and write the corrective update, separate these functions and let each component focus on its specialized objective. The finding that even a much weaker Reflector (GPT-OSS-120B vs. DeepSeek-V3.1) still provides substantial gains (Table 16: 76.6% vs. 78.3%) strengthens this argument — the benefit comes from the separation itself, not from having a particularly capable evaluator.

Follow-Up Research This Work Enables

Characterizing the collapse boundary: when does monolithic rewriting fail, and what context sizes trigger it? Figure 2 provides a single dramatic case study (18K tokens → 122 tokens at step 60 on AppWorld), but the paper does not systematically characterize the conditions under which collapse occurs. A direct follow-up would systematically vary (a) total context length before rewriting, (b) information density of the context (ratio of unique facts to filler text), (c) the number of distinct topics or strategies encoded, and (d) the complexity of the rewriting instruction. The goal would be to determine whether collapse is a threshold phenomenon (occurring abruptly at some critical context size), a gradual degradation, or dependent on information density rather than raw token count. Such a study would provide practical guidance for when existing monolithic methods are safe to use versus when incremental updates become necessary. The experiment could use a controlled synthetic context where the number of inserted "facts" is known, then measure how many facts survive a rewrite as a function of initial fact count and context length. If collapse is predicted by a simple heuristic (e.g., context length / model's effective attention span), that heuristic would become a deployment tool.

Combining ACE-style playbooks with parameter-efficient fine-tuning for closed-loop self-improvement. The paper positions ACE as an alternative to weight updates but never empirically compares them. A natural hybrid approach would use ACE's offline adaptation to construct a comprehensive Playbook on a training split, then fine-tune the base model (via LoRA or full fine-tuning) on the same training data, then compare: (a) base model + ACE Playbook, (b) fine-tuned model (no Playbook), and (c) fine-tuned model + ACE Playbook. The key question is whether context adaptation and weight updates provide complementary or redundant improvements. If complementary, a fine-tuned model with an ACE Playbook might substantially outperform either alone — the fine-tuning captures general patterns in the training distribution, while the Playbook captures specific strategies, edge cases, and procedural knowledge that are hard to encode in weights. If redundant, the Playbook's value might shrink as the model improves, suggesting that ACE is most valuable precisely when fine-tuning is impractical (privacy constraints, rapid deployment, continuous online learning). The experiment should measure both accuracy and total cost (fine-tuning compute + inference compute with and without KV cache reuse), since the practical tradeoff depends on the relative expense of training versus context-length-increased inference. The paper's cost analysis (Tables 12–15) provides a template for this comparison.

Extending ACE to tasks without execution feedback by training a learned quality estimator as a synthetic Reflector. The paper's most important negative result is the FiNER degradation without ground truth labels (Table 2: 70.7% → 67.3% online). This defines a clear boundary for autonomous ACE-style adaptation: tasks that lack natural execution feedback cannot support unsupervised reflection. A direct extension would replace the execution-feedback-dependent Reflector with a learned verifier — a classifier trained on a small set of labeled examples to estimate whether a generated output is correct. This verifier would serve as a synthetic execution signal: when the Generator produces an answer, the verifier estimates its correctness probability, and the Reflector uses this estimate (rather than ground truth or execution traces) to diagnose errors and extract insights. The research question is: how many labeled examples are needed for the synthetic Reflector to provide sufficient signal quality to bootstrap effective ACE adaptation? On FiNER, where the base model achieves 70.7%, a verifier trained on even 100–500 labeled examples might achieve sufficient discrimination to prevent the degradation seen without GT. The experiment would compare ACE-with-learned-verifier to ACE-with-GT and ACE-without-GT across multiple label budgets. If a few hundred labels suffice, the practical applicability of ACE expands dramatically to classification and structured prediction tasks.

Studying temporal distribution shift and conceptual staleness in long-running ACE deployments. The paper evaluates ACE on static benchmarks where test distributions match training distributions. In real deployments, the task environment evolves: APIs change, domain concepts update, user behaviors shift. ACE's Playbook has no mechanism for detecting or responding to staleness — bullets that were historically helpful (high helpful counters) may become actively misleading if the underlying reality changes, yet the counters provide no signal about temporal validity. A stress-test experiment would run ACE in a simulated non-stationary environment: e.g., a modified version of AppWorld where API behaviors change at known time points (a pagination pattern flips from page-based to cursor-based; an authentication method changes). The experiment would measure (a) how quickly the Playbook accumulates harmful bullets after a distribution shift, (b) whether the harmful/harmful counter mechanism detects the shift quickly enough to prevent sustained degradation, and (c) whether simple extensions — temporal decay of counters, recency-weighted helpfulness, explicit versioning of bullets — improve adaptation speed. This is a critical robustness check: if ACE fails catastrophically under distribution shift (e.g., accuracy dropping below the base model for an extended period while harmful counters slowly accumulate), then the framework is unsafe for dynamic environments without additional staleness-detection machinery.

Robustly measuring the relative contribution of the bullet representation versus the incremental update mechanism. The ablation in Appendix §A.5 (Table 18) shows that removing incremental updates from ACE on AppWorld causes a 13.4-point drop on test-normal — but this ablation removes both the bullet representation and the incremental update mechanism simultaneously (replacing them with monolithic rewriting). The bullet representation and the incremental update mechanism are distinct design choices that could, in principle, be separated. A cleaner ablation would test four conditions on the same task: (a) monolithic prose context + monolithic LLM rewriting (Dynamic Cheatsheet baseline), (b) bullet-structured context + monolithic LLM rewriting (the LLM sees the full bullet-organized Playbook and is asked to regenerate a compressed version), (c) monolithic prose context + incremental updates (the context is free-form text but updates are applied as localized edits using a diff-based merge), and (d) bullet-structured context + incremental non-LLM merging (full ACE). The results would decompose ACE's gains into the fraction attributable to the representation (bullets vs. prose) versus the update mechanism (incremental vs. monolithic). If the bullet representation alone provides substantial gains even with monolithic rewriting (b vs. a), that would recommend adopting bullet-structured contexts even in systems that can't support incremental updates. If incremental updates on prose text already prevent collapse (c vs. a), that would simplify ACE's design by removing the need for bullet-specific prompts and metadata.

Evaluating ACE on open-ended generation tasks where "correctness" is multidimensional, to test the limits of the playbook abstraction. The paper evaluates exclusively on tasks with exact-match or execution-verifiable correctness. The playbook metaphor — accumulating "strategies," "common failure modes," and "domain rules" — maps naturally to these settings. But many important LLM applications involve open-ended generation (dialogue, creative writing, explanation, negotiation) where quality is subjective and no single "correct" answer exists. A boundary-testing experiment would apply ACE to a task like convincingness in debate or helpfulness in customer support, where the Reflector's diagnostic signal comes not from execution traces but from a learned reward model or LLM-as-judge. The key question is whether the playbook representation remains useful when bullets must encode qualitative heuristics ("when the user expresses frustration, acknowledge their emotion before proposing a solution") rather than procedural rules ("always use while True loops for pagination"). If ACE provides gains on such tasks, the playbook abstraction generalizes broadly. If it provides no gains — or if the Reflector cannot extract useful insights from reward-model scores — then ACE's applicability is bounded to verifiable-reasoning domains, which would be a significant constraint on the framework's claimed generality.

Practical Applications and Downstream Use Cases

On-device or edge deployment of agents with continuous self-improvement. ACE's 82.3% reduction in adaptation latency versus GEPA (9,517s vs. 53,898s on AppWorld, Table 4a) and 91.5% reduction versus DC online (5,503s vs. 65,104s on FiNER, Table 4b) make it feasible to run continuous context adaptation on modest hardware where full model fine-tuning or expensive prompt optimization loops would be prohibitive. An edge-deployed agent (e.g., a home automation assistant using a 7B–13B model) could use ACE's online adaptation mode to accumulate environment-specific strategies — which APIs to call for which devices, how to handle authentication for local services, common failure modes in the specific home setup — entirely from execution feedback, without requiring labeled data or cloud offloading. The incremental delta mechanism means that each adaptation step costs only a few thousand tokens (Table 13: ACE averages 436K input tokens per query during adaptation vs. GEPA's 1.4M), making adaptation feasible even under tight latency and compute budgets. The offline warmup capability (Table 3: +3.4 points on AppWorld) allows the system to ship with a pre-populated Playbook from manufacturer testing, then refine it for the specific deployment environment online.

Cost-efficient data generation and self-training pipelines. Organizations that use LLMs to generate training data for fine-tuning (rejection sampling, STaR-style self-improvement, distillation) face a tension between generation quality and cost: running a large model with extensive test-time compute (e.g., best-of-N with a verifier) produces higher-quality data but at prohibitive expense. ACE offers an alternative: invest adaptation compute once to build a comprehensive Playbook from a modest number of seed examples, then use the Playbook to guide a smaller or faster Generator during large-scale data generation. The Playbook amortizes the cost of discovering strategies, edge cases, and common failure modes over millions of generation queries. The paper's results suggest this is most effective for tasks with rich execution feedback: on Formula, ACE achieves 85.5% accuracy with ground truth labels using DeepSeek-V3.1 (Table 2) — competitive with what a much more expensive model might achieve — by accumulating XBRL-specific financial computation rules in the Playbook. A data generation pipeline could run ACE offline on a few hundred labeled examples to build the Playbook, then use the Playbook-equipped Generator to produce high-quality training data at scale, with the Playbook's strategies compensating for the Generator's lower base capability.

Multi-tenant agent platforms with per-tenant context adaptation. In a platform where many customers deploy agents for different domains (e.g., a SaaS platform offering customizable customer-support agents, each tenant having different product catalogs, policies, and common customer issues), ACE's itemized, mergeable context representation enables per-tenant Playbook isolation without per-tenant model fine-tuning. Each tenant's Playbook accumulates strategies specific to their domain — handling their specific return policies, knowing their product taxonomy, recognizing their common user complaints — through online adaptation as the agent interacts with that tenant's customers. Because Playbooks are human-readable bullet collections, a tenant administrator can inspect, edit, or remove bullets for compliance or quality control. The de-duplication and pruning mechanisms (Section 3.2) keep Playbooks from growing unboundedly as tenants accumulate months of interaction history. The paper's KV-cache finding (91.8% cache reuse on OpenAI GPT-5.1, Section 4.7) is particularly relevant here: in a multi-tenant setting where each tenant's Playbook is served repeatedly for their users, the long static Playbook prefix benefits from caching, making the per-query serving cost much lower than the raw token count suggests. This is a concrete deployment architecture where ACE's design tradeoffs (more evaluation tokens, but high cacheability; incremental updates, but adaptation-time efficiency) align with the operational constraints.

When to Prefer This Method

The paper explicitly positions ACE against two categories of alternatives: prompt optimizers that produce concise single-instruction prompts (GEPA, MIPROv2) and test-time memory methods that accumulate experience through monolithic rewriting (Dynamic Cheatsheet). The empirical results support the following decision framework:

• Prefer ACE over prompt optimization (GEPA, MIPROv2) when the task requires multiple distinct strategies, domain-specific rules, or procedural knowledge that cannot be compressed into a single instruction without performance loss. The paper's quantitative threshold: on AppWorld, ACE outperforms GEPA by 11.9 points (Table 1); on FiNER and Formula, by 9.4 points (Table 2). The cost tradeoff favors ACE at adaptation time (82.3% latency reduction vs. GEPA, Table 4a) but requires accepting higher evaluation-time context length, mitigated by KV cache reuse. On tasks where a single well-crafted instruction suffices (the paper cites HotPotQA, Game of 24), prompt optimizers may be simpler and equally effective.

• Prefer ACE over monolithic memory methods (Dynamic Cheatsheet cumulative mode) when the adaptation horizon is long enough for context collapse to become a risk. The paper provides both a diagnostic (Figure 2: collapse at step 60 on AppWorld) and quantitative evidence: ACE outperforms DC by 7.6 points on AppWorld online (Table 1) and by 4.8 points on finance online (Table 2). The cost advantage is substantial (91.5% latency reduction vs. DC online, Table 4b). For single-turn reasoning benchmarks where accumulated context remains short and collapse is unlikely, DC may be simpler and comparably effective.

• Prefer ACE with ground-truth labels or rich execution feedback when the task lacks natural runtime verification signals. On FiNER without GT labels, ACE degrades to 67.3% versus 70.7% base (Table 2); on Formula with natural computational feedback, ACE achieves 83.0% without GT. The boundary is whether the execution environment provides diagnostic signals (code execution traces, unit tests, numerical consistency checks) that the Reflector can use to distinguish correct from incorrect outputs without knowing the answer.

• Prefer ACE's online adaptation with offline warmup when deployment involves a distribution of tasks where some strategies can be learned offline (from labeled training data) but test-time-specific insights are still valuable. The offline warmup provides a 3.4-point improvement over pure online adaptation on AppWorld (Table 3: 56.1% → 59.5%) by giving the online phase a strong initial Playbook foundation, reducing the noise from early updates when the Playbook is empty.

• Prefer model fine-tuning over ACE when the task distribution is stationary, sufficient labeled data exists, and the deployment infrastructure supports weight updates. ACE's advantage is in settings where fine-tuning is impractical — continuous online learning, rapid deployment, privacy constraints preventing weight modification, or environments with frequent distribution shifts where retraining would be too slow. The paper does not empirically compare ACE to fine-tuning, so the crossover point (in terms of available labeled data, base model size, or task complexity) at which fine-tuning becomes preferable is unknown.