When AI Learns to Alternate Between Rewriting the Recipe and Practicing Cooking: ScienceBuddy's Recursive-in-Recursive Self-Improvement

A Scenario

Imagine you are a lab PI with a new graduate student. You give them an experimental protocol to analyze a batch of gene data. The results come back wrong — they skipped a database lookup and flagged irrelevant genes as targets.

You give feedback: "Next time, check UniProt first, then PubMed, and only then draw conclusions."

The second attempt is better, but the same kinds of errors persist — not because the student doesn't know the procedure, but because their underlying capability is lacking: they can't interpret protein domains or judge which variants are pathogenic.

So you send them off to read literature and do exercises. Weeks later they return, more capable. But now the revised protocol is no longer sufficient — they can do more complex analyses and need finer operating procedures.

You revise the protocol again. They train again. Revise. Train. Again.

This alternating loop of "revise procedure → train capability → revise procedure → train capability" is the core idea of the ScienceBuddy paper, which names it precisely: Recursive-in-Recursive Self-Improvement.

The Core Problem: Why Don't AI Agents Learn from Interaction?

Current AI agents face an awkward situation: after a thousand rounds of conversation, they still make the same mistakes. The reason is simple — in most agent systems, the harness (workflow) and model capability are decoupled. Your feedback, at best, enters the context window and is forgotten next turn. Neither the model weights nor the workflow changes.

Existing approaches each address only part of the problem:

• Reflexion writes lessons into memory, but only as textual reminders
• GEPA searches for better prompts, but only changes the prompt, not the model
• ACE maintains a contextual playbook, but likewise never touches model weights
• SEAL / Darwin Gödel Machine attempt self-modification, but conflate harness and model changes, causing mutual interference

The crux: workflow and model capability are two different layers; changing both simultaneously causes interference.

It's like rewriting a recipe while practicing knife skills at the same time. When revising the recipe, you must design steps around current skills; when practicing skills, you need a stable recipe. They must alternate — not happen simultaneously.

The Method: Two Nested Recursions

ScienceBuddy splits improvement into two nested recursions:

Inner recursion: freeze the model, change the harness

With model weights frozen (\(\theta_k\) fixed), only the harness changes — the Python program organizing prompts, tool calls, and context management. Concretely:

1. Run the current harness on 16 training tasks, collecting interaction logs 2. An auxiliary model (GPT-6 Astra) proposes 3 candidate harness modifications based on interaction evidence 3. Each candidate is run on 90 validation tasks; the highest-scoring one is selected 4. If the new candidate strictly outperforms the parent, replace it; otherwise keep the parent

Output: a better workflow, but the same model.

Outer recursion: freeze the harness, train the model

With the selected harness frozen, the model is trained via GRPO (Group Relative Policy Optimization) on the collected trajectories.

Output: a stronger model, trained under a better workflow.

Alternating the two

After the outer loop, the updated model returns to the inner loop for another round of harness search — a stronger model may render the previous workflow suboptimal. The new workflow in turn provides a better training environment for the next model update.

\[H_{k,j+1} = \text{Select}(H_{k,j}, \mathcal{C}_{k,j}; M_k, D_{\text{val}})\]
\[M_{k+1} = \text{GRPO}(M_k; H_{k,J}, D_{\text{train}}), \quad H_{k+1,0} = H_{k,J}\]

The paper runs 3 full cycles (\(k=0,1,2\)), each with 10 inner harness-search steps + 20 outer RL updates.

The Chef-and-Recipe Analogy

If the formulas feel abstract:

• Model = the chef's skill (knife work, heat control, seasoning intuition) — "internal power"
• Harness = the recipe (what to cut first, when to add salt) — "external technique"
• Task = a dish to cook

Traditional methods either only train the chef (RL fine-tuning) or only rewrite the recipe (prompt engineering / harness search). The problem:

• Only training the chef: the old recipe can't exercise new skills
• Only rewriting the recipe: an unskilled chef can't execute even a great recipe

ScienceBuddy's insight: recipe and skill are coupled, but not simultaneously. When revising the recipe you need a stable chef to evaluate it; when training the chef you need a stable recipe to collect clean training signal.

Key Experimental Results

Tested on four scientific task families: literature reading (LitQA2), database QA (DbQA), experimental protocol debugging (ProtocolQA), and GWAS causal gene identification. 895 tasks total.

Three co-evolution cycles

| Metric | Before | After | Gain | |--------|--------|-------|------| | Overall accuracy | 42.2% | 73.3% | +31.1pp | | Question coverage (pass@4) | 48.3% | 67.8% | +19.5pp | | Right-to-wrong regression rate | — | 2.2% | very low |

Of the 73.3% accuracy, 33.3% of questions went from wrong to right, and only 2.2% from right to wrong — improvement almost never causes regression, an important safety property.

Ablations: each layer separately

Harness-only (model frozen): validation accuracy 31.1% → 51.1% (+20pp). The final harness contains 4 instruction entries and 9 scoped skills covering Python execution, resource checking, record lookup, answer submission, etc.

