The Correctness Layer

Scroll through the data and AI corners of X for ten minutes this month and the same question keeps coming back, in slightly different clothes. Where do agents belong in a modern data stack? On top of the warehouse? Inside the BI tool? Between the app and the API? A parallel universe that talks to none of the above?

The takes are loud and mostly wrong for the same reason. They all argue about which layer the agent sits on. Almost none of them argue about which layer sits between the agent and the truth.

That in-between layer is where the real work is. It is not a model. It is not a tool. It is not a dashboard. It is a deterministic harness that turns a probabilistic system into a system a business can trust — and it is quietly becoming the most valuable piece of enterprise AI architecture in 2026.

The reference picture most teams carry in their head has two layers. On top, an agent. Underneath, the data. An arrow between them, labeled "queries" or "tools" or "MCP," and a shrug.

The picture that survives contact with production has three. On top, the probabilistic layer — the model, its reasoning, its planner. On the bottom, the deterministic core — your warehouse, your source systems, the numbers that already have a legal and financial owner. And between them, a new layer whose whole job is to make the top and the bottom safe to connect. Call it the correctness layer.

The correctness layer is deterministic on purpose. Given the same inputs, it produces the same outputs. It caches. It validates. It resolves ambiguous questions into concrete queries. It refuses the ones it cannot resolve. And it hands the model a small, typed, reproducible answer instead of a firehose of rows and a prayer.

The hero image at the top of this essay is the whole architecture in one glance. Loose, probabilistic strokes at the top. A rigid geometric grid in the middle. A structured foundation at the bottom. The middle band is where trust lives.

There is a natural instinct to spend attention on the model. The model is the exciting part. It is the part that ships new capabilities every quarter, the part that gets the keynote slot, the part your CEO read about on the plane.

But the model is also the part you have the least leverage over. You did not train it. You cannot fully explain it. It will be replaced by a better one in six months, and you should design your stack assuming that.

The correctness layer is the opposite. You own every line of it. It is boring in the best sense — the same inputs produce the same outputs, and when a number is wrong you can point at exactly where it went wrong. It survives every model swap. It compounds. It is the piece a competitor cannot copy by writing a check to a foundation lab.

This is the same shift analytics engineering made a decade ago, when the industry realised that the durable moat was not the BI tool but the transformation layer underneath it. Agents are now forcing the same realisation one level up.

It is easier to describe by what it does than by what it is. Five jobs, in rough order of how quickly a team feels their absence.

One: resolution. The agent asks a fuzzy question — "how did enterprise revenue trend last quarter?" — and the correctness layer decides which metric, which grain, which filters, which time zone. It picks from a small set of pre-approved answers, not from the whole surface area of your warehouse. If no approved answer fits, it says so.

Two: validation. Before an answer leaves, the layer runs cheap deterministic checks. Does the sum reconcile with the parent aggregate? Is the row count in the expected range? Does the entity actually exist in the system of record? These are the checks a senior analyst runs in their head in three seconds, encoded once so they run every time.

Three: caching. Because the layer is deterministic, its outputs are reusable. The same question, the same day, the same customer — the same answer, served from a small keyed store, not from a fresh model call. This is where the unit economics of agentic AI stop being terrifying.

Four: policy. Access control, redaction, and consent all live here, not in the prompt. The agent does not decide what it is allowed to see; the layer does. If a user cannot see a table, the layer never returns a row from it, no matter how creatively the model asks.

Five: audit. Every request in and every answer out is written to a log with the exact query, the exact filters, and the exact source rows. When someone asks in six months how a number was produced, you have a real answer, not a shrug and a screenshot.

Most of the horror stories about agentic AI costs are stories about a missing correctness layer. A retry loop that costs eleven cents instead of two because the model kept re-fetching a table that could have been cached. A prompt that ballooned to four thousand tokens because six teams pasted their business rules in, one by one, instead of encoding them once in a resolver. An evaluation that runs the full model on the golden set every night because there is no deterministic path to short-circuit the easy cases.

With a correctness layer in place, the model runs less often, on smaller inputs, with tighter budgets. The cheap deterministic checks catch the majority of the traffic. The expensive probabilistic reasoning is reserved for the cases that actually need it. Unit cost per resolved interaction drops by an order of magnitude, and — this is the part nobody expects — quality goes up at the same time, because the model is no longer being asked to do things a SQL query can do better.

