The chatbot posture, and what it costs#

Start with what the default architecture actually is. A user types a request, an agent decides what to do, calls a tool, reads the result, decides again, and eventually emits code. Every decision in that chain is a model judgment. The order of operations, the intermediate data shapes, the choice of which column means what, whether to validate anything at all: all of it is negotiated at runtime, inside the model’s context, on every single run.

That works beautifully for exploration. It is also why so many agent pipelines stall at the demo stage. The demo runs once and looks great. The daily workflow runs a hundred times, and the hundred runs disagree with each other in ways nobody can characterize, since the thing that varied was the plan, and the plan was never written down anywhere a human could inspect it.

The failure that follows is quiet. An agent asked the same question twice does not throw an error when it answers differently. It answers confidently both times. Detecting that after the fact is a real discipline with real tooling, and it belongs to a companion piece, Silent Agent Failures: A Production Blueprint for the Errors Your Dashboard Cannot See (coming soon). This article is about the other side of the problem, which is designing the variance out before it happens.

The compiler premise attacks it structurally. Ryan Lopopolo’s harness-engineering framing, which we covered in Code as Disposable Build Artifact [6], treats the LLM as a fuzzy compiler backend: the spec, lints, and reviewer prompts are the static-analysis and optimization passes, generated code is the build output, and swapping models is swapping codegen backends. Bridgewater arrived at the same structural mapping from a completely different starting point, which is a hedge fund’s production-correctness requirements rather than a keynote about harness design. Two teams reaching the same architecture independently is the first reason to take it seriously.

A hedge fund that decided the code was a build artifact#

McManus opened the talk by telling the room about a 1980 bond system that Bridgewater wrote down on a yellow legal pad, and used it to frame 50 years of the firm progressively turning written-down reasoning into systems. That is an on-stage story rather than a documented artifact, so take it as color, not evidence. The point it sets up is the one that matters: this is a firm whose entire operating history is about codifying judgment into something inspectable.

Santi Weight of AIA Labs states the design premise in one line, thinking of agentic coding “as a compiler problem, not as a [agentic] problem” [1]. The talk’s automatic captions garble the word “agentic” in that sentence, so the bracket is a correction rather than an addition. The analogy he draws is direct: a compiler takes user code and compiles it down to something lower level, and a coding agent takes a plan and compiles it down to Python [1].

Figure 2 - The Mapping, Stage by Stage: Every stage of a conventional compiler has an analogue in the pipeline. The one that changes how a team works is the leftmost: the source you maintain stops being the generated Python and becomes the typed plan that produced it.

The consequence of taking that mapping literally is what the rest of this article is about. If the plan is the source, then the plan has to be typed, compilation has to run in parallel off that plan, verification has to be a pass rather than a suggestion, and execution has to be something the pipeline controls. Four properties, and the grouping is ours rather than the speakers’. They described a working system, and this is the shape we read out of it.

Property one: the plan is a schema-typed intermediate representation#

PAT is architecturally two agents. An investment-domain chat agent, built on LangGraph, talks to the human and gathers what the analysis needs through search tools. Once it knows everything required, it hands off to a coding sub-agent [1]. The handoff is the interesting part, since it is not an instruction. It is a fully specified plan.

The plan breaks into tasks, where each task maps to roughly one Python function calculating one data frame. Every task carries exactly three things: a name, a description of what the function calculates, and structural and semantic information about the schema of the data frame that should come out [1]. Michael Ran describes the planning phase’s output the same way from the investor side, as three things the plan pins down: all of the data frames that will be produced in the analysis, the schemas of all of those data frames, and how all those data frames connect [1].

Figure 3 - The Plan Is the Source: Each task declares its own output schema before any code exists. A downstream task, such as the chart at the end of the plan, therefore already knows the shape of a data frame whose generating function has not been written yet.

That last property is the one that unlocks everything downstream. A visualization task at the end of the plan knows the columns and the meaning of a data frame whose code does not exist. Weight’s phrasing for the whole structure is deliberate: the team does not treat the plan as a to-do list, they “think of it as a natural language Python project” [1]. His expectation of the compile step is equally deliberate, that “we expect every task to deterministically compile via LLM to a piece of code… two LLMs operating on the same task should produce code that when run is semantically equivalent with the same output values, exactly the same” [1].

