DAEDALUS

00tl;dr

Along with the paper and the code, we also release every trajectory of every agent in every run of the paper at 🤗 illuin/daedalus-traces. Use them as you wish!

01Why agents need memory

LLM agents now carry out real tasks in complex environments, with little human guidance. Doing so reliably takes practical knowledge that carries over from task to task: how the tools behave, how the environment is organised. Without a memory of it, an agent rediscovers its environment on every task, repeats the same mistakes, and needs longer, costlier runs.

Memory methods fix this by learning from past attempts, without touching the model's weights. But they learn from a curated set of training tasks, usually with a verifier that scores each attempt. Building that supervision takes prior knowledge of the environment and a lot of human work, so most environments don't have it, and ever more of them are generated automatically. The alternative, learning from test queries as they arrive, leaves the first tasks with no memory at all.

DAEDALUS removes both requirements. The agent practises before deployment, on tasks it generates itself, and keeps only the lessons that demonstrably help it.

02How DAEDALUS builds its memory

Before deployment, DAEDALUS spends a fixed budget of practice sessions in the environment. In each one, an Explorer proposes a task with explicit success conditions, and solves it itself to prove it feasible. A Solver, the same model as the agent, then attempts it from a fresh state while an LLM Judge checks each trajectory against the conditions. After every failure, an Extractor writes a heuristic, or revises the last one, and the Solver retries with it in context.

A heuristic is kept only once the Solver succeeds with it three times in a row. A task the Solver never fails is too easy; one it keeps failing is too hard: either way, the Explorer refines it, up to five times, which keeps tasks at the edge of what the Solver can do. A Surveyor spreads the tasks over the environment beforehand, lessons from each refinement become guidelines for the Explorer, and after the last session a Consolidator merges the accepted heuristics into the memory the agent receives at test time.

Apart from the Solver, all these agents are auxiliary agents: they build the memory but are never deployed, so they can run a larger model than the agent.

Here is one real session of our AppWorld run, step by step.

03The memory at work

After the last session, the Consolidator merges the accepted heuristics into one memory, and the agent receives it whole at the start of every test task. Here is what that changes on one AppWorld test task, which the agent without memory never solves.

04Results

One task shows the mechanism; the benchmarks show how far it carries. We compare DAEDALUS with a no-memory baseline and six memory methods on three benchmarks: app automation in code (AppWorld), customer service conversations (τ²-bench, retail) and SaaS business workflows (AutomationBench, Operations). Five of the methods learn from the benchmark's training tasks, which DAEDALUS never sees; only PREPING, like DAEDALUS, generates its own. The agent is GPT-5.4-mini, with GPT-5.4 for the auxiliary agents (GPT-5.6 Luna and Terra on AutomationBench).

• Best without training tasks. +15.9, +10.0 and +4.3 MSR over no memory, pass^5 up to 2.2×, and ahead of PREPING everywhere.
• Competitive with training tasks. Within error of the best such method in four of the six MSR and pass^5 columns.
• No extra inference cost on AppWorld and τ²-bench: the agent needs fewer turns.
• Self-generated tasks recover most of the benefit of curated ones. Run on the training tasks, the same Solver loop (DAEDALUS-curated) ranks first; DAEDALUS is only 0.6, 2.5 and 4.0 MSR points behind it.

05Across model families

So far, the memory has been generated by the agent's own model family. Is it tied to the models that generated it? We also run DAEDALUS with Qwen and DeepSeek model pairs, and give every memory to every base agent.

All nine gains are positive. GPT-5.4-mini gains as much from the Qwen memory as from its own (+16.8 vs. +15.9); DeepSeek-V4-Flash gains the least, from an 80.6% baseline that leaves little room. With the GPT-5.4 memory, the seven base agents of fig. 1 all succeed more often, in fewer turns.

06What makes generation work

Which parts of the pipeline make the memory work? A cumulative ablation on AppWorld answers it: we rebuild the pipeline one component at a time, each row adding its component to the previous one.

Heuristics must come from the Solver's own attempts: exploring alone makes the agent worse (A, B), Solver traces bring the first jump (C) and validating them the second (D). The guidelines and the survey then make generation cheaper rather than better. With fewer refinements, the Solver and the Judge cost 60% less, and the whole run costs half as much as (D).

07Using the memory

Generating good heuristics is half of the story; the other half is how the agent receives them. Heuristics accepted in different sessions overlap. Consolidated into one memory and injected whole at task start, they are both the best and the cheapest option, 10.7 MSR points above the raw heuristics. Retrieving five heuristics per turn helps less, and BM25, embeddings and a random pick are all within error of each other. Retrieval ranks the heuristics by their resemblance to the agent's current turn, but the heuristic the agent needs often reads nothing like that turn: it warns about a mistake still to come, not about what the agent is doing now.

Retrieving more per turn helps, but never reaches the whole memory at start.

08Ranking models with generated tasks

The generated tasks have a use of their own, beyond memory. Environments without training tasks usually lack a test set as well, which makes it hard to compare agents on them. The tasks DAEDALUS generates could fill that role.

To test it, we evaluate nine models, without memory, on two task sets: the 81 tasks accepted during a 90-session generation run on AppWorld, and AppWorld's official test_normal split. If the generated tasks are a good proxy, the models should come out in the same order on both.

model                         MSR aw     MSR gen    pass³ aw   pass³ gen
────────────────────────────────────────────────────────────────────────
nemotron-3.5-lightning           6.5        13.6         0.2         1.2
gpt-oss-120b                    19.2        39.9         3.2        12.3
minimax-m2.7                    25.1        43.6        10.9        21.0
gpt-5.4-mini                    44.3        66.7        22.2        40.7
qwen3.6-35b-a3b                 44.8        67.9        27.7        46.9
gemma-4-31b-it                  51.0        61.3        32.4        33.3
mimo-v2.5                       52.6        76.0        33.2        51.2
deepseek-v4-flash               60.8        81.5        37.4        61.7
gpt-5.6-luna                    66.2        90.1        49.7        82.7

aw = AppWorld test_normal · gen = DAEDALUS-generated tasks · values in %

The rankings agree. Kendall's τ is 0.89 for mean success rate and 0.89 for pass³ (both p < .001), and 34 of the 36 pairs of models are ordered the same way on both sets.

Absolute scores differ: every model does better on the generated tasks, which were calibrated to GPT-5.4-mini, the solver that generated them. But the order of models is preserved, so tasks generated by DAEDALUS can serve as a proxy for ranking models when no curated test set exists.

09Key takeaways

@Citation

If DAEDALUS, its code or its artefacts are useful to you, please cite:

@misc{edy2026daedalus,
  title         = {{DAEDALUS}: Bootstrapping Agent Memory from Self-Generated Tasks},
  author        = {Edy, Antoine and Conti, Max and Xing, Victor and Allard, Marc-Antoine and Benhamdane, Nawfal and Viaud, Gautier},
  year          = {2026},
  eprint        = {2610.08048},
  archivePrefix = {arXiv},
  url           = {https://arxiv.org/abs/2610.08048}
}

AAppendix