Most enterprise teams have moved past asking whether AI agents can reach their business data and onto a harder question: whether those agents answer correctly once they have access. Business context for AI agents is the variable that decides that outcome, because an agent that can see every table in your customer relationship management (CRM) system, data warehouse, and IT service management (ITSM) platform still has to understand what that data means and how to apply it before it can take action. When an agent returns the wrong answer, the common reaction is to reach for a larger or newer model and expect the extra reasoning to close the gap.
We tested that assumption across 27 models from 12 developers. With business context available through CData’s Context Engine, 333 of 405 runs (82%) succeeded, and 26 of the 27 models succeeded at least once.
In a previous study, we gave models a deterministic, configured and guarded implementation of Connect AI, where joins, federation, and write validation was coded into the data layer. For this study, the tasks given relied on the model to make the right choices with only plain-text context.
In this article, we'll cover why raw access fails, what context entries are, how the benchmark was run, what the results show, and how to add context to your own agents.
Why access alone isn't enough
Raw access gives an agent visibility into every connection, data model, object, and field across your connected systems, which sounds like everything it should need. In practice, that visibility leaves the agent to infer what each object represents, which business rules govern a metric, and how records in one system relate to records in another, and it has to repeat that inference on every question (Thoughtworks). Academic research shows the same pattern on real enterprise schemas. In Spider 2.0, a code agent built on o1-preview solved roughly a fifth of enterprise text-to-SQL tasks, compared with 91.2% on the simpler Spider 1.0. The distance between those two numbers reflects how much enterprise data depends on knowledge that sits outside the schema itself.
Our raw-access runs showed where that effort went. The agents spent most of their turns exploring connections and schemas, and more than a third of runs hit the 40-turn cap before answering. Every model in the benchmark could write a valid request, and the failures traced back to missing knowledge about which objects, rules, and joins each question depended on.
Long discovery loops carry a second cost. Each discovery question and failed request lands in the agent's context window, and as that window fills, the model's ability to recall and reason over the relevant parts degrades, a pattern Anthropic describes as context rot. An agent that struggles to find the right table early in a run is working with less clarity by the time it finds it. Gartner predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data, and business context belongs in that definition of readiness alongside quality and governance. Data your agents can reach but cannot interpret is data that isn't ready for AI yet.
What business context for AI agents means
Business context for AI agents is the written knowledge an agent needs to use data correctly: system context defining relationships between systems, semantic definitions for ideas like at-risk and review-eligible, and company knowledge like which business rules to apply and how to query across systems. The agent retrieves that knowledge on demand instead of rediscovering it from raw schemas on every run. Seen this way, context is a layer of documentation written for a machine reader, kept close enough to the data that the agent can find it at the moment it needs it.
In the benchmark, the mechanism was a single feature, the Context Engine. The agent uses a search_context tool to search short, plain-language context entries stored alongside its connections and reads only the entries relevant to the question in front of it. We wrote ten entries in total: seven object descriptions (system context), the account health-score rules and the usage-trend metric definition (semantic definitions), and rules for writing requests across the CRM, the cloud data warehouse, and the ITSM platform (company knowledge). The entries describe data and rules, and none of them contain answers to the benchmark questions. You can read every entry in the benchmark repository under setup/context/.
This approach sits alongside other ways of adding meaning to enterprise data. BI platforms let model authors attach AI instructions with business logic to a semantic model, and curated toolkits wrap logic in views and custom tools. Context entries in the Context Engine are written text tied to the connections and objects themselves, so your teams can add them without first building views, models, or custom tools.
How the benchmark compared raw access with business context
The scenario placed an agent across a CRM, a cloud data warehouse, and an ITSM platform, connected through a managed Model Context Protocol (MCP) server. Each model worked through three tasks, two that read and composed data across systems and one that wrote eligible accounts to a review queue, under two conditions.
Parameter | Value |
Connections | CRM, cloud data warehouse, ITSM |
Tasks | Account health and eligibility (read); usage-trend composition (read); write eligible accounts to a review queue (write) |
Models | 27 from Anthropic, OpenAI, Google, xAI, and open-weight models served through Together and Mistral |
Runs | 5 per model, task, and condition; 810 total |
Settings | Temperature 0, 40-turn cap |
Raw access | get_catalogs, get_schemas, get_tables, get_columns, get_instructions, queryData (plus execute_insert for the write task) |
With context | The same tools plus search_context |
The two conditions differ by exactly one tool. Every model saw the same systems, the same questions, the same settings, and the same discovery and query tools in both conditions, so the difference in results comes from the context the agent could retrieve.
Results: accuracy, tool calls, tokens, and cost
Measure | Raw access | With context |
Median tool calls per run | 40 | 8 |
Median tokens per run | 489K | 89K (82% fewer) |
Median cost per run | $0.27 | $0.09 |
Total benchmark spend | $350 | $93 |
Median wall time per run | 176 s | 94 s |
Context moved success further than model choice did. With context, 333 of 405 runs (82%) succeeded, 13 of 27 models succeeded on every run, and 26 of 27 succeeded at least once. Without business context, the same models rarely completed the tasks, and full per-run results are in the benchmark repository. The efficiency numbers follow from the same cause, since an agent that reads a few short entries spends far fewer turns, tokens, and dollars than one that maps three systems from scratch. Because so many raw-access runs stopped at the 40-turn cap, the reduction in tool calls is conservative, and the true cost of unguided discovery is likely higher than the table shows.
For enterprise teams, the implication is that the fastest path to better agent accuracy may run through your documentation before it runs through your model contract. We've seen a similar dynamic on the cost side, where scoping and configuring the data layer cut token use on a multi-source query by 97.6%.
Where business context helps most and where guardrails still matter
Read tasks showed the clearest gains. Both read tasks reached 87% success with context, and median turns dropped to five, which means the agent typically found the relevant entries, wrote the query, and answered without an extended search.
The write task tells a more measured story. With context, 73% of write runs were clean, and rows written to the wrong accounts fell by 71%. That is a large improvement, and it still leaves a meaningful number of incorrect writes. Context makes an agent more likely to act correctly, and your write workflows still need guardrails such as scoped tools, approval steps, and review queues before changes reach production records.
Speed improved less than the turn counts suggest. Turns dropped about fourfold, but wall time only halved, and the write task ran slightly slower with context than without it. One small model, Qwen 3.5 9B, never succeeded even with context, and Mistral Large 3 succeeded in only 3 of 15 runs. Context raises the floor, but it can't make up for a model that's too weak for the task.
How to add business context to your AI agent workflows
The benchmark's process transfers directly to your own agents, and it starts with the failures you already have.
Find the questions where agents fail, loop, or hit turn limits. Those questions show you where context is missing, and they give you a baseline to measure against.
Write one entry per table the agent depends on. Describe what the table holds, its keys, and any known gotchas, such as soft-deleted records or fields that mean something different than their names suggest.
Write business rules as rules. Metric definitions, thresholds, and eligibility criteria belong in their own entries, stated plainly enough that an agent can apply them without interpretation.
Add query guidance for joins across systems. Explain which identifiers link records across your CRM, warehouse, and ITSM platform, and note the patterns the agent should avoid.
Measure before and after. Track success rate, tool calls, and tokens per run so you can see which entries carry their weight. The public benchmark repository works as a template for that measurement.
At CData, we built the Context Engine into CData Connect AI so that context lives alongside the connections agents already use. Connect AI gives agents governed, real-time access to hundreds of enterprise sources through one managed MCP server, and the Context Editor lets your teams write, organize, and refine context entries without building pipelines, views, or custom tools first. Because the entries sit at the connectivity layer, every MCP-compatible agent and model that connects through Connect AI retrieves the same definitions and rules, no matter which model your teams choose.
Give AI agents business context across your CRM, data warehouse, and ITSM data
CData Connect AI connects AI agents to hundreds of enterprise sources through one governed MCP server, and its Context Engine lets them read the business context they need before they send a request. Start a free trial to add context entries to your own connections and rerun the benchmark against your data.
Frequently asked questions
Does a better LLM fix AI agent accuracy on enterprise data?
Not on its own. In CData's benchmark, success depended far more on business context than on model choice: with context, 26 of 27 models from 12 developers succeeded at least once, and 82% of runs were correct.
Does adding business context increase token costs?
No. Median tokens per run fell 82%, from 489K to 89K, because the agent read a few short context entries instead of exploring schemas through dozens of tool calls. Total benchmark spend fell from $350 to $93.
How much context do I need to write?
Less than most teams expect. The benchmark used ten short entries: one per table, plus entries for the health-score rules, the usage-trend metric, and query rules across systems.
Is business context enough for agents that write data?
Context helps, but it isn't a safety control. Wrong-account writes fell by 71% with context, so write workflows still need scoped tools, approvals, or review queues.
Does this apply to models other than Claude?
Yes. The benchmark covered 27 models from Anthropic, OpenAI, Google, xAI, and open-weight providers, and 26 of them succeeded with context.
