We post-trained Qwen3.5-122B-A10B on Long-Horizon Multi-Tool Agent Tasks: a suite of RL environments for realistic, long-horizon work involving documents, spreadsheets, web research, planning, and tool use across office services. None of the training tasks involved coding. The model got better at coding anyway.

It improved on held-out tasks from the same distribution, which is what you'd hope for:

It generalized to other tool-use benchmarks the training data never targeted:

Then there's the result we didn't take for granted. It also improved on software-engineering benchmarks it had never seen:

The post-training data supplied no repository conventions, parser semantics, code-level solutions, software-specific graders, or benchmark feedback, and SWE-Bench Pro still improved by 5.8 percentage points. Which raises the obvious question: what does filling out a spreadsheet teach a model that helps it fix a PowerShell CLIXML parser?

Our answer: the training taught the model to form the right goals, keep them stable under pressure, and continuously check its picture of the environment against them. Those skills transfer because every agent runs the same underlying loop, whether it's updating a workbook or modifying a codebase.

Picture a junior engineer who takes a year off to plan weddings. When they return, their code reviews get noticeably better. Nothing about seating charts taught them Python. What the year taught them was how to run a complex project where everything depends on everything else:

• Turn "make it magical" into a concrete plan with dates, vendors, and a budget (translate a loose ticket into a precise change to make)
• Track how one change ripples through the rest: a new venue breaks the caterer's timeline (a change to one module ripples into every consumer that depends on it)
• Keep the couple's actual wishes in view while firefighting on the day (don't let a stubborn bug pull you into changes that break the actual requirement)
• Do the final walkthrough before the guests arrive, not after (run the tests, then check what else depends on what you touched)

Those habits are exactly what working in an unfamiliar codebase demands, and they were learned without writing a line of code.

A quick caveat before we dig in: this is a behavioral interpretation, not a claim about what is represented inside the model's weights. The explanation comes from aggregate trajectory statistics and manual review of dozens of paired trajectories.

What transferred: the model learned goal-directed execution

To make "forming and pursuing goals" concrete, we can describe any agent task using three elements:

• Goal: the desired state of the environment.
• Action: an interaction intended to move the environment toward that state.
• Working state: the agent's current understanding of the environment and its relationship to the goal.

An effective agent repeatedly runs the following loop:

1. Define the goal.
2. Select an action that should move toward it.
3. Observe the result.
4. Update its working state.
5. Compare the new state with the goal.
6. Stop if the goal has been achieved; otherwise, act again.

We call this cycle the goal loop. People run the same loop when parallel parking: check the mirrors, turn the wheel, inch backward, check again, adjust, and stop when the car sits where it should. The hard part for an agent comes from scale: a real task involves hundreds of these loops, nested inside one another, and each has to stay connected to the purpose it serves.

Because an agent rarely begins with complete knowledge, each action serves two purposes: it may change the environment, and it also reveals information about the environment. Opening a file, running a test, querying a database, and inspecting a spreadsheet all double as experiments that refine the agent's understanding of what is true.

When we compared trajectories before and after training, the clearest difference was the reliability with which the trained model executed this loop across long, complicated tasks. New domain knowledge played little role.

Complex tasks require hierarchical goal-directed execution

In practice, agents don't execute a single goal loop. They execute a hierarchy of them.

Consider a task like: Review our software subscriptions and recommend which vendor contracts to renew, renegotiate, or cancel before the quarter ends.

That instruction is too abstract to execute directly. Before the agent can act, it has to break the task down. A plausible decomposition:

1. Locate the contract folder and the finance workbook that tracks spend.
2. Determine the decision criteria: the budget target, usage thresholds, notice periods for cancellation.
3. Extract the active subscriptions and their renewal dates.
4. Pull usage data for each tool from its admin dashboard.
5. Normalize the figures so tools are comparable (monthly vs. annual billing, per-seat vs. flat pricing).
6. Match spend against usage and flag tools that are underused or redundant.
7. Investigate the edge cases: a tool with few logins but a critical integration, a contract with an auto-renewal clause.
8. Produce the renew / renegotiate / cancel recommendation.

Each step is a subgoal that runs its own copy of the loop, and many decompose further. "Pull usage data" splits into finding each tool's dashboard, exporting activity reports, handling the tools that offer no export, and merging everything into one comparable sheet, each of which bottoms out in individual tool calls. A modest-sounding office task expands into a tree several levels deep and dozens of loops wide.

To see how complex this becomes in practice, explore the full decomposition of a successful trajectory from the holdout set here.

Decomposition, however, is only half the problem. Every branch reads from or modifies the same underlying environment, so what one branch discovers or changes affects what every other branch should do. The agent has to fold low-level observations into one coherent working state and understand what each observation means for the immediate subgoal and for the objectives above it. That dual bookkeeping is where things go wrong:

• A locally sensible action can be globally wrong. Converting every contract to a monthly cost makes the comparison step easy, and hides the fact that one annual contract auto-renews next week, which is exactly the deadline the task is about.
• A relevant fact can get lost between levels. While pulling usage data, the agent notes that most activity runs through service accounts, then carries only the five human logins into the comparison, and a heavily used tool looks dormant.
• A subtask can succeed while undermining a parent requirement. Cancelling a cheap, barely-used tool closes the budget gap, and silently breaks the integration that a flagship tool the company is keeping depends on.
• An intermediate result can look plausible while being incomplete. A spend list built from the finance workbook is a perfectly coherent list. Nothing about the list itself reveals the subscriptions expensed on individual credit cards that never reached the workbook.

