PaperlayerView exact revision on arXiv

Source-linked AI summary

$\Delta\tau$-Bench: Pushing Agents Toward a Moving Capability

Shuofei Qiao, Xuanguang Pan, Yijun Chen, Wendi Feng, Bin Wu, Runnan Fang, Yuqi Zhu, Shumin Deng, Emine Yilmaz

arXiv:2610.34238v1cs.CLcs.AIcs.CVcs.IRcs.LGcs.SE

TL;DR

Large, changing tool ecosystems challenge agents to discover effective paths and update procedural knowledge as services evolve. The paper introduces Δτ-Bench and Steward, finding that Steward sustains stronger task performance across ecosystem changes with lower skill-maintenance overhead.

  • Problem

    Existing benchmarks do not examine whether agents can discover efficient tool-use paths and revise procedural knowledge as independently changing services reshape task workflows.

    Source: §1 · pp. 1–2

  • Method

    The paper introduces Δτ-Bench, with 1,588 validated multi-turn tasks across 42 domains and six ecosystem states, and Steward, which incrementally maintains skills and dynamically provides tools and procedural guidance.

    Source: §1 · p. 2, §8 · p. 10

  • Results

    39.04% average SR for Steward versus 36.36% for SkillOpt across six versions, with Steward incurring the lowest maintenance cost from v2 onward.

    Source: §6 · p. 8

  • Takeaways & Limitations

    The results support managing tools and procedural knowledge as interdependent resources to keep accumulated experience useful as ecosystems evolve.

    Source: §8 · p. 10

Abstract

from arXiv · show

In this paper, we introduce $\Delta\tau$-Bench, an executable agent benchmark that models the structural evolution of large tool ecosystems. In $\Delta\tau$-Bench, independently evolving services continually reshape how tasks can be accomplished: familiar tools may disappear or be replaced, while more efficient alternatives emerge amid overlapping functionality and noisy documentation. Against this moving capability frontier, we evaluate whether agents can proactively discover efficient tool-use paths and promptly revise their accumulated procedural knowledge, bringing together demands that existing benchmarks fail to examine. $\Delta\tau$-Bench comprises 1,588 validated multi-turn tasks across 42 domains and six successive ecosystem states generated through capability-preserving transformations. Our evaluation shows that even the strongest evaluated model or harness achieves only 42.3% task success, while initial gains from existing skill-learning methods can not consistently translate into better adaptation as the ecosystem evolves. These findings motivate Steward, an ecosystem manager that jointly manages tools and procedural knowledge through incremental skill maintenance and dynamic provisioning during task execution. Experiments show that Steward sustains higher task success across ecosystem changes with lower skill-maintenance overhead, while improving both recovery from disrupted workflows and adoption of more efficient alternatives.

1 INTRODUCTION

The paper frames evolving tool ecosystems as a challenge of discovering efficient workflows and updating procedural knowledge as services change. It introduces Δτ-Bench to evaluate that challenge and Steward to maintain skills and tools together.

1 INTRODUCTION

  • Independent service updates, overlapping functionality, and noisy descriptions can break established workflows or hide more efficient alternatives.Successful execution can therefore conceal a growing gap between available capabilities and the agent’s learned procedures.Source: §1 · pp. 1–2
  • Existing benchmarks generally assess tool retrieval, stateful execution, replanning, or robustness separately, leaving proactive discovery and procedural updates in evolving ecosystems open.The paper identifies this as a gap in evaluating sustained competence against a moving capability frontier.Source: §1 · p. 2
  • Δτ-Bench contains 1,588 validated multi-turn tasks across 42 domains and six ecosystem states generated through capability-preserving transformations.It evaluates discovery and stateful execution against efficient task paths for each state, including recovery from disrupted workflows and use of efficiency gains.Source: §1 · p. 2
  • 42.3% task success is the ceiling for the strongest evaluated model or harness, and skill-learning gains do not consistently improve adaptation as ecosystems evolve.Steward sustains stronger performance across ecosystem changes while reducing skill-maintenance overhead.Source: §1 · p. 2
  • Steward incrementally maintains skills as tools change and dynamically supplies relevant tools and procedural guidance during execution.Experiments report stronger performance across ecosystem changes with lower maintenance overhead; joint tool-and-skill provisioning benefits performance beyond either resource alone.Source: §1 · p. 2

2 TASK FORMULATION

