3 Anatomy of OpenTI Systems

Section 2 formalized the aim of OpenTI systems to produce realizations that capture how analytical knowledge derives from data as an optimization problem over a combinatorially vast space of operations. In this section, we examine how OpenTI systems derive this analytical knowledge. We frame OpenTI systems as agents that navigate the realization space under partial observability and uncertainty (Section 3.1). We then examine how agents orchestrate the analytical process (Section 3.2), and then decompose the functional capabilities that agents must exercise to construct realizations (Section 3.3). For details on the literature review protocol and the inclusion criteria for systems in Table 1, consult Appendix 8.3.

3.1 OpenTI Systems

Constructing a realization requires a sequence of mutually dependent decisions, like interpreting the insight need, acquiring relevant data from the corpus, selecting and composing analytical operations, and assessing whether the emerging result satisfies the user’s need. These decisions are mutually dependent since data availability constrains what methods can be applied, the choice of method determines what data is needed, and both depend on the interpretation of the insight need, which itself may need to adapt as data and analytical constraints surface. This makes constructing a realization an instance of a coupled decision problem as studied in automated planning (Ghallab, M et al., 2004), where consequences of early actions are uncertain and affect which later actions are appropriate. A system must moreover make these decisions with incomplete knowledge of the user’s latent insight need $i$ and the corpus’s contents and structure. OpenTI is therefore a problem of sequential decision-making under mutual dependencies and partial observability (Ghallab, M et al., 2004) (Russell, S, 2022) (Sutton, R & Barto, A, 2018) (Kaelbling, L et al., 1998). Accordingly, we understand OpenTI systems as agents that interact with their environment to construct a realization that maximizes the utility.

We borrow this terminology from the study of sequential decision-making under partial observability (Kaelbling, L et al., 1998) (Sutton, R & Barto, A, 2018) to characterize the functional role of OpenTI systems without prescribing whether these functions are realized through language model reasoning, learned neural models, classical algorithms, or other mechanisms. While current implementations largely employ LLMs, the design space extends beyond. In OpenTI, the environment, observations, actions, and policy have specific instantiations that shape the setting and the space of possible systems.

Environment. The agent’s environment consists of everything outside the agent that it interacts with (Sutton, R & Barto, A, 2018) (Russell, S, 2022). Following Sutton and Barto (2018), we understand everything the agent cannot change arbitrarily as part of the environment. Thus, the corpus $T$ and insight need $i$ are necessary components of the environment in OpenTI. Agents can explore and use $T$, but cannot alter it. Similarly, they can observe the expressed insight need $\hat{i}$ but not influence the underlying need $i$. The environment may extend beyond these necessary components to data relationships, contextual resources like documentation or ontologies that reduce uncertainty, interaction histories, or user profiles (see Sections 4 and 6).

Observations. While deriving a realization, the agent continually makes observations that inform its subsequent actions (Sutton, R & Barto, A, 2018). In OpenTI, these observations comprise the expressed insight need and the intermediate analytical state. In interactive settings users may specify the expression of their insight need throughout the analytical process, for instance through clarification, feedback, or analytical guidance (see Section 4.1). The observed expression $\hat{i}$ thus accumulates during the process as the user contributes to it, whereas in non-interactive settings it remains fixed to what the user provided initially. The intermediate analytical state captures the partial realization the agent has constructed so far, the outcomes of executed operations, and the intermediate results it has produced. Since realizations are converging DAGs, it can span multiple independent analytical strands that have not yet converged. The environment is only partially observable since the agent cannot access the latent insight need $i$, the corpus $T$ has to be explored, and the agent can only estimate the utility against the expression of the insight need it has observed so far.

Actions and functional capabilities. At any time, an agent takes an action within its action space (Sutton, R & Barto, A, 2018). Actions are the agent’s means of influencing and exploring the environment (Russell, S, 2022). In OpenTI, actions span the functional capabilities required to derive a realization. The concrete actions available to an agent are determined by its specific implementation and may, for instance, include retrieving tables, and composing and executing analytical operations on the tables. The outcomes of actions in OpenTI are uncertain. For example, retrieval may surface irrelevant data and analytical operations may produce errors. Section 3.3 examines these functional capabilities.

The agent’s policy governs how it selects actions based on its observations (Sutton, R & Barto, A, 2018) (Russell, S, 2022). In OpenTI, the policy determines how the agent navigates the realization space, how it allocates effort across functional capabilities, and how it selects specific actions within each capability. The policy affects all choices the agent makes, from high-level decisions such as which capability to invoke next to fine-grained ones such as what analytical operations to apply to a table. The policy itself is often bound up in model parameters, prompt design, or hardcoded logic, making it only indirectly observable. OpenTI agents can instead be characterized by higher-level orchestration strategies, which Section 3.2 examines and structures.

3.2 Orchestration Strategies

The orchestration strategy describes the structural pattern of how an OpenTI agent composes its functional capabilities. Thereby, it provides the high-level scaffolding for the policy applied by the agent. This subsection develops the space of orchestration strategies and positions existing systems within it.

The underlying question of when and how the structure of a process is determined has been studied across several traditions. In planning under uncertainty, approaches range from offline derivation of complete policies before actions are taken, through online methods that interleave deliberation with execution and replan as observations are received, to reactive strategies that select actions based solely on the current belief state (Ghallab, M et al., 2004) (Kaelbling, L et al., 1998). Research into intelligent agent architectures (Wooldridge, M & Jennings, N, 1995) distinguishes deliberate agents, which maintain explicit models of the world and plan before acting, from reactive agents, which dynamically decide on actions based on immediate observations, and hybrid architectures that layer both. Database systems differentiate between static optimization, where the execution plan is fixed before any data is processed, and adaptive query processing, which tunes an initial execution plan based on data-dependent feedback (Deshpande, A et al., 2007). Across these traditions, the fundamental design choice concerns the degree to which the structure of the computational process is fixed before and during the execution of operations. Put differently, it concerns the influence execution-time information, like the actual instance and observations made during processing, has on not-yet-executed operations. Following these traditions, we categorize orchestration strategies by when the topology of the composition of functional capabilities is determined. In fixed orchestration, the topology is fixed at design time based on assumptions about the analytical process. Plan-based orchestration fixes the topology at invocation time, generating an insight-need-specific topology based on anticipation of required actions for the instance. In reactive orchestration the topology is not predetermined or planned but dynamically composed at execution time based on observations of the analytical environment. These orchestration strategies can also be combined in a hybrid orchestration strategy, for instance by employing different strategies at different levels of granularity, like fixing a macro-level structure while allowing incremental decisions within each phase.¹

Figure 7 organizes the systems surfaced in our literature review along this categorization of orchestration strategies, showing 54 of the 58 systems that orchestrate multiple functional capabilities, with the remaining four only commanding a single capability, requiring no orchestration. We classify most studied systems under the fixed orchestration category, a smaller number as reactively orchestrated or following a hybrid orchestration strategy, and only two as purely plan-based.

Fixed

