% ============================================================================ \section{Introduction} \label{sec:introduction} % ============================================================================ Large language models (LLMs) now produce fluent commentary on earnings, valuations, and macroeconomic conditions, and a growing literature documents their ability to extract signal from financial text \citep{lopezlira2026chatgpt,wu2023bloomberggpt,hansen2023fedspeak}. Fluency, however, is not rigour. A model that \emph{describes} a value-at-risk calculation has not \emph{computed} one; a model that \emph{recalls} a price from its training data has not \emph{retrieved} the current quote; and a model that narrates a Monte Carlo experiment has not run the simulation whose numbers a portfolio manager would act upon. Surveys of hallucination in natural-language generation \citep{ji2023hallucination} and of LLM evaluation \citep{chang2024survey} make the same point from the other side: generated numbers are not trustworthy unless they are produced, or at least checked, outside the model. The central engineering problem in applied financial AI is therefore \emph{grounding}: how to bind a probabilistic text generator to live data, deterministic computation, and reproducible artifacts without giving up the conversational interface that makes the technology accessible. This paper describes \textbf{VQuant}, a deployed web platform built around one answer to that problem. VQuant accepts a natural-language request---``analyse NVDA's fundamentals, technicals, and run a Monte Carlo simulation,'' for example---and returns a multi-section report with live data, computed figures, and downloadable documents. The platform is a full-stack TypeScript monorepo: a React front end, a modular Express back end, and an isolated Python scientific-computing layer. Its organising principle is a division of labour: the language model \emph{plans and synthesises}, while deterministic server code \emph{retrieves, schedules, computes, and accounts}. Every number in a VQuant report is meant to originate from a market-data endpoint, a closed-form formula, or Python code that the reader can inspect. The design belongs to the family of program-aided and tool-augmented language models \citep{gao2023pal,chen2023pot,schick2023toolformer,yao2023react,mialon2023augmented}; its specific contribution is to work out, at the level of a production system, what that family's principles require when the tool surface is large, the data are live, and the deliverable is a document. \paragraph{What kind of paper this is.} This is a \emph{design-science} paper in the sense of \citet{hevner2004design} and \citet{gregor2013positioning}: it presents an artifact, states the problem it addresses, and specifies its construction precisely enough to be reproduced and later evaluated. It is \emph{not} an empirical evaluation. We report no measurements of numerical accuracy against ground truth, no hallucination rates, no latency or cost benchmarks, and no ablations; where the first version of this paper used the words ``results'' and ``robustness'', the present version uses ``design rationale'' and ``threats to validity''. Section~\ref{sec:evaluation} instead specifies the evaluation we think the artifact warrants---benchmark, metrics, ablations, and baselines---and marks it explicitly as not yet executed. We regard this separation as a matter of research integrity: a system paper that reports qualitative impressions as results invites exactly the kind of unverifiable claim that the system itself is designed to prevent. \paragraph{Audit against the code.} A second feature of this version is that every mechanism described has been checked against the platform's source code at a fixed commit (\texttt{vquant.git}, commit \texttt{e2a148a}, 2 October 2026, hereafter ``the audited commit''). Where the implementation differs from the platform's own documentation, or from the first version of this paper, we say so. Three such discrepancies are material and are reported in the text: the tool catalogue contains 245 tools rather than the ``200+'' and ``213'' figures used in earlier descriptions; the token-accounting correction uses a general-purpose byte-pair tokenizer whose vocabulary differs from the provider's, so the ``exact'' count of the earlier description is an approximation; and several pre-built numerical routines (Monte Carlo, GARCH, VaR, portfolio optimisation) have server-side handlers but are absent from the tool catalogue, so the model cannot invoke them. Appendix~\ref{app:audit} tabulates each claim of the paper with the file that supports it. \paragraph{Terminology.} Three terms recur and are used in a fixed sense. An \emph{agentic} loop is a control structure in which the model's output can request actions (tool calls) whose results are fed back to the model, repeatedly, until it produces a final answer \citep{yao2023react,wang2024agents}; the loop is agentic in this operational sense and no claim about autonomy is implied. \emph{Tool use} (or function calling) is the provider-level protocol by which a model emits a structured call against a declared JSON schema and receives a structured result \citep{anthropic2026tooluse,schick2023toolformer}. A \emph{reasoning-capable} model is one that can allocate an adaptive budget of private intermediate tokens to deliberation before and between its visible outputs \citep{wei2022chain}; the platform surfaces a summary of this deliberation to the user but does not depend on its content. \paragraph{Contributions.} Within these bounds the paper makes four contributions. \textbf{(1)~A specified orchestration loop.} Section~\ref{sec:methodology} gives the streaming transport, the recursive tool-calling procedure, the batching throttle, and the prompt-level routing that let a model navigate a catalogue of 245 tools without an explicit planner. \textbf{(2)~A specified context-management procedure.} We state, as an algorithm with its actual constants, the three-stage mechanism---per-result truncation at execution time, a re-send cap, and adaptive summarisation under a token budget---that keeps long sessions within the model's context window, and we relate it to the known degradation of long-context attention \citep{liu2024lost}. \textbf{(3)~A single-call computation convention and its substrate.} We argue that consolidating data acquisition, estimation, and visualisation into one sandboxed execution removes model round trips, and we specify the inter-process sandbox that executes model-authored code. \textbf{(4)~A document pipeline.} We describe how one Markdown artifact becomes PDF, DOCX, Beamer slides, and spreadsheets with live formulas. A fifth, methodological, contribution is the evaluation protocol of Section~\ref{subsec:protocol}. The classical quantitative methods the platform automates---option pricing, conditional-volatility modelling, simulation, and risk metrics---are standard and are recorded compactly in Appendix~\ref{app:numerical}. The remainder of the paper is organised as follows. Section~\ref{sec:literature} situates the artifact in the literatures on tool-augmented LLMs, LLM agents and their evaluation, and LLMs in finance and economics. Section~\ref{sec:architecture} describes the architecture, data layer, and model layer. Section~\ref{sec:methodology} develops the orchestration mechanisms. Section~\ref{sec:capabilities} describes the execution substrate and the document pipeline and walks through one request as an illustration. Section~\ref{sec:evaluation} gives the design rationale, threats to validity, reproducibility information, and the proposed evaluation protocol. Section~\ref{sec:conclusion} concludes.