Papers
Topics
Authors
Recent
Search
2000 character limit reached

Environment-free Synthetic Data Generation for API-Calling Agents

Published 18 Jul 2026 in cs.AI | (2607.16900v2)

Abstract: Training API-calling LLM agents demands massive amounts of high-quality trajectories. However, collecting such data at scale typically requires fully implemented environments with executable APIs and realistic, pre-populated backend databases, creating a major bottleneck for scalability. To overcome this, we propose an environment-free synthetic data generation approach that leverages LLMs as on-the-fly digital world models. Given only API specifications, our method generates trajectories mimicking interactions between an agent and a stateful environment. Specifically, an LLM first generates diverse tasks solvable with the provided APIs. A teacher agent then iteratively solves each task while an LLM simulator generates coherent synthetic API responses conditioned on the task context and simulation history. Finally, an LLM judge filters the trajectories to ensure the quality of the resulting dataset. We evaluate our approach on the challenging AppWorld and OfficeBench benchmarks, which include both information-retrieval and state-changing tasks. Fine-tuning models on our synthetic data yields significant performance gains, demonstrating that effective supervision for API-calling agents can be generated without any executable environment. Our results establish LLM-based API simulation as a practical, scalable solution for training agents across diverse API ecosystems.

Summary

  • The paper introduces ESAT, an LLM-centric pipeline that synthesizes stateful API interaction trajectories without requiring executable environments.
  • It decomposes the process into task synthesis, trajectory simulation, and precise LLM-based filtering to ensure high data quality and diversity.
  • ESAT-trained models achieve significant performance gains—up to 50.5% improvement—over traditional methods, demonstrating robust transfer across diverse API domains.

Environment-Free Synthetic Agentic Data Synthesis for API-Calling Agents

Motivation and Problem Statement

Training API-calling LLM agents fundamentally requires large-scale, high-fidelity multi-step agent-environment interaction data. Existing pipelines for generating such data demand executable environments with realistic API endpoints and populated backends, making both data coverage and domain adaptation expensive and slow. Direct manual collection is impractical, and synthetic approaches reliant on functional backends inherit major scalability bottlenecks due to infrastructure dependencies and the difficulty of producing diverse, state-rich environments.

ESAT Pipeline: Environment-Free Synthetic Agentic Trajectory Generation

The paper introduces ESAT, a specification-driven, LLM-centric pipeline that entirely obviates the need for executable API environments. ESAT synthesizes stateful, multi-turn agentic trajectories given only API specifications as input, using LLMs to simulate the digital world model at each trajectory step. The process is decomposed into three distinct stages:

  1. Task Synthesis: An LLM generates bucketized task prompts with coverage and diversity constraints (difficulty, action type, task focus, app count, API count). Tasks are post-processed by an LLM judge for solvability, and rewritten for intent-level conciseness.
  2. Trajectory Synthesis: For each task, a teacher agent LLM iteratively produces API calls; an LLM-based API simulator generates coherent, history-consistent JSON responses using current state, the input spec, user context, and trajectory history.
  3. Trajectory Filtering: A high-precision LLM judge filters complete trajectories for correctness, completeness, and redundancy, using explicit verification criteria.

This paradigm is diagrammed as a sequence of LLM modules converting simple API documentation to high-quality supervision data without executable APIs or real environments.

Simulator Mechanism and Quality Assurance

The API simulator is engineered as a persistent digital world model, receiving per-app interaction histories and context to ensure consistency for both read and write API endpoints. Validation integrates:

  • Deterministic input checks (parameter existence, type, constraint adherence)
  • Structural output schema enforcement (strict JSON schema validation, auto-feedback error correction via in-context prompting)
  • Semantic history checks using an LLM judge to rate each generated response for internal coherence and world-state consistency
  • Multi-stage retry and refinement loop with bounded attempts and explicit error amnesty triggers

This layered validation pipeline maintains high response validity even at substantial trajectory depths and task complexity, moving beyond prior LLM simulators prone to history drift and schema hallucination. Figure 1

Figure 1: Simulator failure rate as a function of output token length, as judged by GPT-5.1.

The simulation quality remains high (>93%>93\% valid responses per GPT-5.1), though error rates increase for extremely long output tokens, highlighting the architectural scaling path to even larger context or more capable LLMs for simulation robustness.

Dataset Synthesis, Diversity, and Coverage