The task formulation treats agentic interaction as a partially observable process involving user intent, environment and dialogue state, and tool or conversational actions. Ecosystem versions change the available calls and feasible paths for the same intent.

2 TASK FORMULATION

  • Agent actions are selected from observable history, and the environment produces the next state and observation according to the transition model.The model includes executable tool calls and natural-language replies, with observations from tools or the user.Source: §2 · p. 2
  • Tool calls can modify the external environment, while dialogue can modify the agent–user interaction state; final reward scores the environment state and satisfaction of user constraints..Source: §2 · p. 2
  • Each episode fixes an ecosystem version, whose available functions and admissible arguments can change feasible actions and successful paths for the same intent.The policy must account for both interaction history and the current action space at each step.Source: §2 · p. 3

3 ∆τ-BENCH

∆τ-Bench combines validated stateful tasks with capability-preserving tool evolution to study agent behavior across changing ecosystems. Its construction provides executable tasks, evolving tool interfaces, reference paths, and metrics for task success and frontier adaptation.

3.1 EXECUTABLE ENVIRONMENT AND TASK CONSTRUCTION

  • ∆τ-Bench contains 1,588 tasks across 42 domains and six ecosystem states, with stateful multi-turn tasks and executable service interfaces.Tasks are synthesized from tool dependencies, grounded in user information or tool outputs, and retained after successful replay and validation.Source: §3 · p. 3, §3.1 · pp. 3–4

3.2 EVOLVING TOOL ECOSYSTEMS CONSTRUCTION

  • Capability-preserving transformations rename or reshape interfaces, split functions, or integrate them; versions may retain or deactivate older interfaces.Transitions are checked to ensure base capabilities remain accessible, and documentation may be perturbed while execution semantics are preserved.Source: §3.2 · p. 4
  • Task reference paths select active realizations that cover the ordered base-function sequence, minimizing either tool-call count or execution cost.The candidate paths are replayed, retaining only those that succeed and reproduce the required state changes.Source: §3.2 · p. 4

3.3 EVALUATION PROTOCOL AND METRICS

  • Task success requires agent-produced database changes to cover all changes in the validated gold execution, while IDR and DAR measure responses to improving or worsening paths.Step and cost variants assess these adaptation measures, and SPE measures execution efficiency relative to reference paths.Source: §3.3 · p. 5
  • Figure 4 reports initial gains from automated skill methods, but they do not consistently adapt to the moving capability frontier.The figure evaluates these methods across ecosystem versions.Source: Figure 4 · p. 6

4 EVALUATING AGENTS IN EVOLVING TOOL ECOSYSTEMS

The evaluation tests whether agents can reach the current capability frontier and whether accumulated skills help them track ecosystem changes. Models struggle to identify and execute efficient, valid tool paths, while skill-based gains do not reliably persist as the ecosystem evolves.

4 EVALUATING AGENTS IN EVOLVING TOOL ECOSYSTEMS

  • The evaluation uses DeepSeek-V3.2 as the user model throughout, and as the task model for controlled ablations and skill-method comparisons.Configurable reasoning effort is set to high; other inference parameters retain recommended defaults.Source: §4 · p. 6

4.1 MODELS STRUGGLE TO REACH THE CURRENT FRONTIER

  • Even the strongest model and harness achieve only 41.65% and 42.27% SR, respectively, and neither exceeds 30% in Step- or Cost-SPE.Codex-GPT-5.5 retrieves 90.36% of relevant tools but has 19.90% precision and 32.04% F1, illustrating difficulty excluding irrelevant candidates.Source: §4.1 · p. 6
  • SR and both SPE variants rise as tool candidates are restricted, but Oracle Path adds no further improvement.The Task Tools-to-Oracle Tools gains indicate difficulty distinguishing efficient, version-valid options from unavailable or overlapping alternatives; the Oracle Path result points to tool use rather than high-level planning as the remaining gap.Source: §4.1 · p. 6, Figure 3 · p. 6

4.2 SKILL METHODS STRUGGLE TO TRACK THE MOVING FRONTIER

  • Skill methods improve over No Skill at v1, but their gains do not consistently persist across ecosystem versions or improve adaptation.At v3, EvoSkill and AutoSkill reach 0 in Step- and Cost-DAR, while No Skill retains 11.11% and 10.25%; SkillOpt averages about 3,000 K/task in maintenance.Source: §4.2 · p. 7

