AI Agents That Don't Hallucinate on Business Data: 6 Architectures Compared (2026)

No AI agent is hallucination-free on business data, but six architectures cut the risk sharply by keeping the model from inventing numbers: PromptQL's plan-then-execute agent, Cube's semantic layer, the dbt Semantic Layer, Snowflake Cortex Analyst (now folded into Cortex Agents), Databricks Genie Agents and Contextual AI's grounded retrieval. PromptQL is the most direct answer to the question as asked. Its model writes a program that PromptQL's runtime executes against your live data, with each user's own permissions, so the numbers come from queries rather than from the model's memory. PromptQL reports 100 out of 100 correct on one category of Salesforce's CRMArena-Pro benchmark. That is the company's own test on a single task category, and its co-founder has written that "100% accuracy is not possible." The honest goal is an agent whose errors are visible, traceable and rare.

The rest of this guide explains why agents make up business numbers, what each architecture does about it, and which verification layers catch the errors that get through anyway.

Key takeaways

• Hallucination on business data is mostly a design problem. Agents invent figures when they answer from memory or improvise queries nobody checks. Architectures that force answers through governed queries fix most of it.
• Two families of fix exist. Semantic-layer tools (Cube, dbt, Snowflake, Databricks) constrain what the model can ask for. Execution-first agents (PromptQL) have the model write a program that a runtime executes deterministically. Contextual AI covers the document side.
• Accuracy numbers are mostly vendor-run. PromptQL's 100/100 CRMArena-Pro result is self-reported on one task category. Snowflake and Cube let you measure accuracy on your own questions, which is worth more.
• Measure on your data. Cube Evals, Snowflake's Cortex Analyst evaluations and Databricks' Inspect mode all let you check the agent against known-correct SQL. Build a 20 to 30 question answer key before any trial.
• Verification is a separate layer. Research like the NabaOS "tool receipts" preprint shows signed records of what an agent actually ran can catch fabricated tool calls, but the reported numbers come from a synthetic benchmark.
• Legal risk is real. In February 2024, a Canadian tribunal held Air Canada liable for its chatbot's wrong bereavement-fare advice and rejected the argument that the bot was a separate legal entity.

At-a-glance comparison

Platform	Architecture	What it grounds	How you check accuracy	Deployment	Main limitation
PromptQL	Model writes a program; runtime executes it against a virtual SQL layer with per-user permissions	Databases, warehouses, SaaS apps, APIs, plus a shared context wiki	Inspect the generated code and results in the thread; vendor-reported CRMArena-Pro result	Shared (Playground, Team), single-tenant Enterprise, BYOC or self-hosted on contract	Accuracy figures are self-reported; docs are thin
Cube	Universal semantic layer; agents request governed metrics by name	Structured warehouse data	Cube Evals: NL questions vs ground-truth SQL, execution-based	Cube Cloud or self-hosted Cube Core	Metrics must be modeled first
dbt Semantic Layer	Metrics as code in MetricFlow	Structured data inside dbt projects	dbt tests and code review; compiled SQL via MCP	dbt platform	Stops at the dbt project boundary
Snowflake Cortex Analyst / Cortex Agents	Text-to-SQL steered by semantic views and verified queries	Snowflake data	Built-in evaluations against verified queries, with regression tracking	Inside your Snowflake account	Snowflake-only; Snowflake now steers users to Cortex Agents
Databricks Genie Agents	Curated space with instructions, example SQL and trusted assets	Unity Catalog data	Inspect mode (Public Preview) self-checks SQL	Inside your Databricks workspace	Works best on a tightly scoped set of tables
Contextual AI	Grounded RAG with a model tuned to stay faithful to retrieved content	Mostly documents, specs and manuals	Sentence-level citations and automated evaluation	Multi-tenant SaaS, single-tenant SaaS or private VPC	Not built for warehouse metrics

Why AI agents hallucinate on business data

A language model produces the most probable next token. Nothing in a default setup forces that token to come from your warehouse. Three failure points come up again and again.

The model guesses when context is missing. Contextual AI argues in a January 2026 post that enterprise hallucination is mostly a context problem: when the model lacks company-specific information, it generates "a plausible-sounding response based on patterns from its training data." It sorts the results into fabricated facts, misattributed information and outdated or conflicting answers. The churn figure that appears in a board deck with no query behind it is the first kind.