CQR-SQL (Xiao, D et al., 2022), Cao et al. (Cao, Y et al., 2023), CRUSH4SQL (Kothyari, M et al., 2023), DataQue (Kochedykov, D et al., 2023), Dater (Ye, Y et al., 2023), DIN-SQL (Pourreza, M & Rafiei, D, 2023), Inner Table Retriever (ITR) (Lin, W et al., 2023), LI-RAGE (Lin, W et al., 2023), MITQA (Kumar, V et al., 2023), MultiTabQA (Pal, V et al., 2023), OpenTab (Kong, K et al., 2023), ReFSQL (Zhang, K et al., 2023), S3HQA (Lei, F et al., 2023), ToolWriter (Gemmell, C & Dalton, J, 2023), JAR (Chen, P et al., 2024), POTABLE (Mao, Q et al., 2024), SYNTQA (Zhang, S et al., 2024), TabSQLify (Nahid, M & Rafiei, D, 2024), ACR (Li, J et al., 2025), ALTER (Zhang, H et al., 2025), CHASE-SQL (Pourreza, M et al., 2025), DAgent (Xu, W et al., 2025), DBCopilot (Wang, T et al., 2025), FISQL (Menon, R et al., 2025), H-STAR (Abhyankar, N et al., 2025), MURRE (Zhang, X et al., 2025), PI-SQL (Chi, Y et al., 2025), QCMA-SQL (Shao, Z et al., 2025), ROUTE (Qin, Y et al., 2025), SAFE-SQL (Lee, J et al., 2025), SGAM (Wang, X et al., 2025), STaR-SQL (He, M et al., 2025), TABDSR (Jiang, C et al., 2025), Table-Critic (Yu, P et al., 2025), TABLELLM (Wu, X et al., 2025), TAMO (Li, L et al., 2025), TART (Lu, X et al., 2025), TiInsight (Zhu, J et al., 2025), UCS-SQL (Wu, Z et al., 2025), DS-GURU (Lai, E et al., 2026), GTR (Zou, J et al., 2026), LitE-SQL (Piao, S et al., 2026), RTS++ (Chen, K et al., 2026)

Plan-based

AixelAsk (Zhang, C et al., 2025), Weaver (Khoja, R et al., 2025)

Reactive

Chain-of-Table (Wang, Z et al., 2024), DA-Agent (Huang, Y et al., 2024), DAAgent (Hu, X et al., 2024), DACO (Wu, X et al., 2024), ReAcTable (Zhang, Y et al., 2024), MACT (Zhou, W et al., 2025), TALON (Jin, R et al., 2025), DATAMIND (Qiao, S et al., 2026)

Hybrid

AutoTQA (Zhu, J et al., 2024), TableGPT2 (Su, A et al., 2024), TableRAG (Chen, S et al., 2024), TaPERA (Zhao, Y et al., 2024), AOP (Wang, J & Li, G, 2025)

3.2.1 Fixed Orchestration

Fixed orchestration follows a topology of capability invocations that is determined at design time. The parameterization, for instance which retrieval query to employ or what code to generate, is determined at execution time. The simplest form of fixed orchestration is following a single sequence of capabilities that is applied identically to every instance. Beyond this, fixed orchestration may also employ conditionals and branching with multiple predetermined paths. This strategy resolves mutual dependencies between functional capabilities by assumption as the designer commits to a fixed ordering based on expectations about how insight needs are typically structured and processed, assuming that this ordering is adequate for the range of instances the system will encounter.

A fixed topology provides a well-defined context for every invocation of a functional capability, since the inputs to each capability are determined by its predecessors and its outputs feed its successors. This bounded structure enables independent optimization of individual capabilities and makes a system’s behavior predictable and easier to trace, which supports interpretability and simplifies fine-grained evaluation of individual capabilities. It also lets the designer of a method encode domain knowledge about effective analytical workflows directly into the topology, drawing on established practices such as the data analysis pipelines common in data science (Martínez-Plumed, F et al., 2021), for instance by hard-wiring an analyst-inspired sequence of stages (Mao, Q et al., 2024) (Lai, E et al., 2026).

These benefits come at the cost of adaptability. A fixed topology cannot adjust to insight needs that deviate from the assumed processing pattern, to unexpected data characteristics discovered during execution, or to errors that fall outside predefined recovery paths. Since the agent operates in an uncertain and only partially observable environment (Section 3.1), the assumptions underlying the fixed structure may be violated for any given instance. A strategy that performs all data retrieval before analytical composition, for example, cannot retrieve tables that become relevant only after initial analysis. The more diverse the insight needs and the more heterogeneous the corpus, the more likely these assumptions are to break.

Many works mirror established retriever-reader (Chen, D et al., 2017) and Retrieval Augmented Generation (RAG) (Lewis, P et al., 2020) architectures, separating an upfront retrieval stage from a downstream data processing step (Lin, W et al., 2023) (Zhang, X et al., 2025) (Zou, J et al., 2026) (Wang, T et al., 2025), often extended with interpretation of the inputs as a first step (Kothyari, M et al., 2023) (Chen, P et al., 2024) (Kong, K et al., 2023) and output synthesis as a last step (Kong, K et al., 2023) (Nahid, M & Rafiei, D, 2024) (Menon, R et al., 2025) (Abhyankar, N et al., 2025). While most methods traverse these fixed stages one-by-one, other systems parallelize the analytical process by decomposing it and following a fixed structure for each sub-analysis (Zhang, H et al., 2025) (Xu, W et al., 2025), resulting in a more complex, fixed topology of functional capabilities.

3.2.2 Plan-Based Orchestration

In plan-based orchestration, the topology of capabilities is determined at the invocation of the agent, which generates an instance-specific topology before starting the execution. In contrast to fixed orchestration, the agent constructs a plan that specifies which capabilities to invoke, in what order, and with what dependencies based on the expressed insight need $\hat{i}$. Execution follows this plan, resembling a fixed topology, which may include specified branches and error recovery mechanisms. This strategy resolves mutual dependencies between functional capabilities by anticipation, as the agent seeks to factor in the likely requirements of the insight need and the expected behavior of its capabilities to produce a topology that addresses the anticipated dependencies upfront.

Since each plan is constructed for a specific insight need, it provides an end-to-end perspective that can account for instance-specific requirements for the analytical process before any operation is executed. This perspective lets the agent assess a plan’s coherence, identify potential bottlenecks, and optimize the structure, for instance by expressing independent steps as a dependency graph that can be executed in parallel (Zhang, C et al., 2025) or by generating and evaluating alternative candidate plans against estimated quality criteria (Wang, J & Li, G, 2025). As an explicit artifact, the plan can also be verified before execution (Khoja, R et al., 2025), surfaced to users for intervention, and used to support interpretability.

The effectiveness of this strategy relies on the quality of the plan, which is generated without execution feedback. The plan rests on anticipations that may not hold, as the required data may have an unexpected structure, an analytical method may prove inappropriate once applied to the actual data, or intermediate results may reveal that the insight need calls for a different approach than planned. Recovery from such deviations and from errors is possible only to the extent that it was anticipated and encoded in the plan.

The two systems with a plan-based orchestration differ in how expressive their plans are. Weaver (Khoja, R et al., 2025) generates a linear plan of interleaved SQL and language model steps that a second model verifies and refines before the plan is executed step by step. AixelAsk (Zhang, C et al., 2025) instead constructs a directed acyclic graph of retrieval and reasoning nodes with explicit dependencies, which exposes independent branches for parallel execution. Beyond these, AOP (Wang, J & Li, G, 2025) illustrates the optimization potential of an explicit plan, compiling operators into a graph that enables parallelization and prefetching.

3.2.3 Reactive Orchestration

Agents with a reactive orchestration strategy select each subsequent action based on their current observations, which can include the partial realization constructed so far, the outcomes of previous actions, and the expressed insight need at that time. The process structure emerges from the accumulation of these step-by-step decisions. This strategy resolves mutual dependencies by reaction as they manifest. When the analysis reveals a data gap, the agent can invoke data retrieval, and when retrieval returns unexpected data, it can adjust its analytical approach without being locked into a plan that assumed otherwise.

Reactive orchestration leverages observations of the uncertain environment that OpenTI agents operate in. By conditioning each decision on the observation history, the agent responds to the actual state of the analysis rather than to assumptions or anticipations that may no longer hold, which gives it inherent capacity for recovery and adaptation, as seen in agents that condition continued execution on observed errors to debug and retry their own operations (Hu, X et al., 2024) (Qiao, S et al., 2026) (Zhang, Y et al., 2024). This adaptivity foregoes an inherent end-to-end perspective on the process. Purely step-by-step decision-making risks pursuing locally reasonable actions that are globally suboptimal, for example selecting data that is adequate in isolation but ill-suited to operations performed later in the process, mirroring the principle from planning under uncertainty that optimal behavior requires accounting for long-range consequences (Kaelbling, L et al., 1998). How well a reactive agent avoids such trajectories depends on how much anticipation its underlying mechanism brings to each decision, which some systems reinforce by adding an explicit planning or critic component to the reactive loop (Zhou, W et al., 2025) (Jin, R et al., 2025).

