% ============================================================================ \section{Execution Substrate and Document Generation} \label{sec:capabilities} % ============================================================================ Having described how the agent is orchestrated, we now detail the two subsystems that turn its plans into artifacts: the sandboxed Python substrate that executes arbitrary model-authored code, and the pipeline that renders the resulting report into multiple document formats. Both are described at the mechanism level. \subsection{The Python execution sandbox} \label{subsec:sandbox} When the model invokes the custom-analysis tool, the server does not evaluate the code in process. It spawns a separate Python interpreter (resolved to a project virtual environment) as a child process and communicates with it over standard streams, an isolation boundary that protects the server from faults in the executed code and bounds its blast radius (Figure~\ref{fig:sandbox}). \input{figures/sandbox} \paragraph{Inter-process protocol.} The server serializes a single JSON object---the model-authored code, an optional context dictionary, and the market-data credential---and writes it to the child's standard input, then closes the stream. The child reads the entire input, executes, and writes exactly one JSON object to standard output: a success flag, captured textual output, a list of base64-encoded figures, a list of generated files, and any error. The child is launched with output buffering disabled so that nothing is lost, and with a hard 90-second wall-clock timeout. The parent collects standard output and standard error separately; a non-zero exit code, or error output with no standard output, is treated as failure and the error is surfaced to the model so that it can revise its code on the next turn. This single request / single response discipline keeps the boundary simple and makes failures explicit. \paragraph{Namespace construction.} Inside the child, execution is performed by building an \emph{execution namespace}---a dictionary---and calling the interpreter's \texttt{exec} against it. Into this namespace the runtime injects the scientific libraries (NumPy, pandas, matplotlib, and the broader set of seventeen), the two artifact helpers (\texttt{save\_excel}, \texttt{save\_word}), and a market-data client constructed from the supplied credential; any context variables passed by the model are merged in last, so that the model can parameterize a reusable script without string interpolation. Matplotlib is configured for a non-interactive backend before any plotting occurs, so that figure rendering requires no display. As a convenience, if the executed code defines a callable named \texttt{main}, the runtime invokes it after execution and captures its return value. \paragraph{Output and figure capture.} Standard output and standard error produced by the code are redirected into in-memory string buffers for the duration of execution, so that the model's \texttt{print} statements become the textual result rather than corrupting the JSON protocol. Figures are captured \emph{after} execution by a deterministic sweep: the runtime enumerates all live matplotlib figure numbers, and for each, renders the figure to an in-memory buffer as a PNG at fixed resolution with tight bounding boxes, then base64-encodes the bytes. This is exactly why the single-call paradigm of Section~\ref{subsec:onecall} asks the model to emit each chart as a \emph{separate} figure: the capture sweep turns each one into an individually addressable image that the report can caption and reference. The encoded figures travel back through the JSON response, are written to a served directory by the server, and are streamed to the client as figure events. \subsection{Embedded numerical tools} \label{subsec:numerical} Alongside the open-ended sandbox, the platform exposes a small set of pre-built numerical tools for common tasks, so that routine requests need not regenerate code: a Monte Carlo path simulator under a standard log-normal price model, a closed-form European option pricer that returns prices together with the full set of risk sensitivities, a GARCH(1,1) conditional-volatility estimator, and a Value-at-Risk calculator offering historical, parametric, and simulation-based variants with companion risk ratios. These tools are conventional in quantitative finance and we do not elaborate their formulae here; what matters for the architecture is that they share the sandbox's contract---deterministic computation over live data, returning structured results and figures through the same channels---so the model can mix them freely with custom code inside a single analysis. Their detailed inputs and outputs are summarized in Appendix~\ref{app:numerical}. \subsection{The document-generation pipeline} \label{subsec:docs} VQuant treats the deliverable as a first-class artifact. From a single Markdown report---the text the agent streams to the user, with embedded figure references---the platform produces several output formats, each through a distinct mechanism (Figure~\ref{fig:docpipeline}). \input{figures/docpipeline} \paragraph{PDF via headless rendering.} The challenge in rendering Markdown that contains mathematics is that a Markdown parser will mangle mathematical syntax. The pipeline solves this with a \emph{protect--parse--restore} mechanism: before parsing, every block- and inline-math span is extracted and replaced by a unique placeholder token; the now math-free Markdown is parsed to HTML; the placeholders are then restored as spans destined for a client-side math renderer. The assembled HTML is loaded into a headless browser, which executes the math renderer; the server explicitly \emph{waits for the rendered output to appear} in the DOM before capturing the page to PDF with page furniture (headers, footers, pagination). Rendering in a real browser engine is what lets complex notation and styled tables reproduce faithfully. \paragraph{Slides via model restructuring and two-pass \LaTeX.} Presentation output is a two-phase mechanism. First, the platform issues a \emph{second} model call whose sole task is to restructure the report into slide content---one idea per slide, special characters escaped, key quantities emphasized---returning only body \LaTeX{}, not a full document. The server then wraps that body in a fixed, branded Beamer preamble and compiles it with two sequential passes of the \LaTeX{} engine, the second pass being required for cross-references and the table of contents to resolve. When the analysis produced figures, the server additionally synthesizes one slide per figure, integrating the visual output into the deck without further model involvement. \paragraph{Word via document conversion.} For an editable office format, the same Markdown is handed to a document converter that emits a word-processor file, preserving tables, lists, and heading structure. \paragraph{Spreadsheets with live formulas.} Within the sandbox, the spreadsheet helper writes multi-sheet workbooks containing \emph{live} formulas---sums, ratios, conditional formats, data bars---rather than pre-computed constants, so the recipient can audit and modify the calculations. This mirrors, at the spreadsheet level, the platform's broader commitment to auditable output: the deliverable carries its own derivation. \paragraph{Sharing and persistence.} Finally, any report can be published to a stable, unique URL; the server stores the report content and its figure references and serves them through a public viewer, so an analysis can be revisited or cited without re-running the computation. Sessions, token ledgers, and cost estimates are persisted per user, supporting both continuity and the operational analytics discussed next.