DAEDALUS: agent memory built from self-invented tasks, where every rule is verified by re-running

STEP 0: The Surveyor studies the environment once → a map of areas and a plan: how many tasks per area
LOOP (n sessions):
  STEP 1: The Explorer invents a realistic task + success conditions and solves it itself (proves it’s doable)
  STEP 2: The Solver tries from a clean environment state; the Judge checks the outcome against the success conditions
  STEP 3: Failure → the Extractor writes (or revises) a rule from the task and the failure trace → the Solver tries again
  STEP 4: Outcome:
         • 3 successes in a row, with at least 1 failure before them → rule ACCEPTED
         • no failures at all → “too easy” → the Explorer makes it harder (up to 5 times)
         • 8 failures → “too hard” → the Explorer simplifies it
STEP 5: The Consolidator merges the accepted rules into a list in a single call
STEP 6: The list is frozen and pasted whole at the start of the working agent’s context

Each step is a separate agent call. This is an orchestrated loop, not a single prompt.

Task: You’ve set up an agent in Claude Code that works with the Shopify Admin API: it reconciles inventory, creates orders, and exports reports. Every new session it steps on the same rakes all over again: wrong field formats, forgotten pagination, redundant requests. You have no ready-made test tasks and no grading script. You want the agent to start work already armed with a set of verified rules.

Below is a manual version of the method for a test account. It’s a simplification, not the original.

Prompt (to the orchestrator):

You are the orchestrator. You are working on a TEST Shopify store; do not touch production data.
Goal: build a list of verified rules for an agent that works with this API.

Run 10 sessions. In each one:
1. Explorer role: invent a realistic task for an online store manager
   (e.g., “find products with stock below 5 and create a purchase order for the supplier”).
   Do it yourself to make sure it’s doable. Write down the success conditions as a list.
2. Solver role (a separate subagent with a clean context): carry out the task.
3. Judge role: check the result against the success conditions. Answer: success / failure + reason.
4. On failure — Extractor role (sees only the task text and the attempt trace,
   does NOT see the list of success conditions): write one general rule
   that would help with similar tasks. Don’t write a rule tailored to this specific task.
   The Solver tries again with that rule in context. After another failure,
   the Extractor revises the rule.
5. A rule counts as accepted only if the Solver succeeded with it 3 times in a row,
   having failed at least once before.
   The Solver never failed → the task is too easy, make it harder (up to 5 times).
   The Solver failed 8 times → the task is too hard, simplify it.

At the end: the Consolidator role merges the accepted rules into one list,
removes duplicates, keeps the specifics. Output the list in a format for an AGENTS.md file.

Result: For each session the orchestrator shows the task, the Solver’s attempts, the Judge’s verdicts, and how the rules changed after failures. The output is a short list of accepted rules, ready to paste at the top of the agent’s instructions. Some sessions will end with no rule: the task turned out too easy or too hard.

The weakness: in a new environment, a model doesn’t know its “local laws”: how a particular tool behaves, what the conventions are. It has to rediscover this in every task. The most reasonable-looking rules, made up “off the top of its head” or from a look around the environment, often turn out useless or harmful.

The strength: a model is good at dissecting a specific failure. It sees exactly where it went wrong and puts the lesson into words. It’s also decent at judging whether a condition was met when the conditions are written as text: in the paper, the Judge matched the official checks at the level of “substantial agreement.”

How the method exploits this: a lesson from a failure is just a hypothesis. It gets tested on the Solver itself: did the rule turn a failed task into a stable success? Three successes in a row instead of one lowers the odds of accepting an empty rule thanks to dumb luck. Difficulty calibration keeps tasks “at the edge” of the Solver’s abilities. Easy tasks teach nothing, and overly hard ones can’t be solved even with a rule.

Control knobs: - Successes in a row (3 in the paper). More means stricter selection but higher cost. Fewer means faster but noisier. - Failure limit (8) and number of simplifications/hardenings (5). Lower them for a cheap trial run. - What the Extractor sees. In the original it doesn’t know which success conditions failed. That forces it to write general rules rather than patch a specific task. - Number of sessions. The benefit shows up even on a small budget. - Delivery method. The paper reports that at this volume it’s better to merge the rules into one list and paste it whole at the start than to retrieve them as you go.

The paper has no ready-made text prompt. Below is the original session structure with the roles and parameters from the paper, written up as an instruction to the orchestrator. The wording of the lines is reconstructed from the role descriptions.

<Role>
You are the orchestrator for training an agent’s memory. Environment: {environment}. Test data only; do not touch production.
The goal is a list of verified rules (heuristics) for the agent {working_agent_description}.
</Role>

<Parameters>
N_sessions = {number_of_sessions}
N_s = 3      # successes in a row to accept a rule
N_f = 8      # failures after which a task counts as too hard
N_r = 5      # maximum number of task difficulty revisions
</Parameters>

<Survey>
Study the environment once. Make a list of areas (e.g., {areas})
and distribute the sessions across them so the tasks cover the environment evenly.
</Survey>

<Session>
Explorer = Agent("explorer")
Solver = Agent("solver")      # clean context before every attempt
Judge = Agent("judge")
Extractor = Agent("extractor") # does NOT see the success conditions, only the task and the attempt trace

task = Explorer.propose_task(area=from the plan)        # instruction + success conditions
Explorer.solve(task)                                # prove the task is doable
heuristic = None; streak = 0; fails = 0; ever_failed = False

While streak < N_s and fails < N_f:
    result = Solver.attempt(task, heuristic)        # from a clean environment state
    verdict = Judge.check(result, task.success_conditions)
    If verdict == success:
        streak += 1
    Else:
        fails += 1; streak = 0; ever_failed = True
        heuristic = Extractor.write_or_revise(task.instruction, result.trace, heuristic)
        # a general rule, not a patch for one task

