Why do AI agents give different answers on the same data?

Why do AI agents give different answers to the same question?

Because the agent is not reading a shared definition of the data, it is inventing one each time. Point the same model straight at raw sources and it answers correctly about 38% of the time, burning 234,000 tokens across 234 tool calls and roughly 15 minutes per question. Put a governed data layer underneath the same model and the same question comes back in 19 seconds, in a single SQL query, at 91% accuracy and about 18,000 tokens (Nekt benchmark). 10x fewer tokens, 45x faster, and more than double the accuracy, from one change: what sits beneath the model.

38% and 91% are the same model. What changes is the layer underneath it. A protocol connects an agent to data; a semantic layer is what tells the agent what the data means.

This is not one benchmark's opinion. Gartner projects that 'by 2028, 60% of agentic analytics projects relying solely on the Model Context Protocol will fail for lack of a consistent semantic layer' (Gartner, Gartner Says Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending, May 11, 2026). The same research points the other way too: 'by 2027, organizations that prioritize semantics in AI-ready data will increase agentic AI accuracy by up to 80% and reduce costs by up to 60%.' The common thread is semantics, the meaning of the data, not the protocol that reaches it.

Isn't MCP enough?

No. MCP is a socket, not a brain. The Model Context Protocol solves connection: it standardizes how an agent discovers and calls tools, so every integration stops being a snowflake. That is a real advance, and it earned its attention. But connection is not the same as meaning. MCP tells an agent how to reach a system; it does not tell the agent what an active customer is in your business, whether revenue is counted on the creation date or the close date, that a field with an odd name holds the lead source, or that two records with different names are the same company. All of that is context, and context does not travel in the protocol. Someone has to model it. Without that layer, the agent receives a pile of raw data with an empty instruction manual, and it does the only thing a model can do when context is missing: it fills the gap with a plausible guess. Well written, well formatted, and wrong. The error looks good, and that is the problem.

What does '234 tool calls' actually look like?

It looks like an agent rebuilding a database by hand, in text. Take a real question from a production operation: how much did each new customer cost last quarter, by channel. With no layer underneath, the agent has to do it the hard way.

1. Pull deals from the CRM. Paginated, so dozens of calls just to read.
2. Pull contacts, because the channel lives on the contact, not the deal.
3. Pull cost from each ad platform, paginated again, each with its own format.
4. Pull billing to see who actually paid.
5. Join all of it inside the context window.

Step five is where it collapses. The agent becomes an improvised database made of text, matching records by reading instead of computing. It gets time zones wrong, counts duplicates, blows the context window halfway through and loses what it already read, hits a tool-call limit and starts over. When it finishes, it hands back a number no one can trust without redoing it by hand. Run the same question tomorrow and a different number comes back, because an improvised path is not reproducible. The model is not the problem. The work pushed onto it is not a model's work.

What are the four ways this fails?

There are four failure modes, and the worst detail is that none of them show up on day one. All of them show up in month three.

• The agent invents the definition. Asked how many active customers, with no rule it makes one up. Monday it counts live subscriptions; Wednesday it counts won deals. Two numbers, both defensible, both different. The reader loses trust and goes back to a spreadsheet, and now there is no agent, there is a doubt generator.
• The join happens in the wrong place. Combining tables is database work: keys, indexes, computation. Doing it by reading inside the context window is expensive, slow and fragile. It is the main source of those 234,000 tokens.
• Scope leaks without permission per agent. The agent that analyzes ads has no reason to see a table of people. An agent serving one client must never touch another client's data. Without permission at the layer, scope is a sentence in a prompt, and a sentence in a prompt is a polite request, not access control.
• Cost and latency grow with volume, not with the question. The base doubles, the token bill doubles, and the answer is no better. This is where a project dies in finance, not in engineering.

None of these four is fixed with a better prompt. Every one of them is a data-layer problem.

What is a semantic layer?

A semantic layer is data modeled into business meaning before any agent touches it, and the cleanest way to build one is in three layers, each with a single job.

• Raw: what the source sent, exactly as it sent it. No cleaning, no opinion. It exists so results can be audited and reprocessed. When someone questions a number, Raw proves where it came from.
• Trusted: data cleaned, deduplicated, correctly typed and time-zoned. This is where the invisible cleanup lives. A concrete example: when two records are merged in a CRM, the absorbed record often stays in the source, because the connector never captures the deletion. Count straight from Raw and the same customer is counted twice. The rule that filters on the merged-record field lives in Trusted, written once and applied forever, for every agent and every report.
• Service: data modeled in the language of the business. Not the deals table but revenue_by_channel, active_customers, one table per question the company actually asks. This is where the agent connects.

The point is that the intelligence leaves the prompt and moves into the data model. The agent stops being the place where the business rule lives and goes back to what it is good at: understanding a question in plain language and picking the right table. One query. 19 seconds.