ESAT is instantiated on two challenging testbeds: AppWorld (9 apps, 340–457 APIs, 10+ API/task, high compositionality) and OfficeBench (8 apps, office workflows, no public train split). ESAT generates data in three principal settings:

  • AppWorld APIs (ESAT-AW7): Trajectories using only seven AppWorld apps—strict generalization to held-out targets.
  • Synthetic App Suite (ESAT-S52): 52 automatically synthesized apps (1017 APIs), spanning ten functional domains beyond AppWorld, confirming transfer and compositional generalization.
  • OfficeBench APIs (ESAT-OB): Coverage-focused data for cross-app office settings.

The synthesized datasets (e.g., 9000+ ESAT-AW7 trajectories; near-complete API coverage for >>99% of APIs at all call-frequency thresholds) are empirically shown to avoid API distributional collapse, a common mode in prior tool/data generation approaches. Figure 2

Figure 2: API coverage across the 340 AppWorld APIs, showing the number and percentage of APIs called in at least NN successful trajectories.

Downstream Performance: Supervised Fine-Tuning for Agent Models

Models trained exclusively with ESAT data (1.7B–27B Qwen3/Qwen3.5, as well as competitive baselines) achieve large and consistent performance improvements over base models, real-environment data, and prior synthetic tool-use datasets. Key results:

  • On AppWorld, ESAT-trained models outperform real-environment-trained models in most settings, with gains up to 50.5%50.5\% (Qwen3.5-9B).
  • Strong transfer from synthetic domains—ESAT-S52 consistently outperforms AppWorld data for all but the smallest models (e.g., Qwen3-4B: +43.1%+43.1\%, Qwen3.5-9B: +47.0%+47.0\% over zero-shot).
  • Knowledge distillation is effective: ESAT enables smaller models (Qwen3.5-9B/27B) to approach or surpass the performance of much larger LLM baselines (Nemotron-3-120B, GPT-4o).
  • On OfficeBench, ESAT data yields 5.260.5%5.2–60.5\% absolute gains, with medium models surpassing models an order of magnitude larger.

These improvements are stable across model sizes and are robust to the addition of app-specific or real-environment data. Figure 3

Figure 3: API coverage across our synthetic app APIs, showing the number (and percentage) of APIs called in at least NN successful trajectories.

Comparison with Prior Synthetic Data Pipelines

Benchmarks against state-of-the-art synthetic datasets (ToolAlpaca, ToolACE, Nemotron) demonstrate that simple tool-call datasets lacking stateful world models do not support robust agent learning in high-complexity settings. ESAT-trained agents achieve much higher downstream scores on both AppWorld and OfficeBench, with competitor methods sometimes underperforming even the base model.

Implications and Prospects

The results establish that LLMs can function as generic, stateful API environment simulators—provided world modeling, schema constraints, and trajectory-level state are carefully preserved. ESAT induces a scalable regime for agentic trajectory construction, decoupled from the need for backend instantiation, crowd data ops, or complex RL training-inference loops. Environment-free data pipelines, with semantic and schema filtering, are thus practical for bootstrapping new API domains, evaluating agent robustness, or stress-testing safety mechanisms across compositional benchmarks. Figure 4

Figure 4: API coverage by frequency threshold for OfficeBench apps.

Theoretically, this suggests a unification path: large foundation models already encode actionable priors for downstream environment simulation, enabling both teacher and world functions in a single architecture. Empirically, this unlocks a rapid domain adaptation and prototyping capability—agents can be prepared for never-seen apps and APIs without infrastructure lead time. However, coverage for extreme compositionality and safety-critical edge cases may still require extensions in prompt engineering, schema verification, or stronger LLM pretraining.

Conclusion

The ESAT pipeline demonstrates that end-to-end, environment-free agentic trajectory synthesis is not only feasible but produces training data of sufficient fidelity and diversity to outperform infrastructure-heavy alternatives on canonical API-calling agent benchmarks. LLM-based simulation, coupled with structured task generation and stringent quality filtering, is an effective paradigm for scalable, specification-driven agent supervision. This reframes open challenges in agent data collection, robustness, and domain transfer, establishing new baselines for both method development and empirical evaluation in LLM agent research.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

Explain it Like I'm 14

Overview

This paper is about teaching AI helpers to use tools and apps by themselves. These helpers don’t just chat—they make “API calls,” which are like sending commands to apps (for example, “create a calendar event” or “send money”). Normally, training these helpers requires building full, working practice worlds with real apps and databases—this is slow and expensive. The paper introduces a new way to create high‑quality practice data without building any real apps at all. Instead, it uses powerful LLMs to pretend to be the apps and generate realistic practice sessions.

What questions did the researchers ask?

