Agents are the new apps

Agents are quickly becoming the new apps. Instead of navigating complex software interfaces, users are increasingly interacting with AI agents that understand intent, retrieve information, and take action on their behalf. And one of the most compelling things you can do with an agent is connect it directly to operational databases, as seen in the recent move by Google to connect all its operational databases to MCPs.

This makes a lot of sense. Operational databases are the systems of record for day-to-day business, capturing everything from customer interactions and transactions to inventory and service requests. Connecting agents to these databases gives them access to live, real-time data, which is exactly what business users need to make timely decisions.

More importantly, this direct connection eliminates the complex middleware that organizations have been building for decades. The traditional approach involves data pipelines, ETL processes, and data warehousing, all of which are time-consuming to build and expensive to maintain. And despite all that effort, these pipelines typically transform only a small subset of the operational data. The rest sits unused, locked away in schemas that only developers understand.

Why is this becoming possible now

This shift is becoming possible because agents are getting incredibly powerful at processing raw data without needing the usual business transformations layered on top. Traditional BI workflows assume that someone needs to clean, reshape, and label the data before a business user can make sense of it. Agents are beginning to bypass that assumption entirely.

In fact, agents can often understand what a business user is asking far better than any manual transform or predefined report ever could. A report is static and opinionated; it answers a fixed set of questions in a fixed way. An agent, on the other hand, interprets the user’s intent in context and retrieves what’s relevant from the raw data. This flexibility is what makes the direct-to-database model so appealing.

The consistency problem

However, there is a significant challenge in connecting agents directly to operational data: the data is raw and machine-level, by definition. Operational schemas are designed by system developers for application efficiency, not for business readability. Column names are abbreviated, relationships are implicit, and the same concept might be represented differently across tables.

When an agent encounters this kind of schema without guidance, it can end up interpreting the data differently each time. One query might treat property_type as a building classification, while the next might confuse it with property_code. An address field like addr might be mapped to a business location in one response and a home address in another. These inconsistencies are not just annoying; they make the entire process unreliable. Unreliable answers in regulated industries like banking, insurance, and healthcare are simply not acceptable.

Therefore, it is better to bake the interpretation offline, once and consistently, rather than letting each agent figure it out at query time. This is where context graphs come in. By encoding the correct interpretation of the data into a persistent graph, you ensure that every agent, every time, resolves ambiguities the same way.

Building the context graph in Tursio

At Tursio, we build context graphs for operational databases to make them searchable in natural language. The first step is pulling business context from multiple sources and reconciling what they tell us.

The context comes from the database itself: the schema, metadata, constraints, and even the data values. But that’s only the starting point. Tursio also ingests context from query workloads, which reveal how the data has been used historically; from BI dashboards in tools like Power BI, which show how business users have been interpreting the data through DAX expressions and report structures, and even from Excel files that business users might have used to post-process or annotate their data.

Each of these sources carries a piece of the puzzle. The database tells you what the data is. The query history tells you how it was accessed. The BI layer tells you what it means to the business. And the spreadsheets tell you how people actually work with it day to day. Ingesting all of that into a single context graph is essential to getting the interpretation right.

Identifying ambiguities

Once the context is collected, Tursio identifies the ambiguities that are likely to trip up an LLM. These fall into several categories:

Confusable columns: Columns with similar names or overlapping semantics that an LLM might mix up. For example, property_type versus property_code, or account_status versus member_status. Without disambiguation, the LLM has no reliable way to choose the right one.

Contextual relevance: Attributes that have relative importance depending on the business context. For instance, addr might be more relevant to a business location in a branch-operations query, while home_addr matters more in a member demographics query. The LLM needs to know which one is the default and when to prefer the other.

Implicit hierarchies: Parent-child relationships encoded through ID columns, like parent_id and child_id, that define organizational or data hierarchies. These relationships are obvious to a database developer but invisible to an agent without explicit guidance.

Custom measures and aggregations: Business metrics that require specific calculation logic, such as how to compute average loan balance or delinquency rates. The agent needs to know not just what columns to use, but how to combine them correctly.

These ambiguities exist at the level of columns, tables, relationships, and even entire datasets. Identifying them systematically is the first step toward resolving them.

Annotating the context graph

Once ambiguities are identified, Tursio allows admins to annotate the context graph to resolve them. This includes adding descriptions that clarify what a column or table represents in business terms, defining aliases so that business users can refer to data elements using their own vocabulary, gathering sample values that ground the LLM’s understanding of a column’s domain, and specifying rules that govern how certain attributes should be used in queries.

For example, an admin might annotate property_type with a description like “classification of real estate collateral, not to be confused with property_code, which refers to the internal coding scheme.” They might add aliases such as “collateral type” or “asset classification” and include sample values like “Single Family,” “Multi-Family,” and “Commercial.” They might also add a prioritization rule specifying that when a user asks about “property type,” this column should be preferred over property_code. Or an enforcer rule to always include the value field when users ask about data points. Or a hierarchy rule to define the implicit hierarchies between category_id and segment_id.

This annotation step is where human expertise meets automated inference. The context graph provides the structure; the admin provides the judgment calls that make it accurate for their specific organization.

Testing and validating

Annotation alone is not enough. You need a robust way to test whether the ambiguities have actually been resolved. Tursio provides this through an iterative testing workflow.

Admins can quickly validate different descriptions and rules against different questions to see how the changes affect query interpretation. Did adding that description for property_type actually prevent the LLM from confusing it with property_code? Does the new alias for addr resolve the business-versus-home address ambiguity? The testing workflow lets you experiment and tune quickly before committing changes.

Beyond individual question testing, Tursio also supports flight testing the context graph over a query workload. This means you can take a representative set of historical or expected queries and run them against the updated context graph to get a comprehensive testing report. This report shows which queries improved, which regressed, and which remain ambiguous, giving admins the confidence to save the updated graph for all agents to use.

This test-before-deploy approach is critical. In regulated industries, you cannot afford to push out a context graph that introduces new errors while fixing old ones. The ability to flight changes over a workload turns context graph management from guesswork into an engineering discipline.

Looking ahead

Context graphs are going to be a critical infrastructure for agents that work with operational data. As more organizations connect agents directly to their databases, the need for a reliable, consistent interpretation layer will only grow. And managing ambiguities in those graphs is what makes them reliable.

Tursio is making early progress in this direction, from automatically ingesting multi-source context, to identifying common ambiguity patterns, to providing annotation and testing workflows that let admins tune the graph with confidence. But there is still a long way to go. The ambiguity space is vast, the edge cases are endless, and the expectations from business users are rightfully high.

What gives us confidence is that this is a solvable problem. It requires combining automated inference with human expertise, building tight feedback loops, and treating context graphs as living artifacts that evolve with the organization’s data and needs. The agents are ready. The data is there. The missing piece is the context graph that bridges the two reliably, and that starts with managing ambiguities well.