ACE: AI Agents That Evolve by Modifying Their Context

The ACE framework explores how language model-based agents can progress without altering the model weights, by adjusting only a context playbook. Tests indicate speed and cost gains compared to existing approaches, but also pitfalls if the feedback signal is weak.

Identified Risks and Quantified Failure Cases

A case observed on AppWorld highlights the fragility of complete context rewrites: a Dynamic Cheatsheet dropped from 18,282 tokens to 122 in a single step, and the reported accuracy fell from 66.7% to 57.1%. This is a one-off example of failure, not a representative rate. More broadly, memory alone is insufficient: the quality and factual robustness of updates condition progress; otherwise, erroneous rules may be learned and then reproduced. This constraint is particularly pronounced when agents reuse tools or domain rules that generic prompts might overlook. The quality of feedback then becomes crucial: the system must first detect incomplete outputs to correct them. A result on FiNER without labels also shows that weak feedback can pollute a playbook.

What ACE Does at the Context Level, Not the Weights

ACE avoids complete rewrites by maintaining context in the form of named modular entries, updated after each task. The loop involves a Generator that performs the task using the existing playbook, a Reflector that examines the attempt and feedback to draw lessons, and then a Conservator that converts these lessons into a concise delta update. A merging mechanism integrates this update into the playbook without modifying the model weights. The playbook retains rules on tool usage, reusable code, and troubleshooting recommendations; each entry has an identifier, utility or harmfulness counters, and can be added, modified, merged, or deleted based on the evolving context. One given example concerns invoice extraction: if a next_page field is detected, a relevant rule would be to continue following it until it is empty before proceeding to totalization. This example illustrates the logic, without corresponding to an actual execution.

Evaluations: Offline and Online Modes, and Measured Gains

Evaluations concern offline adaptation, where the playbook is developed before the testing phase, as well as online adaptation, during which the agent makes a prediction on an item before proceeding with an update based on it. These evaluations are conducted notably in AppWorld, while most LLMs offering these features are still in early stages and would need to be assessed. In AppWorld, the full version of ACE outperforms private variants of multi-epoch adaptation or dedicated Reflector. In online mode, adding offline warming also improves performance. Speed gains have been observed on tested loads: offline on AppWorld, ACE takes significantly less time than GEPA; online on FiNER, ACE is markedly faster and less costly than Dynamic Cheatsheet.

When to Adopt and How to Test in an Application

ACE is particularly relevant when tasks are repetitive, success is verifiable, and small procedural rules can be transferred from one case to another. Some tasks, like HotPotQA or Game of 24, may, however, be limited to concise rules. To evaluate ACE in practice, it is recommended to compare it to a fixed context baseline on reserved task sets, track success rates, the evolution of the playbook, and how often a rule later proves harmful. Maintaining an explicit feedback signal is advised. The provided code offers a concrete implementation and playbook format to facilitate these trials.

ACE's Objective and Positioning Against Rewrites

ACE aims to transform useful experiences into traceable context updates, to improve what subsequent agents will read and do. Results indicate notable gains for tasks where reusable knowledge and feedback are essential. The framework distinguishes itself from approaches that rewrite all context, a practice exposed to the risk of erasing details and requiring careful management in agentic environments. Specifically, ACE operates through small delta updates on modular entries and keeps the model weights unchanged. Its loop relies on three roles—Generator, Reflector, and Conservator—and is accompanied by a playbook editing mechanism rather than a complete overhaul.