LLMs can generate applications but still struggle to answer useful questions about live business data.
2
A unified query language can give an LLM one way to access structured data, unstructured data, and APIs.
3
Data access should combine authorization rules with autonomous, explainable query planning across multiple sources.
Summary
Tanmai Gopal argues that useful AI applications need direct access to live data and business logic. He gives examples involving calendars, Salesforce opportunities, support tickets, product databases, and delivery availability. Current assistants often fail because connecting these systems creates security problems and many small integration errors. His proposed approach, Pacha DDN, exposes data and business logic as tools for an LLM. The system uses a unified query language based on SQL, an object model for authorization, and query planning that the LLM can work out itself. Gopal compares this to asking an LLM to write Python code when arithmetic or reasoning tasks are difficult. In a Blockbuster demo, the system retrieves customer and movie data from several places and drafts an email. The talk is a concise argument for treating realtime data access as part of the AI system rather than as a collection of ad hoc integrations.
Live data is where current AI assistants fall short
Gopal says an LLM can write a Flappy Bird game in 30 seconds, yet cannot intelligently answer questions about his own data. He wants to connect a calendar and ask how many one-on-ones he had last week, what frequency fits his team members' roles, and how to stagger future meetings. Other examples involve explaining why an Acme Salesforce deal is stuck in stage three, joining an enterprise support ticket to its project and product-funnel status, and checking one-day delivery for a product at a specific address. These requests require the model to retrieve and connect information from live systems, then apply business context.
Data and business logic should be exposed as tools
The proposed basic pattern is to make live data and business logic available to the LLM as tools. Gopal says the idea is simple, but making it work well requires solving the integration problems that appear when several systems are involved. The assistant should be able to retrieve the relevant records, apply the right business logic, and answer the user's request without giving the model unrestricted access to an opaque system. This approach is presented as the foundation of Pacha DDN, which connects data sources and APIs to an LLM.
One query language can cover databases, documents, and APIs
Gopal's first design idea is a unified query language for structured data, unstructured data, and APIs. He argues that SQL gives an LLM useful semantic cues. In a SQL expression such as selecting records where an ID is greater than one, the comparison has meaning within the language. An API URL parameter may be ambiguous: it might mean greater than, greater than or equal to, or something else. Giving the model one query language reduces the number of separate conventions it must learn for each data source.
Authorization should follow the data and the session
The second idea is an object model for authorization. Gopal says authorization should not depend on where the data happens to be stored or which access path is used. The data has a schema, the session has properties, and rules can be evaluated against them. The same authorization rules should apply whether the information is accessed through a database, an API, or another source. He presents this as a way to avoid separately rebuilding permissions for every integration.
Gopal's third idea is to let the LLM work out the plan for retrieving data from several sources. He acknowledges that models can fail at simple tasks, such as counting letters or hours, then gives the remedy: ask the model to write Python code that solves the problem. The same pattern can be used for data retrieval. Instead of hardcoding every multi-step path, the system asks the LLM to run code that fetches the needed information, combines it, and resolves the request.
The demo joins customer and movie data into an email
In the demo, Gopal uses a Blockbuster database and related transactions. He asks the system to write an email to his top customer, thank them for their patronage, and mention some recent movies they watched. The request crosses two or three different places in the underlying data. Gopal says the system retrieves the information and produces the email successfully, which illustrates the combination of query planning, access across sources, and natural-language generation.
"The real pain that I have as I work with LLMs is that they can write a Flappy Bird for me with my face going up and down in 30 seconds, but they can't talk to my data intelligently."00:34
Who should watch
You are building an AI assistant that needs to answer questions using calendars, CRMs, support systems, or product databases.
Your team is connecting an LLM to several APIs and wants one query model with consistent authorization.
You want a practical design for letting an LLM plan multi-step data retrieval without hardcoding every route.