In the reviewed works, reactive orchestration rests exclusively on a language model backbone, with most systems following the paradigm of interleaved reasoning and acting introduced by ReAct (Yao, S et al., 2023) (Zhang, Y et al., 2024) (Huang, Y et al., 2024) (Hu, X et al., 2024) (Jin, R et al., 2025) (Qiao, S et al., 2026). A variation is to distribute the process across multiple language model agents, where a planning agent reactively invokes further agents that embody functional capabilities (Zhou, W et al., 2025).

3.2.4 Hybrid Orchestration

Hybrid orchestration combines other orchestration strategies, typically by applying different strategies at different levels of granularity or different phases of the analytical process. The general aim is to use the strengths of the combined strategies so that they counteract their respective shortcomings. Many such combinations are conceivable, and the reviewed systems instantiate three forms that differ in which strategy governs the macro structure and which governs the steps nested within it.

One hybridization is to embed a reactive loop within an otherwise fixed multi-step pipeline, combining an informed macro structure with local adaptivity inside each step. In TableRAG (Chen, S et al., 2024), a fixed sequence of query expansion and retrieval provides the inputs to a reactive program-aided solver that iterates over generated code and its observed outputs. TableGPT2 (Su, A et al., 2024) likewise wraps a reactive code and tool-calling agent inside a fixed pipeline of input preparation, agent execution, and answer generation. The intuition behind this combination is to bound the overall process with a reliable skeleton while letting the least predictable stage, the analytical composition, adapt to intermediate results.

Similarly, embedding reactive behavior in an instance-specific plan allows treating the plan as the primary strategy and reactive orchestration as a fallback, so the system retains the global coherence and efficiency of an optimized plan while avoiding the rigidity that would otherwise make a plan fail once observations deviate from what was anticipated in the plan. AOP (Wang, J & Li, G, 2025) compiles operators into an optimized graph that supports parallelization and prefetching, then executes it as planned and halts to re-plan the remaining pipeline when an operator fails or returns unsatisfactory results.

Nesting a plan inside a reactive loop that governs the macro structure inverts this combination. Instead of committing to a plan, such systems treat plans as provisional and reactively decide when to extend or revise them. TaPERA (Zhao, Y et al., 2024) iteratively builds and refines a plan based on sub-questions, deriving sub-answers and deciding whether to finalize or refine the plan from them, while AutoTQA (Zhu, J et al., 2024) uses a critic that judges intermediate results and directs the planner to revise it whenever it detects gaps.

3.3 Functional Capabilities

The functional capabilities of OpenTI systems describe the means with which they need to be equipped to derive a realization. We derive the necessary functional capabilities from the problem formulation (Section 2.1.5), which requires constructing a realization $r = (O, E, \beta) \in R_{\text{valid}}(i) \cap R_{\text{feasible}}(T)$ for an insight need $i$ over a corpus of tables $T$. Determining which realizations are valid, that is, defining $R_{\text{valid}}(i)$, requires mapping the expressed insight need $\hat{i}$ to a system-side representation $\hat{i}^{s}$ that constrains which realizations satisfy $i$, which in turn requires specifying and disambiguating its data, methodological, and output aspects $i_d, i_m, i_o$. We summarize this capability as interpretation (Section 3.3.1). Identifying feasible realizations $R_{\text{feasible}}(T)$ and constructing data bindings $\beta$ requires exploring $T$ to discover and bind relevant tables, a capability we refer to as data retrieval (Section 3.3.2). Beyond this, OpenTI agents compose the structure of operations $(O, E)$ by selecting, parameterizing, and combining the analytical operations that derive knowledge from the data, which we capture as analytical composition and execution (Section 3.3.3). Finally, the agent produces outputs that satisfy the insight need. While formally part of $(O, E)$, producing this output addresses qualitatively distinct concerns like selecting output modalities, contextualization, and the form of presenting the analytical knowledge, which correspond to the output need $i_o$ rather than the analytical derivation itself. We thus distinguish output synthesis (Section 3.3.4) as a separate functional capability.

In combination, these functional capabilities cover all necessary aspects of constructing a realization and are thus jointly sufficient for constructing some $r \in R_{\text{cand}}$. However, OpenTI seeks a realization that maximizes the utility $r^* = \arg\max_{r \in R_{\text{cand}}}u_i(r)$ in a combinatorially vast space. The necessary functional capabilities introduced above all constitute object-level computation (Davis, R & Buchanan, B, 1977) (Davis, R, 1980), directly producing components that constitute $r$. They do not explicitly cover navigating the realization space towards high-utility realizations, which requires meta-level capabilities (Davis, R & Buchanan, B, 1977) (Davis, R, 1980) (Russell, S & Wefald, E, 1991). Meta-level capabilities concern reasoning about the process of constructing $r$ itself, aiming to work towards the optimization objective but leaving no direct trace in $r$.

The process of constructing a realization can diverge substantially from the clean DAG of the resulting realization. The execution trace of an agent may include cycles (e.g., retrying after errors), branches (e.g., exploring alternative analytical strategies), dead ends (e.g., retrieval returning insufficient data), and backtracking (e.g., revising a strategy based on intermediate results). Meta-level capabilities let the agent navigate this process by assessing whether intermediate results are on course towards the insight need, validating the quality of partial realizations, detecting and recovering from errors, and deciding when to backtrack or pursue alternatives. These capabilities shape which realization gets constructed without themselves appearing as nodes in $r$, which parallels the distinction between reasoning and action in LLM agent frameworks (Yao, S et al., 2023). While the orchestration strategy (Section 3.2) provides the structural pattern within which the agent operates, meta-level capabilities are the functional means the agent exercises within that structure to navigate toward high-utility realizations. We examine these under process governance (Section 3.3.5).

Table 1 provides an overview of systems with a broad coverage of functional capabilities (selection criteria in Appendix 8.3.3). Our discussion of functional capabilities is based on the full set of 58 systems, extended with capability-specific literature. Few systems cover all functional capabilities. Most works lack retrieval capabilities entirely (41 of 58), operating on pre-specified data rather than discovering relevant tables from a corpus. Interpretation often remains implicit (18 of 58), relying on inherent interpretation capabilities of language models rather than explicit mechanisms. Output modalities are largely limited to text or code execution results (46 of 58), with few systems capable of producing tables (15 of 58) or visualizations (6 of 58), despite the diversity of analytical results that may benefit from such presentation.

3.3.1 Interpretation

Interpretation allows agents to determine which realizations satisfy the insight need, that is, which realizations are part of $R_{\text{valid}}(i)$ by mapping the expressed insight need $\hat{i}$ to the system’s representation $\hat{i}^{s}$. The latency of insight needs introduces a gap between $\hat{i}$ and $i$. Users leave aspects implicit because they employ conventions, delegate choices to the system, or lack awareness of what must be specified (Section 4). Interpretation bridges this gap by specifying implicit aspects and resolving ambiguities. All systems perform some interpretation before acting, yet many of the reviewed systems lack explicit mechanisms and instead do so implicitly in a neural model, mostly through the language understanding of an underlying language model. Interpretation may also recur during insight extraction, triggered when data retrieval, analytical execution, or further user inputs reveal misalignment.

Input Decomposition and Augmentation.

Decomposing and augmenting inputs seeks to transform and specify $\hat{i}^s$ to better serve downstream capabilities. Decomposition breaks the expressed need into parts. Augmentation enriches or rewrites it to increase its specification or alignment with the data environment.