Our trajectory analysis surfaced four recurring points at which this process breaks down, each corresponding to a distinct capability:

Failures in an office workflow and a software repository look very different on the surface. Underneath, we kept finding the same four behavioral issues in both.

Why this training data exercises general capabilities

A model can improve on a benchmark for narrow reasons: it memorizes a tool's calling convention, or learns a dataset quirk. That kind of learning doesn't travel. These tasks were designed to capture the complexity of real work, where the model has to manage a hierarchy of goals while piecing together an accurate picture of a complicated environment. Task creators targeted four properties:

• Deep decomposition: high-level objectives had to be broken into branching and sequential subtasks.
• Parallel investigation and synthesis: evidence needed for a decision was distributed across sources and tools.
• Entangled constraints: requirements interacted and couldn't be handled independently.
• Long dependent chains: later work depended on earlier actions and conclusions being correct.

The tasks spanned 27 non-software categories and many different tools. A tool-specific shortcut therefore helped on only a small slice of the data, while better goal-loop discipline paid off across the entire collection.

What it looks like in the trajectories

The examples below show the same underlying problem appearing in both a software-engineering task and a general tool-use task. In every example, the model failed before training and passed after.

1. Defining the right goal

Long tasks break into smaller goals, often across several levels. At each point, the model has to choose what to do next by connecting its immediate context to the larger objective.

Software engineering: SWE-Bench Pro, NodeBB selected fields. The task was to let database callers request only selected fields. Both models found existing helpers that already implemented and tested the required field-selection behavior. The correct local goal was to route the new option through those helpers. The base model instead reimplemented the behavior across the backends and changed existing missing-object semantics. The trained model reused the established path.

General tool-use: Toolathlon, A/B conversion rates. The task was to evaluate how often homepage clicks led to store views. Both models saw the same column names and values, including the fact that clicks exceeded store views. The base model computed clicks / store_views, produced conversion rates above 100%, and kept going with the formula anyway. The trained model interpreted "conversion" in the context of the task and used store_views / clicks.

2. Building goal-relevant state

Each low-level action reveals another piece of the environment. The model needs to combine those pieces into a coherent picture and understand what they mean for the larger task, not just the current subtask.

Software engineering: SWE-Bench Pro, package-name validation. The task was to make package-name validation reject reserved language keywords. The base model had just read the existing imports and validation structure, yet its new helper called a module that was never imported, failing 19 tests. The trained model connected the new requirement to the repository's central validator and reused that established path.

General tool-use: Toolathlon, market workbook. Computing year-over-year growth, the base model hit formula-backed cells and discarded them as missing data, even though their calculated values were exactly what the report needed. The trained model recognized the information mattered, reopened the workbook using cached values, and retained the calculated market data.

3. Keeping the parent goal stable

A local subtask can be hard enough to require many steps on its own. While solving it, the model still needs to keep the larger objective in view. Otherwise it can solve the immediate problem while quietly breaking something the whole task requires.

Software engineering: SWE-Bench Pro, PowerShell CLIXML. The parser had to decode escaped characters while preserving control characters like carriage returns and line feeds. The base model initially preserved them. Then an old unit test expected a trailing CRLF to be stripped, and the model changed the parser to satisfy that test, undoing an explicit task requirement it had already implemented. The trained model recognized that the test reflected the old behavior and kept the CRLF.

General tool-use: Holdout Set, course scheduling. Every selected course had to be at the second-year 2xxx level. The base model correctly identified that constraint and even flagged STAT1010 as an invalid first-year course. Yet while repairing an overloaded semester, it selected STAT1010 as an elective anyway. The trained model kept the constraint active, chose the valid ENG2010 elective, and moved another course to resolve the overload.

4. Checking goal completion

The model needs to verify both the final result and the intermediate work that later steps depend on. At each point, it has to identify what evidence would actually show that the intended result was achieved.

Software engineering: SWE-Bench Pro, Element Web refactor. The base model checked that its new helpers were exported and imported, then declared the refactor complete. It never checked whether existing consumers still depended on the class methods it had removed, leaving downstream code calling APIs that no longer existed. The trained model searched for those stale usages, migrated the call sites, and ran a targeted TypeScript check over the changed files.

General tool-use: Holdout Set, catalogue reconciliation. The base model built a 44-book intermediate file from a bounded spreadsheet read and declared it "the complete list." It inspected that file, but never checked whether the extraction covered the full catalogue. The trained model compared two workbook views, confirmed that each contained the same 347 History authors with no mismatches, and only then relied on the result.

The behavioral metrics agree

The aggregate SWE-Bench Pro statistics point in the same direction:

• The trained model retrieved roughly the same amount of context, but repeated less of it and covered more distinct evidence. It built a better picture of the environment state relevant to the task.
• Its changes were smaller and overlapped more with the reference implementation surface. It chose more accurate, more precise local goals.
• It ran tests more often and earlier, and its verification more frequently informed subsequent work. It checked its progress both mid-task and at completion.

The takeaway: great data can teach general capabilities, not just domain knowledge

General office workflows didn't teach the model PowerShell. They gave it repeated practice applying what it already knew to complex tasks in unfamiliar environments. Solving those tasks demanded better reasoning about goals and environment state, and those gains stayed useful when the tools, the subject matter, and the objectives all changed.

Long-horizon agentic data is expensive to create and expensive to train on. That raises the stakes of every task, but also its potential value. The upside is that high-quality datasets can do more than teach specific workflows. Increasingly, we see models learning sophisticated higher-level skills from them, with surprisingly broad effects far beyond the domains in which they were trained.