Market Models: The Missing Foundation for Quantitative Decision Agents / Architecting Quantitative Decision Agents

A paired keynote and workshop: Uri Yerushalmi builds the argument (why LLMs are insufficient for quantitative decisions, and what a market model is), then Hadar Sharvit takes it down to the mathematics, the code, and a head-to-head experiment.

TL;DR

• The core argument is neuroanatomical: the brain evolved specialized regions, and what matters isn't where they sit but the principle — a decision system's architecture must reflect the complexity and structure of the environment it decides in. In the natural world, images, sound, and movement are first-class citizens. In the business world, the first-class concepts are price, supply, and demand — and in a language-centric agentic workflow they are not first-class at all.
• What a market model is: same deep-learning machinery as everything else, different training data. LLMs train on text, vision models on images, large world models on physical-environment data, and market models on market dynamics. Its atom is neither a token nor a pixel but a probabilistic voxel on a high-dimensional grid (transaction time × delivery time × product attributes × customer class × …), giving the probability of an event — a transaction, a cancellation, a competitor repricing.
• Interpretability comes for free: market models have attention layers, so you can peek into the brain. In one case a new competitor entered mid-year and the model redistributed attention across competitors by their attributes.
• The output is a demand landscape: slice it with own price on x and competitor price on y and you can read expected demand, the equilibrium line where buyers are indifferent, and how competitive each market is (in some, competition barely registers; in others "every cent matters").
• Decision-making is hill-climbing on a moving reward landscape: each hill is a decision regime, and when reality shifts the system must know to move from regime A to a higher regime B. A/B tests show a statistically significant revenue uplift averaging around 7%.
• The implementation (Hadar): wrap forecasting and constrained optimization as tools, build a revenue-manager orchestrator over three sub-agents (market dynamics, pricing policy, QA) with the Claude Agent SDK, and use a PostToolUse hook to log grounding — whether the agent actually used the tools.
• The most revealing result isn't accuracy, it's knowing what you don't know: the equipped agent's QA analyst flagged one product's forecast as too uncertain via evaluate_forecast, escalated to the revenue manager, and got the price analyst re-dispatched — shipping five of six prices and leaving the sixth for a human. The vanilla agent shipped all six, because it had no mechanism for evaluating uncertainty at all.

Discussion Threads

Thread 1: Why a language-centric architecture can't carry business decisions (Uri, ~00:54–01:04)

Uri establishes credibility first: three-plus decades building quantitative decision systems, formerly head of the AI division at an algorithmic trading firm, with a PhD in computational neuroscience. A very large share of volume on NASDAQ and other capital markets is now algorithmic, and back then those decisions rested on models predicting future market dynamics. But capital markets drifted into a speed contest, and what he always wanted was to decide well by being smart, not by being fast — which is why he moved to markets that aren't capital markets.

The argument starts in biology. Over hundreds of millions of years the brain evolved regions specialized for different kinds of natural data: visual cortex for vision, prefrontal cortex for planning, others for sound, taste, and touch. "What's important is not the exact location of each of these regions" — what's important is what it demonstrates: the architecture of a decision-making system needs to reflect the complexity and structure of the environment in which decisions are made.

Compare that with agentic workflows making business decisions today. At the center sits a language model, wrapped in harnessing layers and perhaps some visual models. Those language models are extremely powerful — but they are trained primarily to generate and process text. There is a correspondence between the natural world and the structure of the brain that decides in it: images, sound, and movement are first-class citizens of the natural world and are projected into the structure of the decision-maker. In the business world that correspondence is missing. The central concepts are price, supply, and demand, and they are not first-class citizens of a language-centric system.

Hence Fetcherr's position: language models are not enough for quantitative decisions. Such a system needs market sensation, forecasting of future market dynamics, simulation of scenarios, selection and optimization among them, action, and quantitative evaluation of each decision's reward. LLMs and harness layers remain essential — but the optimal decisions depend on tools trained directly on the dynamics of the business environment.