The data need $i_d$ is often augmented by mapping inputs to data-level representations, for instance by generating hypothetical schemas of the required data (Kothyari, M et al., 2023) (Zhang, X et al., 2025) or extracting concept-attribute pairs (Chen, P et al., 2024) (Chen, S et al., 2024) (Wu, Z et al., 2025) that serve retrieval and analytical execution, and, after retrieval, by schema linking that aligns concepts mentioned in the expressed need with concrete schema elements (Pourreza, M & Rafiei, D, 2023) (Qin, Y et al., 2025) (Shao, Z et al., 2025), a technique originating in text-to-SQL systems (Liu, X et al., 2025). In contrast, the methodological need $i_m$ is augmented by transforming inputs into an actionable plan for the analytical process (Zhao, Y et al., 2024) (Lai, E et al., 2026) (Lu, X et al., 2025) (Zhu, J et al., 2024) (Zhou, W et al., 2025) (Zhang, C et al., 2025), bridging the inputs with retrieval and analytical execution. Beyond these input-level transformations, Zhang et al. (2025) apply step-back augmentation (Zheng, H et al., 2024), abstracting the expressed need to a higher level of generality before deriving specific sub-needs to surface implicit aspects that a direct transformation would miss.

Reflecting the compositional nature of insight needs, decomposition is commonly employed to extract logically dependent (Zhao, Y et al., 2024) (Lai, E et al., 2026) (Zhu, J et al., 2024) (Pourreza, M & Rafiei, D, 2023) (Abhyankar, N et al., 2025) (Jiang, C et al., 2025) and independent (Xu, W et al., 2025) (Zhang, H et al., 2025) sub-needs from the expressed insight need, making the downstream analysis less complex to compose and execute. Decomposition and augmentation are the most widespread explicit interpretation mechanisms, listed as “Decompose” and “Augment” in the Interpretation column of Table 1.

Contextualization.

Contextualization aims to inform the interpretation of the insight need with knowledge that is not directly expressed in the input. This contextual knowledge can originate from different sources. Interaction-histories can serve as shared context, resolving references to previous results and interpreting follow-up needs in the light of prior results (Li, J et al., 2025) (Kochedykov, D et al., 2023) (Xiao, D et al., 2022). Similarly, demonstration-retrieval can contextualize the analytical process in prior instances of processed insight needs (Lee, J et al., 2025) (Zhang, K et al., 2023) (Pourreza, M et al., 2025) (Chen, Y et al., 2025) (Gu, J et al., 2025) or historical planning paths (Xu, W et al., 2025). Additionally, domain-knowledge is used to resolve terminology (Zhu, J et al., 2025) and conventions specific to the analytical domain (Su, A et al., 2024), such as standard operating procedures from business operations (Zhu, J et al., 2024), directly addressing cases where users omit detail because a default interpretation exists in the domain. Systems integrate such external expert knowledge through different mechanisms, retrieving it from an index via retrieval augmented generation (Zhao, X et al., 2024), integrating a dedicated data-expert model that supplies knowledge left implicit in the schema and the expressed need (Hong, Z et al., 2024), or materializing it as supplementary data that extends the retrieved tables with the missing information (Liu, Y et al., 2025).

Scoping.

Part of interpreting the data need $i_d$ is interpreting it against specific tables. Scoping aims to interpret a table and scope its contents to those that are actually relevant to $i_d$ by selecting only the relevant rows, columns, or cells. Approaches vary in granularity, from selecting relevant rows and columns based on semantic similarity to the expressed insight need (Zhang, H et al., 2025) (Kong, K et al., 2023) (Patnaik, S et al., 2024), to retrieving individual schema elements and cell values (Chen, S et al., 2024). Following a different approach, Gemmell and Dalton (2023) generate code on demand to filter rows programmatically before a downstream model computes the answer. The efficacy of an explicit scoping step is disputed, with Mao et al. (2024) finding a reduction in accuracy.

Engaging Users.

Beyond automatically resolving ambiguities, systems may involve users by soliciting clarification or presenting alternative interpretations. This is particularly relevant when the expressed need has multiple sensible interpretations that cannot be resolved through conventions or context alone (Saparina, I & Lapata, M, 2025) (Gomm, D et al., 2025). To address this, systems may engage users by asking targeted follow-up questions (Su, A et al., 2024) (Li, J et al., 2025) (Menon, R et al., 2025) (Chen, K et al., 2026) (Kochedykov, D et al., 2023), or otherwise soliciting their input to specify the expressed insight need. Choosing when to autonomously handle specification and when to solicit clarification from the user introduces a trade-off between burdening the user with interactions and reducing the risk of misalignments. We assess this trade-off and the design of interactions in Section 4 in more detail.

Interpretation Throughout Processing.

The interpretation mechanisms in the reviewed works are predominantly applied before the analytical process begins, operating on the expressed insight need in isolation from data and analytical outcomes that emerge during execution. Yet the environment is only partially observable, so information relevant to interpretation may surface only during processing, for example when a seemingly unambiguous entity matches multiple retrieved tables with different semantics. Nonetheless, explicit re-interpretation during processing, that is, revising $\hat{i}^{s}$ in light of new observations, remains limited, except for iterative retrieval approaches (Zhang, X et al., 2025) (Boutaleb, A et al., 2025) that progressively refine the data need $i_d$ based on intermediate retrieval results, and iterative revisions of analytical plans that re-interpret the insight need under intermediate results (Zhao, Y et al., 2024).

The degree to which re-interpretation is possible depends on the orchestration strategy. Fixed orchestration confines interpretation to designated positions in the topology, preventing revisions based on downstream observations. Plan-based orchestration fixes interpretation at planning time, making re-interpretation possible only if explicitly anticipated. Reactive orchestration lets the agent condition each decision on prior observations, though whether this constitutes re-interpretation depends on whether the agent’s representation $\hat{i}^{s}$ is itself revised rather than merely adjusting execution within an unchanged interpretation.

3.3.2 Data Retrieval

Data retrieval capabilities allow agents to explore the corpus and surface sufficient data to address an insight need, enabling the agent to determine which realizations the corpus supports, $R_{\text{feasible}}(T)$, and to retrieve tables for data bindings $\beta$ of candidate realizations. This requires mapping the data need $i_d$ to a set of tables for the data bindings $\beta$, and may additionally be constrained by the methodological need $i_m$, for instance when an analytical method requires a minimum sample size to yield statistically valid results.

When an insight need can be satisfied from a single table, retrieval concerns identifying the most relevant table. However, insight needs may require integrating information from multiple tables, requiring retrieval to surface a sufficient set (Definition 5) that satisfies both semantic alignment between the insight need and the retrieved tables and structural alignment among the retrieved tables themselves. The Retrieval column in Table 1 shows the data setting each system operates in, separating systems that operate over a pre-selected set of tables from those that select among a bounded set of tables and those that retrieve from an open corpus. Out of the systems in Table 1, only four target an open setting. We examine how existing work represents tables and inputs, the granularities at which retrieval is performed, how sets of multiple tables are composed, and how retrieval integrates within the broader analytical process.

Table and Input Representations.

Index-based retrieval maintains an explicit collection of table representations and scores table relevance against an input at retrieval time. Bridging the semantic gap between input and table representations requires appropriate representations of both that make them comparable.

Tables have predominantly been represented through linearization into text, which enables applying retrieval methods developed for text documents. The design space for linearization is large (Zhang, Y et al., 2025), ranging from schema-only representations using column headers (Kong, K et al., 2023) to full-content serializations including row-level data (Pan, F et al., 2022), representations enriched with surrounding contextual text (Chen, W et al., 2021) (Huang, J et al., 2022), and LLM-generated natural language descriptions of table contents (Balaka, M et al., 2025) (Zhang, Y et al., 2025). These linearization choices have been shown to significantly influence retrieval performance (Gomm, D & Hulsebos, M, 2025). However, linearizing tables into text has been criticized for ignoring semantic dependencies and structural information (Trabelsi, M et al., 2022) (Wang, F et al., 2021), limiting the amount of tabular content that can be represented (Gomm, D & Hulsebos, M, 2025), and being unable to handle different cell datatypes individually (Wang, F et al., 2021). This has motivated table-specific encoding approaches that modify transformer attention mechanisms to account for tabular structure (Herzig, J et al., 2020) (Trabelsi, M et al., 2022), apply graph-based encoders to capture structural properties (Wang, F et al., 2021), or operate on images of tables using multimodal language models (Xu, Z et al., 2026). Despite these efforts, linearization to text with general-purpose encoders remains the dominant approach in research.