They focused on three simple questions:

  • Can we create good training data for tool‑using AIs using only the app instruction manuals (API specifications), without building the actual apps?
  • Can a LLM act like a believable “digital world” that remembers changes (like money sent or files created) across multiple steps?
  • Will training on this pretend-but-consistent data actually make AI helpers better at using tools in real tests?

How did they do it?

Think of it like a realistic driving simulator—but for apps.

They built a 3‑step pipeline called ESAT that starts with only API specifications (these are documents that say what each tool does, what inputs it needs, and what it outputs).

Here are the three stages:

  1. Task Synthesis: An AI writes lots of different, well-balanced tasks that could be solved using the given APIs (for example, “Find the cheapest flight and email the plan”). Another AI checks and fixes or rejects bad tasks. They also make sure tasks cover easy/hard cases, different action types (read data, change data), and different combinations of apps and tools.
  2. Trajectory Synthesis: A “teacher” AI tries to solve each task step by step by making API calls. A second AI acts as the simulator—like a make‑believe app that replies with what would happen. Importantly, the simulator remembers state, just like the real world. If you add a song to a playlist, it stays there later. The system checks each simulated response for:
    • correct format (matches the API’s rules),
    • realistic values (IDs look like IDs, numbers are in range),
    • consistency with the past steps. If something’s off, it tries again a few times.
  3. Trajectory Filtering: A “judge” AI reviews the full solution to decide whether the task was solved correctly and cleanly. Only high‑quality examples are kept as training data.

A few helpful translations of technical terms:

  • API: A set of commands that let one program talk to another (like a menu of actions an app can do).
  • Environment: The world the agent interacts with (apps, databases, and what changes across time).
  • Stateful: The world remembers what already happened (like a bank account balance changing after sending money).
  • Trajectory: The play‑by‑play record of a task, including the agent’s thoughts, the API calls it made, and the responses it got.

The simulator followed four simple rules to stay believable:

  • Keep data consistent over time (no forgetting or contradicting earlier steps).
  • Include some extra but realistic details (not every result should be perfectly relevant, like real search results).
  • Respect each field’s rules (right types, realistic ranges, unique IDs).
  • Match the exact format the API describes.

What did they find, and why does it matter?

They tested the trained agents on two tough benchmarks:

  • AppWorld: Many apps and 457 APIs, with tasks that often need 10+ different tools and lots of steps.
  • OfficeBench: Office tasks across multiple apps (like spreadsheets, calendars, and email).

Main results:

  • Training on ESAT’s synthetic data gave large improvements on both benchmarks—up to about 50.5% on AppWorld and 60.5% on OfficeBench compared to the same models without this training.
  • In AppWorld, models trained on ESAT’s synthetic data sometimes beat models trained on data collected from the real, working AppWorld environment.
  • Smaller models trained with ESAT data sometimes outperformed much larger models that hadn’t been trained with this data. That means the approach helps “teach” strong tool‑use skills efficiently.
  • The judge AI that filters data was very accurate: when it said a solution was correct, it matched real environment checks about 95% of the time and agreed with human reviewers about 95% of the time.
  • The simulator produced valid, consistent responses for about 94% of API calls; mistakes were more common only when very long outputs were required.

Why it matters:

  • You no longer need to build full, complex test environments and databases just to create training data. You can scale to many apps and tools quickly by starting from their API specifications.
  • The training data captures realistic, multi‑step behavior with memory, which is exactly what tool‑using AIs need to learn.

What does this mean for the future?

  • Faster development: Companies can train helpful tool‑using AIs for new apps much quicker, because they only need API specs—not full working systems.
  • Cheaper and broader training: It becomes practical to cover many app types and unusual situations, leading to more reliable agents.
  • Better small models: Even smaller AIs can learn strong skills, making powerful assistants more accessible.
  • Safer testing ground: Because everything is simulated, you can practice risky or sensitive actions without touching real data.

