StateGen: Explicit State-based Generation

• StateGen is a generation framework that organizes synthetic-data creation around an explicit state object to enforce backend consistency and prevent tool-call hallucinations.
• It employs multi-agent loops and state-machine API modeling, generating scored conversations and executable programs with validated state transitions.
• The state-based design pattern extends to systems like StoryState, Graph State-Space Models, and Deep Generative Markov State Models, showcasing scalable orchestration.

Searching arXiv for papers directly related to "StateGen" and adjacent state-based generation frameworks. StateGen denotes a state-centered generation perspective in which generation, editing, simulation, or evaluation is organized around an explicit state object rather than left implicit in prompts, model activations, or unconstrained tool responses. In recent arXiv literature, the name appears explicitly in two systems. "State-Grounded Multi-Agent Synthetic Data Generation for Tool-Augmented LLMs" defines StateGen as a synthetic data generation platform that produces scored, reasoning-trace-rich training conversations through a four-role LLM loop plus an authoritative state manager maintaining a structured world-state object across turns (Khedar et al., 15 Jun 2026). "Evaluating LLMs on Sequential API Call Through Automated Test Generation" defines StateGen as an automated framework that generates executable programs for stateful API interactions through state-machine-based API constraint solving and validation, energy-based sampling, control-flow injection, and code-to-instruction translation (Huang et al., 13 Jul 2025). The same state-explicit viewpoint also appears as a broader design pattern in related systems such as StoryState, Graph State-Space Models, UniGen, and Deep Generative Markov State Models (Sarkar et al., 1 Feb 2026, Zambon et al., 2023, Mahjourian et al., 2024, Wu et al., 2018).

1. Formal scope and defining abstractions

In the state-grounded synthetic-data system, the central object is a structured world-state object $\mathcal{S}_t$ with initialization

$\mathcal{S}_0 = \mathcal{F}_s,$

where $\mathcal{F}_s$ are the scenario’s system facts. A fact enters $\mathcal{S}_t$ if and only if it either was in $\mathcal{S}_0 = \mathcal{F}_s$, or was legally created by a tool call $a_j$ with write authority. The paper calls this the backend-is-truth invariant, and it is the mechanism by which tool-call hallucinations are prevented by construction (Khedar et al., 15 Jun 2026).

In the automated API-task generation system, the formalization starts from a sequence of program states

$S=(s_1,s_2,\ldots,s_n)$

and a sequence of API calls

$O=(o_1,o_2,\ldots,o_n),$

with each API modeled as a transition

$$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$

The ending value of a state variable is expressed as a composition of API-induced transformations,

$$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$

Here state is the object on which legality, executability, and semantic correctness are defined (Huang et al., 13 Jul 2025).

System	State object	Primary output
State-grounded multi-agent synthetic data generation	$\mathcal{S}_0 = \mathcal{F}_s,$0, initialized as $\mathcal{S}_0 = \mathcal{F}_s,$1	scored conversation $\mathcal{S}_0 = \mathcal{F}_s,$2, judge vector $\mathcal{S}_0 = \mathcal{F}_s,$3
Automated sequential API test generation	$\mathcal{S}_0 = \mathcal{F}_s,$4, with $\mathcal{S}_0 = \mathcal{F}_s,$5	natural-language task, executable reference program, runtime oracle

This suggests a common abstraction: StateGen systems use explicit state not merely as memory, but as the object through which validity, locality, and downstream evaluation are defined.

2. State-grounded multi-agent synthetic data generation

The synthetic-data StateGen system is organized as a coordinated multi-role loop with four conversational LLM roles plus an authoritative state manager. The four active roles are a persona-conditioned user simulator, the agent under test, a state-grounded tool simulator, and a multi-axis LLM judge; the state manager maintains backend consistency across turns. The three inputs are a structured YAML scenario containing user facts $\mathcal{S}_0 = \mathcal{F}_s,$6, system facts $\mathcal{S}_0 = \mathcal{F}_s,$7, a user goal $\mathcal{S}_0 = \mathcal{F}_s,$8, and an expected final state $\mathcal{S}_0 = \mathcal{F}_s,$9; a 23-dimensional persona vector $\mathcal{F}_s$0; and a playbook containing the orchestrator system prompt, tool definitions with JSON schemas, per-tool capability templates, and optionally guardrail templates (Khedar et al., 15 Jun 2026).