Orthogonally, the semantic gap can be narrowed from the input side by transforming the expressed insight need into a form that better matches the table representations. One approach that has been explored is to transform inputs into text that is structurally similar to the linearizations of the indexed tables, for instance by generating a hypothetical table schema from the input and retrieving against the actual schemas (Kothyari, M et al., 2023) (Zhang, X et al., 2025), as well as query decomposition and expansion techniques discussed further in the context of semantic and structural alignment. More broadly, retrieval is often deeply intertwined with interpretation capabilities (Section 3.3.1) that expand, decompose, or rewrite inputs to improve alignment.

Given these representations, the reviewed works apply established retrieval paradigms including lexical methods (Kong, K et al., 2023) (Ji, X et al., 2024), bi-encoder dense retrieval (Karpukhin, V et al., 2020) (Pan, F et al., 2022) (Zhang, X et al., 2025) (Kothyari, M et al., 2023) (Chen, P et al., 2024) (Xu, W et al., 2025) (Zhu, J et al., 2025) (Wang, X et al., 2025), late interaction mechanisms (Khattab, O & Zaharia, M, 2020) (Lin, W et al., 2023), cross-encoder re-ranking (Luo, F et al., 2026), and hybrid combinations of lexical and dense signals (Balaka, M et al., 2025) (Li, D et al., 2025). For systems that perform retrieval, the Retrieval column in Table 1 annotates their retrieval mechanism. Retrieval mechanisms are applied largely independently of the representations of tables and inputs. Rather than which retrieval paradigm to apply, research has mostly focused on what representations effectively bridge the semantic gap and how to incorporate sufficiency criteria into retrieval.

Retrieval Granularity.

Besides representation and retrieval mechanisms, approaches vary in the granularity at which tables are indexed. Most index at the table level, producing one representation per table (Kong, K et al., 2023) (Herzig, J et al., 2021) (Balaka, M et al., 2025), which limits the detail that can be captured but preserves cross-column semantics that convey what a table is about as a whole. In contrast, column-level indexing (Kothyari, M et al., 2023) (Chen, P et al., 2024) enables finer-grained matching between individual attributes and components of the data need, at the cost of a substantially larger index and the potential loss of inter-column context. This finer granularity is particularly relevant for composing sufficient sets of multiple tables, where alignment must be assessed per individual attribute rather than per table. Row-level indexing (Kumar, V et al., 2023) (Ji, X et al., 2024) has also been explored, yielding fine-grained representations that capture specific records in the tables, facilitating retrieval in settings where relevance is concentrated in specific records. Since these granularities capture complementary signals, approaches may also combine them, for instance, leveraging coarse-grained representations for initial filtering and fine-grained representations for precise matching (Chen, P et al., 2024) (Wang, J & Li, G, 2025) (Kong, K et al., 2023) (Zhu, J et al., 2025).

Semantic and Structural Alignment.

When the data required to satisfy an insight need spans multiple tables, retrieving individually relevant tables does not guarantee a sufficient set (Definition 5). The retrieved set must be semantically aligned with the data need, collectively covering all required concepts, and structurally aligned among its tables, enabling their integration through operations available to the system (Section 2.2.2). Composing such sets can be understood as a search over candidate table combinations (Boutaleb, A et al., 2025), where candidate sets are assessed along both alignment dimensions. Approaches differ in how they track semantic coverage, assess structural compatibility, and navigate the search space.

Semantic alignment is primarily addressed by decomposing the data need into sub-components and matching which of them are covered by retrieved tables. Kothyari et al. (2023) generate a hypothetical minimal set of table schemas from the insight need, while Chen et al. (2024) decompose it into concept-attribute pairs, each targeting a specific data requirement. Both decompose in a single step without considering which tables are actually available, then track coverage during a subsequent selection phase. These contrast with iterative retrieval, where retrieval steps are interleaved with an assessment of the alignment of the tables retrieved so far (Boutaleb, A et al., 2025). Zhang et al. (2025) retrieve one table per iteration and rewrite the input to remove aspects already covered, continuing until all concepts in the data need are covered. The iterative structure allows adapting to the actual structure of the data and implicitly determining the size of the sufficient set, at the cost of computational overhead that scales with the number of iterations. Chen et al. (2025) instead align the input with the organization of the corpus by exploring relationships among its tables, retrieving a sufficient set in a single pass rather than decomposing the need without regard to available data or querying iteratively.

Structural alignment requires assessing whether retrieved tables can be integrated, for instance through join or union operations. Approaches estimate structural compatibility from signals intrinsic to table pairs, derived from an offline schema graph (Kothyari, M et al., 2023), from online value overlap such as Jaccard similarity over columns (Chen, P et al., 2024), or from a search for join paths that connect the matched attributes (Wang, X et al., 2025). These signals can then be combined with semantic coverage into a joint selection objective (Chen, P et al., 2024) (Kothyari, M et al., 2023), or folded directly into the per-step selection of iterative retrieval, avoiding a separate optimization phase (Boutaleb, A et al., 2025). These column relationships are also applied to expand retrieved sets of tables with joinable ones to include tables that have a low semantic alignment (Agarwal, R et al., 2025). Across these approaches, compatibility is judged on properties intrinsic to table pairs, such as key relationships or value overlap. Yet structural compatibility is ultimately determined by the agent’s capabilities for analytical composition and execution, since capable agents may construct integration paths through transformations such as schema matching or feature engineering. The assessment of structural compatibility should thus depend on the capabilities of the agent.

Zou et al. (2026) take a different approach. Instead of a regular index, they construct a hypergraph of tables based on semantic, structural, and heuristic similarity features. They then apply clustering and PageRank to surface groups of related tables. Unlike the approaches above, which compose sets that align with the specific data need, this approach captures general table relatedness within the corpus. It can surface structurally similar tables but does not explicitly optimize for semantic coverage and structural compatibility.

Notably, none of the discussed approaches actively handles cases in which no sufficient set of tables exists within the corpus for the given data need. When $R_{\text{cand}} = \varnothing$, most retrieval methods would still return a set of tables, leaving the insufficiency undetected.

Generative Retrieval.

Generative retrieval presents an alternative to maintaining an explicit index by encoding the corpus into the parameters of a sequence-to-sequence model that directly generates identifiers of relevant tables given an input (Tay, Y et al., 2022), unifying indexing and search into a single differentiable process. Guo et al. (2025) apply this to individual tables, assigning each a semantic identifier derived from hierarchical clustering of metadata and cell values, while Wang et al. (2025) extend it to multi-table settings by serializing a schema graph into the generation target and constraining decoding to valid connected table sets. Both train on synthetic queries generated over the target schemas.

Since generative retrieval learns the index directly it can capture semantic and structural properties jointly, which, depending on the training, enables deeper input-table interaction than bi-encoders that encode queries and tables independently (Guo, Y et al., 2025). Its effectiveness is limited by the quality of the synthetic training data, which may propagate hallucinations or distributional biases into retrieval errors (Wang, T et al., 2025). Additionally, since the index is learned, corpus changes require new or additional training, with parameter-isolation strategies for new tables explored but not validated at scale (Guo, Y et al., 2025).

Dynamic Retrieval.

Most OpenTI systems treat retrieval as a separate phase preceding the analytical process, constructing the complete data bindings $\beta$ upfront. This assumes the data need $i_d$ can be fully determined from the initial input. Yet intermediate results may reveal requirements for additional data, such as linking tables for data integration, reference data for normalization, or variables whose relevance becomes apparent only after initial analysis. Furthermore, treating retrieval as a decoupled step makes recovery from retrieval misses difficult. Works on text documents have thus explored conditioning retrieval on the processing state (Jiang, Z et al., 2023) (Asai, A et al., 2024). In the tabular context, iterative retrieval methods (Zhang, X et al., 2025) (Boutaleb, A et al., 2025) interleave retrieval and interpretation capabilities, but still operate within a dedicated retrieval phase. Wang and Li (2025) take an initial step towards integrating retrieval with other capabilities by treating it as an operator that is invocable during execution, though without systematic methods for leveraging the intermediate analytical state to inform retrieval decisions.