A simple takeaway: With good instructions (API specs) and smart simulation, we can teach AIs to use tools well—without building the full world for them to practice in. This makes training faster, cheaper, and surprisingly effective.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a concise list of concrete gaps and open questions that remain unresolved by the paper and could guide future research.

  • Robustness to imperfect API specifications: How does ESAT handle incomplete, ambiguous, inconsistent, or noisy API descriptions (e.g., underspecified field constraints, undocumented defaults, outdated schemas)?
  • Cross-app state coherence: The simulator truncates history to the same app for efficiency; how often does this break dependencies across apps in multi-app tasks, and how can cross-app state be tracked efficiently?
  • Fidelity of write operations: Beyond schema conformance, to what extent do simulated write APIs preserve realistic state transitions, invariants, and side effects (e.g., idempotency, constraints, referential integrity)?
  • Real-environment validation of ESAT trajectories: The paper validates the judge on real-executed trajectories, but does not validate ESAT-synthesized trajectories against live environments; what proportion would execute successfully end-to-end?
  • Simulator-induced bias: Do models overfit to artifacts or stylistic regularities of the simulator’s responses rather than acquiring generally applicable tool-use skills? How can such biases be detected and mitigated?
  • Adversarial and failure modes: The simulator does not appear to model realistic failures (e.g., timeouts, rate limits, partial successes, permission errors, version mismatches). How does training on such distributions affect real-world robustness?
  • Asynchrony and concurrency: How would ESAT handle asynchronous APIs, long-running jobs, callbacks, race conditions, or transactional semantics?
  • Authentication, authorization, and security policies: The simulation ignores auth scopes, revocation, consent, and policy checks; how can these be incorporated to teach safe and compliant tool use?
  • Safety and prompt-injection resilience: Simulated environments rarely emulate malicious or adversarial tool outputs; how can ESAT generate adversarial trajectories that harden agents against tool-driven prompt injection or data poisoning?
  • Multimodal APIs: OfficeBench OCR tasks were excluded; how can the approach be extended to vision/audio/multimodal APIs with grounded outputs (e.g., images, PDFs) and verification?
  • Long-output degradation: Simulator failure rate rises sharply with long responses; can structured generation (e.g., constrained decoding, programmatic state stores, tool-specific validators) or stronger simulators eliminate this length sensitivity?
  • Schema and cross-field constraint checking: Programmatic validation checks types and top-level schema, but not richer cross-field dependencies and domain constraints; how to systematically encode and verify these?
  • Trajectory termination mechanism: Relying on a special “task completion API” may not reflect real settings; can termination be detected without a synthetic API, and does training on this pattern bias agents?
  • Task synthesis coverage: Bucketized configurations and inverse-frequency sampling may miss long-tail or compositional patterns; what coverage metrics and diversification strategies ensure broad capability learning?
  • Task rewriting impact: The rewriting step may alter solvability or difficulty; what is its quantitative effect on downstream performance and data validity?
  • Judge dependence and bias: Trajectory filtering relies on a proprietary frontier model (Gemini) with high precision but unreported recall; how sensitive are results to judge choice, prompt design, and decision thresholds?
  • Reproducibility and openness: Heavy dependence on closed models (GLM FP8 variants, Gemini) raises reproducibility and cost concerns; can open-model equivalents match quality and how does performance vary across simulators/judges?
  • Cost, throughput, and carbon footprint: The paper omits compute budgets, wall-clock times, and energy use; what are the scaling curves and practical cost-quality trade-offs to reach millions of trajectories?
  • Sample efficiency: What is the marginal utility of additional trajectories per app/API/bucket, and where do diminishing returns set in?
  • Generalization beyond benchmarks: AppWorld and OfficeBench are synthetic/sandboxed; how does ESAT-trained performance translate to production APIs with messy schemas, evolving versions, and heterogeneous data?
  • Domain shift in user data: The simulator invents virtual user states; how can we measure and control distributional alignment between simulated and target user populations to improve transfer?
  • Error-handling skills: Do agents learn robust recovery strategies (retries, fallbacks, alternative plans) from simulated errors? A targeted evaluation of error-handling is missing.
  • Identifier grounding and entity tracking: The paper claims reduced hallucinations but lacks quantitative analysis of ID reuse, deduplication, and entity linking across long trajectories.
  • Parameter and design ablations: Effects of simulator refinement steps, history window size, bucket settings, and filtering vote counts are not systematically ablated.
  • Curriculum and capability staging: Is a staged curriculum (progressive difficulty, tool subsets, or compositional scaffolding) more effective than uniform bucketized sampling?
  • Versioning and schema evolution: How to simulate API deprecations, breaking changes, and backward compatibility so agents learn to adapt to evolving tool ecosystems?
  • Multi-agent settings: Can ESAT extend to collaborative or competitive agents coordinating via APIs, and does simulator coherence hold in multi-agent interactions?
  • Data quality diagnostics: Beyond length-based failure analysis, a taxonomy of simulator errors (state drift, constraint violations, semantic contradictions) and their frequencies is missing.
  • Privacy and synthetic PII: The simulator emits names/emails/phones; what are the privacy implications and memorization risks, and how should synthetic PII be generated and audited?
  • Negative side effects: Does large-scale training on synthetic trajectories degrade capabilities elsewhere (e.g., increased hallucinations in non-tool tasks)? No off-task evaluation is reported.
  • Mixed real-and-sim data strategies: How should real logs, real executions, and ESAT data be optimally combined (weighting, curriculum, domain adaptation) for best transfer?
  • RL or interactive fine-tuning: ESAT focuses on SFT; can RLHF/ToT/RLAIF with simulated feedback further improve tool-use robustness, and how do simulator biases affect RL stability?
  • API description languages: How well does ESAT handle diverse spec formats (OpenAPI, JSON Schema, bespoke docs), and what automated parsing/normalization is needed for broad portability?
  • Evaluation per capability: Lack of fine-grained capability metrics (state-tracking, cross-app joins, temporal constraints, aggregation, error recovery) obscures where ESAT helps most and where it falls short.

