Thinking of ACE? We Can Do It with Fewer Tokens

Source: https://huggingface.co/blog/ibm-research/altk-evolve-sldd Back to Articles

• What we agree on
• Where we differ
• Why it matters
• Same lessons, different delivery
• Linked artifacts / references
• Method notes- Reference tables

ALTK-Evolve and ACE both let an agent learn from its own trajectories. The difference is what they do with what they learn — and that decides the token bill.

Give an LLM agent a realistic multi-step task — split a bill, find a song, reconcile an order across nine simulated apps — and when it fails, it usually isn’t for lack of knowledge. It mis-paginates an API, resolves the wrong person, or returns a value when none was asked for. The model knows the APIs; what it hasn’t internalized ishow to use them reliably. That’s learnable from the agent’s own history.

Two recent systems do exactly this, on the same kind of agent:ACE(Agentic Context Engineering) and ourALTK-Evolve(introduced here). Both are a form ofagentic memory— turning an agent’s past trajectories into reusablelessonsand feeding them back at inference time, no weight updates, no human labels. They even agree on the hard part. Where they part ways isdelivery.

A note on words, because the two systems name things differently: we’ll call the raw thing an agent learns alesson. ACE organizes its lessons into one comprehensive, evolvingplaybook; we consolidate ours into individually retrievableguidelines. Same lessons, two containers.

https://huggingface.co/blog/ibm-research/altk-evolve-sldd#what-we-agree-onWhat we agree on

Both systems refuse to compress.

ACE names the failure modes precisely:brevity bias— optimization collapsing toward short, generic instructions — andcontext collapse— a model asked to rewrite its whole context each step summarizing the detail away. Its answer is to keep a rich, itemized playbook, with a helpful/harmful counter on every bullet, and let the model distill relevance at read time.

We reach the same conclusion from the other direction. Every distinct guideline keeps asupport count— how many independent episodes produced it — and we never summarize the store down to a handful of rules. A lesson five different tasks discovered is a different object from one that appeared once, and both are worth keeping.

So on the core question —should you compress an agent’s hard-won lessons into a tidy summary?— ACE and ALTK-Evolve give the same answer:**no. Count them, don’t collapse them.**ACE’s per-bullet counters and our support counts are two spellings of the same idea.

https://huggingface.co/blog/ibm-research/altk-evolve-sldd#where-we-differWhere we differ

Two places: how the memory isbuilt, and how it’sdelivered— and it’s the delivery difference that shows up in the token bill.

Consolidation (how the store is built).ACE grows one playbook through aGenerator → Reflector → Curatorloop, applying incremental delta updates and de-duplicating by embedding. We cluster near-duplicate lessons and mergewithina cluster,support-conserving— when several lessons merge, the survivor inherits their combined count, so the store shrinks without losing the record of how much experience backs each guideline. We also extracttypedguidelines — strategy, recovery, and optimization — with causal attribution and provenance back to the source trajectory, and at subtask granularity, so a lesson learned on one app can transfer to another.

Delivery (what reaches the model at inference).This is the one that drives the numbers. ACE injects thecomprehensive playbookon every step, the same way regardless of model or task. We treat delivery as a dial, not a constant: a small fixed core of high-support guidelines, extended per task with a handful selected for the task at hand (cosine or LLM-guided, priority-weighted) — or, when a model has the headroom to use it, the full consolidated set. The same lessons areavailableto both agents; the difference is that ACE always sends all of them, and we send however many a given model can actually use.

https://huggingface.co/blog/ibm-research/altk-evolve-sldd#why-it-mattersWhy it matters

On AppWorld, with thesamebase ReAct agent, running both systems in-house:

ModelTGC / SGCTokens/taskDeepSeek-V3.2ACE80.4 / 73.2634KALTK-Evolve89.3 / 80.4263K****gpt-oss-120bACE54.8 / 35.7777KALTK-Evolve56.0 / 37.5116K On the strong model we’re better on both metrics at**~40% of ACE’s inference cost**. On the weak model we edge ACE 56.0 to 54.8 — close enough that we call it atie on accuracy(a repeat run of ours landed at 54.8, matching ACE almost exactly, which is within this benchmark’s run-to-run noise) — atabout one-sevenththe cost.

A fair word on cost: ACE’s own efficiency story is aboutbuildingits context cheaply. Ours is on a different axis —servingit. Retrieving a few guidelines per task instead of injecting the whole playbook on every step is where the tokens go, and it’s the direct consequence of the delivery difference above.

Where does the accuracy come from? The by-difficulty breakdown tells two different stories:

Figure 1. Post-memory Task Goal Completion by difficulty, ours vs. ACE. On DeepSeek-V3.2 (right) we win Easy, Hard, and Overall; ACE only edges Medium. On gpt-oss-120b (left) ACE leads easy and medium, but per-task selection wins the hard tasks — and the aggregate. Each system improves from its own no-memory baseline (see the by-difficulty reference tables under Method notes below).

The two models tell different stories. On gpt-oss-120b, ACE’s full playbook has the edge on Easy and Medium — there’s enough of the task solved by generic instruction-following that a comprehensive prompt helps more than it distracts. But on Hard tasks, where the model has to pick therightlesson rather than wade through all of them, curated retrieval pulls ahead — and that’s the tier that decides the aggregate. On DeepSeek-V3.2 the story flips: the stronger model absorbs ACE’s full playbook well enough to edge us on Medium, but we lead Easy, Hard, and Overall — with more capacity to spare, more lessons (delivered our way) keep helping instead of crowding each other out.

We give each model itsbest configuration— the full consolidated set for the strong model, selective retrieval for the weaker one, because a large context overwhelms a weaker model rather than helping it. (Exactlyhow muchto inject, and how it scales across the capability spectrum, is the subject of a next post.)

https://huggingface.co/blog/ibm-research/altk-evolve-sldd#same-lessons-different-deliverySame lessons, different delivery

Both systems refuse to compress an agent’s hard-won experience into a tidy summary — that part, we agree on. The difference is whether delivery is fixed or calibrated: ACE sends the whole playbook every step no matter what; we send however much of the guideline set a given model can actually use. That calibration is what bought the numbers above — same-or-better accuracy at a fraction of ACE’s inference cost — and on the weaker model, it was the difference between guidance that helped and guidance that got in the way.

Try theALTK-Evolvelibrary— which includes the extraction, consolidation, and retrieval pipeline used here —**or read thefull technical report**for the complete method and ablations.

https://huggingface.co/blog/ibm-research/altk-evolve-sldd#linked-artifacts–referencesLinked artifacts / references

• **Earlier post:**ALTK-Evolve introduction —link
• ACE(Agentic Context Engineering) —link
• AppWorldbenchmark —link
• ALTK-Evolve—link
• Full technical report—link

https://huggingface.co/blog/ibm-research/altk-evolve-sldd#method-notesMethod notes

AppWorldtest\_normal, 168 tasks. A ReAct code agent (each step writes Python; the environment returns the output).TGC= Task Goal Completion;SGC= Scenario Goal Completion, which requireseveryvariant of a scenario to pass. Memory is mined fromtrain/dev only; results are single runs (pass@1), as is standard on this benchmark.

The ACE numbers are our own runs of the ACE agent, evaluated in-house on the same AppWorld splits and the same base models as ALTK-Evolve (DeepSeek-V3.2 and gpt-oss-120b). The ACE paper reports on a different base model (DeepSeek-V3.1), so running it ourselves keeps the comparison controlled for model and harness. Both systems are thesameReAct agent and differ only in the prompt template — which is why the two no-memory baselines differ (72.0 vs 79.8 TGC); we don’t rest the comparison on that baseline gap, only on the claims a prompt tweak can’t touch: same-or-better accuracy at a fraction of the tokens.

https://huggingface.co/blog/ibm-research/altk-evolve-sldd#reference-tablesReference tables

DeepSeek-V3.2 —test\_normal(168 tasks):

SystemGuidelinesTGCSGCTokens/taskReAct, no memory079.864.3148KReAct + ACE10680.473.2634KReAct + ALTK-Evolve19189.380.4263K gpt-oss-120b —test\_normal:

SystemGuidelinesTGCSGCTokens/taskReAct, no memory039.921.4110KReAct + ACEfull54.835.7777KReAct + ALTK-Evolve (selected)~2956.037.5116K gpt-oss-120b — by difficulty (TGC):

DifficultyBaselineACEALTK-EvolveEasy66.784.282.5Medium35.460.456.2Hard19.123.831.8Aggregate39.954.856.0 **DeepSeek-V3.2 — by difficulty (baseline → +memory):**the two systems start from different no-memory baselines (79.8 vs 72.0 TGC overall) because of the prompt-template difference above.

TierALTK TGCALTK SGCACE TGCACE SGCOverall79.8 → 89.364.3 → 80.472.0 → 80.457.1 → 73.2Easy93.0 → 94.784.2 → 84.278.9 → 84.263.2 → 78.9Medium81.2 → 97.962.5 → 93.885.4 → 100.075.0 → 100.0Hard66.7 → 77.847.6 → 66.755.6 → 61.938.1 → 47.6