What is context engineering?

Context engineering is attaching the meaning of each column to the data itself, so an agent reads the rule instead of guessing it. A person opens a table, sees an odd column, and asks in chat. An agent does not ask; it deduces, and it deduces with confidence. So every column that matters carries a written annotation, served with the data, that says what it is and how to use it. Real cases that catch data teams out:

• Ad cost stored in micros. One currency unit is 1,000,000. Without the annotation, the agent reports a cost per acquisition a million times too high, and writes a very convincing paragraph about how serious the situation is.
• Email type. Corporate email converts around 15% to 20%; personal email near 1%. An agent that does not know this mixes the two and concludes the whole channel is broken.
• Historical wins in the funnel. A customer who was won, then left, still has a win recorded in that month. Come back a year later and that is two wins. Without the rule written down, the agent tells someone who is paying right now that they were never a customer.
• Which date is the date. Creation, close, first charge: three dates, three different answers to how much did we sell in June, and one of them becomes a salesperson's commission.

None of that is data. All of it is context about the data, and it is exactly what a protocol alone does not carry, because carrying it is not the protocol's job. The idea became popular in 2026 for good reason, but at its core it is the oldest job in data: giving data meaning. What changed is the consumer. It used to be an analyst who asked when unsure; now it is an agent that answers even when it is not. That is why the context has to be written, versioned and served alongside the data. On platforms built for this, such as Nekt, an agent querying over MCP receives more than the table: it receives the definition next to it, so the business rule arrives inside the answer instead of being re-explained in a prompt.

Why permission per agent, not per person?

Because an agent is not a person. Permission models were designed for people: a person logs in, looks at what they need, and leaves. An agent runs on a schedule, unattended, dozens of times a day, and does exactly what its permission allows, no more and no less. So permission drops to the level of table and layer, per agent. A paid-media agent reads the channels Service and nothing else. A customer-success agent reads subscription, product usage and conversations, not ad cost. An agent in a multi-client operation gets an isolated workspace, where client A's data never touches client B's, which is a contract, not a preference. There is a useful side effect: tight scope is the best cost optimizer there is. An agent that sees fewer tables makes fewer mistakes, spends fewer tokens and answers faster. Narrow permission is not only security, it is performance.

Live data or the modeled layer: when to read which?

Read live for the state of right now; read the layer for anything aggregated, historical or cross-source. Live data answers point-in-time questions about a single record: is this deal still open this second, is this subscription active. The modeled layer answers trends, cost by channel, cohorts, quarter over quarter, none of which can depend on thirty live calls, because that is exactly where 234 tool calls are born. A pocket rule: if the question contains how many, how much, or since when, it is the layer; if it contains now, it is live.

Live data is not read-only, either. A modern live-data layer both reads from and writes back to the source, so the same agent that analyzes campaigns can also publish one through the layer, without building write credentials into each platform by hand. And there is a split in how the agent connects: MCP is for an AI talking to the data, such as Claude or another model; a Data API is for code running on its own, the scheduled job, the website, the service in the cloud with no AI in the loop. Forcing MCP to be both is why the cron job gets expensive.

How do you build one?

Start from the questions, not the tools. The sequence that works:

1. Write the ten questions the company actually asks every week, not the ones that would be nice to have. That is the scope of the Service layer, and nothing beyond it for now.
2. For each question, list the sources and the key that joins them. If no single key appears in all of them, that is the first problem, and it comes before any AI.
3. Land everything raw in Raw. No cleaning. The goal is to be able to audit and reprocess later.
4. Write the boring rules in Trusted: deduplication, time zone, type, merged records, currency unit. Once, in code, versioned. Not in a prompt.
5. Model the Service in business language, one table per question from step one, named the way the company speaks.
6. Annotate context on every column a person would have to ask about. If a human would have a doubt, the agent will have a confident wrong answer.
7. Only then turn on MCP, with permission per agent and minimum scope. MCP is the last step, not the first. Starting there is why Gartner projects 60% will fail.

Steps one, two and six take an afternoon. Steps three, four and five are the real work, and they are not an afternoon. You can build each piece yourself, warehouse, connectors, orchestration and catalog, and it works, or use a platform that already joins them and turns months of setup into days. What is not an alternative is skipping the layer and hoping the model compensates. It does not. It only gets more convincing while it is wrong.

The takeaway

MCP was the best thing to happen to agent integration in years, and it deserves the attention. But it is not a choice of one. It is three things together: structured data underneath, MCP to connect, and context engineering to give meaning. Remove any one and the agent goes back to guessing. The protocol connects the agent to the data; it does not tell the agent what the data means, who can see what, or which of three dates becomes commission. That part is still necessary. What changed is that the consumer is no longer an analyst who asks when unsure, but an agent that answers even when it does not know. 38% and 91% are the same model. What changes is what exists beneath it.