This is the same move we described in From Agentic RAG to Compiled Knowledge [7], one layer down. There, the compilation target was retrieved knowledge. Here it is executable code. The principle is identical: pay a structuring cost once, at build time, so that runtime stops being a negotiation.

KEY INSIGHT: If your agent pipeline has no artifact between the user’s request and the generated code, the plan still exists. It just lives inside a model’s context where nobody can review it, diff it, or reuse it.

Property two: compilation runs in parallel, and the curve goes flat#

Once every task declares its inputs and outputs up front, code generation stops being sequential. Each sub-agent knows exactly three things before it writes a line: what data frames it depends on, the schemas of those data frames, and the schema of the data frame it is itself producing [1]. Nothing forces it to wait for another task’s code, so every task in the plan can be generated at the same time.

The reported effect is a flat curve. Weight states it plainly, that “a 20-task plan takes the same amount of time as a three-task plan” [1]. That is a self-reported observation from Bridgewater’s own system rather than a published measurement, and it is the single most useful idea in the talk, since it inverts the usual incentive. Under the chatbot posture, a bigger plan costs more wall-clock time, so teams keep plans small and vague. Under the compiler posture, a more detailed plan costs almost nothing extra to compile, so the incentive runs toward specifying more.

Figure 4 - Detail Stops Being Expensive: Sequential generation charges you for every task you add, which pushes teams toward thin plans. Parallel compilation from a fully typed plan holds wall-clock time roughly constant as the plan grows, which pushes the other way.

Bridgewater also compares its generation speed to Claude Code. On Bridgewater’s own benchmark suite, for the same context and the same plan, Weight reports that they are “about four times faster for generating code” [1]. Two things about that number. It is Bridgewater’s internal benchmark rather than a third-party comparison, and nothing in the architecture argument depends on it. Claude Code is the baseline Bridgewater chose because it is the harness their audience would recognize, and this is not a harness bake-off.

The parallel-dispatch half of the argument has peer-reviewed prior art that is worth knowing about, since it means the compiler framing is not a 2026 conference invention. LLMCompiler, published at ICML 2024, formalizes exactly this shape under an explicit compiler framing [8], with a public reference implementation [9]. The paper names three components and only three: a Function Calling Planner that formulates execution plans, a Task Fetching Unit that dispatches the tasks, and an Executor that executes them in parallel [8]. Its reported results are stated as upper bounds against one named baseline, ReAct: latency speedup of up to 3.7x, cost savings of up to 6.7x, and accuracy improvement of up to roughly 9% [8].

Figure 5 - What the Prior Art Covers: LLMCompiler establishes that plan-then-parallel-dispatch is a measured pattern with an academic pedigree. It parallelizes function calls rather than code generation, it makes no reproducibility claim, and it has no enforced-validation stage, so it corroborates one of the four properties and none of the others.

Keep the boundary of that corroboration sharp. LLMCompiler parallelizes function calls, while PAT parallelizes code generation and then runs the result through a separate execution layer. The paper optimizes latency, cost, and accuracy, and claims nothing at all about run-to-run reproducibility, which is the entire point of the next section. Anyone citing it as academic support for a determinism claim has misread it.

Property three: validation is a pass the agent cannot skip#

LLM-generated code does not usually pass on the first attempt, so PAT does not execute it naively. The inner loop, as the talk enumerates it, is four steps: take the task that came in from the plan, take the code generated from that task, run the code and compare it to the task, and if it is not correct, edit the code and repeat until complete [1].

Before that loop starts, the harness runs static analysis over the generated code to build a dependency DAG across the plan’s tasks, then applies validation agents in parallel, layer by layer, in dependency order [1]. The layer counts are small and the talk gives them directly: a 5-task plan comes down to 3 layers, and a 20-task plan “might be four or five layers of validation” [1]. That hedge is theirs and it is worth carrying, since it tells you the number is an observation rather than a specification.