Practical Applications

Practical Applications of “Environment-free Synthetic Data Generation for API-Calling Agents”

Below are actionable, real-world applications that leverage the paper’s ESAT pipeline (task synthesis from API specs, LLM-based API simulation for read/write tools, and LLM judging/curation). Each item includes sector links, potential tools/products/workflows, and feasibility assumptions/dependencies.

Immediate Applications

  • Rapid bootstrapping of AI copilots for SaaS ecosystems
    • Sectors: software, enterprise SaaS (CRM/ERP/HRIS/ITSM/DevOps), productivity
    • What: Generate high-quality, multi-step training trajectories for tool-using agents using only API specs (e.g., OpenAPI), avoiding the need to stand up sandboxes or populate mock databases.
    • Tools/products/workflows: “Agent Training Factory” that ingests API specifications, auto-generates tasks/trajectories, fine-tunes organization-specific models; “API Spec Sandbox” offering on-the-fly simulation for pre-deployment agent QA.
    • Assumptions/dependencies: Requires reasonably complete and accurate API specs; access to capable LLMs for simulator and judge; governance over synthetic data inclusion in training.
  • Enterprise QA and regression testing for tool-using agents
    • Sectors: software quality engineering, MLOps
    • What: Use ESAT to create diverse, stateful workflows to test agent behavior across API versions and edge cases (including write APIs), detecting regressions without backend environments.
    • Tools/products/workflows: CI pipelines that call the ESAT simulator for nightly regression suites; “Spec-based Scenario Coverage” dashboards showing API/flow coverage.
    • Assumptions/dependencies: Spec/schema compliance must be enforced; consistent use of judge to maintain trajectory correctness; tracking of state consistency across long horizons.
  • Red teaming and safety evaluation of tool-use
    • Sectors: security, AI safety
    • What: Emulate risky or policy-sensitive tool-calling paths (e.g., mass emails, financial transactions) to stress-test agent guardrails, input validation, and escalation workflows.
    • Tools/products/workflows: “Tool-Use Red Team Kit” that generates challenging tasks and simulated responses (including realistic noise) to probe agent safety policies.
    • Assumptions/dependencies: Clear risk scenarios defined in prompts; human review of critical/safety findings; simulator must reflect realistic constraints/limits set by the API spec.
  • Privacy-preserving data generation
    • Sectors: healthcare (non-clinical workflows), finance (non-PII scenarios), government services (non-sensitive)
    • What: Produce training data that mimics operational workflows without touching production records, enabling agent development under strict privacy regimes.
    • Tools/products/workflows: Controlled synthetic datasets for internal training; audit logs showing no ingestion of real user data; integration with DLP policies.
    • Assumptions/dependencies: Synthetic outputs must avoid reconstruction of sensitive, proprietary specifics; legal approval for synthetic data use; careful prompt design to avoid inadvertent leakage.
  • Documentation QA and API spec linting via simulation
    • Sectors: developer platforms, API management
    • What: Detect ambiguities and inconsistencies in API documentation by stressing the simulator (e.g., schema mismatches trigger errors that pinpoint doc gaps).
    • Tools/products/workflows: “Spec Linter via Simulation” that reports missing constraints, invalid defaults, ambiguous fields; auto-suggested doc fixes.
    • Assumptions/dependencies: Availability of machine-readable specs (OpenAPI/JSON Schema); organizational process to iterate docs based on simulator feedback.
  • Benchmarking and vendor selection for agent platforms
    • Sectors: procurement, enterprise IT
    • What: Use ESAT to generate domain-specific test suites from API specs and compare candidate agent stacks on identical, stateful scenarios.
    • Tools/products/workflows: “Agent Benchmark-in-a-Box” using ESAT tasks/trajectories; standardized scoring (e.g., TGC/SGC-style metrics).
    • Assumptions/dependencies: Agreement on evaluation criteria; reliable judge calibration; comparable inference budgets across vendors.
  • Education and training sandboxes for API tool-use
    • Sectors: education, developer enablement
    • What: Create realistic labs for courses on LLM agents and tool integration without provisioning backends.
    • Tools/products/workflows: Classroom “virtual environments” built from API specs; assignments graded by LLM judges; code+prompt notebooks with simulator-in-the-loop.
    • Assumptions/dependencies: Stable access to LLMs within cost limits; curated tasks at appropriate difficulty levels; instructor oversight for edge-case correctness.
  • Internal developer productivity (personal/enterprise automation)
    • Sectors: daily life/productivity, internal tooling
    • What: Quickly prototype personal automations (e.g., calendar+email+docs flows) by simulating the target APIs and generating training traces for a personal assistant.
    • Tools/products/workflows: Self-serve “workflow assistant builder” that imports API specs from personal SaaS accounts and produces local fine-tunes or prompts.
    • Assumptions/dependencies: End-user ability to export API specs; safe key/permission handling for eventual deployment against real services.
  • Knowledge distillation to smaller models
    • Sectors: edge AI, cost optimization
    • What: Use ESAT-generated trajectories to train compact models (2B–9B) that match or exceed much larger baselines on tool-use tasks.
    • Tools/products/workflows: Distillation pipelines that generate trajectories with frontier models and fine-tune smaller, cheaper models for production.
    • Assumptions/dependencies: Access to capable teacher simulators; careful filtering (high-precision judge) to prevent error propagation.
  • Cross-app workflow prototyping and UX design
    • Sectors: product management, UX
    • What: Simulate multi-app workflows (read+write sequences) to evaluate task designs and user intents before API implementation or data seeding.
    • Tools/products/workflows: “Workflow Storyboard” that synthesizes tasks, calls, and responses to inform product decisions and functional requirements.
    • Assumptions/dependencies: High-fidelity API specs even for planned endpoints; designer literacy in interpreting synthetic trajectories.

