Agent-World: Scaling Real-World Environment Synthesis for Evolving General Agent Intelligence

ArXiv: 2604.18292

🎯 Pitch

A self-evolving training framework discovers and synthesizes thousands of realistic tool environments from real-world themes, then iteratively identifies an agent's capability gaps to generate targeted new tasks, producing 8B and 14B models that beat proprietary giants on 23 benchmarks. The agent and its training environments co-evolve in a closed loop, with monotonic accuracy gains from each self-evolution round.

---

1. Executive Summary

This paper introduces Agent-World, a self-evolving training arena that unifies scalable real-world environment synthesis with a continuous self-evolving agent training mechanism to advance general-purpose agent intelligence. Across 23 challenging agent benchmarks—including MCP-Mark, BFCL V4, and τ2-Bench—Agent-World-8B and 14B consistently outperform strong proprietary models and environment-scaling baselines. The framework combines Agentic Environment-Task Discovery (an autonomous pipeline that mines topic-aligned databases and executable toolsets from thousands of real-world themes and synthesizes verifiable tasks with controllable difficulty via graph-based and programmatic generation) with Continuous Self-Evolving Agent Training (a closed-loop process where multi-environment reinforcement learning with executable rewards is paired with a self-evolving arena that iteratively diagnoses capability gaps from failure traces and drives targeted environment-task expansion). The self-evolving loop yields monotonic gains across evaluation rounds—for instance, Agent-World-14B improves on MCP-Mark from 29.5% to 38.1% after two evolution rounds, establishing that agent policies and environments can productively co-evolve when diagnosis and targeted synthesis are tightly coupled.

2. Context and Motivation

The Core Problem: Agent Training Needs Realistic, Scalable Environments That Don't Exist Yet

The fundamental problem this paper addresses is deceptively straightforward: LLMs are increasingly expected to function as general-purpose agents that interact with external, stateful tool environments, but we lack the infrastructure to train them effectively for this role. The paper argues that this is not merely a data problem or a model architecture problem — it is an environment problem. Without access to diverse, realistic interactive environments during training, agents cannot learn the complex reasoning, state-tracking, and multi-tool orchestration skills that real-world deployment demands.

The gap manifests in several interlocking ways described throughout Sections 1 and 2:

• Training happens in impoverished settings. Existing agent training often occurs in stateless or single-tool environments where the model makes isolated function calls with no real consequence for ordering, state consistency, or error recovery. But real-world tool environments are inherently compositional and stateful — as the paper illustrates with a flight-booking example, an agent must "check inventory → execute booking → update calendar" in order while tracking how each action modifies the underlying environment state (Section 1, paragraph 4). Stateless training cannot prepare agents for these workflows.

• Manual environment construction doesn't scale. Building realistic sandboxes by hand — writing databases, implementing tool interfaces, crafting tasks, and designing verification logic — is expensive and slow. The paper notes that this has limited both the diversity and complexity of environments available for training, creating a bottleneck that constrains agent capability development.

• Existing simulation approaches sacrifice realism. Using LLMs as implicit textual world models to simulate environment feedback (the paper cites several works including Feng et al., 2025 and Li et al., 2025) scales well but is "vulnerable to hallucinations and often deviates from real-world dynamics" (Section 1, paragraph 5). Simulated environments can produce unrealistic state transitions, inconsistent tool behaviors, or feedback that doesn't match what real APIs would return — meaning agents trained in them may acquire behaviors that fail in deployment.

• Programmatic environment scaling lacks mechanisms for continuous improvement. More recent work has taken initial steps toward synthesizing programmatic environments and tasks for agent training using LLM-generated code, databases, and toolsets (Section 1, paragraph 5, citing EnvScaler, AWM, AutoForge, and others). These approaches improve training realism, but the paper identifies a critical gap: "their reliance on single-round training makes it difficult for agents to acquire robust, transferable interaction logic in broad environment spaces" (Section 1, paragraph 5). In other words, even when environments are realistic, training over them once is insufficient — agents need iterative exposure to their weaknesses with targeted data expansion, and existing frameworks don't provide this.

The paper crystallizes the gap as two unresolved bottlenecks:

Scalable realism and complex environment synthesis: Existing environments are often purely LLM-generated or derived from limited open-source toolchains, which often mismatch real-world interaction logic. Moreover, synthetic environments are often limited in complexity, restricting the training of agents on long-horizon, state-intensive tasks.

Continuous self-evolving training mechanisms: Although realistic environments can naturally serve as effective training arenas, existing work has primarily emphasized environment construction and scaling, while lacking principled mechanisms that use such scalable environments to diagnose agent weaknesses and drive continual self-improvement.

Why This Problem Matters: The Shift Toward Unified Agent Orchestrators

The importance of this problem is driven by a convergence of technological trends and practical demands, which the paper traces in its introduction.

The Model Context Protocol (MCP) and agent skills are creating a unified interface for tool interaction. MCP provides a standardized way for agents to connect with scalable real-world services — databases, APIs, file systems, SaaS platforms — through a common protocol. This standardization means that, in principle, a single agent should be able to orchestrate tools across many different services without needing service-specific adapters. But this vision only works if agents have been trained to handle the diversity and statefulness that real tools introduce. The paper positions MCP as the motivation for building general agents, not as a solution to the training problem: "an ideal agent serves as a unified orchestrator that can invoke scalable real-world tools, track state changes in real time, and seamlessly integrate large-scale agentic services into automated workflows" (Section 1, paragraph 4).

Real-world deployment demands are forcing agents to handle long-horizon, stateful workflows. Benchmarks like τ2-Bench and ClawEval (Section 1, paragraph 5) have moved evaluation closer to frontier agent applications precisely because they test stateful environments where tool order matters and actions have persistent consequences. These benchmarks reveal that even strong proprietary models (GPT-5.2, Claude Sonnet-4.5, Gemini-3 Pro) achieve only 33–54% on MCP-Mark (Table 1), and open-source foundation models score far lower (Qwen3-8B achieves 2.4%). The gap between what agents need to do and what they currently can do is large and economically significant — these are not toy benchmarks but proxies for real productivity applications like customer support automation, data pipeline orchestration, and business process execution.

The training-inference paradigm is shifting from chat completion to interactive agent loops. The paper situates agent intelligence within a "Generation–Execution–Feedback" loop where agents "take actions and observe timely feedback from the environment" (Section 1, paragraph 3). This is fundamentally different from the stateless text generation that standard LLM training optimizes for. Learning to operate in this loop requires experience with environments that provide structured observations, maintain state across turns, and produce verifiable outcomes — which returns us to the environment bottleneck.

Where Existing Approaches Fall Short

The paper situates its contribution against three categories of prior work (Section 5, Related Work), but the gaps it identifies are woven throughout the introduction and methodology sections as well:

1. LLM-Driven Simulated Environments: Realism Gap

Prior work including Web World Models (Feng et al., 2025), SimWorld (Ren et al., 2026), and similar systems (Section 5.1, paragraph 1) use LLMs to simulate environmental feedback — essentially having the LLM pretend to be the tool or database and generate plausible responses to agent actions. The scalability argument is clear: an LLM can simulate any environment description you give it, eliminating the need to build actual sandboxes.

The paper identifies two failure modes:

• Hallucination: LLM simulators can generate tool responses that are internally inconsistent, contradict earlier state, or violate real-world constraints (e.g., a simulated database that "returns" records that were never inserted). Agents trained against these simulators may learn to exploit simulator quirks rather than genuine interaction logic.
• Dynamics mismatch: Even when hallucination is low, simulated environments often fail to capture the precise state transitions, error conditions, and edge cases that real tools exhibit. The distribution of environment feedback during training diverges from deployment, leading to brittle policies.

The paper's empirical evidence for this gap comes from the baseline comparison: Simulator-8B, which uses LLM-simulated environments for training, "achieved good results on τ2-Bench, yet still performed poorly on MCP-Mark and BFCL V4, suggesting that simulated environments are insufficient to capture complex real-world state transitions" (Section 4.2, finding 2). This is a specific, measurable failure: the simulation approach doesn't transfer to benchmarks that stress state tracking and multi-tool orchestration.

2. Programmatic Environment Synthesis: The Static Training Limitation

A more recent line of work — including EnvScaler (Song et al., 2026), AWM (Wang et al., 2026), AutoForge (Cai et al., 2025), and InfiniteWeb (Zhang et al., 2026) — takes a different approach: rather than simulating environments, these systems use LLMs to generate deterministic sandboxes comprising executable code, database backends, finite-state machines, and rule-based reward signals (Section 5.1, paragraph 2). This provides realistic, verifiable feedback because tools actually execute against real data.

The paper acknowledges this as progress but identifies two specific shortcomings:

Limited complexity and coverage. The paper notes in Section 1 that "synthetic environments are often limited in complexity, restricting the training of agents on long-horizon, state-intensive tasks." Even when programmatic environments are realistic, they may not capture the full diversity of real-world interaction patterns — the range of state transitions, error modes, and compositional tool chains that agents encounter in deployment. Table 1 provides evidence: EnvScaler-8B and AWM-8B/14B, while outperforming their Qwen3 backbones on some benchmarks, still show "clear weaknesses on specific environments, including GitHub and Notion" (Section 4.2, finding 2). The gains are uneven — they help on some environments but not others.

Single-round training without iterative diagnosis. This is the paper's most emphatic critique. Existing work "primarily emphasized environment construction and scaling, while lacking principled mechanisms that use such scalable environments to diagnose agent weaknesses and drive continual self-improvement" (Section 1, paragraph 7). The training paradigm is: (1) generate environments and tasks, (2) train an agent once, (3) evaluate. There is no feedback loop where training-time failures inform the next round of environment construction. The paper argues this is insufficient because agents trained once on a fixed environment distribution will inevitably have blind spots — interaction patterns they never encountered, edge cases they weren't tested on, tool combinations they didn't practice. Without diagnosis and targeted expansion, these gaps remain unresolved.

The paper later validates this critique empirically through the self-evolution experiments (Table 2, Section 4.3.4), showing that even the EnvScaler-8B baseline benefits from the self-evolving loop, improving from 37.9% to 41.6% on τ2-Bench after two rounds. This demonstrates that the limitation is not in the environments themselves but in the static training paradigm — environments are useful training arenas, but their value compounds when coupled with iterative diagnosis.

3. Agent Reinforcement Learning: Focus on Policy Optimization, Not Environment Curriculum

Section 5.2 surveys recent agentic RL work, covering search-centric systems (Jin et al., 2025; Song et al., 2025), tool-use training with improved reward design (Dong et al., 2025; Qian et al., 2025), asynchronous and tree-structured training pipelines (Gao et al., 2025; Feng et al., 2025), and multi-agent distillation (Li et al., 2025). The paper's observation is that these methods "still emphasize policy optimization on relatively fixed training distributions" (Section 5.2). The environment is treated as a given — something to train on, not something to improve.

The paper argues this misses a crucial insight: if environments are scalable (i.e., can be programmatically generated and expanded), then the environment itself should be part of the optimization loop. This is the conceptual leap that motivates the self-evolving arena — environments are not just training data but "critical infrastructure for advancing general agent capabilities" (Section 6) that should co-evolve with the policy.

How Agent-World Positions Itself

Agent-World is positioned not as a new RL algorithm, not as a new environment simulator, and not as a new agent architecture — but as an integrated training framework that treats environment synthesis and agent training as two halves of a single closed-loop process. The paper's explicit contributions map directly to the gaps identified above:

Against the realism gap: Agent-World mines real-world structured data from the web (not LLM-generated) and builds executable tools with cross-validation against unit tests (Section 3.1). This anchors environments in real databases and real tool interfaces while maintaining the scalability of automated synthesis. The paper claims 1,978 environments and 19,822 tools after filtering (Figure 4), representing a diversity that manual construction couldn't achieve and a realism that LLM simulation can't match.

Against the static training limitation: The self-evolving arena (Section 3.2.2) is the paper's key architectural innovation. It is not an afterthought bolted onto environment scaling — it is a core component that closes the loop. The arena evaluates the current policy on freshly synthesized tasks (not a static test set), diagnoses failure patterns from executable traces, produces structured guidelines for what kinds of tasks would address those gaps, and feeds those guidelines back into the environment-task synthesis pipeline. This creates the "agent-environment co-evolution" that the paper's title promises.

Against the fixed-distribution RL paradigm: The paper positions its contribution at the intersection of scalable environment synthesis and train-time diagnosis. The GRPO-based multi-environment RL (Section 3.2.1) is relatively standard — the novelty is not in the policy update formula but in what the policy is trained on and how that training data evolves. The environments are drawn from a hierarchical taxonomy (Figure 3) that ensures broad coverage, tasks are synthesized with controllable difficulty (graph-based for sequential dependencies, programmatic for complex control flow), and rewards are executable (rubrics and verification code) rather than model-based.

The paper also positions itself in the broader trajectory of agent research. Section 1 frames the work within the context of MCP standardization, the shift from chat to agent interfaces, and the growing recognition that environments are infrastructure — not just evaluation tools but training substrates. The explicit connection to MCP (Section 1, paragraph 4) and the use of real MCP server metadata for environment discovery (Section 3.1, paragraph 1) situates Agent-World as infrastructure for the MCP ecosystem, not just another training method.

A notable conceptual distinction: Unlike prior work that treats environment scaling as a data generation problem (generate more environments → train on more data), Agent-World treats it as a curriculum design problem (diagnose weaknesses → generate targeted environments → train on those gaps → repeat). The paper doesn't just claim that more environments help (though it demonstrates scaling relationships in Figure 8); it claims that adaptive environment expansion — guided by failure analysis — is more efficient than uniform scaling. The self-evolution experiments (Table 2) provide evidence: targeted synthesis driven by diagnosis produces monotonic gains across rounds, suggesting the system is learning what to learn rather than just learning from more data.

3. Technical Approach

3.1 Reader Orientation

Agent-World is a training pipeline — not a model architecture or a new RL algorithm — that automatically builds thousands of realistic tool-using environments from web data and then trains LLM-based agents inside them through a closed loop where the agent's failures drive the creation of harder, more targeted training tasks. The system solves the chicken-and-egg problem of agent training: you need diverse, realistic environments to produce capable agents, but manually building those environments doesn't scale, and purely simulated environments lack the state-tracking fidelity that real-world deployment demands.

3.2 Big-Picture Architecture (Diagram in Words)

Agent-World has two major components connected in a feedback loop:

1. Agentic Environment-Task Discovery (Section 3.1): An automated pipeline that starts from thousands of real-world environment themes (MCP server specs, tool documentation, industrial PRDs), uses a deep-research agent to mine topic-aligned databases from the web, generates executable tool interfaces with unit-test verification, and synthesises verifiable training tasks at controllable difficulty levels through both graph-based and programmatic generation. Output: a scalable environment ecosystem E containing 1,978 environments and 19,822 tools, plus task sets X_graph and X_prog with structured rubrics and executable validation scripts.

2. Continuous Self-Evolving Agent Training (Section 3.2): A training loop where the agent policy is trained via multi-environment GRPO (Group Relative Policy Optimization) with executable rewards, then evaluated on freshly synthesised tasks in a held-out arena of environments. A diagnosis agent analyses failure traces to identify weak environments and capability gaps, and feeds structured task-generation guidelines back into the environment-task discovery pipeline. The newly synthesised targeted tasks are used for continued RL training. This loop repeats for R rounds, with the agent and environments co-evolving.

