Non-Obvious Patterns in Building Enterprise AI Assistants
Lessons from building production AI systems that nobody talks about.
The conversation around AI agents has
Agentic workflows are already used for initiating action. To be successful, agents typically need to combine multiple steps and execute business logic reflective of real-life decisions. But, as developers rush to deploy these autonomous agents, they are slamming into a wall: the compounding error problem of accuracy.
To understand why agentic workflows require near-100% accuracy on questions that are answerable by your database data, let’s look at the numbers: Assume an accuracy of 90% in a single-step AI process. You ask a question; you get a correct answer 90% of the time. But in an agentic workflow, the AI takes multiple dependent steps – and errors compound exponentially.
Let’s run the numbers on a 90% accurate agent:
One step: 90% success rate.
Two steps: 0.90 × 0.90 = 81% success rate.
Five steps: 0.90^5 = 59% success rate.
Now, imagine that same five-step workflow running on an 80% accurate agent. The success rate plummets to just 33%.
In a business context, even 90% accuracy is often insufficient. And 59% or 33% success rate is downright catastrophic. Indeed, in many industries near-100% accuracy is needed, because the agentic application is customer-facing and inaccuracies lead to loss of trust and loss of revenue. Furthermore, in many industries there are legal, safety and compliance requirements. In such industries, near-100% accuracy must be combined with explainability so that the human-in-the-loop can understand and verify the answers.
Example: consider a real estate agency using an AI workflow to handle new tenant onboarding in a five-step flow. The agentic flow must:
extract data from an application
run a background check via an API
query the database for available units
draft a lease, and
email the tenant.
If step three fails because the AI makes a mistake in the database query and pulls a unit for the wrong city – then, steps four and five will generate a legally binding lease for a property that doesn’t exist, and then send it to the client. The cost of manual remediation, lost trust, and legal liability makes anything less than near-perfect execution completely unviable.
To achieve the required accuracy and explainability when agents interact with enterprise databases, developers are turning to specialized tools. QueryData is such a tool for agents, designed specifically to offer near-100% accuracy for natural language-to-query. By enabling agents to retrieve correct data, QueryData ensures that agents are well-equipped to take action.
A Large Language Model (LLM) inherently knows many dialects of SQL, but it doesn’t know your business logic and your database. Agentic tools use context to bridge that gap. Context is essentially the code which a tool like QueryData uses to guide the LLM towards correct answers. Crucially for achieving near-100% accuracy and explainability, the QueryData works with a comprehensive database context, organized into three main pillars: Schema Ontology, Query Blueprints and Value Searches.
Schema ontology is about understanding your database structure and semantics. This includes natural language descriptions of tables and columns. The QueryData LLM has a greater chance to translate the natural language question into the correct query using these instructions. You can think of schema ontology as a set of “cues” or “hints” – meant to steer the LLM into picking the right tables and columns and synthesizing them correctly into a database query. A couple of examples:
Here is what a database-level description could look like for a search engine of real estate listings:
“Listings, real estate agents and information about communities where listings are located – schools, amenities and hazards: fire, flood and noise”
The table description for property could look like this:
“Current real estate listing, including houses, townhomes, condos and land”
An example of column description that explains that the proximity_miles means
“property distance from the district’s school in miles”
For ease of use, you can autogenerate rich descriptions, which will typically include sample values of the column.
If ontology is the vocabulary, query blueprints are the way to introduce fine control of the generated SQL for important questions that must absolutely receive accurate and business-relevant answers. For example, consider the question “Riverside houses close to good schools”. The interpretation of “close” and “good” provided by Gemini is impressive- in a demo application it translated to
…WHERE city_name = 'Riverside' AND school_ranking <= 5ORDER BY proximity_miles ASC
But this interpretation still leaves much to be desired: Wouldn’t you drive one more mile for a school whose school_ranking is much higher than the Gemini-chosen cutoff? Of course you would! Both proximity and school ranking should affect the overall ranking. A no-cut-corners developer will take control of the interpretation of “close to good school” by introducing a sophisticated ranking function, which may be the result of continuous A/B experiments, along with sensible cutoffs.
Templates
In particular, she will use a template: A pair of natural language intent with its respective parameterized SQL translation.
parameterized_intent : “$1 houses close to good schools”,parameterized_SQL : “SELECT … FROM … WHERE city_name = $1 AND "school_ranking" <= 5 AND "proximity_miles" <= 2ORDER BY school_score("school_ranking", "proximity_miles")”– the school_score stored procedure combines school ranking and proximity into a single ranking
Such info can be given in a JSON file but, even more user-friendly, you can use Gemini CLI, prompt it with an example natural language question and your ideal respective SQL and it will produce the JSON for you.
Furthermore, templates enable the agent to explain how the question was interpreted. This mitigates the effect of the occasional remaining inaccuracies, allowing a human-in-the-loop or agent to understand what the answer of QueryData means.
Facets
While plain query templates provide highly accurate and explainable answers, they have low flexibility: they can only answer the specific critical question patterns that they were designed for. What if you wanted to combine the “close to good schools” with price conditions, square footage, bedroom conditions and more. The facets generalize templates to combine the best of both worlds: highly-accurate, explainable answers to large numbers of questions.
"parameterized_intent": "Property price between $1 and $2", "parameterized_sql_snippet": "T."price" BETWEEN $1 AND $2"
Value searches
Some ambiguities in the NL question are rooted deep in the private data of your database and need a collaboration of the LLM with the database to disambiguate. Value searches solve the hard problem of correctly associating data values in the database with the “entities” that the question talks about.
For example, consider the question “Westwod”s sold properties in the last 1 month.” The first problem is that there is no “Westwod”; it is a misspelling of “Westwood”. Apart from the misspelling, there is a second problem – a deeper ambiguity in our sample database: “Westwood” appears as both the name of a real estate brokerage and as the name of a city. Value searches can utilize the built-in powerful vector+text search capabilities of Google Cloud’s AI-native databases. Here, value searches will enable QueryData to respond to the agent that this is likely a misspelling of ‘“westwood, which appears as both a real estate brokerage and a city name.
Agentic workflows are poised to revolutionize operations, but they are unforgiving when it comes to accuracy. Through context engineering, businesses can mitigate compounding failures and start trusting their autonomous agents to deliver.
As a next step, you can explore how to create context sets across these databases:
And here – your “cheat sheet” for building blocks of context (courtesy by Nanobanana):
Lessons from building production AI systems that nobody talks about.
The conversation around AI agents has
In the enterprise landscape, data is often highly fragmented across multiple source systems. Data curation
Leaders across industries around the world are asking: How do we harness all of this
For decades, expense automation relied on a simple premise: If the machine can read the
Agentic workflows are already used for initiating action. To be successful, agents typically need to