The EV+ of GenAI

Want to design an AI routing policy?

I agree to the Privacy Policy Map the Payoff Matrix

Hero image: Photo by Felix Mittermeier on Unsplash: chess pieces on board.

Why AI engineering is also strategy under uncertainty

The first mistake is to treat an AI answer as a sentence.

In production, an AI answer is a move.

It spends tokens. It consumes latency. It selects a model. It may retrieve documents, call tools, ask a human, refuse, summarize, cache, compress, rerank, or stop. It acts under uncertainty, with partial information, in an environment where users, competitors, model providers, and internal cost constraints keep adapting.

That is why the economics of GenAI does not stop at expected value.

Expected value tells us whether a move is profitable in expectation.

Game theory asks a second question:

What happens when the move is repeated, observed, adapted to, and answered by other moves?

This is the layer where AI engineering becomes strategic. Not strategic in the conference-keynote sense. Strategic in the narrower, colder sense: a system must choose among actions, each action has a payoff, and the payoff depends partly on an uncertain world that does not sit still.

The object of engineering is no longer only the model.

The object of engineering is the policy.

Proposition 1: A model call is not an isolated event

A demo invites us to ask:

Can the model do this?

A production system forces a different question:

Should this system spend resources this way, for this request, under these conditions?

Those are not the same question.

A large reasoning model may produce the best answer on a difficult input. It does not follow that every input deserves the large reasoning model. A retrieval step may reduce hallucination risk. It does not follow that every request deserves retrieval. A tool call may resolve uncertainty. It does not follow that the agent should call the tool whenever it can.

The engineering problem is not the existence of capabilities.

The engineering problem is action selection.

That makes the unit of design something like this:

state -> policy -> move -> payoff -> observation -> updated policy

The model is one part of the move. The surrounding policy decides when that move is worth making.

The payoff matrix

Game theory begins to feel useful when we stop speaking about “the AI system” as one thing. A production AI system is a menu of possible moves.

This table is not philosophy for decoration. It is a product architecture table.

Every row is a route. Every route has a payoff. The payoff is not only accuracy. It includes cost, latency, risk, user trust, and long-run operational behavior.

The EV frame still applies:

EV = p(success) x business_value - inference_cost - risk_cost

But game theory changes the way we read the formula. The system is not computing EV once. It is playing a repeated game of cost, uncertainty, and adaptation.

Proposition 2: “Use the best model” is often a dominated strategy

In game theory, a dominated strategy is one that is worse than another strategy no matter what the other player does.¹

In AI engineering, a simple version appears all the time:

Always use the largest model.

This feels safe because capability is visible. Cost is quieter. Latency is quieter. The opportunity cost of wasted inference is quieter still.

But a strategy can be more capable and still be dominated.

Imagine a support assistant that handles three request types.

The large model is not wrong. It wins the third row. It loses the first two.

The small model is not wrong either. It wins the first row and fails the third.

The best system is not the one that worships a single route. The best system notices the request class and changes its move.

This is why the naive question “which model is best?” keeps producing weak architecture.

The better question is:

Best under what information, risk, latency budget, and payoff?

Mixed strategy AI

One of game theory’s useful provocations is that the best strategy is sometimes not one pure action. It is a mixture.²

Production AI systems already behave this way when they are engineered well:

• Some requests go to a small model.
• Some requests retrieve context first.
• Some requests use reranking.
• Some requests get a stronger model.
• Some requests trigger a tool call.
• Some requests escalate.
• Some requests are answered from cache.
• Some requests should not call a model at all.

This is mixed strategy AI.

Not randomness for its own sake. Not cleverness for the sake of cleverness. A routing policy that assigns different moves to different states because the payoff surface is not uniform.

A useful routing policy has at least four signals:

Then the routing rule becomes simple:

choose the cheapest move that preserves enough expected value

That sentence is less dramatic than “autonomous agent.” It is also closer to what production systems need.

Proposition 3: Retrieval is a strategic move, not a feature

Retrieval is often described as if it were a technical accessory:

Add RAG so the model knows your documents.

That framing is too small.

Retrieval is a move that changes the game state.

Before retrieval, the system has a user query and the model’s prior knowledge. After retrieval, the system has evidence. That evidence may increase p(success), lower risk, and reduce the need for a stronger model.

But retrieval can also make the game worse.

Bad retrieval adds irrelevant context. Too much context increases token cost. Poor chunking gives the model half an answer, which can be worse than no answer because it creates false confidence. Stale documents move risk from the model into the data layer.

So the retrieval question is not:

Should we use RAG?

It is:

When does retrieval improve the payoff enough to justify the next tokens?

That question turns chunking, reranking, metadata filters, freshness checks, and citation policy into economic infrastructure.

The retrieval layer is not just memory.

It is position.

The stop move

Many AI systems are bad at stopping.