3.3.3 Analytical Composition and Execution

Analytical composition and execution capabilities allow OpenTI agents to construct, parameterize, and execute the operational structure $(O, E)$ of a realization. They thus enable OpenTI agents to derive the analytical knowledge to satisfy the user’s insight need. We describe them based on the mechanisms that are employed to specify and execute operations, the analytical composition, that is, the manner in which operations are composed, and the role of data preparation in this process.

Mechanisms.

The mechanisms through which an agent executes operations determine what operations it can express and, therefore, which insight needs the agent can address. OpenTI systems may employ code generation in domain-specific and general-purpose languages, tool calling over defined functionalities, and direct inference techniques as mechanisms for executing operations. The Analysis column of Table 1 shows which of these mechanisms each system employs, showing that most systems rely on domain-specific and general-purpose code, whereas fewer systems make use of direct inference and tool calling.

Domain-Specific Language (DSL) generation, mostly studied in the form of SQL generation, is the most extensively researched mechanism for deriving knowledge from tabular data, building on a substantial body of research into text-to-SQL generation (Liu, X et al., 2025). Several systems apply SQL generation as their sole analytical mechanism (Pourreza, M & Rafiei, D, 2023) (Lee, J et al., 2025) (Menon, R et al., 2025) (Xu, W et al., 2025) (Chen, K et al., 2026), while others combine it with other mechanisms (Zhang, H et al., 2025) (Xu, W et al., 2025) (Kong, K et al., 2023) (Wang, J & Li, G, 2025) (Zhang, Y et al., 2024) (Huang, Y et al., 2024) (Zhu, J et al., 2024) (Su, A et al., 2024). DSLs like SQL are designed for a particular application domain. In SQL, this specialization provides formal semantics grounded in relational algebra (Codd, E, 1970), enabling a well-defined execution behavior and a constrained output space. However, the specialization of DSLs bounds what operations can be expressed. SQL has limited capacity to express statistical modeling, machine learning, optimization, or visualization operations (Zhao, Y et al., 2024) (Kong, K et al., 2023), confining systems that rely on it as their sole execution mechanism largely to descriptive insight needs, with inferential and causal needs falling outside its expressive scope. Systems that employ SQL generation alongside other mechanisms typically delegate operations outside the scope of SQL to complementary mechanisms, such as direct inference for result synthesis (Zhang, H et al., 2025) (Xu, W et al., 2025) (Kong, K et al., 2023) or general-purpose code for data transformations (Zhang, Y et al., 2024) (Zhu, J et al., 2024) (Huang, Y et al., 2024) (Su, A et al., 2024).

General-Purpose Language (GPL) generation, mostly studied in the form of Python generation, generates code in a general-purpose language to interact with data (Gao, L et al., 2023). While GPLs can express arbitrary computations, making them theoretically capable of addressing the full spectrum of insight needs, they provide less domain-specific scaffolding than DSLs, resulting in a less constrained output space and a greater range of potential errors. In OpenTI, the extensive ecosystem of Python libraries for data manipulation, statistical analysis, machine learning, and visualization (Zhang, Y et al., 2024) (Chen, Y et al., 2025) supplies this scaffolding within a GPL, letting systems leverage these abstractions while retaining the expressiveness to address arbitrary operations. Many of the reviewed works therefore employ Python generation as a primary (Zhao, Y et al., 2024) (Mao, Q et al., 2024) (Hu, X et al., 2024) (Chen, S et al., 2024) (Chen, Y et al., 2025) (Lai, E et al., 2026) (Li, J et al., 2025) or complementary mechanism (Zhang, Y et al., 2024) (Zhu, J et al., 2024) (Huang, Y et al., 2024). Despite the theoretical breadth, these systems mostly demonstrate their Python code generation on descriptive needs that largely overlap with tasks also addressable through SQL, with only a few extending to inferential needs such as statistical inference and prediction (Hu, X et al., 2024) (Huang, Y et al., 2024) (Qiao, S et al., 2026) (Li, J et al., 2025), leaving the practical effectiveness for more complex analytical intents largely undemonstrated. Moreover, the unconstrained output space has motivated the application of safety measures like containerization for executing operations (Hu, X et al., 2024) (Huang, Y et al., 2024) (Su, A et al., 2024).

Tool calling employs functions with specified semantics that the agent selects and parameterizes at execution time. Unlike code generation, where the operation is specified in full by the generated code, tool calling constrains the agent to invoking specific functions from a limited set. Abstracting operations into predefined callable functions allows tighter design-time control over the operations applied to the data, at the cost of limiting what an agent can express, making the expressiveness of tool-calling systems mostly dependent on the scope of the tool set. Methods vary in the number and complexity of tools they have access to, from small sets of simplistic table operations like select rows and group by (Wang, Z et al., 2024) (Jin, R et al., 2025), to larger sets of more expressive operations (Wang, J & Li, G, 2025) (Kochedykov, D et al., 2023). Automatically generating missing tools for specific inputs (Gemmell, C & Dalton, J, 2023) (Lu, X et al., 2025) has been proposed to rectify the inflexibility of predefined tools.

Direct inference employs models directly to perform operations over tabular data and intermediate results. Unlike code generation and tool calling, where operations are explicitly specified and executed by an external interpreter, direct inference performs computations within a model itself, making the operation implicit in its learned behavior. The expressiveness of this mechanism depends on the capabilities of the employed models. In principle, a sufficiently capable model could map directly from raw data to analytical knowledge in a single step, subsuming all intermediate operations. In practice, systems apply direct inference at varying levels of granularity, ranging from atomic operations such as cell selection or fact verification (Wang, Z et al., 2024) (Zou, J et al., 2026) (Lin, W et al., 2023) to synthesizing free-form responses from intermediate results produced by other mechanisms (Kong, K et al., 2023) (Zhang, H et al., 2025) (Xu, W et al., 2025). In direct inference, operations are not externalizable, meaning no executable specification can be inspected, verified, or reused independently of the model, limiting the interpretability of how analytical knowledge is derived. Moreover, the reliability of computational operations such as arithmetic, aggregation, or statistical computation relies on the model’s precision rather than formal execution semantics. Studies into the application of language models for numerical computations show degradations (Wu, X et al., 2025) (Wolff, C & Hulsebos, M, 2025) (Zhou, W et al., 2024), particularly as input size increases (Zou, J et al., 2026). Most reviewed works thus combine direct inference with other mechanisms, relegating direct inference to higher-level functions such as aggregating results across sub-needs (Zhang, H et al., 2025) (Wang, J & Li, G, 2025), synthesizing free-form responses from execution outputs (Kong, K et al., 2023) (Xu, W et al., 2025), or performing simple extraction tasks that do not require precise computation (Zhang, S et al., 2024) (Zou, J et al., 2026) (Lin, W et al., 2023).

Analytical Composition.

Analytical composition concerns how the analytical logic $(O, E)$ is assembled, that is, the manner in which operations $O$ are selected, connected and parameterized. Analytical composition is coupled with the orchestration strategy, which determines when and how often the agent invokes analytical composition, constraining the possible composition patterns. In plan-based orchestration, the operational structure may be largely determined during plan generation, integrating composition directly into orchestration (Wang, J & Li, G, 2025). In reactive orchestration, composition decisions are distributed across successive actions during execution, making the capability more clearly distinguishable.