5 STEWARD: MANAGING TOOLS AND SKILLS IN EVOLVING ECOSYSTEMS

STEWARD jointly manages shared tool and skill resources, incrementally maintaining procedural knowledge and provisioning task-specific resources. It updates the agent’s view through retrieval and search as task requirements or execution feedback reveal capability gaps.

5 STEWARD: MANAGING TOOLS AND SKILLS IN EVOLVING ECOSYSTEMS

  • STEWARD updates a three-level hierarchy of planning, atomic, and tool skills using the current catalog and newly verified execution experience.It makes local edits, marks skills active or inactive according to tool availability, and retains inactive skills for possible reactivation.Source: §5 · p. 7
  • From v2 onward, baselines require 1.2–5.5× as many maintenance tokens as STEWARD.Figure 6 also reports the highest SR across all six ecosystem versions and consistent improvements in execution efficiency, frontier tracking, and tool retrieval.Source: Figure 6 · p. 8
  • At task start, STEWARD retrieves planning skills and constructs a provisional plan, then combines relevant atomic skills with directly retrieved tools.New user information or execution feedback can trigger additional retrieval, search, and inspection; verified tools are added to the task view with procedural guidance.Source: §5 · p. 8
  • STEWARD couples incremental skill maintenance with on-demand capability provisioning to reduce update and execution costs while preserving task success as tools evolve.It maintains a persistent skill library alongside the tools exposed to the task agent.Source: §5 · pp. 7–8

6 EXPERIMENTAL RESULTS FOR STEWARD

STEWARD sustains stronger task success across ecosystem versions while keeping skill-maintenance costs lower. Incremental maintenance outperforms other cross-version strategies, and dynamic tool and skill search work best together.

STEWARD Tracks the moving frontier efficiently

  • 39.04% average SR for STEWARD versus 36.36% for SkillOpt, with the lowest maintenance cost from v2 onward and baselines using 1.2–5.5× as many skill-maintenance tokens.STEWARD also improves Step-/Cost-IDR by 4.04%/3.69% and Step-/Cost-DAR by 5.28%/4.76% on average over the strongest baseline.Source: §6 · p. 8

Incremental maintenance balances knowledge reuse and adaptation

  • Incremental maintenance achieves the highest average SR for DeepSeek-V3.2 and GPT-5.5 (36.83% and 40.81%), while reducing maintenance tokens versus full reconstruction by 39.5% and 30.4%, respectively.It also leads on SPE, IDR, DAR, and tool F1; full reconstruction underperforms freezing on GPT-5.5 (38.99% vs. 39.60%).Source: Table 2 · p. 8, §6 · p. 9

Dynamic tool and skill search are complementary

  • Combining dynamic tool and skill search improves every metric; versus tool search alone, Full Provisioning raises Step-/Cost-DAR by 11.41%/9.30% and Tool F1 by 4.90 percentage points.Skill search alone yields little improvement, while tool search alone raises SR and Tool F1 but provides limited SPE and IDR gains and reduces Step-DAR by 2.76%.Source: §6 · p. 9

7 RELATED WORK

Prior work studies tool selection, stateful execution, retrieval, efficiency, robustness, and skill evolution, but these capabilities are largely assessed separately. The paper positions its contribution as addressing their intersection in evolving ecosystems.

Benchmarks for Tool-Using Agents

  • Tool-agent benchmarks cover API selection, multi-tool planning, stateful interaction, large-repository retrieval, efficiency-aware replanning, and robustness, but largely evaluate these capabilities in isolation.∆τ-Bench is presented as unifying large-scale retrieval, multi-turn stateful execution, and efficiency-aware adaptation in a controlled evolving ecosystem.Source: §7 · p. 9

Skill Learning and Evolution for LLM Agents

  • Skill-learning work progresses from trajectory-derived guidance to executable routines, automated construction and refinement, and organization of growing skill libraries.The paper notes that these approaches largely evolve skills over a stable operational substrate and emphasize eventual task success, leaving adaptation to a moving capability frontier open.Source: §7 · pp. 9–10

8 CONCLUSION

The paper introduces ∆τ-Bench for evaluating sustained competence in evolving tool ecosystems and presents STEWARD as a joint manager of tools and procedural knowledge. The remaining statements describe AI use, ethics, and reproducibility practices.