At tool step $\mathcal{F}_s$1, if the agent issues a tool call

$\mathcal{F}_s$2

the tool simulator produces a response conditioned on the current state and the tool template,

$\mathcal{F}_s$3

and the state manager updates the world state by

$\mathcal{F}_s$4

The core invariant is that a simulated API cannot find nonexistent records, invent transaction IDs, fabricate balances, or otherwise create unsupported facts. This is stronger than prompting a tool-simulator model to be careful because the system gives the episode an explicit memory of backend reality and forces every turn to stay aligned to it (Khedar et al., 15 Jun 2026).

A full episode proceeds by initializing the world state, sampling or assigning a persona vector, generating user turns, letting the agent answer or call tools, updating the world state after each tool step, and finally scoring the transcript against $\mathcal{F}_s$5. The pseudocode sets $\mathcal{F}_s$6 turns and $\mathcal{F}_s$7 tool calls per turn. The exported JSONL stores one conversation per line as a {messages, tools, metadata} object, with reasoning as a first-class field on assistant messages, no spurious tool-response messages after terminal actions, and metadata containing judge scores, scenario ID, persona profile, and complexity tier (Khedar et al., 15 Jun 2026).

The persona model has 23 dimensions in three tiers. Tier 1 contains six categorical demographic attributes. Tier 2 contains twelve continuous behavioral traits in $\mathcal{F}_s$8, sampled around a hand-curated base vector with

$\mathcal{F}_s$9

Tier 3 contains five continuous emotional-state traits with scenario-reactive deltas,

$\mathcal{S}_t$0

Orthogonal to persona, the system adds a four-level query-complexity overlay: simple, medium, complex, and vague (Khedar et al., 15 Jun 2026).

The judge scores each conversation on eight independent criteria from 1 to 10: Goal achievement, Tool usage, Tool-call hallucination, Reasoning quality, Reasoning hallucination, Communication quality, Consistency, and Error handling. It also returns a holistic overall score and a boolean goal-achieved flag. On 64,698 conversations across three corpora, the highest-profile result is a tool-call hallucination score of $\mathcal{S}_t$1 on 49,331 conversations in the mixed corpus. Per-criterion means on that corpus are Goal achievement $\mathcal{S}_t$2, Tool usage $\mathcal{S}_t$3, Tool-call hallucination $\mathcal{S}_t$4, Reasoning quality $\mathcal{S}_t$5, Reasoning hallucination $\mathcal{S}_t$6, Communication $\mathcal{S}_t$7, Consistency $\mathcal{S}_t$8, and Error handling $\mathcal{S}_t$9. The system also supports hierarchical multi-agent settings by declaring sub-agents as tools, all sharing a single state object (Khedar et al., 15 Jun 2026).

The train–golden split is central to the paper’s not memorization bait argument. The corpora are Mixed (Mar 2026): 49,331 conversations, 312 scenarios, training pool; CRM Train (Apr 2026): 12,224 conversations, 77 scenarios; and CRM Golden (Apr 2026): 3,143 conversations, 20 scenarios, benchmark set with zero overlap from CRM train. The reported overall score falls from $\mathcal{S}_0 = \mathcal{F}_s$0 on CRM Train to $\mathcal{S}_0 = \mathcal{F}_s$1 on CRM Golden, while channel safety changes only from $\mathcal{S}_0 = \mathcal{F}_s$2 to $\mathcal{S}_0 = \mathcal{F}_s$3 (Khedar et al., 15 Jun 2026).

3. Automated generation of stateful API-call tasks

The second explicit StateGen system addresses evaluation rather than training-data synthesis. Its problem setting is code generation under evolving program state, where a task is not just pick the right API, but generate a program containing a sequence of calls whose legality and meaning depend on intermediate states created or modified by earlier calls. The framework follows a reverse-generation strategy: it first generates valid executable programs, then converts those programs into human-like instructions (Huang et al., 13 Jul 2025).

