---
title: 'Agentar-Scale-SQL: Orchestrated Text-to-SQL Scaling'
url: https://www.emergentmind.com/topics/agentar-scale-sql
type: topic
---

# Agentar-Scale-SQL: Orchestrated Text-to-SQL Scaling

Searching arXiv for the specified paper and closely related agentic Text-to-SQL work.
Agentar-Scale-SQL is a Text-to-SQL framework that advances performance through an explicitly orchestrated use of test-time computation. It is described as a general-purpose framework designed for easy adaptation to new databases and more powerful language models, and it structures inference around three complementary perspectives: Internal Scaling via RL-enhanced Intrinsic Reasoning, Sequential Scaling through Iterative Refinement, and Parallel Scaling using Diverse Synthesis and Tournament Selection. On the BIRD benchmark, the framework reaches 81.67\% execution accuracy on the test set and ranks first on the official leaderboard, positioning orchestrated test-time scaling as a concrete methodology for closing part of the gap between contemporary Text-to-SQL systems and human experts [2509.24403].

## 1. Concept and problem setting

Agentar-Scale-SQL is motivated by the observation that state-of-the-art Text-to-SQL methods still lag significantly behind human experts on challenging benchmarks such as BIRD, and that existing approaches to test-time scaling lack an orchestrated strategy and neglect the model's internal reasoning process [2509.24403]. The framework therefore treats additional inference compute not as an undifferentiated budget, but as a resource to be allocated across distinct forms of reasoning and selection.

The system converts extra inference compute into higher Text-to-SQL accuracy by orchestrating three scaling perspectives at test time. Internal Scaling corresponds to “System-1 → System-2” introspection and equips the model with an intrinsic reasoning loop via reinforcement learning. Sequential Scaling corresponds to iterative, multistep deliberation that repeatedly repairs syntactic and semantic errors in candidate SQL. Parallel Scaling corresponds to concurrent, diverse proposal generation followed by structured selection rather than simple self-consistency.

This design places Agentar-Scale-SQL within the broader movement from one-shot or prompt-only SQL generation toward agentic and compute-scaled inference. Related systems emphasize different bottlenecks: semantic memory and trajectory reuse in AgentSM [2601.15709], hypothesis-verification loops in APEX-SQL [2602.16720], and multi-turn credit assignment in SQL-ASTRA [2603.16161]. This suggests that Agentar-Scale-SQL is part of a broader reconfiguration of Text-to-SQL around controlled inference-time deliberation rather than static schema conditioning alone.

## 2. Orchestrated test-time scaling architecture

The framework embeds the three scaling perspectives within a three-stage pipeline. Stage 1, **Task Understanding**, retrieves relevant database cells and few-shot examples. Stage 2, **SQL Generation Scaling**, combines Internal, Parallel, and Sequential scaling to produce a candidate set \(C\). Stage 3, **SQL Selection Scaling**, applies Internal and Parallel scaling to choose the final query [2509.24403].

The following table summarizes the architecture using the terminology of the original framework.

| Component | Role | Mechanism |
|---|---|---|
| Task Understanding | Retrieve evidence before generation | Relevant database cells and few-shot examples |
| SQL Generation Scaling | Produce candidate set \(C\) | Internal + Parallel + Sequential scaling |
| SQL Selection Scaling | Choose final SQL | Internal + Parallel scaling |

Internal Scaling is implemented through two RL-trained modules: the *Intrinsic Reasoning Generator* and the *Intrinsic Reasoning Selector*. Sequential Scaling is implemented by an *Iterative Refinement* module that repairs errors in candidate SQL. Parallel Scaling is implemented by *Diverse Synthesis*, which builds a broad candidate pool, and *Tournament Selection*, which compares candidates pairwise.

The architecture is explicitly modular. The framework distinguishes schema formats for different modeling pathways: DDL schema is used to fine-tune a code LLM for reasoning, while a Markdown “light” schema is used for in-context learning with general LLMs. Retrieval is also factorized into a vector store \(\rm VD_{cell}\) for database cell values, retrieved by keyword embeddings, and a vector store \(\rm VD_{example}\) for few-shot demonstrations, retrieved by skeleton-extracted queries. The paper states that transfer to new databases requires re-executing the offline preprocessing to index schema, cells, and examples, while all online modules remain unchanged [2509.24403].

A plausible implication is that the framework separates persistent database-specific preparation from model-agnostic online orchestration, which is central to its claim of general-purpose adaptability.

## 3. Internal scaling and RL-enhanced intrinsic reasoning

Both the *Reasoning Generator* and the *Reasoning Selector* are trained with the same RL framework, GRPO [2402.03300], formalized over a state, action, policy, and reward definition. For the generator, the state \(s\) encodes the user question \(Q\), schema \(D\), retrieved evidence \(E\), and the partial SQL prefix. For the selector, the state contains the two SQL candidates plus execution feedback. The action is next-token emission for generation or a binary “choose left vs. right” decision for selection, and the policy \(\pi_\theta(a \mid s)\) is parameterized by a Transformer-based LLM [2509.24403].