8 CONCLUSION

  • ∆τ-Bench evaluates sustained agent competence against the moving capability frontier, while STEWARD couples incremental skill maintenance with dynamic tool and procedural-guidance provisioning.The conclusion reports improved performance and adaptation with lower maintenance overhead, supporting the treatment of tools and procedural knowledge as interdependent resources.Source: §8 · p. 10

AI USE STATEMENT

  • The authors used LLMs only as writing and visualization assistants during paper preparation, reviewed assisted materials, and accept responsibility for the manuscript and artifacts.Experimental LLM use was for scientific research and is described in the Experimental Settings and Reproducibility Statement.Source: AI USE STATEMENT · p. 10

ETHICS STATEMENT

  • The study states that its data came from publicly accessible sources, with no proprietary, confidential, or otherwise restricted information involved.It asks benchmark users to act responsibly and disallows applications that may cause harm or adverse societal consequences.Source: ETHICS STATEMENT · p. 10

REPRODUCIBILITY STATEMENT

  • The reproducibility statement directs readers to the paper and appendices for environment and task construction, ecosystem evolution, dataset statistics, evaluation, STEWARD design, comparisons, ablations, and prompts.Source: REPRODUCIBILITY STATEMENT · p. 10

A.1 EXECUTABLE ENVIRONMENT AND TASK CONSTRUCTION

The appendix grounds services and tasks in domain semantics, implements them as stateful executable environments, and constructs multi-turn tasks with simulated users. It then models ecosystem evolution through validated capability-preserving transformations and searches for efficient task realizations.

A.1 EXECUTABLE ENVIRONMENT AND TASK CONSTRUCTION

  • Service construction starts from coherent activity domains, derives entity schemas and relationships, and turns service blueprints into validated function-calling interfaces with JSON Schemas.The interfaces define function names, descriptions, and input-parameter constraints.Source: §A.1 · p. 17
  • The executable environment instantiates records and relationships in a mock database, then implements functions as server-side code that applies operational policies and updates persistent state.Function execution validates arguments, enforces constraints, performs database reads or writes, and returns results or errors.Source: §A.1 · p. 17
  • Tasks are grounded in dependency-graph paths and validated executions, with path joining and repetition adding longer or repeated tool-use sequences; a simulated user discloses task information progressively.Candidate task templates are evaluated for coherence, function coverage, naturalness, and specificity before retention.Source: §A.1 · pp. 17–18

A.2 EVOLVING TOOL ECOSYSTEMS CONSTRUCTION

  • Ecosystem versions are built from validated one-to-one, one-to-many, and many-to-one interface transformations that preserve source capabilities and are checked through execution.Versions may retain old and new interfaces together or deactivate old ones, while coverage checks ensure every base capability remains accessible.Source: §A.2 · pp. 18–19
  • For each task and version, reference paths cover the ordered base-function sequence with active realizations minimizing either tool-call count or execution cost.The paths are benchmark annotations, not required trajectories for evaluated agents.Source: §A.2 · p. 19

A.3 EVALUATION PROTOCOL AND METRICS

The protocol evaluates outcome-based task completion, tool retrieval, path efficiency relative to reference paths, and adaptation to changing optimal paths. It measures both discovering improvements and remaining effective when execution becomes harder or costlier.

Outcome-based Task Success

  • A task succeeds when agent-produced database changes cover all changes required by the validated gold execution; success rate is reported across tasks at each ecosystem version.Evaluation initializes the corresponding MCP service with the task’s external state.Source: §A.3 · pp. 19–20

Tool Retrieval Quality

  • Retrieval quality measures whether the agent identifies the task’s reference-path tools from the complete action space using task-level precision, recall, and F1.The evaluated set is the final tool set exposed to the agent after retrieval.Source: §A.3 · p. 20

Success-weighted Path Efficiency

  • Success-weighted Path Efficiency (SPE) measures task-completion efficiency relative to reference paths, using function-call count or execution cost as path weight.These weights yield Step-SPE and Cost-SPE.Source: §A.3 · p. 20

Improvement Discovery and Degradation Adaptation

  • Improvement Discovery Rate measures finding newly shortened or cheaper paths, while Degradation Adaptation Rate measures effectiveness when optimal paths become longer or costlier.Function-call count or execution cost yields Step-IDR/DAR and Cost-IDR/DAR.Source: §A.3 · p. 20

A.4 BENCHMARK STATISTICS AND CHARACTERISTICS

The benchmark spans 1,588 tasks across 42 domains and six ecosystem states, with reference-path weights changing non-monotonically across transitions. The section also describes skill-based baselines and their shared evaluation setup.