Figure 6 - Validation in Dependency Order: Static analysis over the generated code produces the dependency graph, and the graph collapses into a small number of layers. Everything inside a layer validates in parallel, so correctness checking scales the same way generation does.

The architectural claim underneath this is the sharpest sentence in the talk, and it is about where the enforcement lives: “no agentic orchestration. This is regular Python code… and the agents cannot forget to validate. They are forced to validate” [1]. Validation is not a step in a prompt that a model may or may not honor under context pressure. It is control flow in an ordinary program that calls the model, which is exactly the arrangement we argued for in Stripe Minions and the Hybrid Secret [10], and it is why the human ceiling we described in The Orchestration Tax [11] does not bind here. Nothing is being orchestrated by a model.

The reported consequence is a number few teams publish at all. Bridgewater reports that on its own test suite, running any one plan through two different agent instances means “95% of the time, the code that comes out is exactly the same for two different agents” [1].

Figure 7 - The Determinism Claim, With Its Fine Print: Two agents, one plan, identical generated code 95% of the time. The denominator is Bridgewater’s own internal test suite rather than production traffic, the figure is self-reported and unaudited, and one talk is the only source that exists for it.

Be clear about the standing of that figure. The denominator is their test suite, not production traffic. The measurement is internal, unaudited, and published nowhere outside a conference talk. The peer-reviewed prior art above does not corroborate it, since it makes no reproducibility claim at all. What the claim is good for is a direction of travel and an existence proof: a firm running production financial analysis decided reproducibility was an architectural requirement, built the pipeline to enforce it, and reports getting most of the way there. Whether your own pipeline lands at 95% or somewhere well below it is an empirical question for your own test suite, which is the argument we made at length in Evals in Practice [12].

KEY INSIGHT: Reproducibility is not a model property you shop for. It is an architectural property you build, by moving verification out of the prompt and into ordinary code the model cannot talk its way past.

Property four: the harness runs the code, and caches it#

Most coding agents invoke their own generated code by calling out to a terminal tool. Bridgewater names two costs for that arrangement, and only two: the latency of the tool calls, and the tendency for agents to “get lost along the way” [1].

PAT runs the code for the model instead. A static-analysis pipeline injects caching annotations into the generated Python, and a custom execution framework runs it, so redundant data loads and redundant re-execution of unchanged intermediates are avoided [1]. The benefit shows up on the second run rather than the first. In Bridgewater’s own comparison, changing only the name of the last chart in a plan forces a conventional harness to effectively rerun the whole plan, while PAT’s cached execution reruns only what actually changed [1].

Figure 8 - The Second Run Is the One That Matters: Renaming a chart should not re-execute an analysis over millions of rows. When the pipeline owns execution, it knows which intermediates are unchanged, so a cosmetic tweak costs a cosmetic amount of compute.

That is a workflow property disguised as a performance property. An analyst iterating on a chart title does not experience an agent, they experience an interface that responds. The reason it is possible at all is that the pipeline, not the model, decided when to execute.

Upstream: pointing the compiler at the right data#

A typed plan compiles into correct code only if the plan points at the right data, and PAT’s retrieval step is where the second-largest claim in the talk lives. Ran describes searching an internal time-series database holding “tens of millions of series that we’ve been modeling internally for 50 years” [1], mixing external market data with internally derived concepts. At that cardinality, many series carry plausible, near-identical names, so name similarity is not enough to tell them apart.

The team started from conventional retrieval, which Ran names directly as traditional techniques including RAG and re-ranking [1]. What they added is an element of human-like inspection, modeled on what a researcher actually does. His enumeration of the signals is three items long: the frequency of the series, the currency of the series, and, most importantly, whether the values in the series align with their priors [1].

Figure 9 - Ranking on What the Data Says: The first two signals are metadata. The third opens the candidate and checks whether its actual values behave the way a series with that name should behave, which is a check no embedding produces.

Ran’s stated result for adding that reasoning to the search agent is that it “got us up from roughly like 50% accuracy all the way to 90” [1]. The hedges in that sentence are his and they should stay. No evaluation set, no denominator, and no definition of what “accuracy” means for this retrieval task appears anywhere in the source, so this is a practitioner’s account of an internal result rather than a benchmark.