The core mechanism is a state-machine-based trace generator. At generation step $\mathcal{S}_0 = \mathcal{F}_s$4, the candidate transition set is

$\mathcal{S}_0 = \mathcal{F}_s$5

Coverage guidance assigns inverse-frequency energy weights

$\mathcal{S}_0 = \mathcal{F}_s$6

and identifies uncovered pair transitions

$\mathcal{S}_0 = \mathcal{F}_s$7

If new coverage exists, it is prioritized; otherwise the next API call is sampled according to

$\mathcal{S}_0 = \mathcal{F}_s$8

The state schema is then updated by

$\mathcal{S}_0 = \mathcal{F}_s$9

and the chosen call is appended to the trace (Huang et al., 13 Jul 2025).

A particularly important notion is the pair transition. The paper treats the current transition as a consumer, collects the states associated with its input parameters, and identifies the most recent transitions that produced or affected those states. This is stronger than adjacency because it is connected through data or state dependency rather than textual order. For comparison across generation methods, the paper defines Adjacent Transition Coverage as

$a_j$0

where $a_j$1 is the total number of unique APIs in the application (Huang et al., 13 Jul 2025).

Linear traces are then turned into richer executable programs by adding initialization code, optional if-else branching, and a final RESULT sink variable. Control-flow injection is implemented by selecting a split point, cloning the TraceGenerator to create an else generator, continuing the original generator as the if branch, and then completing the else branch from the same split point. The implementation currently limits itself to a single split. Oracle expansion is obtained by changing the condition variable to force execution into the opposite branch if it is not a dead code block (Huang et al., 13 Jul 2025).

Instruction translation is carried out by a two-LLM-agent collaboration. The generator agent receives the initialization block and the generated program, and is instructed to produce an instruction that is unambiguous, natural and human-like, and non-redundant. The evaluator agent returns either <OK>, diagnosis plus suggestions, or <IMPOSSIBLE>. Both agents are GPT-4.1, and the maximum number of rounds is three. This stage is followed by manual review and filtering (Huang et al., 13 Jul 2025).

Using this framework, the authors build StateEval, a benchmark of 120 verified test cases. The construction process begins with 60 programs per scenario across three scenarios, each trace targeting five API calls, with optional if-else insertion at a random point. After manual review, 7 cases are removed from Session Service, 12 from Tensor Operation, and 8 from ElevenLabs MCP, and 40 remaining cases are sampled per scenario. The final benchmark has 120 total tasks and 40 per scenario (Huang et al., 13 Jul 2025).

The three scenarios are Session Service, Tensor Operation, and ElevenLabs MCP. Benchmark-level averages are Instruction Length $a_j$2, Code Length $a_j$3, Function Call Num $a_j$4, Path Depth $a_j$5, and Binding Count $a_j$6. Overall pass@1 on StateEval is GPT-4.1 $a_j$7, Gemini-2.5-Flash $a_j$8, GPT-4.1-nano $a_j$9, Llama-4-Scout $S=(s_1,s_2,\ldots,s_n)$0, and Qwen2.5-Coder $S=(s_1,s_2,\ldots,s_n)$1. The paper reports that execution errors dominate in Session Service and Tensor Operation, while result errors dominate in ElevenLabs MCP (Huang et al., 13 Jul 2025).

4. Broader StateGen-style design patterns

Recent work repeatedly treats explicit state as the single source of truth for generation and revision even when the system itself is not named StateGen. StoryState is a training-free, agent-orchestrated state compiler for illustrated storybooks, with story state

$S=(s_1,s_2,\ldots,s_n)$2