Information flows in a cycle: environment themes → database mining → tool generation → task synthesis → multi-environment RL → arena evaluation → diagnosis → targeted task synthesis → continued RL → (repeat). The self-evolving arena (Section 3.2.2) is the mechanism that closes this loop — it is not a static evaluation set but a dynamic diagnostic instrument that regenerates tasks each round to prevent overfitting.

3.3 Roadmap for the Deep Dive

The explanation follows the system's construction and operation order, because each downstream component depends on what the previous component produces:

• First, the formal POMDP model (Section 2 of the paper) — how agent-environment interaction is mathematically structured, since every subsequent design decision (state tracking, reward design, task verification) builds on this formulation.
• Second, Agentic Environment-Task Discovery (Section 3.1) — how environments are built from themes, databases, and tools, because tasks cannot be synthesised without environments, and RL cannot proceed without tasks.
• Third, Verifiable Task Synthesis (Section 3.1.1) — the two complementary strategies (graph-based and programmatic) that produce training and evaluation tasks, because the difficulty scaling and verification mechanisms directly determine what the agent learns.
• Fourth, Multi-Environment Agent RL (Section 3.2.1) — the training procedure, reward design, and policy update, because this is what consumes the environments and tasks to produce agent policies.
• Fifth, Self-Evolving Agent Arena (Section 3.2.2) — the diagnostic loop that connects evaluation back to environment expansion, because this is the mechanism that enables continuous improvement and distinguishes Agent-World from prior static training paradigms.

3.4 Detailed, Sentence-Based Technical Breakdown

This is primarily a systems and infrastructure paper whose core idea is that realistic, scalable environments and continuous, diagnosis-driven training must be unified into a single closed-loop framework — neither environment scaling nor policy optimisation alone is sufficient for building general-purpose tool-using agents.

---

Formal Agent-Environment Interaction Model (POMDP, Section 2)

The paper models multi-turn agentic interaction with external environments as a Partially Observable Markov Decision Process (POMDP), represented by the tuple (U, S, A, O, P). This formalism is the foundation for how state, actions, and rewards are defined throughout the system, and it is worth understanding thoroughly because every subsequent design choice — from tool interface generation to reward computation — builds on it.

Intent space U: Each user interaction begins with a latent intent q ∈ U that the assistant must progressively infer from the accumulated interaction history and environment feedback. This is important because it means the agent's objective is not just to respond to the current observation but to reconstruct the user's unobserved goal — a reasoning task that requires multi-turn information gathering.

State space S: The global state is factored into two components — an environment state s_E ∈ S_E and a dialogue state s_H ∈ S_H — so that s_t = (s_Et, s_Ht) ∈ S at turn t. The environment state captures the mutable external world (databases, files, services) that the assistant can query or modify. The dialogue state summarises conversational context (history, constraints, user preferences). This separation is critical: tool actions modify s_E, while response actions only affect s_H. The environment state is not directly observable — it must be inferred from tool observations — which is what makes this a partially observable problem rather than a fully observable one.

Environment parameterisation: Each environment is explicitly parameterised as a pair e = (D, F), where D is an environment database (the primary carrier of s_E — it contains the structured records and/or files that constitute the mutable external world) and F = {f_k} is a toolset providing executable interfaces to interact with s_E. Each tool f ∈ F is a callable operator that reads and optionally writes the database, thereby inducing environment state transitions. This parameterisation is not just notation — it is the blueprint that drives the entire environment synthesis pipeline: Agent-World must produce both a database D and a toolset F for each environment theme.

Action space A: The assistant chooses between two types of actions: A = A_tool ∪ A_resp. A tool-use action a_t ∈ A_tool invokes a tool with structured arguments (function name with JSON parameters) to query or modify the environment. A language-response action a_t ∈ A_resp emits a natural-language message, which can be an intermediate response or the final answer. In offline training, A_resp typically yields a termination signal.

Observation space O: At each turn, the assistant receives o_t ∈ O where O = O_E ∪ O_H. Structured tool observations O_E contain query results, logs, and error codes returned by tool execution. Dialogue-side observations O_H contain user utterances, system prompts, or explicit termination signals. The critical design point is that s_E is not directly observed — the agent must reconstruct it from the sequence of O_E observations.

State dynamics P: The transition model P : S × A → Π(S × O) defines two distinct transition patterns depending on the action type:

• If a_t ∈ A_tool: a tool f ∈ F executes against database D, potentially updating s_Et+1 via reads/writes, and produces a structured observation o_Et+1 ∈ O_E. The dialogue state s_Ht+1 is updated by appending the new tool interaction.
• If a_t ∈ A_resp: the dialogue state s_Ht+1 updates by emitting a response, but the environment state remains unchanged (s_Et+1 = s_Et). This means pure language actions cannot modify the world — a constraint that mirrors real tool-using scenarios where "talking about" an action doesn't execute it.

Why this formalism matters operationally: The POMDP model tells us exactly what Agent-World must synthesise. Each environment must provide a database D (the state substrate), a toolset F (the action interface), and a mechanism for producing observations O_E (the feedback channel). Tasks must specify an initial state, a goal that requires reconstructing the user's latent intent q, and a verification procedure that checks the final state or answer. Rewards must account for whether actions produced valid state transitions and whether the final state matches the goal. The formalism is not just academic scaffolding — it is the specification that the synthesis pipeline implements.

---

Agentic Environment-Task Discovery (Section 3.1)

This component is the environment factory. It takes raw environment themes as input and produces a scalable ecosystem E of executable environments, each containing a database D paired with a verified toolset F. The pipeline has four sequential stages: theme collection, database mining, tool generation and verification, and taxonomy construction.

Environment Theme Collection

The synthesis pipeline begins with environment themes — natural-language descriptions of what a domain is about. The paper gathers these from three real-world sources to ensure breadth and realism:

1. MCP Servers (M1): Real-world MCP server specifications obtained from Smithery (smithery.ai/servers). Each specification is accompanied by a structured JSON document containing source-data descriptions and standardised tool definitions. The paper denotes the corresponding topics as m ∈ M1. Using actual MCP server metadata means the derived environments mirror real-world service interfaces — the tool schemas, parameter types, and interaction patterns come from deployed systems rather than LLM imagination. This is a deliberate anchoring strategy: if the training environments resemble MCP servers that agents will encounter in deployment, the transfer gap narrows.

2. Tool Documentations (M2): Open-source datasets covering real tool-use scenarios are collected and filtered. The paper extracts tool-definition documents and uses an LLM to inversely map them to environment topics, denoted as m ∈ M2. This source captures tool usage patterns from existing benchmarks and datasets, providing diversity beyond what MCP server specs alone would cover.

3. Industrial PRDs (M3): Product Requirement Documents for specific industries naturally include background information, domain workflows, and system interfaces. The paper uses them as theme anchors, denoted as m ∈ M3. PRDs are valuable because they describe real business processes — workflows that actual software systems implement — rather than synthetic scenarios. They capture the intent behind tool design, not just the interface.

The three sources are merged: M = M1 ∪ M2 ∪ M3. The paper reports approximately 2.8K MCP server themes, approximately 0.5K tool documentation themes, and approximately 0.2K industrial PRD themes (Figure 2 annotation). After filtering, the final taxonomy contains over 2K third-tier labels (Section 3.1, "Environment Taxonomy Construction"), corresponding to the 1,978 retained environments reported in Figure 4.

Why multiple sources: Each source type captures different aspects of environment realism. MCP servers provide precise tool definitions but may be narrow in domain coverage. Tool documentations cover diverse use cases but may lack structured database information. PRDs provide rich domain context and workflow descriptions but without executable interfaces. Combining them produces themes that are both diverse and grounded.

Agentic Database Mining

Given the theme set M, the goal is to produce a topic-aligned real-world environment database D(m) for each theme m. The paper explicitly argues against LLM-synthesised databases (the approach used in prior work like GenEnv and EnvScaler), stating: "the World Wide Web already contains abundant, high-value structured data that can be updated in real time" (Section 3.1, "Agentic Database Mining"). The key insight is that web data provides realism by construction — it reflects actual distributions, edge cases, and inconsistencies that synthetic databases smooth over.

The deep-research agent G: The paper builds an automated workflow centred on a policy model π_θ and an external toolset T that includes search, browser, code compiler, and operating-system (OS) tools. The agent G takes a theme m and conducts iterative loops of in-depth information retrieval and data mining. Concretely, the flow is:

D(m) = G(m; π_θ, T), m ∈ M

where G(·) denotes the topic-conditioned automated research pipeline. This means: for each theme m, the agent searches the web for relevant structured data, browses pages to extract tables, lists, and records, uses code tools to parse and validate the extracted data, and uses OS tools to persist it in structured formats (JSON, CSV, SQL, etc.). The policy model π_θ is GPT-OSS-120B for the environment mining stage (Section 4.1, "Implementation Details").

Database complexification φ: The paper observes that "a single autonomous mining flow often yields databases with limited scale and simple structure" (Section 3.1). To address this, it introduces an iterative expansion procedure φ:

D^{(n+1)}(m) = φ(D^{(n)}(m), m, T), n = 0, ..., N-1

Starting from the initial database D^{(0)}(m), each complexification round prompts the deep-research agent to expand and enrich the topic-specific database. The agent may add new records, introduce additional tables, create cross-references, or inject realistic noise and edge cases. The final database after N rounds is denoted D^{(N)}(m). The paper reports that repeating this procedure "produces high-quality databases that better match realistic environment demands."

What the databases contain: Figure 4(d) shows that database file types include json, csv, sql, html, tex, and yaml. The diversity of formats reflects real-world data heterogeneity — agents trained on these databases encounter the same format variety they would in deployment. Appendix B provides concrete examples: the Arxiv_local environment uses Markdown metadata cards plus a JSON manifest; the Emails environment uses a large historical CSV plus a synthetic JSON export; the Calendar environment uses multiple JSON files with different schemas.

Design choice — web mining over LLM generation: The paper's explicit argument is that web data provides realism that LLM generation cannot match. LLM-generated databases may contain statistically plausible but factually incorrect records, may miss edge cases that real data contains, and may not reflect the distributional properties (skew, sparsity, noise) of real-world data. Web-mined databases inherit these properties naturally. The trade-off is that web mining requires more complex infrastructure (search, browsing, parsing) and may produce noisier data requiring validation. The paper does not provide a direct ablation comparing web-mined vs. LLM-generated databases, so the benefit is argued on principle rather than demonstrated empirically.

Tool Interface Generation and Verification

Given a theme m and its mined database D^{(N)}(m), the next step is to produce a database-grounded executable toolset F(m). This is where the environment becomes interactive — tools are the interface through which agents will read and modify the database state.

The coding agent ψ: A specialised agent, also backed by GPT-OSS-120B, is equipped with a code compiler and OS tools (denoted Ĥ). The agent receives (m, D^{(N)}(m)) and generates candidate tools together with their unit-test sets:

{(ˆf, ˆC_ˆf)} = ψ(m, D^{(N)}(m); π_θ, Ĥ), m ∈ M

Each candidate tool ˆf is a Python function, and each is associated with a set of test cases ˆC_ˆf — a one-to-many mapping meaning one tool can have multiple test cases.

Cross-validation for quality control: Motivated by execution-based verification procedures from prior work (Dong et al., 2024; Zeng et al., 2024), the paper applies automated cross-validation. For each candidate tool ˆf, its test accuracy is defined as:

$\text{Acc}(ˆf; ˆC_ˆf) = \frac{1}{|ˆC_ˆf|} \sum_{ˆc ∈ ˆC_ˆf} \mathbf{1}[ˆf(ˆc) \text{ passes}]$

where |ˆC_ˆf| is the number of test cases associated with tool ˆf, ˆc is a single test case, and \mathbf{1}[·] is the indicator function (1 if the tool passes the test, 0 otherwise).

What it computes: For each candidate tool, the coding agent generates a set of test cases alongside the tool implementation. Each test case specifies inputs and expected behaviour. The tool is executed against each test case in a sandbox. The fraction of passing tests is the accuracy score. A tool that correctly handles all test cases gets Acc = 1.0; a tool that fails all tests gets Acc = 0.0.

Why this form: The accuracy score provides a single, interpretable quality metric per tool. It captures both functional correctness (does the tool produce the right output?) and robustness (does it handle edge cases?). The arithmetic mean equally weights all test cases, which is appropriate because each test case represents a distinct behaviour that the tool must support — failing any single one indicates a bug.

Three-part retention filter: A tool is retained only if it satisfies all of the following conditions:

1. The function can be successfully compiled by the Python compiler (syntax validity).
2. Acc(ˆf; ˆC_ˆf) > 0.5 on its associated test set (majority of tests pass — a lenient threshold that acknowledges test case generation may be imperfect).
3. The corresponding environment contains at least one valid tool and one valid test case (environment-level quality check).

After filtering, the quality-controlled tool set F(m) is obtained. The final environment ecosystem is:

E = {(D^{(N)}(m), F(m)) | m ∈ M}

Scale: Figure 4 reports 1,978 environments after filtering and 19,822 distinct tools. Figure 4(b) shows that each environment averages more than 10 tools, with some containing over 40 tools. Figure 4(c) notes that tools have "rich parameters, ensuring both atomic functionality and tool diversity."

How tools relate to the POMDP: Each tool f ∈ F(m) implements the executable interface for an action a ∈ A_tool. When an agent invokes a tool, it executes against D^{(N)}(m), potentially modifying s_E, and returns a structured observation o_E. The tool implementations in Appendix B show concrete examples: list_emails reads a JSON file and returns paginated results; book_hotel appends a record to a bookings ledger; get_local_paper_metadata parses a Markdown file and returns structured fields. The tools are deterministic file-backed functions, which means environment behaviour is reproducible and verifiable — a critical property for training with executable rewards.

Environment Taxonomy Construction

To systematically organise the synthesised environments, the paper builds a hierarchical taxonomy. This is not just for cataloguing — the taxonomy enables stratified sampling for the evaluation arena (Section 3.2.2) and provides a structural prior for cross-environment generalisation.

Construction procedure (three-stage):