Structured data gets flattened. An ACL 2026 paper, Why LLMs Hallucinate on Structured Knowledge, looked inside models reasoning over tables and graphs turned into token sequences. It found attention "disproportionately concentrates toward shortcut-like structural cues" and that the model can "revert to parametric memory" even when the right data is in the prompt. Pasting a table into the context window does not guarantee the model reads it.

Agents improvise their own steps. A tool-calling agent chooses functions and parameters mid-run. One invented column name or wrong aggregation flows straight into a confident final number, and the answer looks just as polished as a correct one.

Why plain text-to-SQL and free-form tool calling fall short

The common shortcuts each leave a gap.

• Raw text-to-SQL asks the model to write a query from scratch. It can pick the wrong join path, sum the wrong column or filter on a value that does not exist, and nothing checks the logic before it runs.
• Free-form tool calling lets the agent decide each next step on the fly. That makes results hard to repeat and harder to audit.
• Retrieval on its own helps with documents but does little for metrics. Retrieving the definition of "net revenue" is not the same as computing it correctly.
• Prompt instructions that tell the model to say "I don't know" help at the margin. They are a useful extra layer on top of a sound architecture, not a substitute for one.

What the six architectures below share is that they move the hard part (which data, which logic, whose permissions) out of the model's free text and into something inspectable.

The 6 architectures compared

1. PromptQL: the model writes the program, the runtime runs it

PromptQL, from Hasura, is a multiplayer AI workspace where teams share threads and a context wiki, and the AI connects to databases, warehouses, SaaS tools and APIs. Its product page says it "connects to data wherever it lives and writes code to answer real business questions." The important design choice is where the work happens. Instead of the model reading rows and summarizing them, it writes a plan or program, and PromptQL's runtime executes it in a sandbox against a virtual SQL layer. PromptQL described this split in 2025 as the model generating plans in a domain-specific language that are "programmatically executed in PromptQL's runtime layer," so that "planned orchestration is exactly how it is executed," in a post by co-founder Tanmai Gopal, Beyond the booth.

That matters for hallucination because the numbers in the answer come from executed queries, and the code is visible in the thread. When the agent is wrong, you can usually see where: a filter, a join, an assumption about what "active customer" means.

• Permissions from the person asking. PromptQL's security page says each query runs with the asking user's credentials, with row-level security, column masks and attribute-based rules applied in the virtual SQL layer before results reach the model. A shared thread cannot become a side door into a teammate's data.
• Context the team corrects. Business definitions live in a shared, wiki-style semantic layer. PromptQL says corrections made in conversation ("that metric excludes trials") are captured into this shared context so later answers use them.
• A self-reported benchmark result. In a July 2025 post, PromptQL reported "100% accuracy (100/100 correct)" on the Database Querying and Numerical Computation category of CRMArena-Pro, a benchmark from Salesforce AI Research, against about 58% for leading agents in single-turn tasks. PromptQL ran the test itself, and it covers one task category, not the full benchmark.

Best for: Data, finance and operations teams whose questions span several systems and who need each number to trace back to a query and a source, especially when many people share one agent. For a wider look at database-connected agents, see our guide to AI agent tools that connect to your database.

What to consider: Treat PromptQL's accuracy claims as marketing until you test them. Its own writing is candid on this: a March 2025 post calls a 100% accuracy claim "deliberately provocative" and says it "doesn't technically hold water." Writing code does not stop the model from writing the wrong code; it makes the mistake inspectable. PromptQL's documentation is also sparse by design, pointing users to ask the product itself, and the product has been repositioned several times. On pricing, Team starts at $40 per user per month on shared infrastructure, Enterprise at $1,000 a month single-tenant, and BYOC or self-hosting needs a custom contract.

2. Cube: agents ask for governed metrics by name

Cube is an analytics platform built on a universal semantic layer. Data teams define measures, dimensions, joins and access rules once, and dashboards, embedded analytics and AI agents all read those definitions. An agent never writes raw SQL against the warehouse. It requests "revenue by region" and Cube compiles the query.