This is not a theoretical claim. It is roughly the same shape as the caching-and-materialization revolution that made cloud data warehouses affordable in the first place. The pattern generalises.

The Context Advantage is, in many ways, a long argument for exactly this middle band. It is not framed as "the correctness layer" — the book calls the pieces by their functional names — but the ideas map cleanly.

The resolution job lives in Chapter 6, The Semantic Layer Becomes the Foundation: bricksnotes.com/context-advantage/book/chapter-6, and Chapter 7, From Data Models to Business Meaning: bricksnotes.com/context-advantage/book/chapter-7. This is where a fuzzy business question is turned into a concrete, typed query — the first thing the correctness layer has to do well.

The validation and policy jobs are Chapter 12, Guardrails, Approvals, and Audit Trails: bricksnotes.com/context-advantage/book/chapter-12, and Chapter 13, Trust Is Designed, Not Assumed: bricksnotes.com/context-advantage/book/chapter-13. The book's argument, put simply, is that trust is a property of the layer between the model and the data, not of the model itself.

The caching and cost jobs are Chapter 15, The Hidden Cost of Agentic AI: bricksnotes.com/context-advantage/book/chapter-15, and Chapter 18, Quality, Speed, and Cost Tradeoffs: bricksnotes.com/context-advantage/book/chapter-18. Both chapters argue for treating cost as a design constraint, not an invoice you read at the end of the month.

The audit and observation job is Chapter 14, Human in the Loop Still Matters: bricksnotes.com/context-advantage/book/chapter-14. And when you are ready to see all five jobs assembled into one reference design, Chapter 27, The Trusted Agent Architecture, is the nine-step blueprint we keep coming back to: bricksnotes.com/context-advantage/book/chapter-27.

The mistake most teams make when they hear about a new architectural layer is to try to build all of it at once, on a Wednesday, for every use case in the company. This never works, and it is not what any of the teams doing this well actually did.

The pattern that works is boring. Pick one agent feature already in production, or about to ship. Identify the three or four questions it gets asked most often. Encode those questions as named resolvers in a tiny deterministic service — a repository of intents, each with a typed input, a typed output, and a single tested SQL query behind it. Route the agent to those resolvers first. Fall back to open-ended reasoning only when no resolver matches.

That is the correctness layer, version one. It is fifty lines of code and one afternoon of arguing about naming. It will handle sixty to eighty percent of your traffic on day one. The remaining traffic is where you learn what the next resolvers should be.

Six months later, that tiny service has thirty resolvers, a validation harness, a cache, a policy check, and an audit log — and you did not spend a quarter in a design doc. You spent a quarter shipping features that happened to leave a correctness layer behind them.

There are four numbers to watch, and they move together when this is going well.

First, the share of agent requests resolved without a model call at all. This starts near zero and, in a healthy stack, grows past fifty percent within a couple of quarters. The cheap deterministic layer is doing more of the work.

Second, cost per resolved interaction, not cost per model call. This is the number your CFO cares about, and it drops as caching and resolvers absorb the easy traffic.

Third, factuality on a rolling shadow set of real traffic — not the golden set that shipped with the demo. This is the number the business cares about, and it climbs as the layer refuses to answer questions it cannot ground.

Fourth, the rate of "unknown" responses. Counterintuitively, this is a health metric, not a failure metric. A system that never says "I do not know" is a system that is guessing all the time. A correctness layer that has learned when to decline is a correctness layer you can trust with the questions it does answer.

The threads on X are not really about architecture. They are about a growing suspicion, in a lot of technical teams at the same time, that the raw-model era of enterprise AI is ending. The next two years will not be won by whoever has the biggest model or the fastest agent. They will be won by whoever has the most trustworthy layer between the model and the business.

That layer is not glamorous. It will not be on a conference stage. It will not be in a keynote. But it is the reason some agents will still be in production in 2028, and most of the ones being demoed this quarter will not.

The teams that see this early get a rare kind of head start — one that compounds every time a better model ships, because a better model on top of a real correctness layer is a step-change; a better model on top of nothing is just a faster shrug.