The transferable idea survives the missing denominator. When your corpus is structured data instead of prose, the payload is itself a ranking signal, and a domain expert’s plausibility check on that payload can be encoded as a retrieval step. The precondition is having priors strong enough to check against, which 50 years of codified investment logic supplies and most teams do not get for free.

The split that keeps the whole thing usable#

One more decision holds the architecture together, and it is a product decision rather than a technical one. Weight says the team decided early to keep the chat purely about investment content, with the result that “coding is a pure implementation detail” and, from the chat surface, “you can’t tell that there’s code under the hood” [1].

Figure 10 - Domain on One Side, Implementation on the Other: The chat agent talks about markets and never carries code-generation tokens, tool traces, or execution errors in its context. Everything to the right of the boundary is invisible to the user, which is what lets the plan be the contract between them.

Weight frames two further benefits as happy accidents rather than the original motivation. The chat agent’s context never fills with code-generation tokens and execution errors, so each agent specializes at its own job and naturally improves. Freed of implementation concerns, the team can invest directly in the chat agent’s domain fluency, to the point of teaching it Bridgewater’s own jargon so that user and agent talk to each other like colleagues [1].

Ran also describes a per-investor variant of PAT, since different investors are authorized to see different information, and each person’s instance differs in what context and tools it is given [1]. That is a context-level scoping decision rather than a structural isolation guarantee, and the distinction matters enough that it has its own article. We covered it in Multi-Tenant Agent Security [13], and this piece stays on the compiler architecture.

What is honestly proven here, and what is not#

Every performance figure in this article comes from one conference talk, self-reported, on internal benchmarks, with no published evaluation set. That is worth saying plainly rather than burying, and it is worth saying without dismissing the work, since the two are not the same judgment.

Two pieces of context calibrate it. First, AIA Labs does publish audited work. Its AIA Forecaster technical report matches human superforecaster performance on ForecastBench, a third-party benchmark, and separately reports underperforming market consensus on a harder benchmark the lab introduced itself [14]. A lab that publishes its own losses is calibrating differently than this talk did. The unaudited framing is a property of this particular talk rather than of the lab. Second, an independent engineering analysis of the architecture exists, from Stefan Jansen, which is a useful second read on the design even though it draws on the same talk [15].

Here is the honest summary. The architecture is well described and internally coherent, and its individual moves are independently attested. Parallel dispatch from a typed plan has peer-reviewed prior art [8]. The fuzzy-compiler mental model was reached separately by a different team in a different industry [6]. Deterministic control flow around a probabilistic model is a pattern we have documented repeatedly [10]. The performance numbers attached to Bridgewater’s particular implementation are the part that has to be read as a self-report, and none of the architectural argument collapses if those specific numbers move.

The same discipline, on a text-to-SQL engine#

We have shipped this shape five times, on a different problem. Our txtToSql engine converts a plain-English question into a working analytics product, and the four properties map onto it almost line for line.

The plan is a typed intermediate representation. A question does not compile straight into SQL. It compiles into a specification of what the answer looks like, which cards it contains, and which shapes they are, and that specification is what the rest of the pipeline consumes. Generation then fans out across the cards, which is the second property doing its work: once every card has declared its shape in the spec, no card has to wait on another to find out what it needs. A six-card dashboard lands in under 30 seconds against a 90.5-million-row production database spanning 48 tables and 561 columns [16]. We are not claiming the fan-out is what produces that number, since we have not published a measurement isolating it. The same pipeline drives native React charts with no BI server underneath it at all, which is what happens when the plan is the artifact and the renderer is a target rather than the architecture [17], and it drives printable multi-section PDF reports from that same engine [18]. Execution belongs to the pipeline as well. The model never runs its own SQL, never gets a terminal, and never touches the connection: the pipeline executes the validated query inside a server-side sandbox and hands back rows.

Figure 11 - The Four Properties on a Different Problem: A question compiles into a typed dashboard specification, cards generate in parallel, the SQL is validated by ordinary code rather than by model judgment, and the pipeline rather than the model executes it, inside a server-side sandbox whose tenant boundary the model cannot reach past.