If streak == N_s and ever_failed:   bank.add(heuristic)             # ACCEPTED
If not ever_failed:                  task = Explorer.make_harder(task)   # too easy, up to N_r times
If fails == N_f:                     task = Explorer.make_easier(task)   # too hard
</Session>

<Consolidation>
Consolidator.merge(bank): remove duplicates and overlaps, keep the concrete actions.
Output a single list to paste at the start of the agent’s context.
</Consolidation>

What to fill in: {environment} — your tool or API on test data, {working_agent_description} — what the agent does on the job, {number_of_sessions} — 10–20 for a trial, {areas} — the sections of your environment.

🚀 Quick start — paste into a chat or into Claude Code:

Here is a template of the DAEDALUS method. Adapt it to my task: [your environment and what the agent does].
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what environment the agent works in, whether you have test data and can reset it to its initial state, how to tell a task is done, and how much budget you’re willing to spend. All of that matters because the method rests on clean repeat attempts and verifiable success conditions. It will take the pattern from the template and assemble a prompt for your environment.

⚠️ You need an environment you can reset: every attempt starts from a clean state. If you can’t safely repeat actions on a test account, the method won’t work. Don’t touch production data.

⚠️ You need verifiable success conditions: the method works where the outcome can be checked against a clear list of conditions. It wasn’t tested on writing, creative work, or “good/bad” calls without criteria.

⚠️ Exploration without a Solver hurts: rules gathered only from looking around the environment turned out worse than no memory at all. You can’t skip the “try it and verify by re-running” stage.

⚠️ You need orchestration: the method is multi-agent, with loops and resets. You can’t walk through it by hand in a chat. You need an agentic tool with subagents, or automation. In the paper it’s implemented in code.

⚠️ Generation costs money: a full run of 90 sessions came to roughly a hundred dollars in API fees (two hundred in early versions of the pipeline). That’s a one-time cost; in use, the agent spends the same or less thanks to shorter trajectories.

⚠️ The Judge makes mistakes: it rejects some genuine successes, roughly one in six or seven. That’s the safe side to err on, but you’ll get extra iterations.

⚠️ Strong models gain less: if the agent already solves most tasks, there’s little headroom. On the hardest benchmark (SaaS business processes) the gain was more modest, and the best methods with ready-made tasks still lead on some metrics.

The team used three agentic benchmarks: controlling apps through code (AppWorld), retail customer support (τ²-bench), and SaaS business processes (AutomationBench). They compared against an agent with no memory and six memory methods. Five of the six got ready-made training tasks; DAEDALUS had none. Results were averaged over five runs. A large model played the auxiliary roles, and a smaller model from the same family played the Solver and the working agent.

The gain in average success rate over the no-memory agent was 15.9, 10.0, and 4.3 points. Consistency over five runs in a row (pass^5) rose 1.7–2.2×. In four of six columns, the result was within the margin of error of the best method with ready-made tasks. When DAEDALUS was given the same training tasks, it beat the other methods on every benchmark. So the verification mechanism works on its own, and self-invented tasks lose only a little.

The most interesting part is the step-by-step build-up of the pipeline on AppWorld: - A lone Explorer with no Solver scored 35.7 versus 44.3 for the no-memory agent. Worse than nothing. - Adding the Solver’s attempt traces gave about a 16-point gain. That’s the big jump. - Adding the “failure → rule → retry until three successes” loop gave another +4.5 points; the noise gets thrown out. - The environment survey and accumulated difficulty-calibration tips barely changed quality, but they cut generation cost by 48%.

Rules generated by one model family helped agents from other families: all nine combinations came out positive. Qwen’s rules helped GPT-5.4-mini as much as its own did (+16.8 vs. +15.9). Tasks invented by the pipeline ranked models the same way the official tests did. So they can stand in for a test set where none exists.

🔧 Technique: hide the success conditions from the Extractor → rules come out general

In the original, the Extractor sees only the task and the attempt trace. Give it the list of unmet conditions and it starts writing patches like “for order such-and-such, do this.” In your own runs, don’t show it the Judge’s verdict, only the task itself and the trace.

🔧 Technique: one list at the start of the context → no retrieval mid-task

For a trial batch of 10–20 rules you don’t need database retrieval. Merge them into one block and paste it at the top of AGENTS.md or CLAUDE.md. In the paper, this approach beat serving rules on demand at every turn.

An extrapolation — a manual version for live work. It’s not in the paper; it’s a reader’s idea. The method verifies rules by running them, and in everyday work with an agent you do this after the fact:

Here is the rule you suggested adding to AGENTS.md: {rule}.
Here is the task where you made a mistake: {task}.
Solve this task three times in a row from scratch, with this rule in context.
If you fail even once, rewrite the rule and repeat.
Suggest for the file only a rule that worked all three times.

This is a rough version of the “accept a rule after repeated success on a failed task” principle. Three times in one conversation without resetting the context is a weak substitute for clean runs. It’s more reliable to start a new session each time.

• DAEDALUS: Bootstrapping Agent Memory from Self-Generated Tasks — Antoine Edy, Max Conti, Victor Xing, Marc-Antoine Allard, Nawfal Benhamdane, Gautier Viaud, Illuin Technology.
• Code, generated tasks, rule sets, and trajectories: github.com/illuin-tech/daedalus
• Benchmarks: AppWorld (Trivedi et al.), τ²-bench (Barres et al.), AutomationBench (Shepard & Salimans).
• Compared against ExpeL, AutoGuide, ERL, ReasoningBank, ACE, PREPING.