Prompt optimizers compress what an agent knows into ever-shorter instructions — until one rewrite deletes 18,282 tokens of accumulated strategy and accuracy falls below never having adapted at all. ACE splits adaptation into three roles, updates the context in small append-and-edit deltas instead of rewrites, and turns a frozen open-source model into an agent that matches a GPT-4.1 production system — without a single gradient step, and without labels.
Your agent is failing, and you cannot touch the weights.
Concretely: you have wired DeepSeek-V3.1 into AppWorld — a benchmark environment of simulated phone apps (email, file system, contacts, music players) where an agent must read API documentation, write code that calls those APIs, and chain multi-step tasks like "find the venmo-style payment my roommate sent last week and reply to the email thread about it." Out of the box, running the standard ReAct loop, the agent completes 63.7% of task goals on the normal split and only 41.5% on the challenge split. It keeps making the same classes of mistakes: calling an API with the wrong pagination convention, forgetting that a login token expires, re-deriving the same discovery about the file-system app in every single episode, from scratch.
The classical fix is training: collect trajectories, compute gradients, update weights. But you may not have the weights (a closed API), may not have the GPUs (a 671-billion-parameter model does not fine-tune on a laptop), and even if you have both, every deployed copy of the agent would need the new checkpoint shipped to it. So the question this paper lives inside is: how much of "learning" can you get by changing only what the model reads — its context — while the weights stay frozen?
"Context" is not one thing. In a modern LLM application there are at least four distinct input surfaces you control without touching a parameter:
| Surface | What lives there | When it changes |
|---|---|---|
| System prompt | Standing instructions, domain rules, output format contracts | Offline — optimized once against a training set, then deployed fixed |
| Memory | Facts and lessons carried across episodes: "the payments app paginates 10 per page" | Online — updated as the agent works, at test time |
| Evidence | Retrieved documents, API docs, database rows — grounding that reduces hallucination | Per query, via retrieval |
| Demonstrations | Worked examples of input → output (few-shot / many-shot ICL) | Usually fixed after selection |
This paper's method, ACE (Agentic Context Engineering), targets the first two: it optimizes system prompts in the offline setting (learn from a training split, deploy, evaluate frozen) and agent memory in the online setting (adapt continuously on the test stream, where each sample is answered first and learned from second). Same algorithm, both regimes — that dual coverage is unusual and worth noticing now, because the results tables in Chapters 6 and 7 are split along exactly this line.
Adapting context instead of weights is not merely a workaround for missing GPUs. It has four properties that gradient fine-tuning structurally lacks:
1. Interpretability. A context is text. When the agent starts failing, you open the playbook and read what it believes. When a LoRA adapter starts failing, you stare at a tensor. The paper pushes this further in its discussion: because context is readable, you can do selective unlearning — delete the one entry that is wrong, or the one entry a GDPR erasure request covers — something no weight-update method can do surgically.
2. Runtime integration. New knowledge lands the moment it is appended. No training run, no checkpoint rollout, no serving-fleet redeploy.
3. Shareability. One context can be handed to a different model, or to several modules of a compound system at once. Chapter 8 shows ACE working across four different model families with the same algorithm and prompts — try that with a fine-tuned checkpoint.
4. Falling infrastructure cost. Long-context models keep getting longer, and serving stacks increasingly reuse the KV cache — the transformer's internal attention state — across requests that share a prefix. A large, mostly-stable context is exactly the workload prompt caching was built for. Chapter 9 measures this: 91.8% of ACE's input tokens get served from cache.
The same failing agent, two ways to make it better. Watch what each path requires and where the improved behavior lands.
Throughout the paper, one adaptation step has the same shape regardless of setting. The agent (or model) attempts a task sample with its current context. The attempt produces a trajectory: reasoning, tool calls, code, execution results — success or failure. Some process inspects that trajectory and decides how the context should change. Then the next sample arrives. The offline/online distinction is only about which samples drive this loop (a training split iterated for up to 5 epochs, versus the live test stream seen once) — the loop itself is identical.
The state of the art before ACE ran this loop with what the authors call natural language feedback: an LLM reads the trajectory and writes prose about what to change. Reflexion does this for agent planning; TextGrad treats the feedback as a pseudo-gradient; GEPA wraps it in a genetic search over prompt candidates; Dynamic Cheatsheet accumulates an external memory of strategies at test time. ACE keeps the natural-language-feedback engine but changes what is allowed to happen to the context afterward — and Chapter 1 shows exactly why that change was necessary, with a failure case you can watch happen.
If adapting context is so attractive, why wasn't it already solved? Because the existing methods share two failure modes, and both come from the same unexamined assumption: that a context should be short and polished, and that the way to update it is to rewrite the whole thing. This chapter takes each failure mode in turn — the second one with a live replay of the paper's own measurement.
Brevity bias is the tendency of prompt optimizers to converge toward short, generic instructions. It is not an accident of implementation — it is baked into the objective. GEPA, the strongest prompt optimizer ACE compares against, explicitly cites the conciseness of its evolved prompts as a strength. And for some tasks it is one: a crisp instruction generalizes, costs few tokens, and avoids distracting the model.
But watch what happens on tasks that need accumulated specifics. Gao et al. documented the effect in prompt optimization for test-case generation: iterative optimizers kept producing near-identical prompts like "create unit tests to ensure methods behave as expected" — a sentence so generic it could caption any testing tutorial ever written. Every domain-specific heuristic the optimizer had momentarily discovered (how this codebase names fixtures, which edge cases this module historically breaks on) got squeezed out, because the optimizer's notion of "better" rewarded the polished summary over the messy accumulation. Worse, the convergence narrows the search: once every candidate prompt in the population says roughly the same thing, recombining them can only produce more of the same thing, and errors inherited from the seed prompt propagate forever.
The second failure is more violent, and the paper gives it a name: context collapse. It afflicts methods that maintain a growing context by having an LLM rewrite the whole thing at each step — what the paper calls monolithic rewriting. Dynamic Cheatsheet's cumulative mode works this way: at each test sample, the model regenerates its entire memory, deciding holistically what to keep.
The authors ran this on AppWorld and logged the context size at every adaptation step. For 60 steps the memory grew — strategies accumulated, accuracy climbed. At step 60 the context held 18,282 tokens and the agent scored 66.7. Then, at step 61, the model performing the rewrite — faced with regenerating a document that had grown large — did what LLMs do with long documents: it summarized. The rewritten context came back at 122 tokens. Accuracy fell to 57.1, below the 63.7 baseline of an agent that had never adapted at all. Sixty steps of accumulated learning, deleted in one generation, leaving the agent worse than ignorant — confidently guided by a stub.
The paper's Figure 2 case study as a timeline. Press play (or step) and watch the context grow for 60 adaptation steps — then watch one monolithic rewrite delete it. The teal line is context size; the warm line is task accuracy; the dashed line is the never-adapted baseline.
Why does this happen mechanically? Because a full rewrite makes the LLM the storage layer. Every piece of accumulated knowledge survives only if the model, in one autoregressive pass, decides to re-emit it. As the context grows, re-emitting everything gets harder (longer generation, more places to drop things) and summarizing gets more tempting (that is what the model's training distribution overwhelmingly does with long inputs). The probability that any given detail survives step k is less than 1; compound that over sixty steps and the question is not whether collapse happens but when. The paper is careful to say this is not a Dynamic-Cheatsheet-specific bug: it is "a fundamental risk of end-to-end context rewriting with LLMs."
Put the two failures side by side and the shared root cause is visible:
| Failure | Surface symptom | Root cause |
|---|---|---|
| Brevity bias | Optimized prompts converge to short generic instructions; domain detail never accumulates | The objective and the operator both favor compression; there is no append-only path for detail to survive |
| Context collapse | A growing memory is abruptly summarized into a stub; accuracy drops below baseline | The whole context passes through one LLM generation at every update; the LLM is a lossy storage medium |
Both failures are consequences of treating the context as one blob that an LLM rewrites. If the context were instead a collection of small, separately-addressable items — where updates add or edit items and never regenerate the whole — neither failure has a mechanism to occur. Detail accumulates because nothing ever compresses it; collapse is impossible because no single generation ever holds the store's fate. That is the entire structural bet of ACE, and Chapters 3 through 5 build it piece by piece.
Chapter 1 diagnosed two failure modes and traced both to one assumption: contexts should be short, and updates should be rewrites. Before building the machinery that fixes this, stop and ask the prior question — what should a good context even look like? The paper's answer is a genuine position statement, and it cuts against decades of prompt-engineering folklore.
The claim, nearly verbatim: contexts should function not as concise summaries, but as comprehensive, structured playbooks — detailed, inclusive, and rich with domain insights. Do not compress away the tactics, heuristics, and failure modes. Keep them all, organized, and let the model decide at inference time which ones matter for the query in front of it.
The justification is an asymmetry between human and machine readers that is easy to state and easy to forget. Humans benefit from concise generalization because our working memory is tiny; a wall of 200 bullet points overwhelms us, so we distill. LLMs are the opposite: attention over a long context is exactly the operation they are built for, and modern models are demonstrably good at ignoring irrelevant detail while finding the one relevant line — the needle-in-a-haystack skill. A context optimized for a human editor's taste (short, elegant, general) is optimized for the wrong reader.
Here is the same agent, the same AppWorld-style task, under the two philosophies. The optimized-instruction context is what a brevity-biased optimizer converges to. The playbook excerpt is condensed from what ACE actually grows on AppWorld (the paper's Figure 3 shows a real fragment; this mirrors its structure).
You are a capable agent. Read the API docs carefully, plan before acting, verify each step's result, and complete the user's task accurately and efficiently.
## strategies_and_hard_rules
[str-00012] (helpful=17 harmful=0) Always call
apis.api_docs.show_api_doc() before first use
of ANY api — signatures differ from intuition.
[str-00031] (helpful=9) Phone contacts: resolve
relation names ("roommate") via search_contacts
BEFORE filtering transactions by person.
## common_failure_modes
[fail-00007] (helpful=11) Venmo-like app paginates:
len(page)==10 means MORE pages — loop with
page_index until short page, else you miss txns.
[fail-00019] (helpful=6 harmful=1) login() tokens
expire mid-episode; on 401 re-auth, don't retry
the same call blindly.
## verified_code_snippets
[code-00003] (helpful=13) supervisor payment total:
sum(t['amount'] for t in txns if
t['receiver'] == me['phone_number'])
Read the playbook column the way the model does: not as prose to memorize, but as a lookup table keyed by situation. The task mentions a payment app → the pagination bullet fires. A 401 comes back → the re-auth bullet fires. Each bullet is one earned, particular fact — the kind of thing a human engineer scribbles in a runbook after an incident, and precisely the kind of thing brevity bias deletes and collapse vaporizes.
Notice what the playbook claim does not say. It does not say longer is always better — the paper's own discussion section lists tasks where it is not (HotPotQA-style multi-hop retrieval wants a concise how-to-retrieve instruction; Game of 24 needs literally one reusable rule, and more context is dead weight). It says that for the two application classes the paper targets — agents (multi-turn, tool-using, environment-interacting) and knowledge-intensive domain reasoning (finance, medicine, law) — the binding constraint on frozen-model performance is accumulated particulars, and the context is the only place to put them.
There is also a systems-side premise doing quiet load-bearing work: this thesis is only viable because long-context inference has become cheap. A 20K-token playbook re-sent on every call would have been economically absurd in 2023. With prompt caching and KV-cache reuse (Chapter 9 quantifies this), the stable prefix of a long playbook is computed once and reused across calls — the marginal cost of "comprehensive" has collapsed, so the optimal context length has moved. ACE is, in part, a bet that context design should track serving economics, not human reading taste.
Problem one from the last chapter: who writes good playbook bullets from raw experience? The naive answer — "the model does, after each task" — is what Dynamic Cheatsheet already did, and it overloads one generation with three jobs that want different things: solving the task, judging what happened, and editing the store. ACE's first structural move is to split those jobs into three named roles. The design is explicitly modeled on how humans learn: experiment, reflect, consolidate — and explicitly inspired by Dynamic Cheatsheet's agentic design, then taken further.
| Role | Input | Output | Human analogy |
|---|---|---|---|
| Generator | New query + current playbook | A full reasoning trajectory: plan, tool calls, code, execution results — plus tags marking which playbook bullets it actually used, and whether each helped or misled | The engineer doing the work, leaving margin notes on the runbook pages they touched |
| Reflector | The trajectory (and, when available, ground truth or execution outcome) | Concrete extracted lessons: what worked, what failed, why — optionally refined over multiple passes (up to 5) | The post-incident review that turns a messy log into findings |
| Curator | The Reflector's lessons + current playbook state | A delta: a small set of candidate bullets to insert or update — not a rewritten context | The tech-lead merging findings into the runbook as discrete edits |
Two boundaries in this table carry most of the value. First, the Generator/Reflector boundary separates acting from judging: the Reflector reads a finished trajectory cold, so its evaluation is not entangled with the Generator's in-flight self-justification. Second, the Reflector/Curator boundary separates insight extraction from store editing: the Reflector never touches the playbook, and the Curator never re-derives lessons — it only formats and places them. The paper's ablation (Chapter 8) puts a number on the first boundary: adding the dedicated Reflector with iterative refinement lifts AppWorld average from 55.1 to 59.4 when combined with multi-epoch adaptation — and the Reflector alone accounts for the first +1.7 of that.
Step through a single AppWorld-style sample: watch the query hit the Generator, the trajectory flow to the Reflector, insights distill (iterating if needed), and the Curator emit a delta that merges into the playbook — deterministically, without an LLM.
Walk the concrete example the sim animates. The Generator attempts "total the payments my roommate sent me this month." It consults the playbook, uses bullet [fail-00007] (pagination) — tags it helpful — but assumes the roommate's name maps directly to an account handle, and the run fails on an empty transaction list. The Reflector reads the trajectory and the execution result and extracts two lessons: (1) the pagination bullet earned its keep (increment its helpful counter); (2) new insight — relation words like "roommate" must be resolved through the contacts app before filtering transactions. The Curator turns that into a delta: one counter update targeting [fail-00007], one new bullet for the contacts-resolution strategy. The delta merges into the playbook by plain code — dictionary insert, counter increment. No LLM sees the whole playbook at any point in the update path.
A fair challenge: the three roles are typically played by the same underlying LLM (the paper deliberately uses non-thinking DeepSeek-V3.1 for all three, to prove gains come from the structure, not from a stronger helper model). So what did the split actually buy, if the weights are identical?
The answer is about context shape, not capability. Each role sees a purpose-built input: the Generator sees the task and the playbook; the Reflector sees a finished trajectory plus outcome signal, and nothing tempting it to keep solving; the Curator sees lessons plus the store's section headers, and physically cannot emit anything but delta items. Splitting the loop converts "one model juggling three goals in one context" into "one model, three times, each with a clean single-goal context" — the same reason compound AI systems beat monolithic prompts generally. The division of labor is in the information flow, not the parameters. It also, incidentally, means each role could be a different model — Chapter 8 tests exactly that, swapping weaker and stronger Reflectors in and finding ACE keeps working.
Chapter 3 kept saying "delta" and "bullet" as if their structure were obvious. It is not, and it is where ACE stops being a workflow diagram and becomes a data structure. This is the paper's core design principle: represent context as a collection of structured, itemized bullets, not a single monolithic prompt — and update it the way a database is updated, not the way an essay is revised.
A bullet is the atomic unit of the playbook. The concept resembles a memory entry in frameworks like Dynamic Cheatsheet or A-MEM, but adds structure on top. Each bullet has exactly two parts:
one playbook bullet, as data{ "id": "fail-00007", # unique, stable — the address other steps use to point at it "helpful": 11, # times a Generator tagged this bullet as having helped "harmful": 0, # times it misled — evidence for future pruning "content": "Venmo-like app paginates: len(page)==10 means MORE pages — loop with page_index until short page, else you miss transactions." }
The metadata is not bookkeeping decoration — it is the feedback channel. When the Generator solves a task, it reports which bullets it used and whether each helped or misled. Those counters accumulate across episodes, which gives every bullet an evidence trail: helpful=11, harmful=0 is an earned rule; helpful=1, harmful=4 is a candidate for the chopping block. The Reflector reads these signals when proposing corrective updates — the playbook literally learns which of its own lines to trust.
The itemization buys three properties the paper names explicitly, each impossible for a blob-shaped context: localization (an update touches only the bullets it names), fine-grained retrieval (the Generator can attend to the pertinent bullets rather than a wall of prose), and incremental adaptation (merge, prune, and deduplicate item-by-item at inference time).
An adaptation step never produces "a new context." It produces a delta context: a small list of operations distilled by the Reflector and formatted by the Curator. A delta from the Chapter 3 walkthrough looks like this — and merging it is arithmetic, not generation:
the merge, in full — this is the entire "update the context" stepdef merge(playbook, delta): for op in delta: if op["type"] == "add": # new insight → new bullet, fresh id playbook[op["id"]] = { "helpful": 0, "harmful": 0, "content": op["content"] } elif op["type"] == "tag": # existing bullet earned feedback → bump a counter playbook[op["id"]][op["which"]] += 1 elif op["type"] == "update": # targeted content edit of ONE bullet playbook[op["id"]]["content"] = op["content"] return playbook # every bullet not named in the delta is UNTOUCHED delta = [ {"type": "tag", "id": "fail-00007", "which": "helpful"}, {"type": "add", "id": "str-00044", "content": "Resolve relation words (roommate, boss) via contacts search BEFORE filtering transactions by person."}, ]
Work the arithmetic of one step by hand, because the contrast with monolithic rewriting is the entire argument. Say the playbook holds 220 bullets averaging 80 tokens — about 17,600 tokens of accumulated knowledge. The delta above touches 2 bullets: one integer increment, one 30-token insertion. Under ACE, the other 218 bullets are not regenerated, not re-read by any model, not at risk; the merge is O(delta size), a few dictionary operations. Under monolithic rewriting, all 17,600 tokens must be re-emitted by an LLM to apply the same two changes — 17,600 opportunities to drop, mangle, or summarize, purchased at full generation cost. Same semantic update; two failure surfaces that differ by four orders of magnitude.
And because deltas are itemized and non-overlapping in the common case, they compose: multiple deltas from batched rollouts can be merged in parallel, and multi-epoch adaptation (revisiting the same training queries) just keeps merging deltas into an ever-richer store instead of re-deriving it from scratch.
Drag the adaptation-step slider. In incremental mode, deltas append and edit — the store only grows and refines. Switch to monolithic mode and every step regenerates the whole context: watch detail jitter away and, eventually, the collapse from Chapter 1 strike. The bars are individual bullets; height is their accumulated helpful count.
Append-first updates solve collapse, but they open the opposite exposure: a store that only ever grows. Sixty adaptation steps produce sixty deltas; across epochs, the same lesson gets rediscovered in slightly different words; the playbook silts up with near-duplicates. Left alone, that is its own slow failure — not a cliff like collapse, but a rising tide of redundancy that wastes context budget and dilutes attention. ACE's answer is the third mechanism: grow-and-refine, a maintenance discipline that keeps the store compact without ever summarizing it.
| Move | When | What happens |
|---|---|---|
| Grow | Delta contains a bullet with a new id | Append. The store gains one item; nothing else moves. |
| Refine in place | Delta targets an existing id | Update that bullet: increment its helpful/harmful counters, or amend its content. The edit is localized to the named item. |
| De-duplicate | Periodically (proactive) or on overflow (lazy) | Embed each bullet; compare pairwise semantic similarity; prune bullets whose meaning an existing bullet already covers. |
The de-duplication step deserves a careful look because it is doing a job that looks like summarization but is categorically different. Summarization asks an LLM to produce a shorter text that "captures" many items — a lossy generative act, the exact operation that caused collapse. Dedup asks an embedding model a yes/no question per pair — do these two bullets mean the same thing? — and deletes one of two redundant items. No content is ever rewritten; information is removed only when a semantic double already preserves it. The store's size is controlled by subtraction of proven redundancy, never by compression of unique content.
Each dot is a bullet, positioned by meaning (nearby = semantically similar). Drag the threshold: pairs closer than it merge — the survivor keeps both counters' evidence. Too strict a threshold merges distinct lessons; too loose leaves clutter. Watch the token count fall as redundancy — and only redundancy — is removed.
When should dedup run? The paper leaves it as a deployment knob with two settings. Proactive: after every delta merge — the store is always tight, at the cost of an embedding pass per step; choose this when every serving token is precious. Lazy: only when the playbook threatens to exceed the model's context window — near-zero maintenance overhead, tolerating some transient redundancy; choose this when adaptation latency matters more than a few thousand redundant tokens (and Chapter 9 shows redundant cached tokens are cheap anyway). The correctness story is identical either way, which is the point: refinement is a scheduled janitor, not a load-bearing wall. The paper's sensitivity analysis backs this up — on FiNER, accuracy moves only mildly across a wide range of dedup thresholds.
All three chapters of machinery now compose into one picture — worth fixing in memory because every result in Chapters 6–9 is this loop running at scale:
Notice the division one more time: LLMs do all the judgment (what happened, what it means, what to write), code does all the state management (what survives). Every prior method blurred that line somewhere — and every failure mode in Chapter 1 lived exactly on the blur.
Machinery built; time to see whether it pays. The main agent benchmark is AppWorld: a controlled world of simulated everyday apps — email, payments, file system, music, contacts — each exposing real APIs the agent must discover, read, and call from code. Tasks span two difficulty tiers (test-normal and test-challenge), and scoring is two-headed: TGC (Task Goal Completion — did the agent achieve the goal?) and SGC (Scenario Goal Completion — the stricter unit: every task in a related scenario must succeed). Four numbers per method, plus their average. At submission time, the public leaderboard's best system scored only 60.3% average — this benchmark is hard, and it is hard in the realistic way: APIs with quirks, multi-step dependencies, state that persists across calls.
Every method runs on the same substrate: the official ReAct agent loop with DeepSeek-V3.1-671B, so differences isolate the context-adaptation method, nothing else. And crucially, all three ACE roles use that same non-thinking model — no stronger teacher smuggles knowledge in.
Toggle the adaptation setting and the metric. Bars show absolute scores; the dashed line is the never-adapted ReAct baseline. Methods marked ✗ adapted without ground-truth labels, using execution feedback only.
Baseline ReAct averages 42.4. Stuffing the context window with training demonstrations (ICL) buys +3.6 → 46.0. GEPA — the state-of-the-art reflective prompt optimizer, run in its heaviest official configuration — buys +4.0 → 46.4. Then ACE: 59.4, a +17.0 jump, beating ICL by 12.3 points on test-normal TGC and GEPA by 11.9. The pattern inside the four sub-metrics repeats the thesis: on SGC-normal, the strict all-tasks-in-scenario metric, ACE lands at 64.3 versus GEPA's 44.6 — a +21.4 over baseline where GEPA managed +1.7. Long-horizon, multi-task consistency is exactly where an accumulated playbook of app-specific tactics beats one polished instruction, because a scenario's third task depends on quirks discovered in its first.
Now delete the labels. ACE adapting from execution feedback alone — code ran or crashed, task checker passed or failed, no ground truth — still averages 57.2 (+14.8). It gives back only 2.2 points relative to labeled adaptation. Hold that against GEPA's +4.0 with labels: unsupervised ACE beats supervised state-of-the-art prompt optimization by more than 10 points on this benchmark.
Online, the natural comparison is Dynamic Cheatsheet (cumulative mode), the method whose collapse opened this lesson. DC-CU, no labels: 51.9 (+9.5) — genuinely useful, when it doesn't collapse. ACE, same no-label deal, with an offline-warmup context: 59.5 (+17.1), a +7.6 margin over DC. Look at where the margin concentrates in the explorer: test-challenge TGC 66.0 vs 52.3, SGC 48.9 vs 30.8. The harder the split, the wider the gap — challenge tasks are where accumulated, non-collapsed detail compounds hardest.
The no-label result is the one with strategic weight, so slow down on the mechanism. In AppWorld, the environment itself is honest: API calls throw or return; task checkers verify final state; code either produces a value or a traceback. The Reflector reading a failed trajectory does not need an answer key to conclude "the pagination assumption was wrong — the transaction list was silently truncated." Success and failure leave physical evidence in the trajectory. That evidence is precisely what gets distilled into bullets. This is why the paper frames ACE as an ingredient for self-improving systems: the loop closes with signals the deployment generates anyway, no annotation pipeline required. Chapter 7 shows the sharp edge of the same sword — what happens in domains where the environment gives no such honest signal.
Agents were the home game: multi-step tasks, rich execution signals, reusable tactics. The second test is knowledge-intensive domain reasoning, where what accumulates is not tool tricks but concepts and rules. The paper's case study is finance, on two benchmarks built around XBRL — the standardized markup language regulators require for financial filings. FiNER: label tokens in filing text with one of 139 fine-grained entity types (is this dollar figure a DebtInstrumentFaceAmount or a LineOfCreditFacilityMaximumBorrowingCapacity?). Formula: extract values and compute financial quantities — numerical reasoning against filings. Both reward exactly what a playbook stores: definitional boundaries, disambiguation rules, computation recipes.
Same explorer, finance edition. Toggle offline/online. The ✗ rows adapted without labels — watch what happens to them on FiNER, because it is the most honest chart in the paper.
Offline with ground truth, base DeepSeek-V3.1 averages 69.1 across the two benchmarks. ICL: 69.6. MIPROv2, the Bayesian-optimization prompt tuner, in heavy mode: 70.9. GEPA: 72.5. ACE: 81.9 — +12.8 over base and +9.4 over the best prior method. The Formula number is the standout: 85.5 versus base 67.5, an 18-point jump, because computation recipes ("net margin requires excluding discontinued operations"; "this ratio's denominator is average, not ending, assets") are exactly the kind of reusable, particular knowledge that survives in a playbook and dies in a summary. Online with labels, ACE reaches 76.6 versus DC's 71.8 — the margin persists.
Now the chart this chapter exists for. Switch the explorer to online, no labels. DC drops to 65.4 average — 3.7 points below the never-adapted base. And ACE on FiNER lands at 67.3, which is 3.4 points below base too (its average survives at 72.9 only because Formula still gains — +11.0 — where numerical self-consistency provides some genuine signal). Adaptation made things worse than doing nothing, for both methods.
Mechanism, not mystery: in online FiNER without labels, the only "signal" available is the model's own guess about its own answers. There is no compiler, no task checker, no environment to object. A confidently wrong belief about an entity-type boundary gets reflected on, distilled into a bullet, merged, and then retrieved as authority on the next similar token — a self-reinforcing error loop. The paper names it plainly: the constructed context gets "polluted by spurious or misleading signals." Garbage in, curated garbage out.
The domain story is not finance-specific. On DDXPlus, a medical differential-diagnosis benchmark (offline, 1000 training samples), ACE lifts accuracy from 75.2 to 90.2 (+15.0) where GEPA manages 76.4 (+1.2) — multi-step diagnostic disambiguation is playbook-shaped knowledge. Text-to-SQL (BIRD-SQL) shows consistent gains as well. And across model families — GPT-OSS-120B, GPT-5.1, Llama-3.3-70B swapped in for all three roles with zero prompt changes — the gains persist with the expected gradient: stronger backbones reflect better and gain more; weaker ones (Llama-3.3-70B) produce noisier reflections and gain less, but still gain. One notable inversion: on GPT-5.1, label-free offline ACE (61.3) actually edges out labeled ACE (60.2) on AppWorld — for a strong-enough reflector, raw execution evidence can be a cleaner signal than a terse gold label.
A system with three mechanisms owes you an accounting: which piece earns which points? The paper ablates each on AppWorld and stress-tests the framework's weakest joint — the Reflector — on FiNER. This chapter works the arithmetic, because the relative sizes are the design lesson.
| Configuration (offline, AppWorld avg) | Score | Increment |
|---|---|---|
| ReAct baseline (no adaptation) | 42.4 | — |
| ACE without Reflector or multi-epoch (Dynamic-Cheatsheet-style curation + deltas) | 55.1 | +12.7 — itemized incremental structure alone |
| + dedicated Reflector with iterative refinement | 56.8 | +1.7 |
| + multi-epoch adaptation (revisit training queries) | 59.4 | +2.6 |
| Online: ACE alone → + offline warmup of the initial context | 56.1 → 59.5 | +3.4 from warm-starting |
Now place the Chapter 4 ablation beside it. Forcing monolithic rewrites while keeping everything else — roles, reflection, epochs — drops the test-normal average from 70.3 to 56.9: the incremental-update mechanism by itself carries 13.4 of the 17.0 points of total gain (78.8%; on TGC alone, 8.9 of 12.5 → 71.2%). The ledger's message is unambiguous: the data structure is the headline; the workflow refinements are compounding interest. A team porting one idea from this paper should port the delta store, not the three-prompt choreography.
Every mechanism above still depends on one LLM judgment call: the Reflector's lessons. The paper attacks that dependency from two directions on FiNER (offline, base 70.7, clean ACE 78.3).
Direction one — weaken it. Swap the Reflector while Generator and Curator stay fixed: GPT-OSS-120B (far weaker) → 76.6; DeepSeek-V3.1 → 78.3; GPT-5.1 (far stronger) → 78.5. The spread from a much weaker to a much stronger reflector is 1.9 points, and even the weak one clears base by +5.9. ACE degrades gracefully in reflector quality — it does not require a frontier model in the judgment seat.
Direction two — poison it. Harsher: a saboteur reflector, explicitly instructed to inject harmful reflections, fires once every X adaptation steps. Drag the slider:
Adversarial reflections injected every X steps (smaller X = more frequent poison). The curve is final FiNER accuracy; dashed lines mark the base model (70.7) and clean ACE (78.3). Find the crossover: how much poison does it take to make adaptation net-negative?
The measured points: poison every 100 steps → 78.2. Every 50 → 78.2. Every 25 → 77.8. Every 10 → 77.0. Every 5 — a fifth of all reflections adversarial — still 76.1, comfortably above base. Only at X=1, every single reflection hostile, does accuracy finally sink to 66.7, four points below base. Do the relative arithmetic on X=5: retained gain is (76.1−70.7)/(78.3−70.7) = 5.4/7.6 = 71% of the clean improvement surviving 20% adversarial corruption. Why so robust? The store's structure absorbs it: a poisoned bullet is one item among hundreds, its harmful counter accumulates evidence against it, dedup and counter-informed curation give it no amplification path — whereas in a monolithic rewrite, one poisoned generation owns the whole document. The failure containment you bought for collapse pays again for adversarial noise.
Last dial: the Reflector's iterative refinement rounds (test-normal, offline). One round: 61.3 average — under-extraction, insight left on the table. Three: 65.8. Five: 67.6, the paper's default. Ten: 65.2 — past the sweet spot, extra rounds start manufacturing noise instead of insight ("overthinking," in the paper's word). The dedup threshold shows the same mild-hill shape on FiNER. The tuning story is boring in the best way: pick 5, move on — no knife-edge hyperparameters anywhere in the system.
Accuracy wins mean little if the method is too slow or too expensive to run. This chapter is the systems half of the paper — and it is where being co-authored by ML-systems researchers shows. Two cost stories: what adaptation costs to run, and what a long playbook costs to serve. Both end in numbers that flip the intuitive verdict.
| Setting | Method | Latency | Volume metric |
|---|---|---|---|
| Offline, AppWorld | GEPA | 53,898 s (~15.0 h) | 1,434 rollouts |
| ACE | 9,517 s (~2.6 h) — −82.3% | 357 rollouts — −75.1% | |
| Online, FiNER | DC (CU) | 65,104 s (~18.1 h) | $17.7 token cost |
| ACE | 5,503 s (~1.5 h) — −91.5% | $2.9 — −83.6% |
Trace each saving to its mechanism — nothing here is a tuning accident. Against GEPA: no genetic search means no population of prompt candidates each demanding validation rollouts (that alone is most of the 4× rollout reduction), and delta generation means the adapter LLM emits ~30-token edits instead of regenerating full prompts — the fine-grained accounting shows 80.8% fewer input and 83.6% fewer output tokens during offline adaptation. Against DC: the deterministic merge replaces an LLM rewrite of an ever-growing memory at every test sample — DC's per-step cost grows with its own accumulated success, ACE's stays proportional to the delta. An 18-hour adaptation run collapsing to 90 minutes is not a nicety; it is the difference between "nightly job" and "research artifact."
The obvious objection to everything since Chapter 2: ACE's contexts are 10–100× longer than GEPA's. Doesn't every single inference now pay for ~20K extra input tokens? The paper's answer is the most transferable systems insight in it: with modern serving infrastructure, stable long contexts are nearly free, because they are cached.
The mechanism, from first principles: before generating, a transformer runs prefill — computing attention keys and values for every input token — and that KV cache is the expensive part of long inputs. But ACE's playbook is a stable prefix: it changes only between adaptation steps, by small deltas, while thousands of task queries read it unchanged. Serving stacks (vLLM-style prefix caching, provider-side prompt caching, and the CacheGen/CacheBlend/InfiniGen line of systems work the paper cites) recognize a previously-seen prefix and skip its prefill entirely, billing cached tokens at a deep discount. A playbook is close to the ideal caching workload — long, hot, and append-mostly. Even the deltas cooperate: appends preserve the shared prefix; only in-place edits invalidate anything, and only from the edit point on.
Measured, not hypothesized: in the paper's prompt-caching study on the OpenAI API (GPT-5.1), 91.8% of ACE's input tokens were served from cache during evaluation, cutting billed input cost by 82.6% versus raw token counting.
Verify that 82.6% yourself — it falls out of one line of arithmetic. Cached input tokens bill at roughly one-tenth of the fresh-token price on this API. With hit rate h = 0.918 and cached-price fraction d = 0.10, the effective cost multiplier is (1−h)·1 + h·d = 0.082 + 0.0918 = 0.1738 — i.e., you pay 17.4% of the naive bill, a 82.6% reduction. Exactly the paper's number. Now play with the calculator:
Left bars: naive billing intuition (every token full price). Right bars: with prefix caching. Drag both sliders — note how weakly billed cost depends on context length once the hit rate is high, and find the break-even against a 2K-token optimized prompt served uncached.
Zoom out. ACE sits at the junction of two research lineages, and its significance reads differently along each.
Along the natural-language-feedback line, each ancestor contributed one move: Reflexion (2023) showed an agent improving by verbally reflecting on failures; TextGrad treated LLM feedback as a pseudo-gradient to "backpropagate" through prompts; GEPA wrapped reflective mutation in genetic-Pareto search and beat RL methods like GRPO with 35× fewer rollouts; Dynamic Cheatsheet moved adaptation to test time with an accumulating memory; A-MEM structured agentic memory into linked entries. ACE inherits the whole toolkit and fixes the storage layer they all left unguarded: reflection generates the knowledge, but itemized bullets + deterministic merge + embedding dedup decide what survives. In database terms, its ancestors invented the queries; ACE added the transaction log.
Along the self-improving-systems line, ACE is an existence proof with an asterisk. Proof: a frozen open-source model, adapting from its own execution feedback, matching a GPT-4.1 production agent (Chapter 6) — continual learning without touching a weight, with human-readable state you can audit, share across models, and surgically unlearn from (the GDPR right-to-erasure angle the discussion raises: delete the bullet, done — try that with a gradient). Asterisk: the whole loop is powered by feedback quality (Chapter 7's pollution result), and the paper is candid that some tasks don't want playbooks at all — HotPotQA-style retrieval wants one concise instruction; Game of 24 needs a single reusable rule. ACE's honest scope: domains where detailed strategies, tool quirks, and failure modes accumulate faster than model weights can be updated — and where the environment can tell you the truth.
On this site, the story continues in two directions. The survey Gleam Harness Optimization places ACE on the full optimization ladder (context → workflow → optimizer code, through ADAS and AFlow). And the sibling Veanor Meta Context Engineering covers the paper that answers ACE directly: MCE treats ACE's entire generation-reflection-curation workflow as one hand-designed point in a searchable space of context-engineering skills — and lets a meta-agent evolve the skill itself, beating ACE's fixed harness on five domains. Read them in that order: mechanism (here), then the meta-level move that generalizes it. For the harness-design worldview underneath both, see Harness Engineering; for the memory-substrates side of "what should an agent store," see Harness the Memory.
| Mechanism | What it is | What it prevents | The number that proves it |
|---|---|---|---|
| Playbook thesis | Contexts as comprehensive itemized strategy stores, not summaries | Brevity bias deleting domain detail | +21.4 SGC-normal over baseline where GEPA gets +1.7 |
| Generator / Reflector / Curator | Acting, judging, and store-editing split into three role-specific calls (same LLM) | One overloaded generation doing three jobs badly | Reflector +1.7, multi-epoch +2.6 on AppWorld avg |
| Bullets with counters | id + helpful/harmful counts + one unit of content | Unaccountable knowledge — no evidence trail per item | Poison every 5 steps → still 76.1 vs base 70.7 |
| Incremental delta merge | LLM proposes add/tag/update ops; deterministic code applies them | Context collapse (18,282 → 122 tokens in one rewrite) | ~79% of ACE's total gain (70.3 vs 56.9 ablation) |
| Grow-and-refine | Append new ids, edit in place, embedding-dedup redundancy (proactive or lazy) | Unbounded growth — without lossy summarization | Accuracy stable across dedup-threshold sweep |
| Execution-feedback adaptation | Reflector learns from crashes, checkers, run results — no labels | Annotation dependence blocking self-improvement | 57.2–59.5 label-free vs 59.4 labeled (AppWorld) |
| KV-cache co-design | Long stable prefix → prompt caching absorbs serving cost | "Long context is expensive" objection | 91.8% cache hit, −82.6% billed input cost |