Thread 2: Inside the market model (Uri, ~01:04–01:10)

• Relation to other deep models: same techniques, same kinds of layers — the training data is the tweak. LLMs ← text; vision models ← images and video; large world models ← real or simulated physical-environment data; market models ← market-environment data.
• The atomic unit: an LLM's basic concept is the token going in and out. A vision model's is a 3D tensor — image height × width × color depth — where each cell is a pixel representing light intensity. A market model is far more multi-dimensional: dimensions include transaction time, delivery time, product attributes, customer-class attributes, and more. Each combination holds a voxel that is not visual but probabilistic — the probability of an event occurring: a transaction, a cancellation, a competitor repricing.
• The pipeline: consolidate data from many sources → feed the market model → once trained, predict future market dynamics → use those predictions to simulate future scenarios → pick one → inject the right decision into enterprise systems.
• The data layer: proprietary enterprise data such as historical transactions, enriched from the outside world — events, capital markets data, weather, anything with predictive power.
• Interpretability: because the market model is a deep-learning system with attention layers, you can peek into its brain the same way you would an LLM. In one customer's data they knew a new competitor joined the market mid-year (shown in yellow) and wanted to see how much attention that entrance drew. The model was smart enough to redistribute attention across competitors according to their attributes and importance.

Thread 3: Reading the market model's output (Uri, ~01:10–01:18)

The output is multi-dimensional; humans can hold two, three, maybe four dimensions at once, so you slice the cube — fix a specific product, customer type, transaction time, and delivery time, and vary only a few dimensions.

The canonical slice puts own price on x, competitor price on y, and expected demand as the surface. These plots are generated automatically — the model already knows how to quantify expected demand from historical data. Reading them is intuitive:

• Blue = low expected demand, where our price is higher or significantly higher than the competitor's.
• Red = high demand, the opposite case.
• Between them the model finds an equilibrium line — where buyers don't really care about the difference.

Slicing elsewhere reveals what the model thinks of different markets: one where competition has very low impact; one where the equilibrium line shifts right by 50 price units, meaning our product's perceived value there is higher; and one that's far more competitive, with higher contrast, "where every cent matters when making the pricing actions."

The demand surface also moves over time. In an airline pricing case they tracked it against fuel prices — when fuel prices rose around April this year, predicted demand shifted accordingly.

From prediction to decision: with predictions in hand, a digital twin of the business arena simulates the expected reward of each pricing policy. In a simplified case the policy is two parameters, and every combination has an expected reward such as revenue. Crucially these predictions run continuously and reflect data flowing into the market model — and that inflow reshapes the reward landscape, because reality changes all the time. The business wants to sit on the peak of the hill. Several hidden hills lie under that surface, and each hill is a decision regime; when reality changes such that regime B's hill is higher than regime A's, the system needs to know to move.

Validation: each deployment goes out on a subset of markets as the target group, compared against a correlated control group. Repeatedly, these systems show statistically significant revenue uplift — the revenue distribution shifted right by roughly 7% on average.

He frames the whole toolset as what bridges the decision-making industry's transition from practices based on general harness engineering to genuinely enterprise-grade, reliable agent operations.

Thread 4: The mathematics — forecaster plus optimizer (Hadar, ~01:19–01:27)

Hadar picks up by taking "why LLMs struggle with high-stakes quantitative decisions" down to the math.

Any meaningful business answer pairs two capabilities:

1. A forecaster telling you how the market or business objective will move. Formally a point forecast: from time t, predict the signal you care about (here, demand) out to a horizon. Inputs include the known past (past demand and its distribution), covariates / exogenous variables (a product's representation and associated price), static features invariant in time (product IDs and properties), and information known into the future (expected holidays, near-term weather at high confidence, calendar features like day of week). - Swap the network's output head and the point forecast becomes a distribution, because businesses want to reason about uncertainty and confidence — either a parameterized neural distribution or uncertainty expressed via quantiles.
2. An optimization process that takes the pre-trained probabilistic forecaster and, given a reward u to maximize or minimize, a context s (past information, price signals, static features), and a feasible action set (how to price, how much inventory to allocate), finds the action maximizing the objective over the horizon. With price as the action and revenue as the objective (demand × price), you feed a counterfactual price plus the full context into the horizon and see the associated demand. - There are always hard and soft constraints: prices must stay within bounds; consecutive pricing decisions must not swing wildly; ordering must hold — an economy ticket must never be priced above business class.

Why naive agents fail is the same reason these tools exist: they may lack a forecaster that generalizes out of distribution, or lack any usable forecaster at all ("if I were to give Claude Code a query, predict how the price is going to look, I would argue it's going to find it a bit difficult"), and they certainly lack an optimization process that consistently applies constraints while maximizing a business objective.

Thread 5: Plugging the capabilities into a harness (Hadar, ~01:30–01:42)

He walks through runnable code:

• Market model pre-training config: Ray hyperparameter tuning, input size, internal hidden sizes, learning rate, plus feature sets (known past, known future, static). In an airline client's case the static features are cabin, flight direction, and so on. A distribution-based loss serves as criterion for a custom deep network consuming a look-back window and predicting a distribution into the horizon. He notes this is fully compatible with Andrej Karpathy's auto research — but they deliberately don't let it run loose, because for a pre-trained model they want consistency and guarantees. Terminology follows the open-source time-series framework from Nixtla, which he recommends (no commercial relationship — he just thinks they do best practices).
• Inference output: load a pre-trained checkpoint plus feature selection and encoding of numerical and categorical features, run a forward pass, and get a quantile forecast (10th, 50th/median, 90th). The key conceptual point: with demand you don't care about a demand value but about how demand differentiates across price points — the demand curve from econometrics 101. From there come aggregations: mean over the horizon, revenue (price × demand), uncertainty measures — and higher-order derivatives of demand give elasticity and locate the revenue maximum.
• Constrained optimization: a data class for price constraints (lower/upper demand bounds, a max step so consecutive price policy values don't exceed a threshold), and a private function applying constraints during optimization. The market model's forward pass supplies the demand distribution across the horizon; scipy.optimize.minimize_scalar does the work; a helper simulates revenue into the horizon. His illustration: a revenue landscape with a hard constraint floor, where the global maximum at A becomes unreachable and the constrained optimum settles at local maximum B — with the caveat that real revenue landscapes are "rarely this nice" and rarely differentiable.
• Wrapping capabilities as tools: built on the Claude Agent SDK (he's explicit that they aren't working with Claude — it's just the most legible framing for a Claude Code-familiar audience). The predict_market_dynamics tool takes a Pydantic-style config so inputs get validated before invoking the real prediction (abstracted in a capabilities.py), returning structured output exposing quantiles, elasticity, and more. Every capability gets its own designated tool.
• MCP and tool clustering: the SDK abstracts MCP servers. One is data capabilities — GCP buckets, so the agent can fetch real historical market data. The other is a fetcherr capabilities MCP, a thin server wrapping the tools. They cluster into data tools, large market model tools (market-dynamics prediction and optimization), and evaluation tools.
• Sub-agent structure: an analyst factory plus an analyst initializer define three sub-agents and one orchestrator. The orchestrator is a revenue manager with its own system prompt; the analysts cover market dynamics, pricing policy, and QA — the last making sure predictions and policies are sensible. All of it is fully runnable code.
• Hooks and grounding: a PostToolUse hook matcher catches the moment after a tool fires, enabling custom behavior that logs what they call grounding — whether, during its reasoning, the agent actually used the tools they defined. Everything assembles into ClaudeAgentOptions: the revenue manager's system prompt, allowed tools, MCP server, sub-agents, and hooks, plus a simple query loop for logging results.

Thread 6: The head-to-head, "Is the price right?" (Hadar, ~01:43–01:52)

Setup: two agents, same question.

• A: a plain Claude Code harness — reasoning, web access, able to write and run its own code, "it could do whatever the hell it wants."
• B: Fetcherr's market-model agent — the same, plus the capabilities that let it understand the market.

The question (real, anonymized client data): year over year, demand for a specific product in a specific market fell 22% while prices for that product rose more than 60%. Is that sensible? The answer is not trivial — you might say demand fell because price rose, but demand could have fallen for some other reason entirely.

What they did: both produced markdown rationales and a recommendation CSV — raise or lower the price, and by how much.

• The vanilla Claude agent bashed away: wrote Python scripts, ran statistics, used pandas ("his favorite tool"), and produced CSVs covering historical data, patterns, and correlations for that product and market. It did quite a lot.
• The market-model agent used its capabilities extensively and then aggregated the results — parsing outputs, building product lists, aggregating optimization results. Taken at face value, it made far more tool calls.

The most interesting finding came from clustering tool calls per analyst: while predicting demand, the equipped agent identified high uncertainty in one product's forecast, possibly because the historical data wasn't substantial enough. This was the QA analyst's doing — it flagged the issue using the evaluate_forecast tool and escalated to its boss, the revenue manager, who re-dispatched the price analyst on that subset of the market. That's the spike visible in the tool-call chart.

The outcome: in a market with six products, the Fetcherr analysts recommended shipping five prices and flagged the sixth — the uncertain one — for the revenue manager, writing it into the rationale and the recommendations. The unaided agent shipped everything; it had no mechanism to evaluate uncertainty.

Zooming into one product priced at $1,100 at that moment:

• Vanilla agent: recommend a price increase of $200.
• Fetcherr agent: recommend a price decrease of about $250.

Same data, different reasoning, and conclusions that differ in both magnitude and direction.

The Fetcherr agent's chain: it invoked the market model and found that at this price the absolute elasticity exceeds 1, so it recommended a decrease; in an unconstrained setup the optimum fell at $828, where elasticity is maximal. (Elasticity being how much a percentage price change moves demand.) Quoting its own rationale: "Demand on the route is elastic — every 1% price reduction yields about 1.4% more bookings, more than offsetting the fare reduction in revenue terms." The revenue manager then invoked the price optimization tool; because it was constrained and had to look across the entire set of departure dates, it couldn't sit where the maximum truly lies and settled at $863, noting in its rationale that a holiday falls on that departure date — so averaging demand across price in that market could understate what should be charged. It reconciled $828 and $863, rounded for simplicity, and shipped $850 — an estimated 6%-plus revenue uplift on that product.

How the vanilla agent failed: it was trying its best, but it confused correlation for causation. It ran correlation analysis across markets that don't necessarily correlate with each other, and never fixed a specific product to vary the price counterfactually. In its own words: "demand elasticity is negligible … correlation of nearly zero. So raising the floor carries near-zero demand destruction risk." Elasticity, unfortunately for it, is a real thing — and in an unbiased revenue estimation the decision came out at roughly −8% revenue.

Thread 7: The architecture, summarized (Hadar, ~01:52–01:54)

The end-to-end shape, distilled:

• One manager runs the loop, reviews, and aggregates.
• Specialized sub-agents split the work, each with its own tools, not sharing context so they don't get confused by similar tools.
• An unbiased QA mechanism able to check its counterparts' assets.
• Crucially, all of them use quantitative capabilities — that's where the mathematics lives and where the formulas are implemented. The revenue manager knows it isn't the expert here and delegates in order to give a meaningful, reliable answer.
• Grounding makes the whole process visible after the fact.

The closing position: there is great power in combining LLM orchestration and agentic harness development with knowing when and how to delegate to capabilities you can trust. The LLM orchestrates; the capabilities carry the guarantees.