LAGO: Enhancing Agent Capabilities Through Task Streams Without Updating a Single Weight

With the same backbone, published SWE-bench results can range from 25% to 62%. The difference often lies in the scaffold around the model.

Yet most scaffolds today do not accumulate experience. Roles such as planner, coder, tester, and reviewer are manually fixed before execution. A sub-problem solved today is solved from scratch again when a different issue arrives tomorrow. After a thousand tasks, the system is no more capable than it was on the first.

Our ICLR 2027 submission, LAGO: Language Agents with Reusable Growing Options, takes a different approach. Each specialized language agent is treated as an option—a temporally extended action from hierarchical reinforcement learning—and stored in a persistent library. A meta-agent makes decisions over a growing action space of primitive tools and reusable agent-options: retrieving, spawning, verifying, admitting, and deduplicating them. No model weights are updated; the action space itself is what changes.

• Frozen models can still outperform competing scaffolds. On all 500 SWE-bench Verified tasks, a single frozen Qwen3.5-35B-A3B serves as both meta-agent and executor, achieving a 58.6% resolve rate with temperature 0, one attempt per task, and the official Docker evaluator.

• We re-run the baselines ourselves rather than importing published numbers. On the same 150-task subset, with identical weights, temperature, task IDs, and evaluator, end-to-end reruns yield 49.3% for mini-SWE-agent, 57.3% for Terminus 2, and 60.3% for LAGO (+11.0 percentage points over mini-SWE-agent).

• The library is actively used. Across the measured systems, 78.8%–86.4% of executor options are retrieved from the library rather than newly spawned. A separate 150-task rollout reaches a cumulative reuse rate of 84.4% (276 reuses and 51 spawns).

• Growth is limited. The seed library starts with 123 options, drops to roughly 80 after the first deduplication pass, and ends at 86 after 150 tasks. Net growth after initialization is modest.

• Decomposition quality can be varied independently. With the executor fixed to DeepSeek-V3.2, changing only the meta-agent gives 40% on SWE-bench Pro for an SFT Qwen3-30B versus 34% for its base counterpart. But using the smaller model in both roles brings performance down to 4–6%: decomposition cannot substitute for executor capability.

• The gains also extend across domains. On BrowseComp (50 English and 50 Chinese questions), average accuracy rises from 33% for a single agent to 46% (English: 22% → 32%; Chinese: 44% → 60%).

Capabilities Have to Be Built Again on Every Task

A ReAct-style single-agent loop is simple and general, but becomes brittle on long-horizon tasks. A real repository-level issue requires five kinds of work: understanding a large repository, localizing a bug across files, implementing a patch, running tests, and checking for regressions. When all five share one trajectory and one context, context overflow, diluted attention over irrelevant observations, and error accumulation over long action sequences become common failure modes.

Hand-designed multi-agent pipelines relieve some of this burden by assigning parts of a task to different roles. But these systems are largely static: roles, prompts, and interaction patterns are fixed before execution. Successful tasks do not automatically become reusable capabilities.

This leads to our question: can a language-agent system accumulate capabilities as it solves more tasks? It must decide when to reuse an existing agent, when to spawn a new one, how to verify and admit it, and how to keep the library from filling up with near-duplicates.

Method: Agents as Options

Each agent-option is a four-tuple:

$$o = (\mathrm{spec}_o, \pi_o, \beta_o, v_o)$$

• $\mathrm{spec}_o$: the role, goal, allowed tools, input-output contract, and execution limits.

• $\pi_o$: the intra-option policy implemented by an LLM and a tool-call loop.

• $\beta_o$: the termination condition, triggered when the sub-task is completed, verified, failed, or its execution limit is reached.

• $v_o$: the verifier that evaluates whether the option has produced a valid result.

Once the meta-agent selects an option, its intra-option policy runs autonomously:

$$a_{t+k} \sim \pi_o(\cdot \mid x_{t+k})$$

until:

$$\beta_o = 1$$

It then returns its result and verification signal to the meta-agent.

Its action space is:

$$A_t = A_{\mathrm{prim}} \cup O(L_t)$$

Primitive tool actions, $A_{\mathrm{prim}}$, are combined with reusable options retrieved from the library, $O(L_t)$. If no suitable option exists, the system falls back to ordinary tool-using behavior. The library is not required for every task.

Option Admission

A new option must pass two thresholds before it can enter the library:

$$\operatorname{admit}(o_{\mathrm{new}}) = \mathbf{1}\left[v^{\mathrm{task}}(o_{\mathrm{new}}) \geq \theta_{\mathrm{task}} \land \operatorname{novelty}(o_{\mathrm{new}}, L_t) \geq \theta_{\mathrm{nov}}\right]$$

The first term checks quality: the sub-task result must be valid, satisfy the required format, and stay within the execution limit. The second checks redundancy: near-duplicate agents must not be inserted repeatedly.

Library governance also involves three operations:

• Deduplication merges agents with similar specifications and behavior, retaining the higher-quality validated version.

• Pruning removes agents that are rarely used or fail regression checks.

• Versioning records the prompt, tools, model version, and verifier version.

Objective over a Task Stream

Over a stream of $T$ tasks, the objective explicitly penalizes library size:

$$\max \sum_{i=1}^{T} \left(\operatorname{Success}(\tau_i) + \lambda\operatorname{Quality}(\tau_i)\right) - \rho |L_T|$$

This term discourages unbounded library growth and encourages reuse over unnecessary spawning.

Result 1: Reruns with the Same Weights, Tasks, and Evaluator Yield 60.3% vs. 57.3% vs. 49.3%