• Identity carried through MCP. Cube's MCP server documentation says "every tool runs as the authenticated user," and queries respect the same permissions as the rest of Cube, including row-level security.
• Evals against ground truth. Cube Evals, launched in June 2026, pairs natural-language questions with known-correct SQL. Cube runs the agent, executes both queries against the warehouse and compares the result sets, with no LLM judge. Cases live as YAML in the data model repo, so they can run on a branch before a change merges.
• One definition everywhere. Because BI, embedded apps and agents share the model, the AI's number matches the dashboard's number.

Best for: Companies with several BI tools or customer-facing analytics that want one metric definition to hold across dashboards, customers and AI.

What to consider: A semantic layer only answers what it models. Questions outside the defined measures either fail or need new modeling work, and building the model is a real project. Cross-system questions that touch SaaS APIs rather than a warehouse are outside its sweet spot.

3. dbt Semantic Layer: metrics as code

The dbt Semantic Layer, powered by MetricFlow, defines metrics as code inside a dbt project, next to the transformations that shape the data. An agent asking for monthly revenue by region gets the same number finance reports, because both use one definition.

• Version control for metrics. Definitions go through the same code review and deployment process as the rest of the project, so every change is traceable.
• MCP tools for agents. The dbt MCP server exposes list_metrics, get_dimensions, query_metrics and get_metrics_compiled_sql, so an agent can discover valid metrics and see the SQL before running it.
• Portable definitions. dbt Labs open-sourced MetricFlow under Apache 2.0 in 2025 as a reference implementation for the Open Semantic Interchange spec, which was renamed Apache Ossie when it entered the Apache Incubator in July 2026.

Best for: Analytics engineering teams already centered on dbt that want agents to use official definitions.

What to consider: Its context stops at the dbt boundary. Data living outside the project, or questions that need live SaaS data, need another layer. It governs metrics well but does little for free-form exploratory questions.

4. Snowflake Cortex Analyst: verified queries and built-in evaluations

Snowflake Cortex Analyst generates SQL from natural language, guided by semantic views that describe business terms, relationships and example questions. Its most useful anti-hallucination feature is the verified query repository: approved question-and-SQL pairs that steer the model toward known-good logic for recurring questions.

• Measured accuracy. Cortex Analyst evaluations execute generated SQL and compare results with verified queries, reporting accuracy and regressions where a previously correct answer starts failing.
• Honest scoring. A verified query "can either guide Cortex Analyst at runtime or be used as evaluation ground truth, but not both at the same time." Snowflake creates a temporary copy of the semantic view without the selected queries, so scores reflect real generation ability.
• No data movement. Everything runs inside your Snowflake account under its existing governance.

Best for: Teams standardized on Snowflake that want natural-language analytics with accuracy they can measure.

What to consider: It only sees Snowflake data. Snowflake's own documentation now recommends "transitioning to Cortex Agents, which supports every Cortex Analyst capability with higher answer quality," so new projects should evaluate Cortex Agents directly.

5. Databricks Genie Agents: curated spaces with trusted assets

Databricks Genie Agents, formerly called Genie Spaces, turn curated Unity Catalog data into a conversational analytics space. Authors pick the tables, add instructions and example SQL, and register trusted assets such as parameterized queries and SQL functions.

• Verified logic. When Genie uses a trusted asset to build a response, Databricks says "the answer comes from this verified logic" rather than freshly generated SQL.
• Inspect mode. In Public Preview, Inspect reviews Genie's generated SQL, runs smaller checks on filters, date ranges and joins, and returns an improved query if it finds problems.
• Inherited governance. Row filters and column masks in Unity Catalog are enforced per user, and generated queries are always read-only.

Best for: Lakehouse teams on Databricks that want business users to self-serve answers from a well-defined set of tables.

What to consider: Accuracy depends heavily on curation. Databricks' own curation guidance says to "aim for five or fewer tables," so broad "ask anything" use across the whole lakehouse tends to disappoint. It is Databricks-only.

6. Contextual AI: grounded answers from documents

Contextual AI builds grounded retrieval agents, and its founding team co-authored the original RAG paper. It focuses on the documents, specs and manuals that semantic layers cannot reach.

• A model tuned to stay on source. Its Grounded Language Model is built to prioritize retrieved knowledge over training data and provides "inline attributions, citing the sources of retrieved knowledge directly within its responses."
• Checkable outputs. Contextual AI's site describes sentence-level citations with bounding boxes back to the source page, plus automated natural-language evaluation of responses.
• Flexible deployment. It offers multi-tenant SaaS, single-tenant SaaS or private VPC.