On top of those four, our version adds a fifth constraint the general pattern does not have, since the failure mode is worse. In a multi-tenant deployment, a wrong answer is embarrassing and a cross-tenant row is a breach. Our isolation core puts identity into the system exactly once, from a cryptographically verified JWT claim, and gives the model only a server-side parameterized sandbox scoped to that claim. Our own adversarial harness ran 605 scoped queries across 3 admins with 0 cross-tenant rows returned, and blocked 19 of 19 probes across 6 attack classes, including a jailbroken query that passes the validator and then dies at execution, since the table it targets is structurally absent from the sandbox [19]. A chat front door on top of that core ran 15 chat-driven queries with 0 cross-tenant rows and disjoint tenant sets, with no isolation logic reimplemented on the chat side [20].

Two honest caveats, since this article has spent a lot of words on other people’s fine print. We do not publish a run-to-run determinism percentage, since we measure SQL success rate and isolation rather than code identity, and those are different claims. Our numbers are our own re-runnable harness results on our own data, which puts them in exactly the same category as Bridgewater’s, and we would rather say so than imply otherwise.

KEY INSIGHT: The compiler posture is not a hedge-fund luxury. Any pipeline that turns a request into generated code can adopt it, and the entry cost is writing the plan down as a typed artifact instead of leaving it inside a model’s context.

Four moves you can make on a pipeline you already have#

None of this requires rebuilding from scratch, and the four properties are independently adoptable in roughly increasing order of effort.

Write the plan down and type it. Before any code is generated, emit a structured plan whose tasks each declare a name, what they compute, and the schema of what they produce. This alone is the largest single change, since it turns an invisible runtime negotiation into an artifact you can review, diff, version, and hand to a colleague.

Generate in parallel off that plan. Once every task declares its inputs and outputs, the dependency information needed to fan out already exists. The payoff is not only speed. It removes the incentive to keep plans thin.

Move validation out of the prompt. Take the check that currently lives as an instruction the model may forget, and make it control flow in ordinary code that calls the model. Build the dependency graph, validate in layers, and make the loop repeat until the task matches its spec. An agent that cannot forget is worth more than an agent that usually remembers.

Take execution back from the model. Have the pipeline run the generated code rather than letting the agent shell out, and cache the intermediates. The second run is where the user experience actually lives.

Figure 12 - The Migration, in Four Steps: The left side is where most agent pipelines are today, with the plan trapped inside a model’s context. The right side is the same capability with a typed plan as the contract, parallel generation, validation as control flow, and pipeline-owned execution.

Conclusion#

The interesting thing about Bridgewater’s architecture is not the speed. It is that a firm which cannot tolerate an unreproducible answer looked at coding agents, decided the conversational posture was structurally wrong for their problem, and rebuilt around a compiler instead. The plan became the source, the code became the build output, and correctness became a pass the pipeline runs rather than an instruction the model honors.

The numbers attached to that decision are theirs, self-reported, on their own benchmarks, and we have flagged every one of them as such. The architecture does not depend on them. Parallel dispatch from a typed plan is documented in a peer-reviewed paper. The fuzzy-compiler mental model was reached separately by a different team in a different industry. Deterministic control flow wrapped around a probabilistic model keeps showing up in production systems because it keeps working.

If your agent pipeline currently produces a different program every run, the fix is probably not a better model or a longer prompt. It is an artifact you are not writing down. Start with the plan, give it types, and let the rest follow. The infrastructure that carries a pipeline like this into production is a separate discipline with its own patterns, which we covered in Scaling Agents to Production [21].

If you are running a text-to-SQL or analytics agent and it produces answers you cannot reproduce, or a tenant boundary you cannot prove, that is the engagement we do. Bolt the txtToSql engine onto your data, or bring us the pipeline you already have and we will restructure it around a typed plan and deterministic validation.

References#

[1] LangChain, “How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes,” LangChain, YouTube, July 24, 2026. https://www.youtube.com/watch?v=lXZb21CfeIY