where $S=(s_1,s_2,\ldots,s_n)$3 is a character sheet, $S=(s_1,s_2,\ldots,s_n)$4 is world settings, and $S=(s_1,s_2,\ldots,s_n)$5 are page states. Edits are expressed as modifications to a minimal subset of $S=(s_1,s_2,\ldots,s_n)$6, while unrelated components remain unchanged. The Prompt Writer maps this state into a global identity prompt $S=(s_1,s_2,\ldots,s_n)$7 and page prompts $S=(s_1,s_2,\ldots,s_n)$8. On multi-page editing, StoryState reports Consistency $S=(s_1,s_2,\ldots,s_n)$9, Pages changed $O=(o_1,o_2,\ldots,o_n),$0, Turns $O=(o_1,o_2,\ldots,o_n),$1, and Time $O=(o_1,o_2,\ldots,o_n),$2 s, compared with 1Prompt1Story at $O=(o_1,o_2,\ldots,o_n),$3, $O=(o_1,o_2,\ldots,o_n),$4, $O=(o_1,o_2,\ldots,o_n),$5, and $O=(o_1,o_2,\ldots,o_n),$6 s. The ablation without explicit state drops back to Consistency $O=(o_1,o_2,\ldots,o_n),$7, Pages changed $O=(o_1,o_2,\ldots,o_n),$8, Turns $O=(o_1,o_2,\ldots,o_n),$9, and Time $$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$0 s (Sarkar et al., 1 Feb 2026).

Graph State-Space Models formulate latent state generation itself as a stochastic graph process. The latent graph state is

$$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$1

with graph-valued transition

$$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$2

dynamic latent edge inference

$$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$3

and message-passing update

$$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$4

The paper states that this is the first probabilistic state-space framework with stochastic graph states whose topology is learned directly end-to-end and can differ from the observed graph. On GPVAR, graph-based methods achieve near-optimal MAE: gRNN $$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$5, eGSS $$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$6, eGSS-in $$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$7, close to the analytical optimum $$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$8. On poGPVAR, eGSS-in $$o:\mathbb{S}\times\mathbb{P}\rightarrow \mathbb{S}, \qquad \forall o\in\mathbb{O}.$$9, eGSS $$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$0, and gRNN $$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$1 remain best (Zambon et al., 2023).

UniGen treats autonomous-driving scenario generation as joint generation of placement, initial state, and future trajectory. For each inserted agent,

$$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$2

with $$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$3. The system uses a shared global scenario embedding, occupancy prediction over a $$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$4 grid, an attribute decoder with $$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$5 modes, and a trajectory decoder with $$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$6 trajectories. UniGen Combined reports Static Collision Rate $$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$7 and Dynamic Collision Rate $$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$8, compared with TrafficGen at $$s^e_{j} = o_j^{t}(o_{j}^{t-1}(\ldots o_{j}^1(s_j^{0}))).$$9 and $\mathcal{S}_0 = \mathcal{F}_s,$00 (Mahjourian et al., 2024).

Deep Generative Markov State Models use learned states as the organizing structure for next-step generation. The transition density is factorized as

$\mathcal{S}_0 = \mathcal{F}_s,$01

with encoder $\mathcal{S}_0 = \mathcal{F}_s,$02, landing densities $\mathcal{S}_0 = \mathcal{F}_s,$03, and induced Markov transition matrix

$\mathcal{S}_0 = \mathcal{F}_s,$04

Generation is recursive: from $\mathcal{S}_0 = \mathcal{F}_s,$05, compute $\mathcal{S}_0 = \mathcal{F}_s,$06, sample $\mathcal{S}_0 = \mathcal{F}_s,$07, generate

$\mathcal{S}_0 = \mathcal{F}_s,$08

then re-encode and continue. The paper emphasizes that this is a state-based generative dynamics model with soft discrete states and a valid stochastic transition matrix (Wu et al., 2018).

A plausible implication is that StateGen is not a single architecture class. It is a recurring design pattern in which explicit state mediates validity, persistence, locality, and regeneration.

5. Evaluation regimes, validity criteria, and scaling arguments