Long-Term Applications

  • Sector-specific agent training without environments in regulated domains
    • Sectors: healthcare (EHR scheduling, non-diagnostic admin tasks), finance (transactions, onboarding), public sector (case management)
    • What: Train agents using ESAT where live testbeds are restricted, then validate against constrained, real environments.
    • Tools/products/workflows: “Regulated Sandbox” ESAT layers with explicit policy constraints and auditability; phased rollout from simulated to real endpoints.
    • Assumptions/dependencies: Extensive verification/validation frameworks; regulator-approved synthetic data practices; robust alignment on side-effects from write APIs.
  • Continuous, spec-driven agent lifecycle management
    • Sectors: MLOps, platform engineering
    • What: Tie ESAT to API version control so every spec change triggers automatic generation of new tasks and trajectories, retraining or regression evaluation.
    • Tools/products/workflows: “SpecOps” pipelines integrating ESAT with Git/CI, auto-curation with judges, and drift/coverage reports.
    • Assumptions/dependencies: Standardized spec hygiene across teams; compute budgets for continual data synthesis and fine-tuning; change management policies.
  • Industry standards for simulation-ready API specifications
    • Sectors: policy, standards bodies (e.g., OpenAPI community), developer platforms
    • What: Promote spec conventions that encode constraints, state semantics, and validation rules to enable high-fidelity simulation and training.
    • Tools/products/workflows: “Simulation Readiness” checklists; extensions to OpenAPI/JSON Schema for stateful behaviors and uniqueness constraints.
    • Assumptions/dependencies: Broad industry adoption; tooling ecosystem to validate conformance; governance on schema evolution.
  • API virtualization for agent marketplaces and app stores
    • Sectors: software marketplaces, ecosystem curation
    • What: Host ESAT-backed simulators for third-party APIs so developers can test/badge agents pre-integration, improving trust and interoperability.
    • Tools/products/workflows: “Agent Sandbox Certification” where agents must pass ESAT-simulated scenarios before listing; automated judge reports.
    • Assumptions/dependencies: Marketplace governance; incentives for API providers to publish high-quality specs; standardized badges/metrics.
  • Advanced safety and compliance testing with hazardous-state synthesis
    • Sectors: safety-critical software, compliance
    • What: Generate rare or hazardous state combinations (e.g., conflicting permissions, quota exhaustion) to pressure-test agent error recovery and escalation policies.
    • Tools/products/workflows: Compliance suites that synthesize long-horizon failure chains; automated incident taxonomy from judge outputs.
    • Assumptions/dependencies: Calibrated simulator that can reliably model edge constraints; human oversight for high-stakes scenarios.
  • Data minimization and provenance-aware training at scale
    • Sectors: data governance, privacy engineering
    • What: Replace portions of real interaction logs with high-fidelity ESAT trajectories to reduce exposure to personal or proprietary data while maintaining agent performance.
    • Tools/products/workflows: Provenance trackers marking synthetic vs. real data; risk-weighted curation strategies; policy-compliant retention.
    • Assumptions/dependencies: Demonstrable equivalence (or superior generalization) of synthetic training compared to real logs; buy-in from legal/compliance.
  • Integration with reinforcement learning and closed-loop evaluation
    • Sectors: research, advanced MLOps
    • What: Combine ESAT-generated trajectories with RL fine-tuning in simulated settings, then progressively introduce real API calls for sim-to-real transfer.
    • Tools/products/workflows: Curriculum generation that escalates complexity and uncertainty; judge-in-the-loop reward shaping.
    • Assumptions/dependencies: Reliable state consistency over long horizons; methods to bridge sim-to-real gaps; safeguards for write-side effects.
  • Domain-general “digital world models” for tool ecosystems
    • Sectors: multi-domain platforms (travel, logistics, commerce, IT)
    • What: Evolve simulators that maintain coherent, persistent state across many apps and users, supporting complex, long-running automations.
    • Tools/products/workflows: Persistent simulation backends with memory and identity; scenario planners mixing task types (read, write, mixed).
    • Assumptions/dependencies: Frontier LLMs or hybrid simulators with improved long-context consistency; efficient memory/state representations.
  • On-device or edge agent personalization via local spec ingestion
    • Sectors: consumer devices, enterprise edge
    • What: Enable devices to ingest local app specs and generate synthetic training tasks privately, personalizing agents to a user’s toolset without cloud data.
    • Tools/products/workflows: Lightweight ESAT runtimes; small fine-tunes or prompt adapters executed on-device.
    • Assumptions/dependencies: Sufficient on-device compute or quantized models; power-efficient inference; compact judges or heuristic filters.
  • Public-sector policy sandboxes for AI service delivery
    • Sectors: government, civic tech
    • What: Test and validate citizen-facing AI agents (e.g., benefits triage) using ESAT-generated scenarios that cover diverse citizen states without accessing real records.
    • Tools/products/workflows: Policy sandboxes with published specs; transparent judge criteria and public audit reports.
    • Assumptions/dependencies: Policy frameworks for synthetic scenario testing; civic oversight; careful fairness and bias evaluation.