Published SWE-bench results are difficult to compare across papers: the same backbone can range from 25% to 62% with different scaffolds and context budgets. Instead of assembling a leaderboard from those numbers, we re-run the competing scaffolds end-to-end on our own deployment, sharing weights, temperature, attempt count, task IDs, and evaluator.

Evaluation Protocol

SWE-bench Verified, scored by the official Docker evaluator using the binary FAIL_TO_PASS / PASS_TO_PASS metric, with no partial credit.

The controlled comparison uses a fixed 150-task subset drawn by repo-proportional stratified sampling (seed 42), with exactly the same task IDs in every row.

All systems use the same frozen Qwen3.5-35B-A3B at temperature 0, one attempt per task, and the official Docker evaluator. Every row is an end-to-end rerun.

The two baselines span a range of scaffold strength: a minimal ReAct loop and a stronger terminal-agent scaffold. Their published results with a native 200k context window are 59.8–61.6%; our reruns place them under LAGO’s frozen-policy setup and context budget.

Separately, LAGO resolves 58.6% of the full 500-task split, establishing its absolute performance level. This result shares the frozen-policy, single-attempt, official-evaluator protocol with the controlled table, but is not another row in it. The competing scaffolds were re-run only on the 150-task subset, so these results cannot be combined into one ranking.

A Closer Look: Disabling the library costs six resolved tasks, disabling decomposition costs four, and shuffling reused content costs only two

The component ablation uses a fixed 50-task split, the same frozen Qwen3.5-35B-A3B, temperature 0, a single attempt, and a context budget of 65,536 tokens. The denominator is always 50; incomplete rollouts count as unresolved.

These results warrant a cautious reading. On this split, disabling the library costs six resolved tasks, disabling decomposition costs four, and shuffling reused content costs only two. This supports a role for library availability, but does not establish that decomposition itself is necessary for success. Component-level causality remains task- and model-dependent.

Result 2: Changing Only the Meta-Agent Raises Performance from 34% to 40%

The main table uses just one backbone. To examine whether the ordering is tied to a particular model or domain, we move to a second model family (DeepSeek-V3.2 and Qwen3-30B) and add open-domain search tasks.

On SWE-bench Pro (50 tasks), the single-agent DeepSeek baseline scores 34%, while LAGO with DeepSeek-V3.2 in both roles reaches 50% (+16 percentage points). Holding the executor fixed to DeepSeek-V3.2 and varying only the meta-agent yields 40% for SFT Qwen3-30B versus 34% for its base version. This six-point gap is consistent with a role for decomposition quality. But with Qwen3-30B in both roles, absolute performance falls to 4–6%: decomposition quality cannot replace executor capability.

On BrowseComp (50 English and 50 Chinese questions), average accuracy rises from 33% to 46% (English: 22% → 32%; Chinese: 44% → 60%). Replacing the meta-agent with Qwen3-30B lowers performance.

The instance-level comparison is particularly revealing. The SFT meta-agent resolves 20 tasks and the base meta-agent 17, with five newly resolved tasks and two regressions. The gains occur mainly where the base version under-decomposes: skipping verification or combining independent concerns into an overly broad sub-task. The regressions arise from excessive granularity: an overly narrow scope causes the executor to miss edge cases that a broader decomposition would have covered. Finer is not always better; the meta-agent must balance precision and coverage.

Result 3: An 84.4% Option Reuse Rate and a Library That Shrinks from 123 Entries to 86

Across three systems, 78.8%–86.4% of executor options are retrieved from the library rather than newly spawned.

In a separate 150-task rollout, cumulative reuse reaches 84.4% (276 reuses and 51 spawns). The library starts from the 123 options in agent_library_seed350, drops to roughly 80 after the first deduplication pass, and ends at 86. Net growth after initialization is limited, indicating that deduplication does curb unchecked accumulation.

One distinction matters: reuse rate measures retrieval activity, not the causal value of the retrieved content. Retrieval uses a similarity function over option specifications. Distinguishing transferred skills from generic prompt scaffolding requires matched content ablations; the component ablation above supplies only partial evidence.

More Options ≠ Better Agent

Every additional agent-option adds both a capability and another candidate that must be selected correctly. As the library grows, finding the right option at the right time becomes harder for the meta-agent. This is why LAGO includes verifiers, deduplication, and a library-size penalty. It also explains why losing six resolved tasks without the library and only two with shuffled reused content are compatible findings: the library must be available, but availability alone does not establish usefulness.

Expanding capabilities and organizing them are separate problems. LAGO’s proposal is to make task decomposition itself a reusable, verifiable, governable component, allowing the system’s action space to grow across a task stream without updating model weights. Decomposition is most useful when sub-problems are separable and recur across tasks. Whether this pattern transfers to other agent systems with growing libraries remains an empirical question.

Growing capability is one problem. Reusing it is another.

---

Title: LAGO: Language Agents with Reusable Growing Options https://arxiv.org/abs/2610.19843

Authors: Evolvent AI Team

Core contributions:

• Formalizing specialized language agents as options, enabling a meta-agent to invoke temporally extended agent behaviors rather than only primitive tool calls.

• Introducing a growing agent-option library with spawn, admission, reuse, and deduplication mechanisms, allowing the effective action space to evolve over a task stream.

• Reporting SWE-bench Verified results with frozen Qwen3.5-35B-A3B under a single-attempt, temperature-0, official-Docker protocol (58.6% on the full 500-task split), alongside a controlled comparison that re-runs two competing scaffolds end-to-end on the same frozen policy and the same 150-task subset.