The generator reward is defined as
\[
R_G(o) =
\begin{cases}
1.0, & \text{if execution result matches ground truth,}\\
0.1, & \text{if the SQL is syntactically valid and executable,}\\
0.0, & \text{otherwise.}
\end{cases}
\]
The selector reward is
\[
R_S(c_{\rm chosen}) = 1
\]
if the selected SQL is correct, and \(0\) otherwise [2509.24403].

The GRPO optimization uses a clipped surrogate loss. Let each input \(Q\) yield \(N\) rollouts \(\{o_i\}\) under \(\pi_\theta\), with
\(r_i = \pi_\theta(o_i)/\pi_{\theta_{\rm old}}(o_i)\) and \(A_i = R(o_i)-\overline R\). The per-sample loss is
\[
L(\theta)
= \frac1N\sum_{i=1}^N
\min\!\bigl(r_i A_i,\;\clip(r_i,1-\epsilon,1+\epsilon)\,A_i \bigr),
\]
and the full objective adds a KL penalty:
\[
\mathcal{J}_{\rm GRPO}(\theta)
= \mathbb{E}[L(\theta)]
-\beta\,D_{\rm KL}\!\bigl(\pi_\theta\;\Vert\;\pi_{\rm ref}\bigr).
\]

Within Agentar-Scale-SQL, this RL machinery is not confined to SQL token generation. It also governs candidate comparison. That distinction matters because the framework claims that existing test-time scaling approaches often neglect the model’s internal reasoning process. Here, “internal reasoning” is operationalized as a trainable inference policy rather than as an untrained prompt format. In comparison, SQL-ASTRA also uses GRPO but focuses on dense step-level and trajectory-level rewards for multi-turn agentic SQL [2603.16161]. This suggests that Agentar-Scale-SQL’s contribution is less about reward shaping for multi-turn execution than about embedding RL-trained reasoning and selection into an orchestrated test-time stack.

## 4. Sequential and parallel scaling mechanisms

Sequential Scaling begins from an initial pool of \(n\) SQL candidates \(C^{(0)}\) and applies a bounded repair process. The iterative refinement algorithm examines each candidate and invokes either `SQL_Fixer` for syntactic invalidity or `SQL_Reviser` for semantic incorrectness, repeating until no new repairs are produced or a maximum number of iterations \(T_{\max}\) is reached [2509.24403]. To prevent combinatorial growth, candidates are grouped by identical execution results at each step, and only one representative per group is refined.

This mechanism is narrower than general-purpose agentic exploration. It does not seek new evidence from the database during every refinement step; rather, it repairs an existing candidate pool. A plausible implication is that the framework assigns exploration primarily to candidate generation and evidence retrieval, while reserving refinement for local correction.

Parallel Scaling is implemented through *Diverse Synthesis* and *Tournament Selection*. Diverse Synthesis uses two generators in parallel:

1. **Reasoning Generator** \((M_{\rm reasoning})\): an RL-tuned, code-specialized model fine-tuned on DDL schema for precise, stepwise SQL synthesis.
2. **ICL Generator** \((M_{\rm ICL})\): a proprietary LLM given a light Markdown schema and retrieved few-shot examples [2509.24403].

Diversity is further increased by varying prompt styles, including direct prompting, Chain-of-Thought, and decomposition; by shuffling few-shot examples; and by sampling multiple temperatures and even different LLM backbones such as Gemini-Pro and GPT-5. Each generator emits \(k\) candidates in parallel, yielding \(\lvert C \rvert = k_{\rm reason} + k_{\rm ICL}\). The union increases the upper bound on correct queries from 75.9\% or 81.4\% individually to 84.3\% combined [2509.24403].