A.4 BENCHMARK STATISTICS AND CHARACTERISTICS

  • 1,588 tasks across 42 domains yield 9,528 task–ecosystem instances across six states, with 1,191 training tasks and 397 test tasks.Aggregate tool scale remains comparable across states, while reference-path weights change non-monotonically; function-call count and execution cost capture complementary efficiency dimensions.Source: §A.4 · p. 20
  • Figure 8 shows task distributions by function-call count and execution cost, while Table 3 covers tool scale across six states and corresponding interface changes.Table 4 reports domain-level task counts and mean calls in original gold trajectories by domain and split.Source: §A.4 · p. 20, Figure 8 · p. 21, Table 3 · p. 21

B DETAILS OF SKILL-BASED BASELINES •

  • AutoSkill, Trace2Skill, EvoSkill, and SkillOpt maintain or optimize reusable skill libraries from inputs or execution trajectories while keeping the target model fixed.Their approaches include filtering or consolidating skills, failure analysis, and validation-based acceptance or retention of updates.Source: B DETAILS OF SKILL-BASED BASELINES • · p. 21
  • All skill-based baselines are adapted from their official implementations without module revisions and use DeepSeek-V3.2 as the common backbone.Source: B DETAILS OF SKILL-BASED BASELINES • · p. 21

C DETAILS OF STEWARD

STEWARD maintains a structured skill library and supplies task-specific skills and tools initially, then provisions additional capabilities during execution. Its maintenance process preserves reusable knowledge while updating it from verified experience.

C DETAILS OF STEWARD

  • At initialization, planning and atomic skills are extracted from successful training trajectories, while tool skills combine schemas with repeated failure evidence to capture invocation constraints and recovery procedures.Planning skills encode workflows, atomic skills reusable operations and tool dependencies, and tool skills invocation guidance.Source: C DETAILS OF STEWARD · p. 21
  • After initialization, planning skills remain fixed while atomic and tool skills are incrementally maintained using newly verified training trajectories.Updates can add, modify, keep, or skip records; inactive skills are retained for possible reactivation when dependencies return.Source: C DETAILS OF STEWARD · pp. 21–22
  • Table 4 reports domain-level task statistics, with mean calls computed from original gold trajectories before ecosystem-specific interface transformations.Source: Table 4 · p. 22
  • Maintenance favors cost savings only when trajectory evidence establishes equivalent preconditions and state effects, and preserves required actions and verification.The skill graph and retrieval indices are rebuilt over active skills; an auxiliary distillation step learns retrieval-policy skills without directly changing tool visibility.Source: C DETAILS OF STEWARD · pp. 22–23
  • For each episode, STEWARD retrieves planning skills to form a provisional plan, selects related atomic and tool skills, and supplies their guidance as procedural context.It also retrieves tools for plan steps and intersects them with the current catalog to form the initial visible tool set.Source: C DETAILS OF STEWARD · p. 23
  • During execution, the task agent can request additional tools or delegate a focused capability search when its current tool set is insufficient.The manager searches the skill library and tool catalog, checks candidate schemas, and can recommend equivalent replacements; its reports update available tools and procedural context as execution reveals capability requirements.Source: C DETAILS OF STEWARD · p. 23

D PROMPTS

The prompts guide agents in planning and selecting procedures, maintaining reusable tool skills, and investigating or retrieving capabilities as needed. They emphasize evidence-grounded, efficient actions and concise, actionable workflow guidance that accounts for constraints and recovery while avoiding duplication.

D.1.1 PLANNING SKILL EXTRACTION

  • Planning extraction turns API histories into concise, ordered, reusable task plans that capture sub-goals and key APIs while excluding exploration, debugging, and failed steps.Plans should be agent-centered and precise enough for other models to follow.Source: §D.1.1 · pp. 23–24

D.1.2 ATOMIC SKILL EXTRACTION

  • Atomic skill extraction creates modular, specific-tool entries with typed parameters, input/output descriptions, usage examples, and tool lists, while avoiding overlap with existing skills.Each skill uses the fields name, document, content, and tools, and should not call other library skills or import Python packages.Source: §D.1.2 · p. 25
  • The atomic-skill updater chooses modify, add, or keep based on library gaps and clear issues, preserving broadly reusable skills and avoiding duplication.Modification and keeping require an existing library skill; adding is for tools not already represented.Source: §D.1.2 · pp. 25–26