Model-only (harness frozen): question coverage 48.3% → 67.8% (+19.5pp). Under the same harness and attempt budget, the model solves more distinct problems.

Each layer contributes ~20pp; combined, 31pp — synergy, but not simple addition.

Engineering Insights

1. Separation of concerns beats unified optimization

The paper's most important engineering insight. Harness search and model training are done separately, each with clean optimization objectives and evaluation signals. Changing both at once makes it impossible to attribute performance changes — the optimization signal is polluted.

2. The harness is an executable Python program, not a natural-language prompt

The harness exposes a run(task, api) interface and can do anything Python can: conditionals, loops, exception handling, state management. Candidates are generated by the auxiliary model (GPT-6 Astra), must cite evidence from at least two training tasks, must keep the run(task, api) interface, reject known invalid instruction patterns, deduplicate byte-identical programs, and execute in isolated controller containers. This turns harness search into a constrained program synthesis problem, not vague prompt engineering.

3. Layered feedback signals

Two feedback types are kept separate:

• Diagnostic feedback (score \(q_t \in \{-1, 0, +1\}\)): used for harness improvement, generated by a feedback interpreter
• Trajectory reward (\(R_x(\tau)\)): used for model RL, evaluated independently by a verifier

Diagnostic feedback helps the harness reflector understand *why* something failed, but never directly serves as an RL reward. Trajectory rewards are clean scalar signals, uncontaminated by diagnostics.

4. The improvement mechanism itself does not improve

The paper explicitly states: "its reflector remains fixed, so improved task performance does not imply that the improvement mechanism itself has become stronger."

This is a deliberate safety design. The auxiliary model (GPT-6 Astra) and feedback interpreter are fixed. If the improvement mechanism itself improved, a runaway positive feedback loop could form — exactly the "self-evolution positive-feedback failure loop" identified in the Aspire work. By freezing the improvement mechanism, ScienceBuddy avoids the trap of optimizing a proxy further and further from real capability.

Open-Source Code

The paper ships with open-source experiment code: Gen-Verse/ScienceBuddy

The repository includes:

• src/simple_scibuddy/: simplified agent implementation with experimental harness, execution broker, verifier, and SkyRL adapter
• docs/algorithm.md: detailed documentation of the two-layer recursive RSI algorithm
• docs/experiments.md: experiment configs, task splits, reproduction guide

Experiments use Qwen3.5-4B as the task model, with a frozen set of 715 training / 90 validation / 90 test tasks, and three harness/RL cycles. Each harness phase runs 3 steps with 16 training interactions and 3 candidate proposals per step; each RL phase runs 30 GRPO updates.

Note: the repo does not include the ScienceBuddy product's frontend or API services — only experiment code. The product is available at science-buddy.io.

Personal Reflections

Versus Aspire: why does ScienceBuddy's self-improvement work?

Aspire found that under ambiguous objectives, weight-level self-evolution barely works — the more you optimize the proxy, the further you drift from real capability. ScienceBuddy works because of three differences:

1. It has a verifier: an independent scientific verifier provides clean trajectory rewards. Aspire relied on self-assessment, whose gap from real capability amplifies with optimization. 2. Two separated layers: harness and model are improved separately with clean signals; Aspire changed them together, polluting the signal. 3. A fixed improvement mechanism: ScienceBuddy's reflector doesn't improve, avoiding runaway positive feedback. Aspire's self-assessment co-evolved, forming a positive feedback loop.

Together: self-improvement requires clean signal, separated optimization, and a fixed improvement mechanism. All three are necessary.

Another case for "division of labor beats unification"

ScienceBuddy joins a lineage:

• CritICL: small model errs, large model analyzes, large model benefits
• Weak-to-strong guidance: weak models coach strong models on prefixes
• ScienceBuddy: harness improvement, model training, interaction collection

Each splits a seemingly unified task into subtasks with clear responsibilities and independent optimization objectives. Unified optimization looks elegant; divided optimization works better.

Implications for AI agent engineering

The direct lesson: don't only tune prompts, and don't only fine-tune the model — alternate between both.

1. With the model frozen, search for a better harness (prompt + tool orchestration + context management) 2. Use the selected harness to collect training data; do RL fine-tuning 3. Re-search the harness with the updated model 4. Loop

This outperforms standalone prompt engineering or standalone RLHF due to synergy. The prerequisite is a verifier providing clean training signal — relatively easy in science (ground-truth answers exist), but requiring more design in open domains.

A boundary worth heeding

ScienceBuddy's improvement mechanism does not improve itself (fixed reflector) — a key safety design. If the mechanism were also allowed to self-improve, runaway positive feedback becomes a real risk, as Aspire demonstrated. ScienceBuddy's stance: let the system improve, but don't let the improvement system improve. This parallels human institutions — a legal system can improve society, but changes to the legal system itself require more careful procedures and must not be mixed with law enforcement.

Paper and Code

• Paper: ScienceBuddy: Recursive-in-Recursive Self-Improvement for Interactive Scientific Agents
• Code: github.com/Gen-Verse/ScienceBuddy
• Product: science-buddy.io
• Technical report: PhAI Labs TR-2026-02