Approaches mostly differ in how much of the analysis they specify at a time. In one-shot composition, agents specify the analytical logic in a single step, for instance a full SQL query (Kothyari, M et al., 2023) (Zhang, X et al., 2025) (Wang, T et al., 2025) (Chen, P et al., 2024) or a complete Python script (Chen, Y et al., 2025) (Lai, E et al., 2026), committing to the operational structure without observing intermediate states. In incremental composition, the operational structure is built over successive actions, each producing an intermediate result the agent can observe before determining the next operation (Zhang, Y et al., 2024) (Mao, Q et al., 2024) (Wang, Z et al., 2024) (Zhou, W et al., 2025) (Huang, Y et al., 2024) (Chen, S et al., 2024) (Zhu, J et al., 2024) (Hu, X et al., 2024), allowing it to detect unexpected results, adjust the analytical approach, or refine the scope of operations based on the data. Works report improved accuracy over one-shot generation (Zhang, Y et al., 2024) (Wang, Z et al., 2024), contingent on the agent’s ability to effectively use intermediate state information. When insight needs are decomposed into sub-needs, each sub-need can be treated individually and integrated with the others downstream (Zhao, Y et al., 2024) (Zhang, H et al., 2025) (Xu, W et al., 2025) (Wang, J & Li, G, 2025), which also lets independent sub-needs be processed in parallel (Wang, J & Li, G, 2025) (Zhang, H et al., 2025).

Execution mechanisms and composition patterns are largely coupled, though not rigidly. The declarative nature of DSLs favors one-shot composition, as a single query typically encodes the full analytical logic, yet DSL generation is also used incrementally (Zhang, Y et al., 2024) (Mao, Q et al., 2024) (Chen, S et al., 2024). Tool calling is inherently incremental, since each call is a separate action with observable intermediate state (Wang, Z et al., 2024) (Zhou, W et al., 2025), whereas general-purpose code generation spans both one-shot (Chen, Y et al., 2025) (Lai, E et al., 2026) and incremental settings and allows arbitrarily sized actions.

Data Preparation.

Data preparation aims to select, clean, and transform retrieved data into a form that enables the analytical operations that generate the analytical knowledge. It forms a substantial component of manual analytical workflows (Martínez-Plumed, F et al., 2021), addressing the selection of relevant data, data quality issues such as inconsistent formatting, missing values, and structural irregularities (Rahm, E & Do, H, 2000), as well as structural mismatches between data and the requirements of intended operations (Wickham, H, 2014). Insufficient data preparation has been identified as a significant contributor to failures of systems operating in open environments with messy, real-world data (Lai, E et al., 2026). Nonetheless, it has seen limited coverage in the reviewed works. Several systems integrate specific data cleaning stages (Mao, Q et al., 2024) (Zhang, H et al., 2025) (Su, A et al., 2024), sanitizing data before applying analytical operations. Beyond these, other approaches may apply ad-hoc cleaning, such as type coercions and string normalization (Chen, S et al., 2024) (Chen, Y et al., 2025) (Zhang, Y et al., 2024). Departing from these programmatic approaches, Lu et al. (2025) explore fine-tuning a language model to perform data cleaning as a sequence-to-sequence task.

3.3.4 Output Synthesis

Output synthesis capabilities enable OpenTI agents to produce the final user-facing output from the analytical knowledge derived in the realization. Formally, this corresponds to executing the sink node of the realization DAG to address the output need $i_o$. While this is part of the operation structure $(O, E)$, output synthesis addresses how analytical knowledge is communicated to the user rather than how it is computed. This distinction matters because the utility of a realization depends not only on the soundness of its analytical derivation but also on how effectively its results are presented (Munzner, T, 2014) (Moritz, D et al., 2019).

OpenTI agents perform output synthesis to different degrees. At the minimal end, a system returns solely the raw computational result (e.g., a retrieved or calculated value, a result table). At the other end, systems select appropriate modalities, integrate results from multiple analytical branches into a coherent response, and add interpretative framing that contextualizes the analytical knowledge. In practice, the output need $i_o$ is often underspecified or entirely absent from the input, as reflected in current benchmarks where the expected modality is typically specified in the evaluation protocol rather than in the input (Section 5.2). This means that systems need to compose a fitting presentation (Gomm, D et al., 2025) (Mackinlay, J, 1986). The degree to which a system performs output synthesis thus determines to what extent it can make the analytical knowledge accessible to the user.

Output Modalities.

The output modality determines the form the analytical knowledge is presented in. Outputs may consist of natural language text, structured data such as tables, visualizations, and multimodal combinations thereof. As shown in the Output column of Table 1, the majority of the reviewed systems only output text. Within these, however, the outputs range considerably, from single discrete values concerning descriptive insight needs (Zhou, W et al., 2025) (Mao, Q et al., 2024) (Kong, K et al., 2023), through short natural language responses that verbalize computational results (Zou, J et al., 2026) (Wang, Z et al., 2024), to paragraph-length answers that narrate analytical findings (Zhao, Y et al., 2024) and long-form analytical reports that synthesize complex results (Xu, W et al., 2025). Systems that return raw execution results, whether that is SQL result tables (Zhang, X et al., 2025) (Kothyari, M et al., 2023) (Chen, P et al., 2024) (Wang, T et al., 2025) or code output values (Chen, Y et al., 2025) (Lai, E et al., 2026), surface the computational result without verbalization or interpretation, requiring that users understand the analytical context to interpret the raw results directly.

Beyond text and tables, systems have explored visual outputs, either as a separate modality, selected based on the input and standing on its own (Huang, Y et al., 2024) (Li, J et al., 2025) (Zhu, J et al., 2025) (Kochedykov, D et al., 2023), or contextualized in a multimodal response (Su, A et al., 2024). Dedicated capabilities for generating visualizations from data and natural language descriptions exist (Yang, Z et al., 2024) but have not been widely integrated into the reviewed OpenTI systems. Generally, different types of analytical knowledge benefit from different modalities. Retrieved facts and summary statistics, for example, are well served in text form, whereas trends and distributions may benefit from visualizations.

Result Integration.

If insight needs decompose into sub-needs, particularly independent sub-needs that are processed in parallel (Section 3.3.1), the output must integrate the results of these sub-needs into a coherent output that addresses the original need. Systems that handle result integration specifically employ LLMs to compose a unified output from the results of sub-needs (Zhang, H et al., 2025) (Xu, W et al., 2025) (Wang, J & Li, G, 2025) (Zhao, Y et al., 2024).

Modality Selection.

To best address an output need $i_o$ and maximize the utility, a OpenTI system must select an appropriate modality, or combination of modalities, for outputting the analytical knowledge. The appropriate modality depends on the nature of the analytical result, the insight need, and the user’s ability to interpret different forms of presentation (Munzner, T, 2014). However, in most reviewed systems, the selection is fixed to an evaluation-task-specific modality. In systems that support multiple modalities (Huang, Y et al., 2024) (Li, J et al., 2025), the modality for a given instance is typically specified in the task instruction rather than determined by the system. A few systems do select the modality themselves. TableGPT2 (Su, A et al., 2024) dynamically selects it based on learned behavior in training, while TiInsight (Zhu, J et al., 2025) and DataQue (Kochedykov, D et al., 2023) apply explicit rules and heuristics that map the result’s data characteristics to a chart type or fall back to a table. Adjacent works on visualizations have addressed modality selection through methods that map data characteristics and analytical tasks to effective visualizations (Mackinlay, J, 1986) (Moritz, D et al., 2019) (Mackinlay, J et al., 2007). However, among the reviewed systems, similar efforts have thus far not been undertaken.

Contextualization.

Recalling the definition of an insight as a collection of knowledge that links analytical knowledge with a person’s contextual understanding (Section 2.1.1), the output of an OpenTI system may integrate the presented analytical knowledge with contextual information to improve the insight the user gets. This may involve relating findings back to the insight need, noting limitations of the underlying data, qualifying the scope of the results, or explaining what the analytical knowledge means in context. Yet contextualization is largely absent from output synthesis in current systems. A few systems target it explicitly. For instance, DAgent (Xu, W et al., 2025) generates reports that include interpretations alongside analytical results, DACO (Wu, X et al., 2024) is trained to translate quantitative findings into strategic, domain-specific recommendations, and AOP (Wang, J & Li, G, 2025) attaches generated reasoning to its results through a dedicated explanation operator. In most other systems, contextualization is incidental rather than a designed capability, as in TableGPT2 (Su, A et al., 2024), which occasionally notes data availability limitations. The absence of contextualization of outputs is also reflected in evaluation practice, which mainly assesses the correctness of final values and treats additional verbalization as noise rather than value (Section 5.3).