Best for: Engineering, manufacturing and research teams whose hard questions live in technical documents rather than warehouse tables.

What to consider: It is not the right tool for computing metrics from a warehouse. Many teams will pair it with one of the structured options above. If mapping relationships across documents matters, compare tools that build a knowledge graph.

How to add verification and containment to any agent

Grounding lowers how often an agent is wrong. Verification catches errors that slip through, and containment limits damage if an agent is manipulated. These four steps work alongside any platform above.

Step 1. Record what the agent actually ran

The simplest check is comparing what the agent says it did with what it actually did. Route every tool call through a runtime so the model requests actions and never executes them itself. Have the runtime log each call's tool name, inputs, outputs and result count. Before a response is shown, check that every number and "nothing found" claim matches a logged call.

A March 2026 preprint by Abhinaba Basu, Tool Receipts, Not Zero-Knowledge Proofs, formalizes this with signed receipts. Its NabaOS framework detected 94.2% of fabricated tool references, 87.6% of count misstatements and 91.3% of false absence claims, with under 15 milliseconds of overhead. Those results come from a synthetic benchmark of 1,800 scenarios in a single-author paper, so treat them as promising rather than proven. Receipts also cannot catch a tool that returns bad data, so pair them with data quality checks at the source.

Step 2. Keep credentials out of the agent

An agent holding a database password is one prompt injection away from leaking it. Run generated code in a sandbox with no stored connection strings, and have a separate layer inject short-lived credentials only at execution time. PromptQL's security page describes this pattern, with credentials injected at runtime and never exposed to the model. Write every brokered action to an audit log the security team owns. That record also feeds data provenance and lineage tracking.

Step 3. Put the agent inside a network perimeter

Identity decides who can act; a perimeter decides where data can go. On Google Cloud, VPC Service Controls added agent-specific controls in June 2026. Agents can be principals in ingress and egress rules, and rules can condition on MCP attributes such as mcp.toolName, mcp.method and mcp.tool.isReadOnly. Google's example allows reads from a Workspace MCP server while blocking email sends. If an injected instruction tells the agent to post internal data to an outside webhook, the perimeter blocks it even when the agent's IAM permissions would allow the call.

Step 4. Scope every answer to the person asking

Retire shared service accounts for AI agents and pass each user's identity to the data layer, so existing row filters and column masks apply. Require explicit approval for high-risk actions, and move sensitive questions into private threads, since answers in a shared thread are visible to everyone in it. Every access then maps to a real person. For approval workflows specifically, see our comparison of enterprise AI tools with human-in-the-loop approval.

How to test an agent for hallucination before you buy

Vendor accuracy figures are rarely comparable, because every vendor picks its own benchmark. Your own test set is the only number that counts.

Build an answer key. Pick 20 to 30 recurring questions where a wrong answer costs money: monthly churn, net revenue by region, pipeline by stage. Give each one a human owner who writes down the correct answer and the logic behind it.

Include traps. Add questions that should fail: a metric you do not track, a region that does not exist, a date range before your data starts. A good agent says it cannot answer or asks a clarifying question. A bad one invents a number.

Check the working, not just the answer. For each response, look at the SQL or code it ran. Right answers from wrong logic will break the next time the data changes.

Test permissions. Ask the same question as two users with different access. If the answers match when they should not, the agent is using shared credentials.