The two explicit StateGen systems differ sharply in what they validate, but both treat state as the object against which semantic correctness is checked. The synthetic-data system validates multi-turn transcripts against an expected final state $\mathcal{S}_0 = \mathcal{F}_s,$09, scores conversations on eight axes, and uses a zero-overlap train and golden evaluation split for per-criterion gap analysis (Khedar et al., 15 Jun 2026). The automated API-task system validates executable programs through runtime oracles, uses execution rather than string matching, and compares generators through coverage metrics such as Adjacent Transition Coverage (Huang et al., 13 Jul 2025).

Related systems reinforce the same pattern. StoryState uses system-level measures of Visual Consistency, Pages Changed, User Effort, and 5-point Likert ratings, and its ablation study shows that explicit state and page-level regeneration are the dominant contributors (Sarkar et al., 1 Feb 2026). UniGen evaluates initial-state and trajectory realism with MMD, Static Collision Rate, and Dynamic Collision Rate rather than paired forecasting metrics, because generated agents need not correspond one-to-one with ground-truth agents (Mahjourian et al., 2024). GSSM evaluates forecasting by MAE and AZ-tests on residual spatial, temporal, and spatio-temporal correlation (Zambon et al., 2023).

For deterministic state evolution, "Bounded Local Generator Classes for Deterministic State Evolution" offers a formal design template rather than a benchmark. It defines graph-indexed local generators

$\mathcal{S}_0 = \mathcal{F}_s,$10

with deterministic schedule

$\mathcal{S}_0 = \mathcal{F}_s,$11

and proves that under fixed locality radius, bounded neighborhood size, fixed local dimension, bounded outputs, and projection into $\mathcal{S}_0 = \mathcal{F}_s,$12, per-step work satisfies

$\mathcal{S}_0 = \mathcal{F}_s,$13

The paper is explicit that this is a subclass result and does not claim universality beyond the stated locality and boundedness constraints (Martin, 12 Feb 2026).

This suggests two distinct strands inside StateGen-style research. One strand is execution-grounded and benchmark-oriented; the other is systems-theoretic and asks what structural constraints make explicit state evolution scalable.

6. Limitations, unresolved issues, and future directions

The synthetic-data StateGen system identifies several open issues. Judge calibration is unresolved because the 8-axis LLM judge has not been validated against a human gold standard. Persona covariance is still simplistic, with some correlations encoded directly in base profiles and seven added by post-sampling rules. The overall score is not a deterministic function of the axis scores. The state manager, though run at temperature $\mathcal{S}_0 = \mathcal{F}_s,$14, is still an LLM rather than a true database engine, so complex updates such as multi-record transactions or partial rollbacks may still introduce subtle inconsistencies (Khedar et al., 15 Jun 2026).

The automated API-task system currently requires manual modeling of API documentation into state and transition models for each new scenario. The authors identify external validity as a threat because the framework has been demonstrated on three scenarios, and internal validity as a threat because natural-language instructions are produced by LLMs and then manually filtered. Future work is explicitly framed as an LLM-enabled middleware that automatically parses documentation and converts it into structured state and transition models (Huang et al., 13 Jul 2025).

The broader StateGen-style literature shows parallel limitations. StoryState currently operates at the level of characters, settings, and page-level scenes; future work includes richer narrative structure, finer-grained object- or region-level edits, and application to video generation and interactive media (Sarkar et al., 1 Feb 2026). Graph State-Space Models are demonstrated only on synthetic data; the graph-learning distribution uses independent Bernoulli edges; score-function gradients can be high variance; and highly irregular, missing, or asynchronous data are not deeply developed (Zambon et al., 2023). UniGen does not explicitly learn a distribution over the number of inserted agents, and position generation is discretized on a grid (Mahjourian et al., 2024). DeepGenMSM conditions generation on metastable state rather than the exact current configuration except through $\mathcal{S}_0 = \mathcal{F}_s,$15, which is excellent for long-time kinetics but may lose important within-state dynamical detail (Wu et al., 2018).

A plausible implication is that explicit state is already a powerful orchestration and validation primitive, but fully automatic state induction, calibrated judging, and universal cross-domain state abstractions remain incomplete. Across the cited literature, the strongest recurring result is not that a single StateGen architecture has emerged, but that making state explicit changes what can be localized, validated, regenerated, and measured.