3.3.5 Process Governance

Process governance capabilities operate at the meta-level (Davis, R & Buchanan, B, 1977) (Davis, R, 1980), shaping which realization $r$ gets constructed without directly contributing executable operations to it.

This includes error detection and recovery, validating intermediate and final results, reflecting on and revising the analytical strategy, and determining when the process is complete. As shown in Table 1, many systems lack explicit process governance or only handle errors. Other systems employ a range of process governance techniques extending to result validation, adaptive steering, and ensembling.

Error Detection and Recovery.

Error detection and error recovery deal with failure states in the analytical process. This requires detecting failure states and exerting appropriate corrections, which may range from rigid fallbacks that follow predetermined alternatives to adaptive corrections informed by the observations of the error. In the reviewed works, error detection is universally implemented as programmatic checks on code execution, using runtime exceptions from Python and SQL execution as a signal for failure states. In contrast, error recovery approaches follow different patterns. The most rigid form consists of applying predetermined fallbacks that are fixed at design time, such as cascading to executing simpler code (Kong, K et al., 2023), switching to an alternative tool (Zhou, W et al., 2025), or falling back to a different mode of generating the output (Lu, X et al., 2025). More adaptive recovery feeds the error message back to a generating LLM to re-generate the failing operation. This pattern is rooted in self-debugging (Chen, X et al., 2023) and widely adopted in the reviewed works (Chen, Y et al., 2025) (Lai, E et al., 2026) (Mao, Q et al., 2024) (Huang, Y et al., 2024) (Hu, X et al., 2024) (Li, J et al., 2025) (Su, A et al., 2024) (Zhao, Y et al., 2024) (Chen, S et al., 2024) (Jin, R et al., 2025) (Jiang, C et al., 2025) (Qin, Y et al., 2025) (Pourreza, M et al., 2025), typically bound by a fixed limit for retries (Chen, Y et al., 2025) (Mao, Q et al., 2024), or a global step budget in ReAct-based systems (Huang, Y et al., 2024) (Hu, X et al., 2024). In contrast, Zhang et al. (2024) explore error recovery by retrying failed SQL queries arising in a ReAct step against intermediate tables from earlier steps.

Result Validation.

Result validation assesses whether intermediate or final results meet quality criteria beyond successful code execution, since code can run error-free yet yield results that are empty, irrelevant, or misaligned with the insight need. Validation differs in depth. At a surface level, systems verify that execution produces non-empty or structurally compliant outputs and trigger error recovery otherwise (Chen, Y et al., 2025) (Lai, E et al., 2026). At a deeper level, systems assess whether a result is relevant to the insight need, either before execution by scoring or rewriting generated queries against the analytical requirements (Xu, W et al., 2025) (Chen, K et al., 2026) (Chi, Y et al., 2025) or after execution by filtering out results obtained from irrelevant tables (Kong, K et al., 2023). At the process level, validation can assess whether accumulated results collectively address the insight need, as in AOP’s (Wang, J & Li, G, 2025) operators that search external knowledge for supporting or contradicting evidence and AutoTQA’s (Zhu, J et al., 2024) critic agent that compares results against the original need and triggers replanning where sub-needs remain unaddressed.

Adaptive Steering.

Adaptive steering covers capabilities to diagnose whether the analytical process is on track to yield the desired result and to adjust course where it is not. This mirrors the monitoring and replanning cycle in automated planning under uncertainty (Ghallab, M et al., 2004), where agents detect when observations invalidate the assumptions underlying their current strategy and adapt accordingly. Adaptations can range from assessments and alterations within individual steps, to backtracking, the exploration of different analytical paths, and, most comprehensively, to strategic revisions of the full analytical plan. Language model-based systems can perform the diagnostic component through self-reflection, reasoning about the analytical process as a whole as part of the generative process. In ReAct-based systems (Huang, Y et al., 2024) (Hu, X et al., 2024) (Chen, S et al., 2024) (Su, A et al., 2024) (Wang, Z et al., 2024), the interleaved reasoning steps provide an implicit form of reflection, where the agent reasons about its observations before selecting the next action. AOP (Wang, J & Li, G, 2025) handles self-reflection in a dedicated operator that generates justifications for intermediate results, making the agent’s reasoning explicit and available for subsequent integration across analytical paths. For correcting the analytical course, some systems implement re-planning, adjusting an overarching analytical plan to the results of self-reflection. TaPERA (Zhao, Y et al., 2024) and AutoTQA (Zhu, J et al., 2024) perform a post-hoc analysis of the analytical process, informing re-planning of a further iteration of analysis. In contrast, AOP (Wang, J & Li, G, 2025) adapts its generated plan forward by evaluating intermediate results after each execution layer and pruning branches where operations have failed, re-invoking pipeline generation conditioned on the results gathered so far. Table-Critic (Yu, P et al., 2025) structures correction as a multi-agent loop in which a judge identifies errors in the reasoning chain, a critic suggests fixes, and a refiner revises the affected steps.

Ensembling.

Ensembling mitigates the variance inherent in stochastic processes, such as language model generation, by sampling multiple analytical trajectories and aggregating their results. A common approach is majority voting over independent runs of the full analytical process (Chen, S et al., 2024) (Zhang, Y et al., 2024) (Sun, R et al., 2023), selecting the most frequent answer. Alternatively, a trained selector can be applied to select among candidates (Zhang, S et al., 2024) (Pourreza, M et al., 2025). Ensembling is also applied to the analytical operations themselves, as CHASE-SQL (Pourreza, M et al., 2025) selects between candidate SQL queries and AOP (Wang, J & Li, G, 2025) generates multiple candidate pipelines with justifications and has a language model combine them by assessing the soundness of each analytical process. Instead of comparing outputs or complete realizations, Zhang et al. (2024) explore branching at each analytical step and grouping intermediate steps that produce computationally equivalent results, finally selecting by aggregated log-probability of the respective output generation, grounding the selection in computational outcome rather than surface-level agreement. On a finer granularity, MACT (Zhou, W et al., 2025) samples multiple candidate actions per step and selects by majority vote.

Governance Mechanisms.

The mechanisms discussed above vary in how far meta-level governance capabilities are separated from object-level analytical capabilities. Separating the component that assesses results from the one that produces them is a well-established principle, originating in actor-critic architectures in reinforcement learning (Konda, V & Tsitsiklis, J, 1999). For LLM-based systems, which dominate current OpenTI implementations, this separation is particularly relevant as self-correction by language models has been shown to be unreliable without external verification (Huang, J et al., 2023), though structured verification procedures can partially mitigate this (Wu, Z et al., 2024). The majority of the reviewed works use the same language model that performs the analytical work for process governance, differing only in prompting (Chen, Y et al., 2025) (Lai, E et al., 2026) (Mao, Q et al., 2024) (Zhao, Y et al., 2024) (Huang, Y et al., 2024) (Hu, X et al., 2024). Some systems introduce a separation by instructing the same underlying language model for different roles, as in AutoTQA’s (Zhu, J et al., 2024) critic agent and AOP’s (Wang, J & Li, G, 2025) validation operators. In contrast, other systems use distinct models for a stronger separation, such as a pretrained cross-encoder for relevance assessment (Kong, K et al., 2023), a fine-tuned evaluator for query quality (Xu, W et al., 2025), or multiple agents in different roles that mutually validate one another (Zhou, W et al., 2025). Complementing these, programmatic checks for code execution errors and results provide deterministic governance signals (Chen, X et al., 2023).