Re-run after changes. Schema changes, new data sources and metric redefinitions are when accuracy slips. Tools with built-in evaluation (Cube Evals, Snowflake's evaluations) make this cheap; with others, keep the answer key in a script. Our suggestion is to re-run it weekly for the first few months in production and after every schema change.

Limitations

This comparison relies on vendor documentation, product pages and published research available in September 2026. We did not benchmark the platforms ourselves. PromptQL's CRMArena-Pro result is self-reported on a single task category, and the NabaOS detection rates come from a synthetic benchmark in a preprint. Neither should be read as a guarantee of real-world accuracy.

The six tools are not direct substitutes. Cube and dbt are semantic layers, Snowflake and Databricks are features of their data platforms, Contextual AI targets documents, and PromptQL is a full agent workspace. Placing PromptQL first reflects that it is the only option here designed as a general-purpose agent across many systems, not a claim that it is more accurate than the others on any shared benchmark.

Products change quickly. Databricks renamed Genie Spaces to Genie Agents, Snowflake is steering Cortex Analyst users to Cortex Agents, and the Open Semantic Interchange spec became Apache Ossie in July 2026. Check current documentation before you decide.

Finally, no architecture removes hallucination completely. Grounded answers are only as accurate as the source data, and a correctly executed query against a broken pipeline still produces a wrong number.

Conclusion

The agent that "doesn't hallucinate" does not exist, but the agent whose mistakes you can see and fix does. Pick the architecture that matches where your data lives. If your questions span a warehouse, a CRM and a few SaaS tools, and a whole team will share the agent, an execution-first agent like PromptQL, which runs code against live data with each user's permissions, is the most direct fit among the tools compared here. If you already have a warehouse and a modeling team, a semantic layer (Cube or dbt) or your platform's native agent (Snowflake Cortex Agents, Databricks Genie Agents) will constrain the model well. If your hard questions live in documents, look at Contextual AI.

Whichever you choose, give your most important numbers an owner and an answer key before the trial starts. That answer key becomes the test every vendor has to pass, and the tool you rerun whenever a schema or definition changes. Regulated teams can see how this plays out in our guide to AI agent tools for financial services.

Frequently asked questions

Is there an AI agent that doesn't hallucinate on business data?

No agent is fully hallucination-free, but some architectures make invented numbers much rarer and easier to catch. Agents that answer by executing queries or code against your live data, rather than generating figures from memory, are the strongest option. PromptQL takes this approach, as do semantic-layer tools like Cube and the dbt Semantic Layer and platform agents like Snowflake Cortex Agents and Databricks Genie Agents. Always test on your own questions.

How accurate is PromptQL?

PromptQL reported 100 out of 100 correct on the Database Querying and Numerical Computation category of Salesforce's CRMArena-Pro benchmark in July 2025. That test was run by PromptQL on one task category, and the company's own co-founder has written that 100% accuracy is not possible in general. Treat it as a signal, and run your own answer-key test during a trial.

What causes AI agents to hallucinate when querying databases?

Three causes dominate. The model lacks company context and fills gaps with plausible patterns. Structured data pasted into prompts gets misread, since research shows models latch onto structural shortcuts. And tool-calling agents improvise table names, joins or aggregations mid-run with nothing checking them. Semantic layers, verified queries and execute-first designs each target one or more of these.

What is the difference between a semantic layer and a plan-based agent?

A semantic layer defines metrics, dimensions and joins in advance; the agent can only request what has been modeled, and the layer writes the SQL. A plan-based or execution-first agent has the model write a plan or program for each question, which a runtime then executes deterministically. Semantic layers are tighter but narrower; execution-first agents handle more open-ended, cross-system questions, and the plan is inspectable when something goes wrong.

Does fine-tuning a model on company data stop hallucinations?

Not on its own. Fine-tuning teaches a model your vocabulary and style, but it still has no access to current records when it answers, so it can hallucinate more fluently. It also needs retraining whenever definitions change. Grounding answers in live queries or retrieved documents is more reliable.

Does lowering the temperature reduce hallucinations?

It makes outputs more repeatable and can trim some errors, but it does not give the model data it lacks. A deterministic wrong answer is still wrong. Architecture matters far more than sampling settings.

Who is legally responsible when an AI agent gives wrong information?

Generally the company deploying it. In Moffatt v. Air Canada, decided in February 2024, British Columbia's Civil Resolution Tribunal found Air Canada liable for negligent misrepresentation after its website chatbot wrongly said bereavement fares could be claimed retroactively. It awarded C$650.88 in damages plus interest and fees, and called the airline's argument that the chatbot was a separate legal entity "a remarkable submission."

How often should you re-test an AI agent's accuracy?

Re-run your answer key after every schema change, new data source or metric redefinition, since those are when accuracy most often slips. Beyond that, our suggestion is weekly checks for the first few months in production, then monthly. Tools with built-in evaluation, such as Cube Evals and Snowflake's Cortex Analyst evaluations, make this cheap to automate.