Agents keep thinking because the trace has not ended. Retrieval keeps expanding because context is available. Tool calls keep firing because the tool is callable. Models keep explaining because verbosity looks like competence.

But in a repeated game, stopping is a move.

Stopping can mean:

• answer now,
• ask one clarifying question,
• refuse,
• route to a human,
• return a cached answer,
• summarize the uncertainty,
• or decline to spend another token.

The stop move matters because marginal value decays.

The first retrieval result may change the answer. The fifth may only decorate it. The first tool call may resolve the missing fact. The third may mostly copy noisy observations into context. The first reasoning step may produce a plan. The seventh may rehearse the same plan in a more expensive voice.

A mature AI system needs stop-loss rules:

max_tool_calls = 2
max_retrieved_chunks = 6
max_observation_tokens = 900
max_latency_ms = 1800
max_cost_per_request = $0.08

These limits are not anti-intelligence.

They are the boundary conditions that make intelligence usable.

Equilibrium in production

The first EV+ article used poker as an analogy because poker teaches a useful discipline: do not judge a decision only by the result of one hand.

Game theory extends the analogy.

In a competitive market, everyone adapts.

Users adapt to the interface. They learn what the assistant is good at. They learn how to phrase questions, when to trust it, and when to bypass it.

Competitors adapt. They copy visible features. They switch providers. They buy the same model access. They ship their own chat interface.

Model providers adapt. Prices move. Context windows grow. Smaller models get stronger. Tool APIs change. Latency profiles change.

Your own system adapts too, if it has telemetry. It learns which routes work, which retrieval documents help, which tool calls waste money, which prompts generate escalations, and which requests should have been stopped earlier.

In that environment, durable advantage rarely comes from “using AI.” Everyone can do that.

Durable advantage comes from the inference policy:

• the eval set,
• the route thresholds,
• the retrieval quality,
• the chunking discipline,
• the cache behavior,
• the refusal policy,
• the escalation design,
• the cost trace,
• the observability layer,
• and the willingness to remove expensive moves that do not earn their keep.

That is the equilibrium layer of AI engineering.

Not one beautiful prompt. Not one heroic model choice. A system of incentives, measurements, and defaults that remains hard to exploit when the environment changes.

A small philosophical detour

There is an old temptation in technical work to search for essence.

What is intelligence?

What is reasoning?

What is understanding?

Those questions matter. But production engineering usually has to answer a more prosaic question first:

What should the system do next?

That question is less metaphysical, but it is not less serious.

It contains a theory of value. It contains a theory of harm. It contains an assumption about the user. It contains a budget. It contains a stopping rule. It contains a definition of success.

In that sense, every production AI system has a philosophy. Most just leave it implicit.

The practical task is to make it explicit enough to engineer.

The engineer as strategist

The modern AI engineer is not only a prompt writer. And not only a model integrator.

The AI engineer is becoming the designer of payoff-sensitive systems.

That means asking questions like:

• What is the cheapest route that is good enough?
• What uncertainty would justify a stronger model?
• What risk would justify a human?
• What evidence would justify retrieval?
• What value would justify a tool call?
• What telemetry would prove this policy is working?
• What should the system stop doing?

These are game-theoretic questions in engineering clothing.

They do not require pretending that every product is a chessboard. They require something more practical: accepting that AI systems act in environments where payoffs vary, information is incomplete, and repeated decisions compound.

The strongest AI product is not the one that makes the strongest possible move every time.

It is the one that knows which move is worth making.

Closing

Expected value gives AI engineering its arithmetic.

Game theory gives it shape.

A production system has choices. The choices have costs. The costs are repeated. The world adapts. The route that looked best in a demo may become wasteful at scale. The cheap route may be brilliant for one class of request and dangerous for another. Retrieval may be grounding or noise. A tool call may be evidence or theater. A refusal may be safety or lost utility.

This is why AI engineering is not only about making models answer.

It is about designing the policy that decides how answering should happen.

And the best policies do not merely maximize intelligence.

They preserve value under uncertainty.

References

1. John von Neumann and Oskar Morgenstern, Theory of Games and Economic Behavior, Princeton University Press, 1944.
2. John Nash, “Equilibrium Points in N-Person Games,” Proceedings of the National Academy of Sciences, 1950.
3. Thomas C. Schelling, The Strategy of Conflict, Harvard University Press, 1960.
4. Richard S. Sutton and Andrew G. Barto, Reinforcement Learning: An Introduction, 2nd edition, MIT Press, 2018.
5. Michael Lewis, The New New Thing, W. W. Norton, 1999. Useful less as AI theory than as a reminder that technical systems become economic behavior once they enter markets.
6. Felix Mittermeier, “Chess,” Unsplash image nAjil1z3eLk: Unsplash photo.

Want to design an AI routing policy?

I agree to the Privacy Policy Map the Payoff Matrix