D.1.3 TOOL SKILL EXTRACTION

  • Tool-skill extraction uses a tool schema and repeated failure evidence to produce one generic skill describing tool purpose, I/O, failure constraints, and recovery.The prompt requires natural-language examples and asks the skill to clarify rollout usage that differs from the schema.Source: §D.1.3 · p. 27

D.2.1 INCREMENTAL SKILL MAINTENANCE

  • Incremental maintenance reviews task outcomes, trajectories, and retrieved skills to keep, modify, or add reusable agent-side workflow guidance for future tasks.It prioritizes non-trivial coordination, hidden dependencies, recovery behavior, and subtle constraints, while leaving simple sessions unchanged when they add no guidance.Source: §D.2.1 · p. 28
  • Maintenance favors guidance for lookup-act and preview-confirm sequences, error repair, multi-tool ordering, and difficult subtasks rather than merely restating tool functions.A successful session may warrant an update when it reveals a non-obvious workflow or important control rule.Source: §D.2.1 · p. 28
  • Skill maintenance prioritizes evidence-backed minimal correct workflows and reusable guidance on pitfalls, sequencing, validation, recovery, and tool coordination; agents should not force updates.Prefer lower-cost tools only when rollout evidence shows semantic equivalence, including matching preconditions and state effects; capture cost guidance for avoidable calls, invalid retries, or equivalent alternatives.Source: §D.2.1 · pp. 29–30

D.2.2 RETRIEVAL-POLICY SKILL DISTILLATION

  • The retrieval-policy distillation prompt asks for one evidence-based reusable rule about when to retrieve, how to query, or how to assess retrieved schemas.It prohibits task-specific IDs, invented tools, business-tool API descriptions, and claims that retrieval executes an action.Source: §D.2.2 · p. 30

D.3.1 TASK-SPECIFIC PSEUDO PLAN CONSTRUCTION

  • Pseudo-plan construction rewrites retrieved planning skills for the current request as short actionable steps in strict JSON.Source: §D.3.1 · p. 31

D.3.2 SKILL SELECTION

  • Skill selection considers the request and pseudo-plan, returning strict JSON with no more than the configured maximum number of skills.Source: §D.3.2 · p. 31

D.3.3 SKILL CONTEXT INJECTION

  • Injected reusable skills are references only: agents must check the current session’s actual tool list before deciding which tools they can call.The context template supplies selected atomic skills and tool clarifications for use when applicable.Source: §D.3.3 · p. 31

D.4.1 CAPABILITY INVESTIGATION INTERFACE

  • Capability investigation is for insufficient, unclear, or failed capabilities; the manager searches skills and tools, inspects schemas, and returns recommendations without executing actions.The request specifies the goal, missing capability, and any known failures; existing usable tools should not be recommended again unless a parameter detail caused the blocker.Source: §D.4.1 · p. 32

D.4.2 TOOL RETRIEVAL INTERFACE

  • On-demand retrieval supplies additional tools only when the current list is insufficient, using one short, specific natural-language capability query.Source: §D.4.2 · p. 32

D.4.3 ON-DEMAND CAPABILITY INVESTIGATION

  • Capability investigations must verify tools, account for changing names, and use learned tool skills for parameter and ordering rules rather than relying on schemas alone.Investigators should search broadly, inspect tools before recommending them, and compress findings into actionable steps; committed skills preserve parameter-level or ordering details, while tools must be committed separately.Source: §D.4.3 · p. 33
  • The prompt includes a slot for known failures.It is labeled {KNOWN_FAILURES}.Source: §D.4.3 · p. 34
  • The prompt includes a slot for recent user messages.It is labeled {RECENT_USER_MESSAGES}.Source: §D.4.3 · p. 34
  • The prompt includes a slot for recent tool errors.It is labeled {RECENT_TOOL_ERRORS}.Source: §D.4.3 · p. 34
  • The prompt includes a slot for a pseudo-plan.It is labeled {PSEUDO_PLAN}.Source: §D.4.3 · p. 34
  • The prompt includes a slot for tools already visible to the main agent.It is labeled {VISIBLE_TOOL_NAMES}.Source: §D.4.3 · p. 34
  • The prompt includes a slot for skills already injected.It is labeled {INJECTED_SKILL_NAMES}.Source: §D.4.3 · p. 34

Related papers

Loading 2610.34238v1…