Notes on feasibility across applications:

  • The ESAT approach relies on high-quality API specifications and effective LLMs for simulation and judging. The paper’s results indicate high precision of the judge (≈95%) and strong downstream performance, but long, complex outputs increase simulator failure rates. Frontier or specialized models and improved spec standards will further enhance reliability, especially for high-stakes or long-horizon workflows.

Glossary

  • agentic trajectories: Multi-step records of an agent’s reasoning, tool calls, and outcomes during problem-solving. "A variety of contemporary works now utilize LLMs to automatically synthesize agentic trajectories at scale"
  • API-calling agents: LLM-based systems that use external tools or services by issuing API calls to complete tasks. "Training API-calling LLM agents demands massive amounts of high-quality trajectories."
  • API simulator: A model that emulates API responses without executing real services, enabling synthetic interactions. "the core trajectory synthesis stage pairs a teacher agent with our LLM-based API simulator."
  • API specifications: Formal descriptions of API names, purposes, inputs, and outputs used to guide generation and simulation. "Given only API specifications, our method generates trajectories mimicking interactions between an agent and a stateful environment."
  • AppWorld: A multi-app benchmark environment with hundreds of APIs for evaluating complex agent workflows. "We evaluate our approach on the challenging AppWorld and OfficeBench benchmarks"
  • backend databases: Data stores that real APIs would read from or write to; often required by executable environments. "backend databases filled with realistic underlying states"
  • bucketized generation: A task-generation strategy that organizes prompts into predefined configuration buckets for balanced coverage. "Bucketized generation."
  • digital world model: An LLM-driven simulation maintaining state and producing coherent environment feedback across steps. "a context-aware, LLM-based API simulator that acts as a dynamic digital world model."
  • environment-free: A setup that avoids building or running real environments by simulating all feedback via LLMs. "we propose an environment-free synthetic data generation approach"
  • execution-based verifiers: Automated checks that run tasks against a real environment to label success or failure. "obtained ground-truth trajectory labels from AppWorld's execution-based verifiers."
  • frontier models: The most capable, cutting-edge LLMs used for judging or generation. "using another frontier model and observed similar trends."
  • inverse frequency-based sampling: A selection method that favors underrepresented apps/APIs to ensure balanced data. "we employ an inverse frequency-based sampling strategy."
  • knowledge distillation: Transferring capabilities from stronger models or data sources to smaller models during training. "This demonstrates the efficacy of our approach for knowledge distillation, confirming that complex API-calling capabilities can be transferred to smaller models using purely synthetic, environment-free data."
  • LLM-as-a-judge bias: Potential systematic errors when using LLMs to evaluate outputs instead of humans or executable checks. "To mitigate potential LLM-as-a-judge bias, we performed the same analysis using another frontier model and observed similar trends."
  • LLM judge: An LLM used to evaluate and filter generated tasks or trajectories for quality and correctness. "Finally, an LLM judge filters the trajectories to ensure the quality of the resulting dataset."
  • long-context capabilities: The ability of modern LLMs to condition on lengthy histories to maintain state and coherence. "leveraging the long-context capabilities of modern LLMs"
  • long-horizon workflows: Multi-step, cross-app procedures requiring extended planning and coordination. "Tasks require agents to plan long-horizon workflows across apps, such as extracting spreadsheet data, scheduling calendar events, and dispatching emails."
  • multi-app benchmarks: Evaluations that require an agent to use multiple applications/APIs within a single task. "We evaluated our approach on two challenging, multi-app benchmarks designed to test complex API interactions."
  • offline evaluation: Assessing tool usage or outputs without live execution, often via simulation. "a GPT-4 simulator as a fallback for the offline evaluation of read APIs."
  • OfficeBench: A benchmark focused on office-automation tasks across multiple apps and APIs. "We evaluate our approach on the challenging AppWorld and OfficeBench benchmarks"
  • read APIs: Endpoints that retrieve information without changing the underlying state. "most simulators focus on read APIs"
  • reinforcement learning (RL): A training paradigm where agents learn via reward signals through interactions. "replacing real environments with simulated feedback during RL."
  • schema compliance: Strict adherence of outputs to the fields and types specified in an API schema. "Schema compliance: responses must strictly conform to the schema provided in the API specification."
  • scenario goal completion (SGC): A benchmark metric measuring whether overall scenario-level objectives are met. "we report the task and scenario goal completion (TGC and SGC)."
  • seed trajectories: Initial example traces used to bootstrap or augment training data generation. "by augmenting seed trajectories for SFT"
  • state drift: Loss of consistency in simulated state across long interactions. "leaves them vulnerable to state drift and hallucinated identifiers in long, complex trajectories."
  • stateful environment: An environment whose data can change over time and must be tracked across steps. "mimicking interactions between an agent and a stateful environment."
  • supervised fine-tuning (SFT): Training a model on labeled sequences to imitate desired behaviors. "supervised fine-tuning (SFT) on ESAT data leads to significant performance improvements"
  • task completion API: A special endpoint indicating that the agent believes it has finished the task. "explicitly calls a special task completion API"
  • task goal completion (TGC): A benchmark metric measuring whether specific task-level goals are achieved. "we report the task and scenario goal completion (TGC and SGC)."
  • task synthesis: Automatic generation of task instructions from API specs and configuration controls. "First, during the task synthesis stage"
  • teacher agent: A stronger agent that demonstrates trajectories, guiding data generation. "pairs a teacher agent with our LLM-based API simulator."
  • trajectory curation: Selecting and refining generated trajectories to form a high-quality training set. "employing GLM for trajectory curation actually degrades the performance."
  • trajectory filtering: Post-processing step where an LLM judge accepts or rejects entire trajectories for quality. "Finally, during trajectory filtering, an LLM judge evaluates the generated trajectories for correctness, completeness, and redundancy"
  • trajectory synthesis: The process of generating complete multi-step traces via agent–simulator interaction. "the core trajectory synthesis stage pairs a teacher agent with our LLM-based API simulator."
  • write APIs: Endpoints that modify state; also called state-changing APIs. "ESAT supports state-changing write APIs"
  • zero-shot: Evaluating a model without task-specific training or fine-tuning. "Off-the-shelf models (zero-shot)"

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 2 tweets with 60 likes about this paper.