1. Clustering: Based on thousands of environment themes, hierarchical clustering (Ward's method, Ward Jr., 1963) is applied to obtain 50 cluster centres. The paper then traces back the sample set covered by each cluster and randomly selects representative samples.

2. LLM summarisation: Building on TOUCAN's taxonomy (Xu et al., 2025), GPT-OSS-120B is used as a supervised summarisation model to identify the central environment theme of each cluster, yielding 50 second-tier labels. The paper notes that "relying solely on LLM summarization may introduce templated text and bias."

3. Human abstraction: Three annotators merge the second-tier labels and abstract them into 20 first-tier types. Cross-validation and discussion yield the final hierarchical taxonomy.

Result: Figure 3 shows the taxonomy contains 20 first-tier labels, 50 second-tier labels, and over 2K third-tier labels (corresponding to individual environments). The left panel shows the distribution of the 20 first-tier categories with their server counts. The right panel shows the top-10 second-tier categories ranked by server count. Examples of categories visible in Figure 3 include "Communication & Messaging," "Database & Storage," "Development Tools," and "E-commerce & Retail."

Why a taxonomy matters: The taxonomy serves as the structural backbone for the self-evolving arena. When the arena needs to sample environments for evaluation (Section 3.2.2), it does so by stratified sampling across first-tier categories — ensuring coverage of all environment types rather than over-representing common ones. When the diagnosis agent identifies weak environments, it reports them by taxonomy category, enabling targeted expansion within specific domain clusters.

---

Verifiable Task Synthesis (Section 3.1.1)

With the environment ecosystem E constructed, the pipeline synthesises agentic tasks — specific problems that require an agent to use tools in sequence or combination to achieve a goal. The paper uses two complementary synthesis strategies because different real-world scenarios require different reasoning patterns.

The shared verification philosophy: Both synthesis strategies share a common principle: tasks must be verifiable through execution, not through LLM judgment alone. This means each task includes either (a) a structured rubric with specific, checkable criteria or (b) an executable verification script that programmatically validates the agent's answer and the resulting database state. The paper uses sandbox execution to collect execution traces, derive ground-truth answers, and preserve task verifiability — citing prior work (Cai et al., 2025; Tu et al., 2026) that established this pattern.

Quality consistency protocol (shared across both strategies): To ensure task stability, each synthesised task is evaluated by deploying a ReAct agent to solve it 5 separate times within the sandbox. The task is retained only if the agent successfully reaches a consistent answer in at least two independent runs. This protocol serves dual purposes: it filters out tasks that are impossibly hard (the agent never succeeds) and tasks that are ambiguous or underspecified (the agent succeeds inconsistently). It also validates that the verification mechanism (rubric or script) correctly evaluates the task.

Graph-Based Task Synthesis

This strategy models sequential tool dependencies — scenarios where tools must be called in a specific logical order because later tools depend on earlier tools' outputs. The approach is fundamentally reverse-engineering: first synthesise a valid tool-call sequence, then generate the corresponding task description, then execute to obtain the ground-truth answer.

Tool Graph Construction: For each environment (D^{(N)}(m), F(m)), a fully connected, weighted directed graph G = (V, E) is constructed. Each node v ∈ V corresponds to a tool f ∈ F(m). Each edge encodes call dependencies between tools, evaluated and assigned by an LLM.

Three edge types with distinct weights:

• Strong dependency (f_i → f_j, w_ij = 3): The input of tool f_j strictly relies on the output of tool f_i. Example: calling create_order to obtain an order_id before calling get_order_details. This forms a strictly directed edge, ensuring the most logical data flow. The weight 3 biases the random walk toward respecting natural tool chains.

• Weak dependency (f_i ↔ f_j, w_ij = 2): The input of f_j can be derived from f_i's output, but can also be obtained via other means (querying a database directly or using a constant). This is modelled as a bidirectional edge, offering flexibility during the walk. The weight 2 makes these transitions less likely than strong dependencies but more likely than independent edges.

• Independent edge (f_i ↔ f_j, w_ij = 1): Tools with no parameter-level dependencies. These edges act as a fallback to guarantee that G is fully connected, preventing dead ends during random walks. The weight 1 makes these the least preferred transitions.

Why weighted edges: The weight scheme encodes a prior that realistic task sequences follow natural data-flow patterns. Strong dependencies (weight 3) are the most realistic because they mirror how real APIs chain: you must create a resource before you can read or modify it. But exclusively following strong dependencies would produce overly predictable sequences. The weaker edges (weights 2 and 1) inject diversity by allowing the walk to sometimes take less obvious paths, producing tasks that require more creative reasoning about how tools can be combined.

Random Walk on Tool Graph: A raw tool-call sequence τ = [f_1, f_2, ..., f_k] is generated by performing a random walk on G. The procedure prioritises starting nodes f_1 that return tool output but have no strong dependency precursors — these are "entry point" tools that can be called first without needing prior state. At step t, the next tool f_{t+1} is sampled from the successors of f_t with a probability distribution biased by the edge weights w, encouraging sequences with realistic reasoning patterns.

Parameter instantiation: Once the tool sequence τ is sampled, its input parameters are populated:

• For strong/weak dependencies: the output of the preceding tool is passed forward.
• For independent edges: valid values are randomly sampled from the database D^{(N)}(m).

An LLM reviews the populated chain to prune redundancies, verify logical consistency, and output a refined, executable tool sequence τ*.

Task and Rubric Generation: Given τ*, an LLM drafts an initial task description q_init. Crucially, q_init is "strictly prohibited from containing technical details such as tool names or database schema" — this prevents data leakage where the task description would directly tell the agent which tools to use. Next, τ* is executed step-by-step within a Python sandbox, recording the intermediate execution trace and final return results. Observing the actual data fields and formats allows the LLM to refine q_init into a highly realistic and well-grounded final query q_final. Simultaneously, the LLM generates:

• A strictly formatted JSON ground-truth answer a*
• Structured evaluation rubrics R that enable automated evaluation across multiple dimensions including field completeness, schema matching, and numerical tolerances

Difficulty Scaling for Graph-Based Tasks: Difficulty is increased along two axes while maintaining solvability:

1. Increasing the maximum step count of the random walk to expand the tool chain length — longer chains require more planning and state tracking.
2. Increasing the sampling probability of weak dependencies and independent edges to reduce reliance on obvious sequential outputs — this obscures the natural tool ordering and forces the agent to determine the correct sequence through reasoning.
3. Rewriting the final task description to obscure explicit mentions of tool names and execution logic, forcing the agent to infer the required workflow purely from abstract task goals.

The final task set from graph-based generation is denoted X_graph.

Programmatic Task Synthesis

While graph-based synthesis captures sequential dependencies, "real-world tasks often demand reasoning patterns that cannot be expressed linearly, such as conditional tool usage, multi-step loops, and result aggregation" (Section 3.1.1). Programmatic synthesis directly generates executable Python solutions capable of performing code-based reasoning over provided tools.

Task and Solution Code Generation: An LLM is prompted with the environment's tool schemas and database descriptions to generate:

1. A highly complex task query q_prog that focuses entirely on task scenarios and objectives without revealing tools or databases
2. A comprehensive, end-to-end executable Python script π_code that loads the tool implementations and utilises complex control flows (for loops, if-else branches, statistical aggregations) to solve q_prog

The solution code generation step is wrapped in a ReAct loop: if the sandbox throws syntax or runtime errors, the agent iteratively debugs and repairs the code. The successfully executed script yields the ground-truth answer a*. This means the ground truth is not LLM-estimated — it is computed by actual execution, which is the strongest form of verification the system can provide.

Verification Code Generation: Traditional string-matching evaluation falls short for complex programmatic tasks because answers may be structurally complex (nested JSON, lists with multiple valid orderings, numerical results with floating-point tolerance). Therefore, the LLM also generates an executable verification script V_code(a, a*). This script includes:

• Multi-level assertions
• Custom logic to robustly determine whether the candidate answer a and the underlying database state s_E satisfy all task constraints

Similar to solution code generation, a ReAct agent debugs V_code in the sandbox to guarantee its reliability.

Why executable verification is necessary: The verification script can check properties that simple string matching cannot: that the database is in the correct final state (not just that the answer text matches), that all required side effects occurred, that no unauthorised modifications were made, and that the answer satisfies domain-specific constraints (e.g., all returned items belong to a delivered order, as in Appendix C.1). This is the paper's answer to the verifier reliability problem discussed in the prior analysis — by making verification programmatic and execution-based, it eliminates the hallucination risk inherent in LLM-based evaluation.

Difficulty Scaling for Programmatic Tasks: Similar to graph-based synthesis:

1. Increase the number of unique tools and invocations through modified LLM instructions.
2. Inject instructions for implementing intricate inter-tool logic such as conditional branches and mandate advanced data operations like cross-database aggregations, sorting, and filtering.
3. Rewrite the task description to remove any direct references to APIs or execution traces, ensuring the agent must plan complex programmatic logic entirely from high-level user intents.

The final task set from programmatic generation is denoted X_prog.

Static Statistics of the Environment-Task Data

Figure 4 provides a quantitative characterisation of the synthesised ecosystem through six subfigures:

• (a) Environment diversity: Over 2,000 environments initially, with 1,978 retained after filtering. The distribution across the 20 first-tier taxonomy categories shows substantial breadth.
• (b) Tools per environment: Each environment averages more than 10 tools, with the distribution right-skewed — some environments contain over 40 tools.
• (c) Total tool count: 19,822 distinct tools across the ecosystem, each with rich parameters.
• (d) Database file types: JSON, CSV, SQL, HTML, TEX, YAML, and environment-specific formats — reflecting real-world workspace heterogeneity.
• (e) Task interaction turns: All synthesised tasks contain at least 7 interaction turns, with an average of over 20 turns and a non-trivial portion exceeding 40 turns. This is the paper's operational definition of "long-horizon."
• (f) Task difficulty (Pass@10): Evaluated under Pass@10 using Doubao-Seed-2.0-pro, a strong proprietary model. Only a small fraction of tasks are solved in all 10 attempts; most are solved only once out of 10; some are not solved at all. This validates that the difficulty scaling strategy is effective — tasks are challenging even for frontier models.

---

Multi-Environment Agent Reinforcement Learning (Section 3.2.1)

With environments and tasks synthesised, the paper trains agent policies through multi-environment RL. This component is relatively standard in its algorithmic core (GRPO) but distinctive in its rollout design and reward structure.

Multi-Environment Rollout

Unlike static tool-calling scenarios where the model makes isolated function calls, Agent-World implements a closed-loop interaction among three components:

1. An LLM policy π_θ: Generates the next action conditioned on the dialogue history and tool feedback. The backbones are Qwen3-8B and Qwen3-14B, initialised from a cold-start SFT stage (Section 4.1).

2. A tool interface/runtime: Executes the environment-specific tool set F(m) and maintains environment-side states (database connections, caches, etc.). This is a sandboxed Python runtime.

3. A database state D^{(N)}(m): Serves as the read/write substrate for tool execution and provides a verifiable, updatable structured data backbone. The database is the ground truth for state — tool observations reflect actual reads from and writes to it.

Step-by-step execution: At each step, the model produces both natural-language reasoning and tool/action decisions. When a tool call is triggered, the interface executes the selected tool in a sandboxed environment to read or update the environment database state, and returns structured observations to the policy for subsequent decision making.

Formal rollout structure: Given a task x and its training environment (D^{(N)}(m), F(m)) ∈ E, the policy π_θ samples an action a_t based on the instruction and history h_t = (o_0, a_0, ..., o_t). Two cases:

• If a_t ∈ A_tool: executes f ∈ F(m) on D^{(N)}(m) and returns a structured observation o_Et+1 ∈ O_E
• If a_t ∈ A_resp: outputs a natural-language response (typically the final answer or completion marker) and terminates the trace

The output is a model output y = (τ, a_final), where τ = (o_0, a_0, ..., o_T, a_T) is the interaction trajectory and a_final is the final answer.

Multi-environment sampling: Following Group Relative Policy Optimization (GRPO), N outputs per task are sampled. Tasks within each global batch are paired with independent and dynamic environments to realise multi-environment rollouts. This means each training batch exposes the policy to diverse tool interfaces and database states simultaneously, preventing overfitting to any single environment's patterns.

Implementation details (Section 4.1): The maximum trajectory length is 80K tokens, and the maximum generation length per step is capped at 32K tokens. In each training step, 32 tasks are sampled and 8 rollouts are collected (so N = 8, G = 8 in the GRPO notation). Decoding uses temperature = 1.0 and top_p = 1.0 for both training rollouts and evaluation. Each experiment is repeated eight times with average accuracy reported to reduce random variance.

Structured Verifiable Reward

Reward signals define the optimisation objective and directly guide policy behaviour. The paper distinguishes two reward types corresponding to the two task synthesis strategies.

Graph-based tasks (X_graph): Each task provides a structured rubric R = {r_j}_{j=1}^n where each r_j is a specific criterion (schema matching, fact checking, field completeness, numerical tolerance, etc.). A rubric-conditioned LLM-as-judge evaluates each criterion r_j from the model output y under task x. The overall pass rate is computed by averaging criterion-level pass indicators.

Programmatic tasks (X_prog): Each task provides an executable validation script V_code that is run in the sandbox. The script verifies either the predicted answer or the resulting database state.

Output-level reward computation:

$r(x, y) = \begin{cases} \mathbf{1}\left[\frac{1}{n}\sum_{j=1}^n \mathbf{1}[\text{Judge}(x, y, r_j)] == 1\right], & \text{if } x \in X_{\text{graph}}, r_j \in R \\ \mathbf{1}[\text{Execute}(V_{\text{code}}(y, y^*))], & \text{if } x \in X_{\text{prog}} \end{cases}$

where \mathbf{1}[·] is the indicator function (returns 1 if the condition is true, 0 otherwise), \text{Judge}(x, y, r_j) denotes a rubric-conditioned LLM judge that assesses whether model output y satisfies criterion r_j under task x, and \text{Execute}(V_{\text{code}}(y, y^*)) denotes running the task-specific validation script V_{\text{code}} in a sandbox over model output y to verify that answer/state are satisfied with the ground truth y^*.

What it computes: For graph-based tasks: the judge evaluates each rubric criterion independently, producing a binary pass/fail per criterion. If all criteria pass (the average equals 1.0), the task is considered correct and the reward is 1; otherwise 0. For programmatic tasks: the verification script is executed against the model's answer; if the script's assertions all pass, the reward is 1; otherwise 0. In both cases, the reward is a binary (sparse) signal — the agent either completes the task correctly or it doesn't.

Why this form: The binary reward structure mirrors the evaluation metrics used at test time (accuracy). It provides a clean, unambiguous training signal: the agent is optimised to maximise the probability of fully correct task completion, not partially correct completion. This is appropriate for tool-use tasks where partial correctness (calling some tools in the right order but failing to produce the correct final answer) is not useful in deployment. The alternative — dense rewards that give partial credit for intermediate steps — would be harder to design without introducing unintended incentives (e.g., the agent learning to maximise step-level scores without completing tasks).

Why two reward types: Graph-based tasks require rubric-based judging because their verification criteria are semantic (e.g., "does the returned list contain all and only the items matching the filter?") rather than purely executable. Programmatic tasks can use executable verification because their solutions are code that produces deterministic outputs. The paper uses the strongest verification available for each task type — rubrics for semantic checks, execution for computational checks.

Policy Update (GRPO)

The paper adopts Group Relative Policy Optimization (GRPO) (Shao et al., 2024) as the RL algorithm. The choice is motivated by GRPO's suitability for training with environment interaction — it directly maximises verifiable returns without requiring a separate value function (critic).

GRPO objective:

$J_{\text{GRPO}}(\theta) = \mathbb{E}_{x \sim D, \{y_i\}_{i=1}^G \sim \pi_{\theta_{\text{old}}}(\cdot|x)} \left[ \frac{1}{G} \sum_{i=1}^G \frac{1}{|y_i|} \sum_{t=1}^{|y_i|} \min\left( r_{i,t}(\theta) \hat{A}_{i,t}, \text{clip}(r_{i,t}(\theta), 1 - \epsilon, 1 + \epsilon) \hat{A}_{i,t} \right) - \beta D_{\text{KL}}(\pi_\theta \| \pi_{\text{ref}}) \right]$

Symbol definitions:

• x: a task sampled from the training dataset D
• G: the number of trajectories/outputs sampled per task (group size)
• y_i: the i-th model output in the group, including the interaction trajectory and final answer
• |y_i|: the length (number of tokens) of output y_i
• π_θ: the current policy (model being trained)
• π_{θ_{\text{old}}}: the behaviour policy from which trajectories were sampled (frozen during the update)
• π_{\text{ref}}: a reference policy (typically the initial SFT model) used for KL regularisation
• r_{i,t}(\theta) = π_θ(a_t | s_t) / π_{θ_{\text{old}}}(a_t | s_t): the importance sampling ratio — how much more (or less) likely the current policy is to take action a_t compared to the behaviour policy
• \hat{A}_{i,t}: the normalised advantage of the i-th rollout within the group at timestep t — measures how much better or worse this trajectory's outcome was compared to the group average
• ε: the clipping hyperparameter (controls how far the policy can deviate per update)
• β: the KL penalty coefficient (controls how strongly the policy is regularised toward the reference)
• D_{\text{KL}}(\pi_\theta \| \pi_{\text{ref}}): the Kullback-Leibler divergence between the current and reference policies

What it computes: For each task, G trajectories are sampled from the old policy. The advantage \hat{A}_{i,t} of each trajectory is computed relative to the group — trajectories that achieved higher reward than the group average get positive advantages, and vice versa. The objective then maximises the probability of actions that led to positive advantages while minimising the probability of actions that led to negative advantages. The min(·, clip(·)) construction implements a trust region: if the new policy would make an action much more or much less likely than the old policy (ratio outside [1-ε, 1+ε]), the gradient is clipped to zero for that action, preventing destructive large updates. The KL penalty term -β D_KL provides an additional regularisation force keeping the policy close to the reference model, preventing catastrophic forgetting of general language capabilities.

Why this form: GRPO is a variant of PPO (Proximal Policy Optimization) adapted for group-relative advantages. The key innovation over standard PPO is that advantages are computed within each group of trajectories for the same task rather than across the entire batch. This is important for tool-use tasks because the difficulty of different tasks varies enormously — a trajectory that gets reward 0 on a hard task might represent better behaviour than a trajectory that gets reward 1 on an easy task. Group-relative normalisation ensures that improvements on hard tasks are rewarded even if the absolute reward remains low, and that stagnation on easy tasks is penalised even if the absolute reward remains high.

Clipping hyperparameters: Section 4.1 specifies ε_low = 0.2 and ε_high = 0.28 — slightly asymmetric clipping that allows the policy to increase action probabilities slightly more aggressively than it decreases them. This follows prior work (Yu et al., 2025, DAPO). The KL penalty coefficient β is not explicitly stated in the paper but is part of the standard GRPO formulation.

Training initialisation: Before RL, a cold-start supervised fine-tuning (SFT) stage is performed using the same data-synthesis strategy as Agentic Environment-Task Discovery, where 40K trajectories are generated by an in-house Doubao-Seed-1.8 policy model. The Qwen3-8B/14B backbones are initialised from this SFT checkpoint before RL begins. This provides a reasonable starting policy that already has basic tool-use capabilities, allowing RL to focus on improvement rather than cold-start exploration.

---

Self-Evolving Agent Arena (Section 3.2.2)

This is the paper's key architectural innovation — the mechanism that closes the loop between evaluation and training. The arena is not a static benchmark but a dynamic diagnostic instrument that regenerates evaluation tasks each round, analyses failures from executable traces, and produces targeted guidelines that drive the next round of environment and task expansion.

Motivation (explicit from the paper): The environment ecosystem E "serves not only as a training source but also as an agentic diagnostic arena. Beyond synthesising training data, we aim to continuously identify weaknesses of the current agent policy and then expand environments and tasks in a targeted manner to close those gaps. This yields a self-reinforcing loop in which evaluation, diagnosis, and data generation evolve together with the agent."

Arena Construction

Based on the hierarchical environment taxonomy (20 first-tier categories), the arena is constructed by stratified sampling. For each first-tier category c ∈ C, K = 5 environments are randomly selected and merged into the arena set:

E_arena = {(D^{(N)}(m_i), F(m_i))}_{i=1}^{|E_arena|}

With 20 categories and 5 environments per category, |E_arena| = 100 environments. This design ensures broad coverage over different environment types while keeping evaluation cost controllable — evaluating on all 1,978 environments would be prohibitively expensive and unnecessary, since many environments within the same category share similar interaction patterns.

Why stratified sampling: Random sampling across all environments would risk over-representing categories with many environments (e.g., if "Database & Storage" has 200 environments and "E-commerce" has 50, random sampling would draw proportionally more from the larger category). Stratified sampling guarantees each category is represented equally, ensuring the diagnosis agent sees failures across all environment types.

Dynamic Evaluation Task Synthesis

For each arena environment, a fresh batch of verifiable tasks is synthesised at each iteration. Concretely, at iteration r, the task set X^{(r)}_arena(m_i) is instantiated for each arena environment, consisting of both graph-based tasks and programmatic tasks, each paired with an executable rubric R or verification code V_code. The full evaluation set is:

X^{(r)}_arena = ∪_i X^{(r)}_arena(m_i)

Why dynamic synthesis: Both the sampled environments and the synthesised tasks are dynamic across rounds. This prevents overfitting to a static evaluation — if the same tasks were used every round, the policy could memorise solutions rather than learning generalisable interaction strategies. Dynamic task synthesis ensures that each evaluation round tests genuine capability, not memorisation. It also means the diagnosis agent sees current failure patterns, not artefacts of stale tasks.

Agentic Diagnosis

Given a trained agent policy π_θ^{(r)} (the policy after r rounds of training), it is evaluated on the synthesised tasks X^{(r)}_arena under the agent-tool-database execution protocol. Task-level assessment is performed by the corresponding executable rubric R or verification code V_code.

The diagnosis agent δ: An auto-diagnosis agent, equipped with a Python interpreter and search tools, analyses failure patterns. The diagnosis agent receives three inputs:

1. Per-task failure traces: Tool logs, intermediate observations, and validator feedback for each failed task. These are the raw execution traces that show exactly where and how the agent went wrong.
2. Error distribution statistics: Aggregated statistics by environment and taxonomy category — which environments and categories have the highest failure rates.
3. Environment metadata: Tool schemas and database descriptions for each arena environment — providing context for interpreting failure traces.

Diagnosis outputs: The agent produces two structured outputs:

• (a) A ranked set of weak environments W^{(r)} ⊆ E_arena — the environments where the current policy performs worst.
• (b) Environment-specific task-generation guidelines G^{(r)}_guide(m) — characterisations of missing capabilities, such as erroneous tool use (calling tools in the wrong order, passing incorrect parameters) or state-update mistakes (failing to track how previous actions modified the database).

The diagnosis prompt (Appendix A): The full prompt template specifies that the diagnosis agent should (1) identify failure patterns by categorising each failure into root-cause types, (2) rank weak environments, and (3) generate targeted guidelines for each weak environment. The output is a structured JSON diagnosis report. The prompt template includes placeholders for the model name, evaluation protocol, total instances, pass rate, error distribution by environment, and per-task failure traces with tool schemas, conversation history, evaluation results, and execution statistics.

Why agentic diagnosis rather than rule-based: Rule-based diagnosis (e.g., "if the agent called create_order after get_order_details, flag as ordering error") would require manually specifying failure patterns for every tool in every environment — exactly the kind of manual engineering the system is designed to avoid. Agentic diagnosis uses the LLM's reasoning capabilities to identify patterns from raw traces, generalising across environments without per-environment rules.

Agent-Environment Co-Evolution

Conditioned on the weak environments W^{(r)} and task-generation guidelines G^{(r)}_guide, the verifiable task synthesis pipeline (Section 3.1.1) is re-run to generate a targeted training set X^{(r)}_target. When the weakness is due to insufficient state diversity, environment expansion via database complexification (φ) is also applied to enrich the databases in weak environments.

Starting from π_θ^{(r)}, multi-environment agent RL (Section 3.2.1) is performed on the augmented data to obtain an improved policy π_θ^{(r+1)}. The full loop:

π_θ^{(r)} → [evaluate] → W^{(r)} → [diagnose+target] → X^{(r)}_target → [continue RL] → π_θ^{(r+1)}

Algorithm 1 (Self-Evolving Agent Arena Loop) formalises this as pseudocode:

1. For r = 0, ..., R-1:
   • Phase 1 — Dynamic Evaluation: For each arena environment, synthesise fresh verifiable tasks. Evaluate π_θ^{(r)} on X^{(r)}_arena under agent-tool-database execution.
   • Phase 2 — Agentic Diagnosis: Input failure traces, error statistics, and metadata to the diagnosis agent δ. Output weak environments W^{(r)} and task-generation guidelines G^{(r)}_guide(m).
   • Phase 3 — Co-Evolution: For each weak environment, complexify the database and generate targeted tasks conditioned on the guidelines. Define X^{(r)}_target as the union. Continue RL on X^{(r)}_target to obtain π_θ^{(r+1)}.

Empirical results (Table 2, Section 4.3.4): Running two rounds of this loop from the Agent-World-14B base model yields:

The largest gains appear on MCP-Mark (+8.6 over two rounds), which the paper attributes to the benchmark's requirement for "stronger state tracking and deeper interaction with realistic MCP server environments" — precisely the kind of capability that targeted diagnosis and expansion addresses. Second-round gains are smaller than first-round gains but remain positive, reflecting "diminishing yet still effective returns." The paper hypothesises that "early rounds mainly fix pattern-level errors in unfamiliar environment interactions, while later rounds focus on residual failures, especially in long-horizon complex interaction cases."

Cross-method validation: Importantly, the same self-evolving loop applied to the EnvScaler-8B baseline (not initialised from Agent-World) also yields monotonic gains: τ2-Bench improves from 37.9% to 41.6%, BFCL-V4 from 47.6% to 50.0%, and MCP-Mark from 9.5% to 15.1%. This demonstrates that the self-evolving mechanism is not specific to Agent-World's initialisation — it provides value as a general training strategy that can be applied to other environment-scaling methods.

Why this loop works: The diagnosis-driven expansion creates a curriculum that is automatically tailored to the agent's current weaknesses. Rather than uniformly generating more environments and tasks (which would waste compute on capabilities the agent already has), it concentrates expansion on the specific interaction patterns, environment types, and failure modes that the current policy struggles with. This is more compute-efficient than uniform scaling and ensures that training resources are allocated where they provide the largest marginal improvement.

A subtle design choice — separate arena and training environments: The arena environments E_arena are a held-out subset of the full ecosystem E. The agent is never trained on arena environments directly — training tasks are synthesised from other environments in E \ E_arena. The arena is used only for diagnosis. This separation ensures that evaluation is genuinely out-of-distribution relative to training, providing an honest signal of capability gaps. If the same environments were used for both training and diagnosis, the agent might appear to improve simply by memorising environment-specific patterns rather than acquiring transferable skills.

4. Key Insights and Innovations

Innovation 1: Diagnosis-Driven Environment Co-Evolution as a Training Paradigm

The paper's most fundamental contribution is not a new RL algorithm or environment generator, but a conceptual reframing of what environment scaling means for agent training. Prior work — including EnvScaler, AWM, AutoForge, and InfiniteWeb — treated environment scaling as a data generation problem: use LLMs to produce more environments, train the agent on them, and hope coverage improves. The implicit assumption was that diversity alone drives capability gains, and that the relationship between environment count and agent performance is roughly monotonic with diminishing returns at scale.

Agent-World challenges this assumption at a fundamental level. The paper demonstrates that what environments you add matters enormously — and that the most efficient way to determine what to add is to diagnose the agent's current failures and target expansion accordingly. This is not a minor scheduling tweak; it is a shift from passive scaling (generate more, train on everything) to active curriculum design (diagnose gaps, generate targeted tasks, repeat). The self-evolving arena (Section 3.2.2) is the embodiment of this shift: it closes the loop between evaluation and environment synthesis, turning scalable environments from a static training corpus into a dynamic diagnostic instrument.

Prior work comparison: EnvScaler and AWM both demonstrate that training on programmatically synthesised environments improves agent performance, but their training paradigm is single-round: generate environments → train → evaluate → done. The paper explicitly identifies this as a limitation (Section 1: "their reliance on single-round training makes it difficult for agents to acquire robust, transferable interaction logic"). Agent-World's innovation is showing that the second round — and the mechanism that decides what goes into it — provides gains comparable to or exceeding the first round on challenging benchmarks. Table 2 provides the evidence: Agent-World-14B improves on MCP-Mark from 29.5% to 36.3% in the first evolution round (+6.8 points) and from 36.3% to 38.1% in the second (+1.8 points). The first-round gain alone is larger than the gap between many environment-scaling baselines and their backbones in Table 1.

Why this is fundamental rather than incremental: The diagnosis-driven co-evolution loop is not just an optimisation of existing environment-scaling methods — it redefines the relationship between environments and training. In the static paradigm, environments are inputs to a fixed training procedure. In Agent-World, environments are co-evolving partners that adapt to the agent's developmental trajectory. This mirrors how curricula work in human education (diagnose what a student struggles with, design targeted exercises) but automated through an agentic diagnosis pipeline. The paper also provides cross-method evidence that this paradigm generalises: the same self-evolving loop applied to the EnvScaler-8B baseline (Table 2) yields gains of +2.3 on τ2-Bench, +1.5 on BFCL-V4, and +4.4 on MCP-Mark in the first round. This demonstrates that the benefit of diagnosis-driven expansion is not tied to Agent-World's specific environment synthesis pipeline — it is a general training strategy that could be applied to any scalable environment framework.

What makes it intellectually distinctive: The paper frames environment scaling not as a data quantity problem but as an exploration-exploitation problem in curriculum space. The arena evaluation phase explores the agent's capability landscape across diverse environment types, the diagnosis phase exploits the failure signal to identify high-value expansion targets, and the targeted synthesis phase exploits the environment generation pipeline to produce training data concentrated on those targets. This framing — that the environment ecosystem itself should be treated as a resource to allocate adaptively rather than uniformly — is what distinguishes Agent-World from prior work.

---

Innovation 2: Real-World Anchoring as a First-Class Design Principle in Environment Synthesis

A second distinctive contribution is the paper's systematic argument for — and implementation of — real-world anchoring as the primary design principle for scalable environment synthesis. The paper makes a specific, falsifiable claim: that environments synthesised from web-mined real-world data produce better training outcomes than environments generated purely by LLMs from descriptions. This is not obvious a priori — LLMs can generate plausible database schemas and tool interfaces for any described domain — but the paper argues that plausibility and realism diverge in ways that matter for agent training.

The anchoring strategy operates at three levels:

1. Theme anchoring: Environment themes are sourced from real MCP server specifications (Smithery), real tool documentation datasets, and real industrial PRDs — not from LLM-generated domain descriptions. This means the vocabulary of environments (what tools are called, what parameters they take, what workflows they support) mirrors deployed systems rather than LLM-imagined ones.

2. Data anchoring: Databases are mined from the web using a deep-research agent that searches for, extracts, and structures real-world data — not generated by prompting an LLM to "create a database of hotels" or "generate email records." The paper argues explicitly that "the World Wide Web already contains abundant, high-value structured data that can be updated in real time" and that this provides "realism by construction" — real data distributions, real edge cases, real noise — that synthetic data smooths over.

3. Verification anchoring: Tool interfaces are validated through execution-based cross-validation against unit tests (Section 3.1, "Tool Interface Generation and Verification") rather than accepted on the basis of syntactic correctness alone. The retention filter requires that tools pass more than 50% of their test cases and compile successfully, creating a quality floor enforced by actual execution.

Prior work comparison: LLM-driven environment simulators (Web World Models, SimWorld, GenEnv) use the LLM itself as the source of environmental dynamics — the LLM simulates what a tool would return, what state transitions would occur, what errors would arise. The paper's critique is specific: "such simulators are vulnerable to hallucinations and often deviate from real-world dynamics" (Section 1). Programmatic synthesis methods (EnvScaler, AWM) improve on this by generating executable code and databases, but the databases themselves are typically LLM-generated — statistically plausible but potentially missing the distributional properties of real data. Agent-World's web-mining approach is the most aggressive form of anchoring among these methods: it sources data from the actual web rather than from the LLM's training distribution memory.

Evidence for the anchoring claim: The paper provides circumstantial rather than direct ablation evidence (there is no head-to-head comparison of web-mined vs. LLM-generated databases with all else held equal). However, several results are consistent with the anchoring hypothesis:

• Simulator-8B, which uses LLM-simulated environments, "performed poorly on MCP-Mark and BFCL V4, suggesting that simulated environments are insufficient to capture complex real-world state transitions" (Section 4.2, Finding 2). This supports the claim that simulation realism matters for stateful benchmarks.
• Agent-World's consistent cross-benchmark improvements over EnvScaler and AWM (Table 1) — both of which use LLM-generated databases — are consistent with the hypothesis that real-world data anchoring provides additional transfer benefits, though this confounds multiple design differences.
• The diversity of database file types (Figure 4d: JSON, CSV, SQL, HTML, TEX, YAML) reflects real-world heterogeneity that would be unlikely to emerge from LLM generation alone.

Why this is a conceptual contribution: The anchoring principle shifts the evaluation criterion for environment synthesis from "does the environment look realistic?" to "does the environment behave like a real deployed system?" The distinction is subtle but consequential: an LLM-generated hotel booking database might contain plausible hotel names, prices, and amenities, but it might miss the correlation between star rating and price range, the geographic clustering of certain amenity types, or the realistic distribution of booking dates — all of which affect the reasoning patterns agents need to learn. Real web-mined data preserves these correlations naturally, without requiring the synthesis pipeline to explicitly model them.

---

Innovation 3: The Separation of Task Synthesis into Graph-Based and Programmatic Strategies as a Coverage Principle

The paper's decomposition of task synthesis into two complementary strategies — graph-based for sequential dependencies and programmatic for non-linear control flow — may appear at first glance to be an implementation detail. It is, in fact, a coverage principle with implications for what kinds of agent capabilities can be trained and evaluated.

What makes this distinctive: Most prior environment-scaling work generates tasks through a single mechanism — typically by prompting an LLM to produce a task description given an environment specification, sometimes with additional filtering for executability. The resulting task distribution is determined by whatever the LLM tends to produce, which may over-represent simple, linear workflows and under-represent tasks requiring conditional branching, iteration, or multi-step state-dependent reasoning. The paper's dual-strategy approach is a deliberate attempt to ensure coverage of both sequential reasoning patterns and programmatic reasoning patterns, recognising that they are fundamentally different cognitive demands on the agent.

Graph-based synthesis captures the reasoning pattern "do A, then use A's output to do B, then use B's output to do C." This is the most natural pattern for tool-use tasks, and it is likely what LLMs would predominantly generate if asked to produce task descriptions. The weighted tool graph (strong/weak/independent edges with weights 3/2/1) provides a formal mechanism for controlling the realism of the generated sequences — strong dependencies produce natural tool chains, while weaker edges inject diversity by allowing less obvious tool combinations. The random walk abstraction ensures that the generated tool sequences are executable (since edges encode actual parameter dependencies) while allowing controllable diversity through edge weight biasing.

Programmatic synthesis captures reasoning patterns that cannot be expressed as linear tool sequences: "if the user's order total exceeds $100 and they have a loyalty membership, apply a 10% discount; otherwise, check for seasonal promotions; then aggregate results across all product categories." These patterns require the agent to plan code-level logic (conditionals, loops, aggregations) that orchestrates multiple tool calls, rather than simply deciding which tool to call next. The paper argues that "traditional string-matching evaluation falls short for complex programmatic tasks" — and the verification script V_code addresses this by programmatically checking not just the final answer but the resulting database state.

Why this matters beyond implementation: The dual-strategy decomposition is a taxonomy of agent capabilities. An agent that excels at graph-based tasks but fails at programmatic tasks has learned sequential tool chaining but not computational reasoning over tool outputs. An agent that excels at programmatic tasks but fails at long-horizon graph-based tasks has learned algorithmic thinking but not multi-step state tracking. The paper does not report per-strategy performance breakdowns (a notable omission), but the existence of the decomposition means that future work can diagnose which kind of reasoning an agent struggles with and target expansion accordingly — which is precisely what the self-evolving arena's diagnosis agent is designed to do.

Connection to the difficulty scaling results: Figure 4f shows that tasks are challenging even for Doubao-Seed-2.0-pro (most solved only 1/10, some never solved), but does not break this down by synthesis strategy. A natural hypothesis — untested in the paper — is that programmatic tasks are harder on average because they require both tool orchestration and computational reasoning, while graph-based tasks primarily stress the former. If true, the dual-strategy design provides a mechanism for difficulty control orthogonal to step count: easier tasks use graph-based synthesis with short tool chains and strong dependencies; harder tasks use programmatic synthesis with multiple tools, conditional logic, and aggregation requirements.

Significance: This is an incremental rather than fundamental contribution — the idea of using multiple task generation strategies for coverage is not novel in itself. But within the specific context of agent environment scaling, where prior work has largely used monolithic task generation pipelines, the explicit decomposition into sequential and programmatic reasoning patterns represents a useful conceptual framework for thinking about what agents need to learn and how to test whether they've learned it.

---

Innovation 4: Executable Verification as a Bridge Between Training Signal Quality and Task Complexity

The paper's reward design — binary rewards computed from rubrics (for graph-based tasks) or execution of verification scripts (for programmatic tasks) — appears straightforward, but it encodes a non-obvious design principle: that verification mechanism and task synthesis strategy should be co-designed such that task complexity can scale without degrading reward signal quality.

The problem this solves: In reinforcement learning for language agents, reward design is typically the bottleneck. Sparse binary rewards (correct/incorrect) provide clean signal but make exploration difficult. Dense rewards (partial credit for intermediate steps) ease exploration but risk reward hacking — the agent learns to maximise the proxy rather than the true objective. LLM-based reward models (using another LLM to score outputs) scale well but introduce hallucination and calibration issues. The paper does not choose among these — it structures the task synthesis pipeline so that the appropriate reward type is determined by the task structure.

• Graph-based tasks use rubric-conditioned LLM judging. This is appropriate because the verification criteria for sequential tasks are often semantic (e.g., "does the returned list include all items matching the filter?") and hard to encode programmatically. The rubric decomposes verification into atomic, checkable criteria, reducing the hallucination surface compared to holistic LLM judging.
• Programmatic tasks use executable verification scripts. This is appropriate because the solution involves code-level operations whose correctness can be determined by re-execution. The verification script checks both the answer and the database state, providing a stronger guarantee than output matching alone.

Prior work comparison: Most agent RL work uses one of the approaches mentioned above — sparse rewards (ToolRL, Search-R1), LLM judges (various preference optimisation methods), or rule-based rewards (EnvScaler, AWM). The paper's contribution is not any single reward type but the co-design principle: the task synthesis strategy determines what kind of ground truth is available (execution trace for graph-based, solution code for programmatic), and the reward mechanism is matched to that ground truth type. This allows tasks to scale in complexity — longer tool chains, more complex control flow — without the reward signal degrading, because the verification mechanism is structurally aligned with the task structure.

Why this matters for the field: As agent tasks become more complex and long-horizon, reward design becomes increasingly challenging. The paper's co-design principle suggests a path forward: rather than trying to build a universal reward model that works for all task types, design task synthesis pipelines that produce verifiable ground truth as a byproduct of task generation. The graph-based pipeline produces rubrics because the tool sequence is known; the programmatic pipeline produces verification scripts because the solution code is known. This is a form of reward-by-construction that sidesteps the reward design problem by embedding verification into synthesis.

Evidence: The training dynamics (Figure 9) show stable reward improvement and entropy maintenance for both the 8B and 14B backbones, suggesting the reward signal is sufficiently clean to drive policy improvement without collapse. The paper does not provide an ablation comparing rubric-based vs. holistic LLM judging or executable vs. string-matching verification, so the benefit of the co-design principle relative to alternatives is not directly quantified. This is a limitation, but the principle itself — that task synthesis and verification should be structurally coupled — is a useful conceptual contribution even without a direct ablation.

Significance assessment: This is an incremental contribution at the implementation level (reward design is a standard RL concern) but a useful articulation of a design philosophy that prior agent-scaling work has not made explicit. The paper's demonstration that both reward types can coexist within a single training framework — with graph-based and programmatic tasks mixed in training batches — is a practical validation that the co-design principle is implementable at scale.

5. Experimental Analysis

Evaluation Methodology

• Datasets. The primary evaluation uses three core agentic tool-use benchmark suites: MCP-Mark (106, covering five subdomains: File, GitHub, Notion, Play, and Postgres), BFCL V4 (73, covering WebSearch, Memory, Multi-Turn, No Live, Live, Relevant, and Irrelevant splits), and τ2-Bench (7, covering Retail, Telecom, and Airline domains). An additional 17 benchmarks are used for long-horizon generalization analysis (Figure 6), spanning General Reasoning (MATH500, GSM8K, MATH, AIME24, AIME25, KOR-Bench Cipher, OlympiadBench), Agentic Search & Coding (WebWalkerQA, SWE-Bench Verified, SWE-bench Multilingual, Terminal-Bench 1.0, Terminal-Bench 2.0, GAIA, HLE), and Knowledge & MCP (MMLU, SuperGPQA, MCP-Universe five sub-domains). Three advanced AI assistant benchmarks (SkillsBench, ARC-AGI-2, ClawEval) are evaluated separately (Figure 7). Following prior work (20, 21, 43, 48, 50), sampled subsets are used for some benchmarks (e.g., GAIA and HLE) to accelerate evaluation.

• Base model(s). The primary training backbones are Qwen3-8B and Qwen3-14B (114), initialised from a cold-start supervised fine-tuning stage using 40K trajectories generated by an in-house Doubao-Seed-1.8 policy model (82). These model sizes are chosen to sit in a regime where environment-scaling methods can demonstrate clear gains over base capabilities while remaining computationally tractable for the multi-round self-evolving training loop. For the environment mining and task synthesis stages, GPT-OSS-120B (70) serves as the policy model. For baseline comparisons, the paper evaluates frontier proprietary models (GPT-5.2 High, Claude Sonnet-4.5, Gemini-3 Pro, Seed 2.0) and open-source foundation models spanning 8B to 685B parameters (DeepSeek-V3.2-685B, GPT-OSS-120B, Qwen3-235B-A22B, Qwen3-8B/14B/32B).

• Metrics. Accuracy (%) is the primary metric across all benchmarks, computed as the fraction of test instances where the agent's final answer or action sequence matches the ground truth. For graph-based tasks, a rubric-conditioned LLM judge evaluates per-criterion pass/fail with strict binary grading. For programmatic tasks, an executable verification script programmatically validates both the answer and the resulting database state. Each experiment is repeated eight times and average accuracy is reported to reduce random variance. For the training dynamics analysis (Figure 9), training reward score and actor entropy are tracked over steps, with curves exponentially smoothed for clarity.

• Baselines. The paper compares against three groups. Frontier Proprietary Models: GPT-5.2 High (69), Claude Sonnet-4.5 (4), Gemini-3 Pro (23), and Seed 2.0 (8). Open-Source Foundation Models (8B–685B): DeepSeek-V3.2-685B (58), GPT-OSS-120B (70), Qwen3-235B-A22B (114), and Qwen3-8B/14B/32B (114). Open-Source Environment Scaling Methods (7B–14B): Simulator-8B (54), which uses LLM-driven environment simulation; TOUCAN-7B (113), which synthesises tool-agentic data from real MCP environments; EnvScaler-8B (89), which uses programmatic environment synthesis; AWM-8B and AWM-14B (100), which build agent world models for synthetic environment generation; and ScaleEnv-8B (98), which scales environment synthesis from scratch for interactive tool-use training. All baselines and benchmarks are evaluated using the same in-house evaluation framework with results aligned to official scores.

• Generation budget / compute accounting. In the RL training stage (Section 4.1), each training step samples 32 tasks and performs 8 rollouts per task (so group size G = 8), with decoding at temperature = 1.0 and top_p = 1.0. The maximum trajectory length is 80K tokens, with a 32K token cap per generation step. For the environment scaling analysis (Section 4.3.3), environments are progressively increased from 0 to 10, 100, 500, 1000, and 1978, with models evaluated at each scale. For the self-evolution analysis (Section 4.3.4), two rounds of the arena loop are run, with each round involving fresh task synthesis, evaluation, diagnosis, and targeted data expansion followed by continued RL. Evaluation uses temperature = 1.0 and top_p = 1.0.

• Cross-validation / statistical protocol. The paper does not describe a formal cross-validation procedure for the main benchmark evaluations. For the environment taxonomy construction (Section 3.1), three annotators cross-validate and merge second-tier labels into 20 first-tier types through discussion. For task quality verification, each synthesised task is evaluated by deploying a ReAct agent to solve it 5 separate times within the sandbox, and the task is retained only if the agent successfully reaches a consistent answer in at least two independent runs. Each experiment in the main results is repeated eight times with average accuracy reported.

Main Quantitative Results

Core Agentic Tool-Use Benchmarks

The main results are presented in Table 1, covering MCP-Mark, BFCL V4, and τ2-Bench. The headline finding is that Agent-World consistently outperforms all existing environment-scaling baselines across all three benchmark suites, with Agent-World-14B achieving the strongest results.

Frontier proprietary models remain limited in complex agentic tool-use scenarios. Table 1 shows that even the strongest proprietary models struggle on MCP-Mark: GPT-5.2 High achieves 53.1%, Seed 2.0 achieves 54.7%, while Claude Sonnet-4.5 reaches only 33.3% and Gemini-3 Pro reaches 50.8%. On BFCL V4, performance varies significantly by subdomain — GPT-5.2 High achieves 75.5% on WebSearch but only 45.8% on Memory and 48.5% on Multi-Turn. On τ2-Bench, the best proprietary models reach the low-to-mid 80s (Gemini-3 Pro at 85.4%, Claude Sonnet-4.5 at 84.7%), suggesting this benchmark is more tractable for current frontier models. The overall picture is one of uneven capability: proprietary models do well on some domains but show clear weaknesses on others, particularly those requiring multi-turn state tracking and tool orchestration.

Open-source foundation models are substantially weaker out-of-the-box. Table 1 reveals a dramatic capability gap: GPT-OSS-120B scores only 4.7% on MCP-Mark and 55.0% average on τ2-Bench. Qwen3-8B scores 2.4% on MCP-Mark, 40.4% average on BFCL V4, and 26.2% average on τ2-Bench. Qwen3-32B improves to 7.5% on MCP-Mark and 46.7% on BFCL V4, but still substantially lags proprietary models. Even DeepSeek-V3.2-685B, at 685B parameters, achieves only 36.7% on MCP-Mark and 54.1% on BFCL V4. These results establish that the base models have significant room for improvement through environment-scaling training.

Existing environment-scaling methods produce uneven gains that are environment-specific. Table 1 shows that Simulator-8B achieves 0.0% on MCP-Mark subdomains except Play (4.0%) and Postgres (4.8%), and 23.9% average on BFCL V4 — essentially matching its Qwen3-8B backbone (2.4% MCP-Mark, 40.4% BFCL V4) on some measures while underperforming on others. TOUCAN-7B scores 1.0% on MCP-Mark and 36.6% average on BFCL V4. EnvScaler-8B shows more consistent gains, reaching 5.6% on MCP-Mark and 47.6% on BFCL V4, but still shows clear weaknesses: 0.0% on MCP-Mark (Notion), 4.4% on MCP-Mark (GitHub), and only 9.5% on MCP-Mark (Postgres). AWM-8B and AWM-14B follow similar patterns — improvements on some subdomains but negligible or zero scores on others (MCP-Mark GitHub: 0.0% for AWM-8B, 8.7% for AWM-14B; MCP-Mark Notion: 0.0% for both). ScaleEnv-8B is evaluated only on τ2-Bench, where it achieves 38.5% average. These results validate the paper's central critique: environment-scaling alone, without targeted diagnosis and expansion, leaves capability gaps unaddressed.

Agent-World achieves more consistent cross-environment generalization. Table 1 shows Agent-World-8B reaching 8.9% on MCP-Mark (vs. 5.6% for the next-best EnvScaler-8B), 51.4% average on BFCL V4 (vs. 47.6% for EnvScaler-8B), and 61.8% average on τ2-Bench (vs. 38.5% for ScaleEnv-8B). Agent-World-14B further improves to 13.3% on MCP-Mark, 55.8% average on BFCL V4, and 65.4% average on τ2-Bench. On BFCL V4, Agent-World-14B (55.8%) surpasses DeepSeek-V3.2-685B (54.1%), which has roughly 49× more parameters. The gains are most pronounced on the most challenging subdomains: MCP-Mark Postgres improves from 4.8% (Qwen3-8B) to 19.1% (Agent-World-8B) to 38.1% (Agent-World-14B). The paper attributes this to "its unified framework, which tightly integrates scalable environment-task discovery with continuous self-evolving agent training."

Generalization on Long-Horizon Agentic Reasoning Scenarios

Figure 6 presents results across 17 additional benchmarks organised into three capability groups: General Reasoning, Agentic Search & Coding, and Knowledge & MCP. Agent-World-8B is compared against Qwen3-8B (backbone) and EnvScaler-8B (strongest environment-scaling baseline).

Agent-World strengthens agentic behaviour while preserving general reasoning. On the General Reasoning axis (MATH500, GSM8K, MATH, AIME24, AIME25, KOR-Bench, OlympiadBench), Agent-World-8B achieves the best overall profile with clear gains on most dimensions and no degradation on core math reasoning. Specific numbers are reported via radar chart in Figure 6, where Agent-World-8B's polygon consistently encloses or matches the Qwen3-8B and EnvScaler-8B polygons across all seven benchmarks. This is significant because it demonstrates that environment-scaling training — which focuses on tool-use and state-tracking skills — does not cause catastrophic forgetting of general reasoning capabilities.

The largest gains are in long-horizon search and coding tasks. On Agentic Search & Coding (WebWalkerQA, SWE-bench Verified, SWE-bench Multilingual, Terminal 1.0, Terminal 2.0, GAIA, HLE), Figure 6 shows Agent-World-8B consistently outperforming both baselines. These benchmarks stress iterative planning, long-horizon software engineering, deep information retrieval, and multi-tool coordination. Notably, EnvScaler-8B underperforms its Qwen3-8B backbone on SWE-bench and Terminal 1.0, suggesting that its environment expansion may be less effective at eliciting complex software-engineering reasoning patterns — a finding that supports the paper's argument for diagnosis-driven targeted expansion rather than uniform environment generation.

Agent-World shows stronger robustness in heterogeneous knowledge and MCP environments. On Knowledge & MCP (MMLU, SuperGPQA, and five MCP-Universe sub-domains: Browser Automation, Web Searching, Location Navigation, Repository Management, Financial Analysis), Figure 6 shows Agent-World-8B substantially outperforming baselines. The MCP-Universe results are particularly notable because these sub-domains were not part of the training environment taxonomy — they test transfer to unseen MCP server types, validating that Agent-World's training produces generalisable interaction strategies rather than domain-specific memorisation.

Generalization on Agentic AI Assistant Scenarios

Figure 7 evaluates Agent-World-8B and 14B against Qwen3, EnvScaler, and AWM baselines on three advanced AI assistant benchmarks: SkillsBench, ARC-AGI-2, and ClawEval.

Existing open-source baselines struggle in real-world AI assistant settings. Figure 7 shows most baseline models obtaining average scores below 20% across the three benchmarks, with inconsistent scaling trends. Qwen3 drops on ClawEval from 25.6% (8B) to 24.7% (14B). AWM shows uneven improvements across tasks. The paper interprets this as evidence that "naive parameter scaling alone is insufficient for stable long-horizon agentic generalization."

Agent-World generalizes strongly to unseen advanced assistant domains. At 8B, Agent-World achieves 9.2% on SkillsBench, 6.5% on ARC-AGI-2, and 30.5% on ClawEval, surpassing Qwen3-8B, EnvScaler-8B, and AWM-8B across all three tasks. The paper emphasises that this is achieved "without benchmark-specific training," meaning the agent's capabilities transfer from the general environment-scaling training to these specific assistant benchmarks.

Agent-World exhibits stable cross-scale gains. Unlike the unstable scaling trends of several baselines, Agent-World improves consistently from 8B to 14B: SkillsBench 9.2% → 12.6%, ARC-AGI-2 6.5% → 8.5%, ClawEval 30.5% → 31.5%. The paper argues this "supports that our method remains effective across parameter scales and transfers robustly to complex, integrated assistant scenarios."

Scaling Analysis of Training Environments

Figure 8 analyses how the number of synthesised training environments affects downstream agentic tool-use performance. Environments are progressively increased from 0 to 10, 100, 500, 1000, and 1978, with models evaluated on four representative domains: MCP-Mark (Postgres), BFCL (WebSearch), BFCL (Multi-Turn), and τ2-Bench (Airline).

Performance improves consistently as environment scale grows. Averaged over the four domains, the score rises from 18.4% (0 environments, bare Qwen3-8B) to 38.5% (1978 environments), a gain of +20.1 percentage points — more than doubling the initial level.

The gains exhibit stage-wise patterns. Performance jumps markedly from 10 to 100 environments, and again from 100 to 500. MCP-Mark (Postgres) improves from 4.8% to 19.9% across this range, while BFCL (WebSearch) increases from 7.0% to 47.0%. BFCL (Multi-Turn) and τ2-Bench (Airline) also improve steadily. The paper interprets this as evidence that "moderate-scale expansion rapidly improves coverage of critical interaction patterns."

From 500 to 2000 environments, marginal improvement gradually decreases but remains positive, indicating "diminishing-yet-positive returns at larger scales." The paper argues this suggests "early expansion mainly captures missing high-impact environment diversity, while later expansion contributes finer-grained robustness gains." This finding contextualises the self-evolving arena's value proposition: if uniform scaling yields diminishing returns, targeted expansion to address diagnosed gaps may provide more efficient improvement than simply adding more random environments.

Effect of Continuous Self-Evolution

Table 2 reports the effect of running the self-evolving arena loop (Section 3.2.2) from two different starting points: Agent-World-14B and the EnvScaler-8B base model. Two evolution rounds are run for each.

Monotonic gains across all evaluation suites for both models. For Agent-World-14B: τ2-Bench improves from 60.2% (base) → 63.5% (+3.3, round 1) → 65.4% (+1.9, round 2). BFCL-V4 improves from 52.4% → 54.9% (+2.5) → 55.8% (+0.9). MCP-Mark (Postgres) shows the largest gains: 29.5% → 36.3% (+6.8) → 38.1% (+1.8). For EnvScaler-8B: τ2-Bench improves from 37.9% → 40.2% (+2.3) → 41.6% (+1.4). BFCL-V4 improves from 47.6% → 49.1% (+1.5) → 50.0% (+0.9). MCP-Mark (Postgres) improves from 9.5% → 13.9% (+4.4) → 15.1% (+1.2).

The largest gains appear on MCP-Mark. Agent-World-14B gains +8.6 points over two rounds on MCP-Mark (Postgres), compared to +3.4 on BFCL-V4 and +5.2 on τ2-Bench. The paper attributes this to MCP-Mark's requirement for "stronger state tracking and deeper interaction with realistic MCP server environments" — precisely the capabilities that diagnosis-driven targeted expansion addresses by identifying and remediating state-tracking errors and environment-specific interaction failures.

Second-round gains are smaller than first-round gains but remain positive, reflecting "diminishing yet still effective returns." The paper hypothesises that "early rounds mainly fix pattern-level errors in unfamiliar environment interactions, while later rounds focus on residual failures, especially in long-horizon complex interaction cases."

The loop benefits other environment-scaling methods, not just Agent-World. EnvScaler-8B's gains of +2.3/+1.5/+4.4 on τ2-Bench/BFCL-V4/MCP-Mark in the first round demonstrate that the self-evolving mechanism is a general training strategy, not dependent on Agent-World's specific environment synthesis pipeline.

Training Dynamics of Agent-World

Figure 9 presents the multi-environment reinforcement learning curves for Agent-World-8B and Agent-World-14B, tracking training reward score (a) and actor entropy (b) over approximately 300 training steps.

Clear upward reward trends for both backbones. Figure 9a shows training reward score increasing from approximately 0.2 to approximately 0.6–0.7 for both the 8B and 14B backbones over the course of training, with the 14B curve tracking slightly above the 8B curve. The curves are exponentially smoothed. The paper notes that policy performance "improves steadily under GRPO supervision" and that this trend is "consistent across different environment complexities."

Stable entropy growth over time. Figure 9b shows actor entropy increasing from approximately 0.10–0.15 to approximately 0.30–0.40 over the training steps. The paper interprets this as evidence that "as the model gradually adapts to unseen APIs and heterogeneous state transitions, it maintains or even expands its exploration space, learning new interaction patterns instead of collapsing prematurely into narrow exploitation." This behaviour is significant because entropy collapse is a known failure mode in RL fine-tuning of LLMs — the fact that entropy increases suggests the multi-environment rollout design successfully sustains exploration despite the policy becoming more capable.

Ablation Studies and Robustness Checks

The paper includes several analyses that function as ablations or robustness checks, though they are not labelled as formal ablation studies in a dedicated section. I identify and describe them here.

Difficulty scaling validation (Figure 4f). To verify that the difficulty scaling strategies produce genuinely challenging tasks, the paper evaluates synthesised tasks under Pass@10 using Doubao-Seed-2.0-pro, a strong proprietary model. The result: only a small fraction of tasks are solved in all 10 attempts; most are solved only once out of 10; some are not solved at all. This validates that difficulty scaling is effective and that the tasks would not be trivially solved by a strong model without specialised training.

Task quality consistency protocol (Section 3.1.1). Each synthesised task is validated by deploying a ReAct agent to solve it 5 times. The task is retained only if the agent succeeds at least twice. This filters out impossibly hard tasks and ambiguous or underspecified tasks, ensuring that the training set consists of challenging-but-solvable instances.

Tool verification with cross-validation (Section 3.1). Each candidate tool must pass three retention filters: successful Python compilation, >50% test case pass rate, and at least one valid tool and test case per environment. This is a quality control ablation embedded in the synthesis pipeline rather than reported separately. The paper does not report what fraction of candidate tools pass these filters, which would be informative about the reliability of the tool generation process.

Self-evolving loop applied to a non-Agent-World baseline (Table 2). The EnvScaler-8B row in Table 2 serves as a cross-method robustness check: the self-evolving loop produces gains (+2.3/+1.5/+4.4 in round 1 on τ2-Bench/BFCL-V4/MCP-Mark) even when applied to a model not initialised from Agent-World's environment ecosystem. This demonstrates that the diagnosis-driven targeted expansion mechanism is not an artefact of Agent-World's specific environments but a general training strategy.

Dynamic vs. static evaluation (Section 3.2.2). The arena dynamically resynthesises evaluation tasks each round, preventing overfitting to a static test set. This is a design choice rather than an ablation, but its motivation is to ensure that evaluation scores reflect genuine capability rather than memorisation. The paper does not compare dynamic vs. static evaluation directly, so the benefit of dynamic resynthesis is argued on principle rather than demonstrated empirically.

Models at two scales (8B and 14B). The paper evaluates Agent-World at both 8B and 14B parameter scales (Table 1, Figure 7, Figure 9), showing consistent gains at both scales with 14B outperforming 8B as expected. This provides evidence that the method scales with model size, though only two sizes are tested.

Critical Assessment

The experimental results in this paper are extensive — 23 benchmarks, multiple baselines, two model scales, scaling curves, and self-evolution rounds — and they broadly support the paper's central claims. However, several important caveats limit the strength of the conclusions that can be drawn. I examine each major claim in turn.

Claim: "Agent-World consistently outperforms strong proprietary models and environment scaling baselines." The evidence for outperforming environment-scaling baselines (EnvScaler, AWM, Simulator, TOUCAN, ScaleEnv) is strong across the three core benchmarks (Table 1). Agent-World-8B and 14B show consistent and sometimes substantial gains over these methods on MCP-Mark, BFCL V4, and τ2-Bench. The evidence for outperforming proprietary models is more qualified. Agent-World-14B achieves 65.4% on τ2-Bench, which is competitive with but below the best proprietary models (Gemini-3 Pro: 85.4%, Claude Sonnet-4.5: 84.7%, Seed 2.0: 83.0%). On BFCL V4, Agent-World-14B (55.8%) is competitive with DeepSeek-V3.2-685B (54.1%) but substantially below GPT-5.2 High (73.4%) and Seed 2.0 (73.4%). On MCP-Mark, Agent-World-14B (13.3%) significantly underperforms all proprietary models (33.3%–54.7%). The paper's abstract claim of "consistently outperforms strong proprietary models" is therefore misleading — the outperformance is limited to comparisons against smaller models (8B–14B vs. proprietary models of unknown but presumably much larger scale) and is not consistent across benchmarks. A more accurate characterisation would be that Agent-World enables small open-source models to approach or match proprietary performance on some benchmarks while still substantially lagging on the most challenging one (MCP-Mark).

Claim: "Further analyses reveal scaling trends in relation to environment diversity and self-evolution rounds." The environment scaling analysis (Figure 8) convincingly demonstrates a positive relationship between environment count and performance. However, the analysis has a significant confound: when environments are added, both environment diversity and total training data volume increase. The paper does not disentangle these — it does not, for example, control for total training steps or trajectory count while varying environment count. It is possible that the gains attributed to environment diversity are partially or entirely due to simply training on more data. A controlled experiment that holds total training compute constant while varying environment count would be needed to isolate the diversity effect.

The self-evolution analysis (Table 2) demonstrates monotonic gains across two rounds for both Agent-World and EnvScaler. However, only two rounds are tested, and the second-round gains are substantially smaller than the first-round gains (+1.9 vs. +3.3 on τ2-Bench for Agent-World). Extrapolating from two data points, diminishing returns appear to set in quickly. The paper does not report how many additional rounds would be needed for the gains to saturate, nor whether the diagnosis agent's recommendations remain useful after multiple rounds. If second-round gains are already tapering, the practical value of the self-evolving loop for long-term continuous training is uncertain.

The diagnosis quality is not directly evaluated. The paper describes the diagnosis agent's inputs and outputs (Section 3.2.2, Appendix A) and demonstrates that the loop produces gains (Table 2), but it never directly evaluates whether the diagnosis agent's outputs are correct — i.e., whether the identified weak environments and capability gaps match actual agent weaknesses. The gains in Table 2 could be due to any form of continued training on additional synthesised tasks, regardless of whether the task synthesis was targeted at diagnosed weaknesses. A critical ablation — comparing targeted expansion (diagnosis-driven) against random expansion (synthesise new tasks for randomly selected environments) — is not performed. Without this, the paper cannot attribute the gains to the diagnosis mechanism specifically rather than to the continued training generally.

The cold-start SFT uses a different model (Doubao-Seed-1.8) for trajectory generation (Section 4.1). This means the initial policy π_θ^{(0)} is already specialised for tool-use, having been fine-tuned on 40K trajectories from a proprietary model. The paper does not report Agent-World performance when initialised from the bare Qwen3 checkpoint without SFT. This makes it difficult to isolate how much of Agent-World's advantage comes from the environment scaling and self-evolution pipeline vs. the quality of the SFT initialization. If the Doubao-Seed-1.8 trajectories are particularly high-quality, a simpler training approach (SFT only, or SFT + standard GRPO on a single environment set) might achieve similar results.

Limited model scale range. Only two model sizes (8B and 14B) are tested for Agent-World training. The paper demonstrates that Agent-World-14B outperforms Agent-World-8B (Table 1, Figure 7), but does not test whether the method's benefits continue to scale to larger models (e.g., 32B, 70B). The comparison against DeepSeek-V3.2-685B (Table 1) shows Agent-World-14B being competitive on BFCL V4 (55.8% vs. 54.1%) but substantially behind on MCP-Mark (13.3% vs. 36.7%), suggesting that larger models may still have advantages that environment scaling at 14B cannot fully close.

No per-task-synthesis-strategy breakdown. The paper describes two task synthesis strategies (graph-based and programmatic) but does not report performance separately for each. This is a missed opportunity to validate the paper's argument that the two strategies train complementary capabilities (sequential dependencies vs. programmatic reasoning). If graph-based tasks primarily train tool-chaining while programmatic tasks primarily train computational reasoning, per-strategy evaluation would show whether Agent-World improves both capabilities and which strategy contributes more to which benchmark's gains.

The environment taxonomy is built with human annotation but its downstream value is not ablated. The hierarchical taxonomy construction (Section 3.1, "Environment Taxonomy Construction") involves clustering, LLM summarisation, and three human annotators. The taxonomy is used for stratified arena sampling. However, the paper does not compare stratified sampling (using the taxonomy) against random sampling (ignoring the taxonomy) for arena construction. Without this ablation, the value of the carefully constructed taxonomy for the self-evolving loop is assumed rather than demonstrated.

Evaluation uses the same decoding hyperparameters as training (temperature = 1.0, top_p = 1.0). This is a reasonable choice for consistency, but it means evaluation performance may be lower than what could be achieved with optimized decoding (e.g., lower temperature for more deterministic tool use). The paper does not explore whether the relative gains of Agent-World over baselines are sensitive to decoding strategy.

No confidence intervals. Despite repeating each experiment eight times, the paper reports only average accuracy. Standard deviations or confidence intervals are not provided for any result in Table 1, Figures 6–9, or Table 2. This makes it impossible to assess whether the reported differences (e.g., Agent-World-14B at 55.8% vs. DeepSeek-V3.2-685B at 54.1% on BFCL V4) are statistically significant or within noise. The self-evolution gains in Table 2, particularly the smaller second-round improvements (+0.9 on BFCL-V4 for Agent-World), could potentially be within the variance of the evaluation.

The diagnosis agent uses GPT-OSS-120B (Section 4.1), the same model used for environment mining and task synthesis. This means the diagnosis capability is tied to a specific model's reasoning abilities. The paper does not explore whether diagnosis quality would degrade with a weaker model or whether the self-evolving loop would still produce gains — an important practical consideration for reproducing the method with open-source models of varying capability.

In summary, the paper demonstrates that Agent-World's environment-scaling and self-evolving training pipeline produces capable tool-using agents that outperform similarly-sized open-source baselines, with gains that scale with environment count and persist across model sizes. The self-evolving loop provides additional improvements, though the specific contribution of diagnosis-driven targeting vs. continued training is not isolated. The strongest claims (outperforming proprietary models, diagnosis as the key mechanism, cross-benchmark generalization) are supported with qualifications — the outperformance of proprietary models is benchmark-dependent and incomplete, the diagnosis mechanism's specific contribution is not ablated, and generalization is demonstrated on benchmarks that share structural similarities with the training environments rather than on entirely dissimilar tasks. These caveats do not undermine the paper's core contribution — an integrated framework for scalable environment synthesis with continuous training — but they bound the strength of the conclusions that can be drawn from the current experimental evidence.

6. Limitations and Trade-offs

The Cost of Difficulty Estimation Is Not Amortized

The assumption or constraint. The compute-optimal paradigm rests on being able to estimate the difficulty of each environment or task before deciding how to allocate training and synthesis resources. The paper's diagnosis agent (Section 3.2.2) operates on the arena evaluation results — it requires evaluating the current policy on freshly synthesised tasks across 100 arena environments (5 per first-tier category, 20 categories), which itself requires generating those evaluation tasks (both graph-based and programmatic, Section 3.1.1), running the agent on them under the execution protocol, and processing failure traces with the diagnosis agent δ. The paper does not account for the cost of this evaluation-diagnosis step in any budget calculation.

The consequence. If the difficulty estimation cost (arena evaluation + diagnosis) were included in the total compute budget, the self-evolving gains reported in Table 2 would be offset by the substantial computation consumed by the diagnosis phase. In a practical deployment where total FLOPs or wall-clock time is constrained, the question is not whether the self-evolving loop produces gains — it is whether the gains exceed what could be achieved by spending the same compute on simply running more rounds of standard multi-environment RL with random environment expansion (i.e., without diagnosis). The paper does not answer this question. The diagnosis agent itself runs on GPT-OSS-120B (Section 4.1) with a Python interpreter and search tools — the per-round cost includes synthesising fresh evaluation tasks for 100 environments, evaluating the policy on them, and running the diagnosis agent over the failure traces. If this cost is comparable to or exceeds the cost of one round of RL training, then a fair comparison would be: (1) self-evolving loop with R rounds vs. (2) R + k rounds of standard RL where k accounts for the diagnosis budget.

What evidence exists in the paper. The paper provides no budget accounting for the arena phase. Table 2 reports gains from the loop but does not report the compute cost of diagnosis relative to RL training. The implementation details (Section 4.1) state that 5K RL samples are synthesised for training and that 32 tasks × 8 rollouts are used per training step, but no equivalent numbers are given for arena evaluation scale. The dynamic evaluation task synthesis (Section 3.2.2) regenerates both graph-based and programmatic tasks for all 100 arena environments each round — generating these tasks uses the same GPT-OSS-120B policy model as the environment mining phase and involves sandbox execution for verification.

Mitigation status. The paper acknowledges the cost implicitly in Section 3.2.2 ("This design ensures broad coverage over different environment types while keeping evaluation cost controllable" — referring to the K=5 per category sampling) but does not provide any analysis of what fraction of total training compute the arena phase consumes. It does not suggest future work on reducing diagnosis cost or amortising it across training rounds more efficiently.

---

Diagnosis Quality Is Never Directly Evaluated — The Loop's Gains Cannot Be Attributable to Diagnosis

The assumption or constraint. The self-evolving arena's central novelty is agentic diagnosis — the claim that the diagnosis agent δ can analyse failure traces, identify weak environments, and produce targeted task-generation guidelines that address specific capability gaps. The entire value proposition of the "co-evolution" loop (vs. simply adding more random environments and continuing training) depends on this diagnosis being accurate — that the identified weak environments are genuinely the ones where the agent is weakest, and that the generated guidelines produce tasks that actually remediate those weaknesses.

The consequence. If the diagnosis agent's outputs are noisy, incomplete, or wrong — if it identifies the wrong weak environments, mischaracterises failure modes, or produces guidelines that do not lead to tasks targeting the actual capability gaps — then the "targeted" expansion is effectively random expansion with extra steps. In that case, the gains in Table 2 are attributable to continued training on additional synthesised tasks, not to diagnosis-driven targeting. The paper does not isolate these two factors. The critical missing ablation is: random expansion with the same total task volume vs. diagnosis-driven expansion. Without it, the contribution of diagnosis to the self-evolving loop's effectiveness is unknown — the loop could be producing gains because any form of continued training on diverse environments helps, with diagnosis providing no additional benefit over random task synthesis.

What evidence exists in the paper. The paper provides qualitative evidence that the diagnosis agent produces outputs — Appendix A shows the prompt template with the expected output schema (weak environments, task-generation guidelines). It provides quantitative evidence that the loop produces gains (Table 2). It does NOT provide: (a) a direct evaluation of diagnosis accuracy (e.g., human evaluation of whether identified weak environments match actual agent weaknesses), (b) a comparison of diagnosis-driven vs. random expansion with matched task volume, or (c) an analysis of whether the task-generation guidelines correlate with subsequent improvement on the targeted environments. The diagnosis agent uses GPT-OSS-120B (Section 4.1), the same model family used for environment mining and task synthesis, but its specific performance as a diagnostic tool is unmeasured.

Mitigation status. Not addressed. The paper presents the loop's gains as evidence for the effectiveness of the approach without decomposing the contribution of diagnosis vs. continued training.

---

The Cold-Start SFT Initialization Uses a Proprietary Model — The Contribution of Environment Scaling vs. Initialization Quality Is Confounded

The assumption or constraint. All Agent-World models are initialised from a cold-start supervised fine-tuning stage that uses "40K trajectories generated by an in-house Doubao-Seed-1.8 policy model" (Section 4.1, "Implementation Details"). Doubao-Seed-1.8 is a proprietary ByteDance model (Seed, 2026) whose capabilities are not publicly characterised or reproducible. The trajectories are generated using "the same data-synthesis strategy as Agentic Environment-Task Discovery," meaning the SFT data is synthesised from environments in the Agent-World ecosystem using a different, presumably stronger model.

The consequence. The paper's headline results (Table 1, Figures 6–9) compare Agent-World-8B/14B against baselines, but these baselines are either proprietary models (tested zero-shot), open-source foundation models (tested zero-shot or with their own training), or environment-scaling methods (initialised from Qwen3 backbones with their own training procedures). The Qwen3-8B/14B rows in Table 1 represent the bare backbones — not SFT-initialised versions. This means the comparison is between SFT-initialised + Agent-World RL (Agent-World models) and no SFT initialisation (Qwen3 rows) or different SFT/RL procedures (EnvScaler, AWM, etc.). The paper cannot isolate how much of Agent-World's advantage comes from the environment-scaling pipeline and self-evolving training vs. the quality of the Doubao-Seed-1.8-generated SFT trajectories. If Doubao-Seed-1.8 is a strong proprietary model, its 40K trajectories might impart substantial tool-use capabilities that would boost any subsequent training method.

What evidence exists in the paper. The paper reports that the SFT uses 40K trajectories from Doubao-Seed-1.8 (Section 4.1). It does not report Agent-World performance without this SFT stage (i.e., RL from the bare Qwen3 checkpoint). It does not report whether EnvScaler, AWM, or other baselines received comparable SFT initialization. The paper also does not characterise Doubao-Seed-1.8's tool-use capabilities or compare them against the Qwen3 backbones used for other methods.

Mitigation status. Partially addressed. The self-evolving loop is shown to benefit the EnvScaler-8B baseline (Table 2, bottom rows), which presumably was not initialised from Doubao-Seed-1.8 SFT. This demonstrates that the loop provides value beyond the initialisation. However, the magnitude of Agent-World's absolute performance advantage over EnvScaler and AWM in Table 1 cannot be attributed to the environment-scaling pipeline vs. the SFT initialization quality without controlling for initialization.

---

Only Two Model Scales (8B, 14B) Are Evaluated — The Scaling Trajectory Beyond 14B Is Unknown

The assumption or constraint. The paper trains and evaluates Agent-World at exactly two model sizes: Qwen3-8B and Qwen3-14B (Table 1, Figure 7, Figure 9). The scaling analysis in Figure 8 varies environment count but holds model size fixed (presumably 8B, though this is not explicitly stated for that figure). The self-evolution results in Table 2 use the 14B model for Agent-World and the 8B model for EnvScaler.

The consequence. Two data points (8B → 14B) are insufficient to characterise a scaling law or to predict whether the method's benefits would continue, plateau, or reverse at larger scales (32B, 70B, 235B, or larger). The paper's comparison against DeepSeek-V3.2-685B in Table 1 shows Agent-World-14B being competitive on BFCL V4 (55.8% vs. 54.1%) but substantially behind on MCP-Mark (13.3% vs. 36.7%). This raises a critical question: would Agent-World-32B or Agent-World-70B close the gap with 685B models, or does the method's advantage diminish with scale because larger base models already have better tool-use capabilities that leave less room for environment-scaling gains? The 8B→14B trend in Table 1 shows improvements on all three core benchmarks, but the per-benchmark gain varies (MCP-Mark: +4.4%; BFCL V4: +4.4%; τ2-Bench: +3.6%), and extrapolating from two points is unreliable.

What evidence exists in the paper. Figure 9 shows training dynamics for both 8B and 14B with similar reward and entropy trends — the method works at both scales. Table 1 shows 14B outperforming 8B on all three core benchmarks. The paper does not test 32B, 70B, or any larger scale. The paper does not report whether the improvement from 8B to 14B is larger or smaller than the improvement from the Qwen3-8B to Qwen3-14B backbone alone (without Agent-World training), which would indicate whether the method's benefits scale with model size or are additive.

Mitigation status. Not addressed. The paper does not claim that the method scales indefinitely, and the finding that it works at two scales is a reasonable starting point. But the absence of larger-scale experiments means the practical question — "should I apply Agent-World to my 70B model or just use a larger model with simpler training?" — cannot be answered from the current evidence.

---

MCP-Mark Remains a Hard Ceiling — The Method's Gains Are Not Uniform Across Benchmark Difficulty

The assumption or constraint. The paper demonstrates substantial gains over environment-scaling baselines on BFCL V4 and τ2-Bench, but MCP-Mark scores remain low in absolute terms. Agent-World-14B achieves 13.3% on MCP-Mark (Table 1), compared to 5.8% for Qwen3-235B-A22B, 36.7% for DeepSeek-V3.2-685B, and 53.1% for GPT-5.2 High. The self-evolution loop provides the largest relative gains on MCP-Mark (+8.6 points for Agent-World-14B over two rounds, +5.6 for EnvScaler-8B, Table 2), but the absolute ceiling remains far below proprietary models.

The consequence. MCP-Mark is described as "stress-testing realistic and comprehensive MCP use" (Wu et al., 2025) — it tests exactly the kind of stateful, multi-tool orchestration that Agent-World's environments are designed to train. The fact that Agent-World's performance on this benchmark remains low despite being trained on 1,978 MCP-inspired environments with self-evolving diagnosis suggests one of two things: (1) the training environments, while diverse and realistic, still do not capture the specific interaction patterns that MCP-Mark tests, implying a coverage gap that more environments may not close; or (2) the 8B–14B model scale is fundamentally insufficient for the reasoning complexity that MCP-Mark demands, and environment scaling alone cannot compensate for model capacity limits. Either possibility bounds the method's applicability — there may be a class of complex stateful tool-use tasks that are inaccessible to small models regardless of training environment quality.

What evidence exists in the paper. Table 1 shows that all environment-scaling methods (Simulator, TOUCAN, EnvScaler, AWM, Agent-World) score below 14% on MCP-Mark. Even the best open-source model (DeepSeek-V3.2-685B) achieves only 36.7%. Figure 8 shows that MCP-Mark (Postgres) improves with environment count from 4.8% (bare) to 19.9% (1,978 environments at 8B), but the scaling curve may be approaching a plateau — the jump from 1,000 to 1,978 environments provides a smaller gain than the jump from 100 to 500. Table 2 shows the self-evolving loop providing the largest relative benefits on MCP-Mark, but the absolute ceiling (38.1% after two rounds at 14B) remains well below proprietary models.

Mitigation status. The paper does not explicitly discuss this ceiling. The self-evolving loop is presented as a mechanism for continuous improvement, but how many rounds would be needed to approach proprietary-model performance on MCP-Mark — and whether such improvement is possible at the 14B scale — is not addressed.

---

No Per-Task-Synthesis-Strategy Evaluation — The Claim That Graph-Based and Programmatic Synthesis Train Complementary Capabilities Is Untested

The assumption or constraint. Section 3.1.1 frames graph-based and programmatic task synthesis as complementary strategies: graph-based synthesis trains sequential tool dependency reasoning, while programmatic synthesis trains non-linear reasoning with conditionals, loops, and aggregation. The paper argues that "real-world tasks often demand reasoning patterns that cannot be expressed linearly" (Section 3.1.1) and that having both strategies ensures coverage of both sequential and programmatic reasoning patterns.

The consequence. Without per-strategy performance breakdowns, the paper cannot validate whether the two strategies actually train distinct capabilities. Consider three plausible hypotheses: (1) both strategies contribute independently to overall performance (the paper's implicit claim), (2) one strategy dominates and the other provides negligible additional benefit, or (3) the strategies interact — e.g., programmatic synthesis primarily improves graph-based task performance by teaching general planning skills rather than by directly training programmatic reasoning. The current evaluation (aggregate accuracy across benchmarks) cannot distinguish these. If hypothesis (2) were true, the programmatic synthesis pipeline — which involves generating, debugging, and executing solution code and verification scripts — represents substantial engineering complexity that could be eliminated without performance loss. If hypothesis (3) were true, the paper's characterisation of the two strategies as targeting distinct capabilities would be partially incorrect.

What evidence exists in the paper. The paper provides no per-strategy results. The evaluation benchmarks (Table 1, Figures 6–7) aggregate performance across all task types. The task statistics (Figure 4e) report interaction turns for all tasks pooled together, not separated by strategy. The training procedure (Section 3.2.1) mixes graph-based and programmatic tasks in training batches without distinguishing their contributions.

Mitigation status. Not addressed. The paper does not report per-strategy breakdowns or ablate the contribution of each synthesis strategy to overall performance.

7. Implications and Future Directions

How This Work Changes the Landscape

Agent-World does not introduce a new model architecture, a new RL algorithm, or a new benchmark. It introduces a new relationship between environments and training — one where environments are not static inputs to a fixed procedure but co-evolving partners that adapt to the agent's developmental trajectory. This is less a paradigm shift than a reframing of the environment-scaling problem from "generate more environments" to "generate the right environments, guided by diagnosed failures."

What makes this reframing consequential is that it addresses a genuine bottleneck. Prior work (EnvScaler, AWM, AutoForge, InfiniteWeb, and others cited throughout Section 5.1) established that programmatic environment synthesis could scale training beyond what manual construction allowed, and that training on diverse environments improved agent performance. But these methods hit a wall familiar from data-scaling research: uniform expansion yields diminishing returns once the most common interaction patterns are covered. Figure 8 shows this pattern directly — performance jumps markedly from 10 to 100 environments and again from 100 to 500, but the marginal gain from 500 to 1,978 environments is visibly smaller. The field needed a mechanism for deciding which environments to add next, and Agent-World's self-evolving arena provides one.

The diagnosis-driven co-evolution loop (Section 3.2.2, Algorithm 1) is the specific mechanism that enables this shift. It treats the environment ecosystem as a resource to allocate adaptively rather than uniformly — an exploration-exploitation framing applied at the meta-level of curriculum design. The arena evaluation phase explores the agent's capability landscape across diverse environment types, the diagnosis phase exploits failure signals to identify high-value expansion targets, and the targeted synthesis phase exploits the environment generation pipeline to concentrate training data on those targets. This framing — that scalable environments should be treated as infrastructure for continuous diagnosis, not just as a training corpus — is the paper's most transferable insight.

What this means for research priorities: The paper implicitly argues that improving environment synthesis quality and diagnosis accuracy is now more urgent than improving policy optimisation algorithms for agent training. If environments can be generated at scale, if they can be verified through execution, and if agent weaknesses can be reliably diagnosed from failure traces, then the specific choice of RL algorithm (GRPO vs. PPO vs. REINFORCE) matters less than the quality of the training distribution. Figure 9 supports this: both 8B and 14B backbones show stable learning with GRPO on Agent-World's environments, and Table 2 shows that the same self-evolving loop improves both Agent-World and EnvScaler models — the loop is algorithm-agnostic. This suggests that research investment should shift from policy optimisation toward environment infrastructure: better database mining, more robust tool verification, more accurate failure diagnosis, and cheaper difficulty estimation.

Reconciling prior contradictions: The paper resolves a tension in the environment-scaling literature between "simulated environments scale but lack realism" and "programmatic environments are realistic but limited in coverage." Agent-World's web-mining approach shows that realism and scalability are not mutually exclusive — you can have both if you source data from the web rather than from LLM generation. The paper also resolves a tension in agent RL between "training on fixed distributions limits generalisation" and "curriculum design requires manual specification." The self-evolving arena shows that curriculum design can be automated through agentic diagnosis, removing the manual bottleneck while still providing targeted training.

What becomes less attractive: The paper's results cast doubt on the sufficiency of LLM-driven environment simulation for training robust tool-using agents. Simulator-8B, which uses LLM-simulated environments, achieves only 2.4% on MCP-Mark (matching the bare Qwen3-8B backbone) despite showing some gains on τ2-Bench (Table 1). The paper's interpretation — that "simulated environments are insufficient to capture complex real-world state transitions" — is consistent with this result. If the goal is stateful, multi-tool orchestration (as MCP-Mark tests), simulation-based training appears to provide negligible benefit. Research programmes that rely exclusively on LLM-simulated environments for agent training may need to incorporate executable, stateful backends to make progress on the hardest benchmarks.

What becomes more attractive: The paper makes a compelling case that environment infrastructure is a research contribution in its own right, not just a means to an end. The 1,978 environments and 19,822 tools that Agent-World produces are not just training data — they are a diagnostic instrument, a curriculum engine, and a testbed for capability analysis. The hierarchical taxonomy (Figure 3), the environment cards (Appendix B), and the case studies (Appendix C) represent a form of scientific contribution that the field has not traditionally valued as highly as model checkpoints or benchmark scores. This paper argues, implicitly but clearly, that building scalable, realistic, verifiable environments is as intellectually significant as training on them.

---

Follow-Up Research This Work Enables

Diagnosis accuracy: directly evaluate whether the diagnosis agent identifies the right weaknesses. The self-evolving loop's gains (Table 2, +6.8 on MCP-Mark in round 1 for Agent-World-14B) are attributed to diagnosis-driven targeted expansion, but the paper never evaluates whether the diagnosis agent δ is correct. A critical follow-up would: (1) take the weak environments W^{(r)} identified by δ after round r, (2) train separate models on targeted tasks synthesised from those environments vs. random tasks from the arena, and (3) measure whether targeted training produces larger gains on the diagnosed environments than random training. If it does not — if random expansion matches or exceeds targeted expansion — the diagnosis agent adds no value beyond continued training, and the self-evolving loop's central mechanism is unvalidated. This experiment requires no new infrastructure beyond what the paper already describes; it is a straightforward ablation of the diagnosis step.

Arena construction: test whether stratified taxonomy sampling matters vs. random sampling. The paper constructs the arena by stratified sampling (5 environments per first-tier category, 20 categories = 100 environments) using a three-stage taxonomy built with clustering, LLM summarisation, and human annotation (Section 3.1). Is this taxonomy necessary? A direct ablation would compare the self-evolving loop's gains using (a) stratified sampling from the taxonomy, (b) random sampling of 100 environments from the full ecosystem, and (c) uniform sampling proportional to category size. If all three produce similar gains, the taxonomy — which required substantial engineering and human annotation — is unnecessary infrastructure. If stratified sampling produces larger gains, the taxonomy is validated as a mechanism for ensuring coverage of rare but important environment types. Figure 3 shows that category sizes are highly skewed (some first-tier categories have many more environments than others), suggesting that random sampling could under-represent small categories — this ablation would quantify how much that matters.

Cheap difficulty estimation: train a lightweight classifier to predict environment difficulty from metadata alone. The diagnosis agent requires evaluating the current policy on 100 arena environments with freshly synthesised tasks each round — a cost the paper does not account for. Can environment difficulty be predicted without running full evaluations? A natural follow-up would train a lightweight classifier (e.g., a small fine-tuned BERT or Llama-3B variant) that takes environment metadata (tool schemas, database descriptions, taxonomy category) and the agent's performance on a small number of representative tasks (e.g., 8 tasks per environment) as input, and predicts pass rate on a larger held-out task set. This would decouple the difficulty estimation cost from the full arena evaluation, making the self-evolving loop practical for larger-scale training. The training data for such a classifier already exists as a byproduct of the arena evaluation logs. The key metric: how well does the classifier's predicted ranking of environment difficulty correlate with actual pass rates on fresh tasks, and does using the classifier for arena environment selection produce comparable gains to full evaluation at a fraction of the cost?

Scaling model size: test whether Agent-World's benefits persist or diminish at 32B, 70B, and beyond. The paper evaluates only 8B and 14B models (Table 1, Figure 7, Figure 9). Two critical questions are: (1) Does the absolute gain from Agent-World training increase, stay constant, or decrease with model scale? (2) Does Agent-World training at 32B close the gap with proprietary models on MCP-Mark, where Agent-World-14B (13.3%) substantially trails GPT-5.2 High (53.1%) and DeepSeek-V3.2-685B (36.7%)? A scaling study at 32B, 70B, and (if computationally feasible) 235B using the Qwen3 model family would answer both questions. The hypothesis consistent with the paper's narrative is that environment-scaling gains compound with model scale (larger models can exploit environment diversity more effectively), but the alternative — that larger models already possess better tool-use capabilities from pretraining, leaving less room for environment-scaling improvement — is equally plausible and would bound the method's practical value. The experiment requires training Agent-World at each scale with matched compute (controlling for training steps or FLOPs) and reporting both absolute accuracy and improvement over the corresponding backbone.

Task synthesis strategy decomposition: measure what graph-based vs. programmatic tasks actually teach. The paper argues that graph-based synthesis trains sequential tool dependency reasoning while programmatic synthesis trains non-linear reasoning with conditionals, loops, and aggregation (Section 3.1.1), but provides no per-strategy evaluation. A targeted follow-up would train three variants of Agent-World-8B: (a) graph-based tasks only, (b) programmatic tasks only, and (c) both (the current setting), all with matched total task volume. Evaluate each variant on benchmarks that stress sequential dependencies (e.g., τ2-Bench, which requires ordered multi-step workflows) and benchmarks that stress programmatic reasoning (e.g., SWE-Bench Verified, which requires code-level logic). The paper's implicit claim predicts a double dissociation: the graph-only variant should match the combined variant on sequential benchmarks but underperform on programmatic benchmarks, and vice versa. If instead one strategy dominates across all benchmarks, the engineering complexity of maintaining both synthesis pipelines is unjustified. This experiment also tests whether the two strategies interact synergistically — e.g., whether programmatic training incidentally improves sequential reasoning through shared planning skills.

Hard-problem ceiling: characterise what makes MCP-Mark resistant to environment-scaling training. MCP-Mark scores remain low across all environment-scaling methods: Agent-World-14B achieves 13.3%, EnvScaler-8B achieves 5.6%, AWM-14B achieves 5.1% (Table 1). Even DeepSeek-V3.2-685B reaches only 36.7%, and the best proprietary model (Seed 2.0) achieves 54.7%. Is this a model capacity ceiling, a training environment coverage gap, or a more fundamental limitation? A diagnostic study would: (1) categorise MCP-Mark failures by type (state-tracking errors, tool selection errors, parameter errors, planning errors) using the diagnosis agent's methodology applied to MCP-Mark traces, (2) determine whether Agent-World's training environments contain tasks with similar failure-relevant patterns to MCP-Mark (i.e., is it a coverage problem or a transfer problem?), and (3) test whether targeted synthesis focused specifically on MCP-Mark-like patterns (e.g., environments with multi-table database schemas, tools with complex interdependencies) produces disproportionate gains. If targeted synthesis does not help, the ceiling is likely a capacity issue that requires larger models. If it does, the current environment ecosystem has coverage gaps that targeted expansion can address. This study would establish whether further investment in environment scaling for the 8–14B range has diminishing returns or whether substantial headroom remains.

---

Practical Applications and Downstream Use Cases

On-demand MCP server training for enterprise tool ecosystems. Organisations deploying MCP servers for internal tools (databases, SaaS platforms, internal APIs) face a common problem: general-purpose agents do not know how to use their specific tools, and manually writing training data for each tool combination is impractical. Agent-World's pipeline — theme collection from MCP server specs (Section 3.1, source M1), database mining from internal data sources, tool interface generation and verification, and task synthesis — provides a template for automatically building training environments from an organisation's own MCP server specifications. The key practical benefit is that the environment synthesis is execution-grounded: generated tools are verified against unit tests with a >50% pass threshold, synthesised tasks are validated by deploying a ReAct agent 5 times and retaining only those with consistent solutions, and rewards are executable (rubrics or verification scripts) rather than model-estimated. This means the resulting training pipeline produces verifiable signal without requiring human annotation of tool-use trajectories. For an enterprise with 50–200 internal MCP tools, the paper's reported scale (1,978 environments, 19,822 tools from ~3.5K themes) suggests the pipeline can handle real-world tool ecosystems.

Targeted fine-tuning for domain-specific agent assistants. The self-evolving arena (Section 3.2.2) is directly applicable to domain-specific deployment where an agent's weaknesses are concentrated in particular environment types or interaction patterns. Consider a customer-support agent that handles booking, order tracking, and returns across multiple backend systems. After initial training, the arena evaluates the agent on fresh tasks across all backend types, the diagnosis agent identifies that return-processing workflows have a 40% higher failure rate than booking workflows, and targeted synthesis generates additional return-processing tasks with more complex state dependencies (e.g., partial returns, refund calculations, inventory updates). Table 2 provides evidence that this loop works: Agent-World-14B gained +6.8 points on MCP-Mark in one evolution round, and even the EnvScaler-8B baseline gained +4.4 points. The per-round improvement is significant enough to justify the diagnosis cost in high-stakes deployment scenarios where each percentage point of accuracy translates to measurable operational savings (e.g., reduced escalation to human agents).

Self-improving agent data flywheels for open-source model ecosystems. The paper demonstrates that the self-evolving loop works across different starting models (Agent-World-14B and EnvScaler-8B both benefit, Table 2). This suggests a deployment pattern where an open-source community maintains a shared environment ecosystem (themes, databases, tools, task synthesis prompts) and a shared diagnosis infrastructure, and individual model developers run the self-evolving loop to specialise their models for specific capability profiles. The environment ecosystem is the reusable asset — once built, it can serve as a diagnostic arena for any agent policy, not just the one that was initially trained on it. The paper's hierarchical taxonomy (20 first-tier categories, 50 second-tier, over 2K third-tier, Figure 3) provides the structural framework for such sharing: developers can contribute environments to specific taxonomy nodes, and the stratified arena sampling ensures that evaluation covers all categories regardless of which are most heavily contributed to. The key practical enabler is that the environment synthesis pipeline is model-agnostic — it uses GPT-OSS-120B for mining and synthesis, but the resulting environments are executable Python sandboxes that any agent can interact with.