[2] The LangChain Team, “Join us for Interrupt: The Agent Conference,” LangChain Blog, February 12, 2026. https://www.langchain.com/blog/join-us-for-interrupt-the-agent-conference

[3] LangChain, “Interrupt 2026 Recordings,” LangChain, 2026. https://interrupt.langchain.com/recordings

[4] Bridgewater Associates, “AIA Labs: The Future of Investment Intelligence,” Bridgewater Associates, 2026. https://www.bridgewater.com/aia-labs

[5] Bridgewater Associates, “How Bridgewater’s AIA Labs Built PAT: The AI Pocket Analyst Tool,” Bridgewater Associates, 2026. https://www.bridgewater.com/aia-labs/how-bridgewaters-aia-labs-built-pat-the-ai-pocket-analyst-tool

[6] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Code as Disposable Build Artifact: LLMs as Fuzzy Compilers,” Dotzlaw Consulting, July 16, 2026. /insights/ai-07-code-as-disposable-build-artifact/

[7] K. Dotzlaw, R. Dotzlaw, and G. Dotzlaw, “From Agentic RAG to Compiled Knowledge: Why Karpathy’s Wiki Idea Is Spreading,” Dotzlaw Consulting, June 11, 2026. /insights/ai-02-agentic-rag-to-compiled-knowledge/

[8] S. Kim, S. Moon, R. Tabrizi, N. Lee, M. W. Mahoney, K. Keutzer, and A. Gholami, “An LLM Compiler for Parallel Function Calling,” arXiv:2312.04511, December 7, 2023 (rev. June 5, 2024; ICML 2024). https://arxiv.org/abs/2312.04511

[9] SqueezeAILab, “LLMCompiler,” GitHub, 2024. https://github.com/SqueezeAILab/LLMCompiler

[10] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Stripe Minions and the Hybrid Secret: Deterministic Rails Around AI,” Dotzlaw Consulting, June 24, 2026. /insights/ai-04-stripe-minions-deterministic-rails/

[11] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Orchestration Tax: Why Loop Engineering Has a Human Ceiling, Not a Token One,” Dotzlaw Consulting, August 4, 2026. /insights/claude-code-17-orchestration-tax/

[12] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Evals in Practice: The Two Wrong Ways and the Three-Stage Fix,” Dotzlaw Consulting, August 5, 2026. /insights/ai-12-evals-in-practice/

[13] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Multi-Tenant Agent Security: The LLM Is Not Your Security Boundary,” Dotzlaw Consulting, August 25, 2026. /insights/ai-26-multi-tenant-agent-security/

[14] R. Alur, B. C. Stadie, D. Kang, et al., “AIA Forecaster: Technical Report,” arXiv:2511.07678, November 10, 2025. https://arxiv.org/abs/2511.07678

[15] S. Jansen, “How Bridgewater Engineers a Research Agent,” ML for Trading Insights, July 29, 2026. https://insights.ml4trading.io/p/how-bridgewater-engineers-a-research

[16] Dotzlaw Consulting, “Ask Your Database Anything: The Metabase Version,” Dotzlaw Consulting, April 9, 2026. /projects/txttosql-metabase/

[17] Dotzlaw Consulting, “Ask Your Database Anything: Native React Dashboards,” Dotzlaw Consulting, April 13, 2026. /projects/txttosql-native-charts/

[18] Dotzlaw Consulting, “Ask Your Database Anything: Printable PDF Reports,” Dotzlaw Consulting, April 30, 2026. /projects/txttosql-velocity/

[19] Dotzlaw Consulting, “Structural Multi-Tenant Isolation for Text-to-SQL,” Dotzlaw Consulting, July 22, 2026. /projects/txttosql-isolation-core/

[20] Dotzlaw Consulting, “txtToSql-eve: A Chat Front Door With the Tenant Boundary Intact,” Dotzlaw Consulting, July 23, 2026. /projects/txttosql-eve-chat/

[21] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Scaling Agents to Production: Four Infrastructure Patterns, and Why the Second Agent Is the Hard One,” Dotzlaw Consulting, August 19, 2026. /insights/ai-23-scaling-agents-to-production/