Tournament Selection replaces majority voting over execution results with pairwise competition. The system first reduces the pool by grouping candidates with identical execution outputs on \(D\), selecting one representative per group to form \(C'=\{c_1,\dots,c_m\}\). For each unordered pair \((c_i,c_j)\), the selector computes
\[
p_{i,j} = \pi_\phi\bigl(\text{“i beats j”}\mid Q,\,{\rm schema},\,{\rm exec\_results}\bigr),
\]
increments the appropriate win-score, and returns
\[
c_{\rm final} = \arg\max_{c_i \in C'} W_i.
\]
Because the selector itself is trained through GRPO with reward \(R_S\), the framework claims that it learns to pick more accurate queries than simple frequency-based self-consistency [2509.24403].

The combination of iterative repair and pairwise tournament structure distinguishes Agentar-Scale-SQL from systems centered on retrieval of prior trajectories or explicit database exploration. AgentSM, for example, emphasizes structured semantic memory and composite tools [2601.15709], while APEX-SQL emphasizes hypothesis-verification and exploration directives grounded in real data [2602.16720]. Agentar-Scale-SQL instead concentrates compute into generation diversity, repair, and learned selection.

## 5. Adaptability, modularity, and scaling behavior

The paper characterizes Agentar-Scale-SQL as a modular, plug-and-play framework. Its adaptability is expressed through interchangeable schema formats, retrieval stores, and language-model backbones. To transfer the system to new databases, the required step is to re-execute offline preprocessing that indexes schema, cells, and examples; the online modules are unchanged. To scale with stronger language models, one can replace \(M_{\rm ICL}\) or the code LLM backbones used in reasoning and selection, and allocate more rollouts \(N\), more refinement iterations \(T\), and larger tournaments [2509.24403].

This modularity is important because Text-to-SQL often exhibits sharp dependence on schema presentation and retrieval strategy. The DDL-versus-Markdown split effectively assigns different schema views to different generators. This suggests that the framework treats representational heterogeneity not as noise to be normalized away, but as a source of candidate diversity.

The use of vector stores for \(\rm VD_{cell}\) and \(\rm VD_{example}\) also aligns the system with retrieval-augmented Text-to-SQL pipelines, but with a narrower role than in semantic-memory systems. In AgentSM, memory is explicitly represented as a store \(M=\{(k_i,p_i)\}_{i=1}^N\) of dense keys and structured program fragments, with top-\(k\) retrieval by cosine similarity and selective update under an accuracy threshold [2601.15709]. Agentar-Scale-SQL does not define memory in that form; instead, retrieval is concentrated in task understanding and example selection. A plausible implication is that its main scaling axis is inference orchestration rather than persistent trajectory reuse.

The framework’s description that performance lifts automatically when stronger LMs, more rollouts, more refinement iterations, or larger tournaments are used should be read as a design claim about scalability rather than as a closed-form law. It states the intended direction of scaling behavior, not a universal guarantee.

## 6. Empirical results, ablations, and significance

The benchmark evaluation is reported on BIRD, which contains 12,751 QA-SQL pairs across 95 real-world databases. Agentar-Scale-SQL achieves 74.90\% Dev EX, **81.67\%** Test EX, and 77.00\% R-VES, surpassing the previous best prompt-only result of 80.88\% Test EX from AskData+GPT-4o and the best single-model baseline of 75.68\% from Databricks RLVR 32B. The paper further states that Agentar-Scale-SQL was **Leader #1** on the official BIRD leaderboard as of Sept 28 2025 [2509.24403].

The ablation results assign differentiated value to the three scaling components and to task understanding.

| Ablation | Effect on EX |
|---|---|
| –Reasoning Generator | drops by **4.89 pp** |
| –ICL Generator | drops by **3.78 pp** |
| –Selection Scaling (self-consistency) | drops by 1.82 pp |
| –Iterative Refinement | –0.52 pp |
| –Task Understanding | –0.45 pp |

These results indicate that the two parallel generators account for the largest performance contributions, with the RL-tuned reasoning generator producing the largest single drop when removed. Selection scaling also matters, though less than generator diversity, while iterative refinement and task understanding contribute smaller but still measurable gains.

The generator-synergy analysis reports an upper bound of 81.36\% using only the ICL generator, 75.88\% using only the reasoning generator, and **84.29\%** using the combined pool. The effect of candidate count shows that Pass@k rises steeply until \(k=8\), then plateaus [2509.24403]. This empirical profile is consistent with the framework’s emphasis on parallel scaling: additional candidates help substantially at first, but marginal returns diminish after moderate pool sizes.

In the broader Text-to-SQL landscape, these results should not be conflated with other benchmarks or task settings. APEX-SQL reports 70.65\% execution accuracy on BIRD and 51.01\% on Spider 2.0-Snow under an exploration-centered design [2602.16720]. AgentSM reports 44.8\% execution accuracy on Spider 2.0 Lite with reduced average token usage and trajectory length through semantic memory [2601.15709]. SQL-ASTRA reports gains from dense multi-turn reward shaping on BIRD and Spider-Dev [2603.16161]. These systems address related bottlenecks, but their reported metrics are attached to different datasets, evaluation protocols, and architectural assumptions. The significance of Agentar-Scale-SQL lies specifically in demonstrating that orchestrated Internal, Sequential, and Parallel test-time scaling can deliver state-of-the-art BIRD performance within a modular Text-to-SQL pipeline.

A common misconception is that “test-time scaling” in Text-to-SQL is equivalent to sampling more SQL candidates and taking a vote. Agentar-Scale-SQL directly contradicts that narrower view. Its framework includes RL-trained intrinsic reasoning, iterative repair, dual-generator diversity, and tournament-style learned selection. Another misconception is that stronger base models alone explain the reported gains. The ablation results indicate that orchestration itself contributes materially: removing the reasoning generator, ICL generator, selection scaling, iterative refinement, or task understanding each reduces execution accuracy [2509.24403].

Taken together, Agentar-Scale-SQL defines a form of agentic Text-to-SQL in which inference-time compute is organized rather than merely increased. Its central claim is that the effective unit of scaling is not a single reasoning trace, but a coordinated system of reasoning, repair, synthesis, and comparison.

Source: https://www.emergentmind.com/topics/agentar-scale-sql