1. Let Me Say This First
For a while now, people have been putting three kinds of Agents in front of me. Code Agent, general office Agent, Data Agent — aren't they all large models calling tools? The loop looks the same. The capabilities look like they overlap. The more direct question is: Code Agents can already write SQL. Does that mean the Data Agent problem is solved too?
The question is natural. Over the past year, people have seen the same kind of demo over and over: the model calls a tool, the tool returns a result, a chain of thought appears on the screen. It all looks Agentic. So the next inference comes easily — if the loop is the same, the product difficulty should be similar; if a Code Agent can already write SQL, a Data Agent is just a matter of connecting the warehouse.
Looking at the loop, that is true. The model thinks a step, calls a tool, reads the result, then decides the next step. That skeleton is used by all three products.
Looking at the products, the problems they face, the hard parts, and what they optimize for are not in the same place. Capabilities can overlap. The center of gravity cannot. Treat them as the same product, and what you usually get is: SQL gets written, and nobody dares to use the number.
I personally think this is the easiest thing to get wrong in this round of Agent products. People watching demos see the same Agentic loop. People building products get stuck in completely different places every day. The inference is cheap, and it hides the parts that are actually hard. This article will be long. Please be patient. I will go through it piece by piece.
2. Three Kinds of Agents Look Like They Are Calling Tools. What the Industry Gets Stuck On Is Completely Different
First, be clear about the deliverable. Three kinds of work Agents look like they are calling tools, and all of them can write a little SQL. What actually separates them is what they deliver, where they get stuck, and what counts as done.
A Code Agent delivers working code. It has to read the repo, change the code correctly, then rely on compile, test, and run to confirm the work is finished. If the program passes the checks and hands back a runnable result, the work has moved forward. Business definitions are usually not its first problem. Wiring Word, Excel, the browser, and internal systems into one cross-software flow usually isn't either.
A general office Agent delivers a job that actually got done across software. Its hard part is the ecosystem and the connections: hooking up existing software, letting the flow pass through different systems, and actually running it through. Making one Word tool, one Excel tool, or one browser tool excellent does not mean the whole cross-system flow is finished. A single tool working well, and the whole job being done, are still separated by permissions, formats, notifications, write-back, and the unfriendly seams between systems. In office work, failure is often not that the model cannot write a paragraph. It is that the flow stops at the door of the second system: the login session expired, the fields don't match, the attachment wasn't attached, the write-back was rejected. No single tool, however good, can carry the whole cross-system flow.
A Data Agent delivers a number, and why that number can be trusted. It also writes SQL a lot, and it also calls tools a lot. Where it gets stuck is rarely "can it write a SELECT." There is no compiler and no unit test to tell you "this is the revenue you wanted." Writing SQL is only one step.
Of course the three overlap. A Code Agent will write a little SQL. An office Agent will touch data. A Data Agent will also change scripts and produce reports. Overlap exists. That does not mean product difficulty can substitute for product difficulty.
Figure 1: Code Agent, general office Agent, and Data Agent all call tools. What actually separates them is the deliverable, where they get stuck, and what counts as done.
Make a simple comparison. The completion standard for a Code Agent can, roughly, be handed to compile, test, and run. The completion standard for an office Agent is that the cross-system flow actually ran through, not that one software tool is good on its own. The completion standard for a Data Agent is that the number is right, the definition is right, and the process can be audited. All three are called Agents. What the industry gets stuck on is completely different.
That is why I talk about them separately. People who write code care about the repo, the change, and whether it runs. People who do office automation care about whether the software is connected, and whether the flow stopped at the door of the second system. People who do data analysis care about whether this table is revenue, and whether this number can be taken into a meeting. All three groups can say they are building Agents. The hurdles they have to clear are not the same hurdle.
My conclusion is straightforward: the loop can be the same; the product hard parts are not. A Code Agent that can write SQL does not automatically become a Data Agent.
3. The Three Hard Problems of a Data Agent
Internally we call the three hard problems of a Data Agent: asset search, definition alignment, and result verifiability. When we talk about it outside, the slides have used a harder set of three cards: million-scale asset search fails, Source of Truth is hard to judge, there is no deterministic grader. Different wording, same thing.
Start with the first.
The first is finding the actually relevant data assets among hundreds or thousands of tables and files. Miss one table, or misread one field, and the answer is wrong. Users have already connected warehouses of hundreds of tables, even 1,400 tables or more, and then asked questions. Governance is often not finished. Table names are unfriendly. Fields look like codes. The same "revenue" might be called ARR, recognized revenue, net revenue, or it might be hidden in a fact table whose name does not look like revenue at all. The first capability here is not generating SQL. It is finding the actually relevant data assets. We once did an acquisition analysis that went from 8 raw tables to about 199,000 target users. What was actually hard that time was finding those 8 tables first, not the last few aggregations.
What this means is that warehouse scale itself is not a report card. 1,400 tables or more only means some users have already connected a warehouse of that size. After it is connected, the hard part is: among these hundreds or thousands of tables, which few are related to this question. However fluent the SQL is, if you pick the wrong table, everything after that is spinning.
Now the second.
The second is understanding the business definition the user actually wants, the Source of Truth, and the meaning. Getting the AI to match what is in the user's head is very hard. What you can query in the warehouse is fields and rows. The version the company actually books often lives in people's habits, historical reports, and spoken agreements. There is no column in the field types that says "this is the revenue finance recognizes." The model sees columns it can query. What people want is how this company books the number.
The third is making it convenient for a person to check whether an important number is actually right. Whether a Code Agent is done can often be told from tests, compilation, and running. Whether the number a Data Agent computed is accurate depends on whether the first two were done. Even if the first two look done, important numbers still need a person to look at the process and the data flow.
These three can be written separately, but they are bound together. Miss an asset, get the definition wrong, and the SQL after that cannot save you no matter how pretty it is. If the process cannot be audited, even a correct number cannot enter a decision.
I wrote these three hard problems into a public post.
Figure 2: This was the public statement of the three hard problems of a Data Agent at the time. Finding assets, aligning definitions, inspecting the process. Accuracy is critical. Enterprises need a Context Hub to complete self-learning of context.
Figure 3: The three hard problems can be written separately, but they are bound together. Miss an asset, get the definition wrong, and the SQL after that cannot save you no matter how pretty it is. If the process cannot be audited, even a correct number cannot enter a decision.
Put these three together, and writing SQL only covers a small piece. If the assets are wrong, the SQL is written against the wrong tables. If the definition is not aligned, the SQL computes a number that runs, but cannot be used. If the process cannot be laid open, even a correct number cannot enter a scene where someone has to be responsible for it. Among the three, generating SQL is at most the small step at the end.
So being able to write SQL is far from having built a Data Agent. A Data Agent is also not connecting a data source, writing a query, and making a table. Accuracy comes first. To make accuracy something that can accumulate, an enterprise has a lot of internal work to do, and among that work there must be a Context Hub, used to complete self-learning of enterprise context. I will come back to this later. For now I am putting the judgment here.
4. Being Able to Compute a Number Does Not Mean the Definition Is Right
When a Code Agent finishes changing code, the compiler will error, tests will go red, the runtime will crash. These things are not perfect, but they exist. If the program cannot pass the checks, at least someone knows this round did not get done.
A Data Agent has no unit test to tell it whether the answer is correct. The most dangerous error is: the code did not error, the number was computed, and the definition is wrong. The query ran. The table was drawn. A clean integer appeared in the chat box. No error, so no alarm.
Make a simple comparison.
The four characters "Q1 revenue": sales counts by signed contracts, finance counts by cash received, and both sides can find fields in the warehouse that look quite respectable. The model picks one of the tables, writes SQL that runs, and returns an integer. On the interface it looks like the right answer. In the business it may be answering a different question.
We have seen the same English question: Let's calculate the revenue in the first quarter. The sales definition can give 4.10 million. The finance definition is another set of numbers. Both numbers can be computed from real tables. They are not answering the same question. If the system only hands over one of them, and treats it as "revenue," every discussion after that will slide on the wrong definition.
What this means is that 4.10 million itself may not be computed wrong. It may be exactly the sales version. The problem is which version the person asking actually wanted, and whether the system made that clear. Source of Truth is not written in the field types. It is written in how this company books numbers, which team uses which definition, and which version the person asking this time actually wants. Matching what the user actually wants is very hard for AI, and for the product it cannot be skipped.
If the system only generates SQL, it will wrap this error as a successful tool call. A system that can write SQL is exactly the one most likely to hide this error. My judgment is straightforward: being able to compute a number does not mean the definition is right.
5. In an Industry Without a Grader, You Can Only Lay the Process Open
Even if the assets were found correctly, and the definition was aligned, important numbers still need a person who can quickly inspect the process and the data-processing flow.
The final answer in the chat box is not enough. People need to see which tables were used, which intermediate results were generated, which step the number was computed from, and how the dependencies run. A Code Agent at least still has tests and runtime results that can serve as a grader. A Data Agent has no deterministic grader. Without a grader, you can only lay the process open and let people trace it back themselves.
In the product, this shows up as openable steps, clickable SQL, viewable intermediate tables, and a data lineage graph you can drag and zoom. In cross-database analysis tasks we leave graphs like this: nodes are tables, edges are dependencies, and a person can follow the data flow to trace a conclusion back.
Figure 4: Data lineage left behind in a cross-database analysis task. Steps, intermediate tables, and dependencies can be traced back along the graph, instead of leaving only one sentence of conclusion in the chat box.
Without this layer of visibility, even if a Data Agent occasionally computes a number correctly, it is hard to enter a scene where someone actually has to be responsible for the number. An enterprise will not write a revenue number into a decision just because the model said "I am very sure." Finance, operations, and risk need not a chat bubble, but a path that can take a number from the conclusion back to the table, from the table back to the filter conditions, from the filter conditions back to the version of the definition. A number you cannot trace back will start another argument every time it is used.
This is also a boundary between Data Agent and Code Agent. Code has tests and runtime results as a grader. A Data Agent has no deterministic grader. Reliability can only come from a process that can be audited, a definition that can be aligned, and intermediate results that can be inspected. In an industry without a grader, you can only lay the process open for people to see.
6. Context Cannot Start from Zero Every Time
The three hard problems together force a conclusion: a Data Agent must have a self-learning system. Definitions, cases, table meanings, and preferences produced during use have to accumulate automatically into enterprise Context. Otherwise it will stay hard to use. Every new session starts from zero, feeling out tables, guessing from zero what "revenue" is, and the user will keep teaching the same definition. However long the product is used, it is still in the state of a first meeting.
We wrote this update path very strictly:
Find the definition is wrong → a person gives a correction → the Agent reflects and generates a knowledge update → human review → enter Context Hub → later tasks retrieve it.
Knowledge cannot be quietly rewritten by AI. The Agent can propose an update. A person approves or rejects it in Review Center. What passes enters Context Hub. There are four kinds of objects: Table Data, Cases, Metrics, User Preferences. Later tasks retrieve them. Updates that do not pass cannot become company facts.
These four kinds of objects each govern something different. Table Data is the business meaning of tables and fields. Cases are questions and paths already taken. Metrics are metric names, definitions, and computation methods. User Preferences are preferences about result form and expression. What a person sees in Review Center is also these four kinds of updates waiting for review. The Agent can draft. It cannot put them into effect by itself.
Figure 5: A correction has to go through human review before it can enter Context Hub. Updates that do not pass cannot become company facts.
Figure 6: Review Center gathers pending updates to tables, cases, metrics, and preferences, for a person to approve or reject. AI cannot quietly rewrite enterprise Context.
Same rule as always: put the numbers down first. There is a comparison we have done in public. Same question: Let's calculate the revenue in the first quarter.
| No usable Context | After Context entered | |
|---|---|---|
| Time | 8 minutes 23 seconds | 2 minutes 48 seconds |
| Steps | 12 steps | 15 steps |
| Human corrections | 1 | 0 |
| Result delivered | One number, 4.10 million | Sales and finance definitions side by side, collection rate 48.78% |
Look at the steps row first. The later run did not get shorter. It even went from 12 steps to 15. What changed was time, from 8 minutes 23 seconds to 2 minutes 48 seconds. What changed was corrections, from 1 to 0. More important, the number went from "one integer that looked respectable" to two definitions laid side by side, plus a collection amount that could be matched.
What this means is that the time saved on feeling around was used on cross-checking. The run without Context ended with 4.10 million, and a person still corrected it once. After Context came in, the same question no longer handed over only one integer. It laid out the sales and finance definitions, and computed a collection rate of 48.78%. Three more steps, more than half the time gone, corrections from one to none.
What an enterprise wants is this Context Hub: let enterprise context self-learn, and let every learning pass through a person's hands. Without it, the product will not get easier because it was used a few more days. It will only keep returning to the state of a first meeting.
7. Exploration Cannot Fill Up the Database
Beyond the three hard problems at the product layer, the engine layer has another set of problems. The first is: how can AI explore efficiently without putting too much pressure on the database.
An Agent's instinct is to look at more. List, sample, aggregate, then switch a dimension. If every step does a full table scan on the source database, exploration itself becomes an incident. The larger the warehouse, the faster this problem arrives. Whether the connected tables are a few hundred or 1,400 or more does not change this: exploration has to be cheap, and heavy computation has to appear late.
Our approach is to put cheap actions first. First !show, first look at table structure, first LIMIT sample, then do the heavy aggregations. DirectQuery leaves computation at the source. Data does not move. Computation is pushed down. Complex questions can be written as short fragments step by step. Scope then compiles those fragments into one pushed-down SQL. Intermediate results do not have to be pulled back into the engine first.
There is a cheaper action still: Explain-before-execute. DirectQueryExplain only looks at the compiled SQL. It does not touch the source database's rows. A person or an Agent can read the plan first, then decide whether to run it.
There is a place that is easy to get wrong. Profiling such as DataSummary does actually read data. You cannot describe it as "not touching the source database." What saves the source database is metadata queries, sampling with a row limit, and Explain that only compiles and does not execute.
Let me say what I think. If exploration fills up the database, definition and verification have not even started, and the system has already crushed the warehouse. The first job of the engine layer is to keep the Agent's instinct to look at more from becoming a full table scan on the source.
8. After SQL Blows Up the Window, the Agent Cannot See the Whole Query Either
The second engine problem: complex business will write a lot of SQL. How do you keep SQL information-dense and execution effective, without blowing up the LLM's context window? How do you make SQL suitable for an Agent to use, so the model keeps its attention on the business, not on writing SQL?
Make the problem a little more complex, and the Agent's SQL cannot swell to tens of thousands of lines, far beyond the window. If the Agent cannot see the whole SQL, it cannot judge whether this SQL is right. After the window is filled, what the model sees is fragments. You cannot do a code review on fragments.
InfiniSQL lands intermediate results as named session tables. State is kept on the server by owner. Later calls only need the table name. They do not have to stuff the previous table's data or the previous long SQL back into the model. What remains in context is the name and a structure summary. The data itself does not pass through the model. Switch models once, drop a connection once, as long as it is still the same owner, those earlier tables are still there. The analysis scene is no longer tied to one conversation window.
Template compression is one example we have already recorded, not a universal law. Same rule as always: put the numbers down first. That time with GA360 daily-sharded tables, handwritten enumeration was 1,713 lines, 79,384 bytes, about 20,000 tokens. After changing to a template it was 52 lines, 1,337 bytes, about 370 tokens. That was a reproduction in a test environment, used to show: compression happens on the engine side, cleaner than generating first and then summarizing.
| Handwritten enumeration | After changing to a template | |
|---|---|---|
| Lines | 1,713 lines | 52 lines |
| Bytes | 79,384 bytes | 1,337 bytes |
| Tokens | about 20,000 | about 370 |
Figure 7: A test-environment reproduction of the GA360 daily-sharded-table task: 1,713 lines compressed to 52. This is the measured result of that task, not a universal compression ratio for InfiniSQL.
Look at this set of numbers first. 1,713 lines down to 52. About 20,000 tokens down to about 370. This is the measured result of that task, not a universal compression ratio for InfiniSQL. I cannot write it as a law that applies everywhere. But it shows one thing: if you leave the expansion work inside the engine, the model window does not have to pile up thousands of lines first and then summarize them itself.
Each tool call should also not require writing hundreds or thousands of lines of SQL. The SQL that has to be written at each step cannot be too heavy. This needs an engine, not only a smarter prompt.
After SQL blows up the window, the Agent cannot see the whole query either. If it cannot see it, there is no talking about judging right or wrong.
9. What InfiniSQL Is For: Keep the Model's Effort on the Business
InfiniSQL's top-level surface is small: load, select ... as, save, train, register, and a few more, about ten verbs. Each step is one short statement, landed as a named table. What the Agent should ask next is a business question: is this table revenue, should cash received be joined, are the filter conditions right. It should not write a 2,000-line SQL novel in the window.
Short is not only for looking good. After it is short, a person can finish reading this step. The Agent can match this step to the previous table. When something goes wrong, you know which sentence to change, instead of hunting for a missing date among thousands of lines. The engine takes over expansion, pushdown, and naming. Then the model has a chance to keep its attention on the definition.
That is also why a Data Agent cannot be finished by an LLM plus a SQL client. You have to rebuild the runtime, the language, the knowledge, and the execution engine. The language is responsible for making each step short. The runtime is responsible for keeping state on the server. Knowledge is responsible for keeping definitions for people to review. The execution engine is responsible for pushdown and Explain.
Figure 8: Three things the engine layer has to do for the Agent. What people still see is the Agentic loop. Underneath it is no longer generating one giant SQL and waiting for it to happen to be correct.
What people see is: the Agent is still doing the Agentic loop. Underneath, the way of working has already been changed. Each step is short. State is on the server. Compiled results can be read first. Definition updates must pass through a person. The model is still calling tools. The tools just no longer force it to be DBA, metric administrator, and author of a long SQL novel in the window at the same time.
What InfiniSQL is for is to keep the model's effort on the business, not drowned in SQL.
10. Closing: Being Able to Write Code Does Not Automatically Make a Data Agent
The article is already not short. I will make a simple close.
The same Agentic method. The product difficulty is not the same.
A Code Agent that can write SQL does not automatically become a Data Agent. An office Agent that can connect Word and the browser will not automatically solve definition and verification. A Data Agent that cannot accumulate Context will not get easier the longer it is used.
We built InfiniSQL so the Agent can keep its attention on the business, not drowned in SQL. The three at the product layer — asset search, definition alignment, result verifiability — plus those at the engine: exploration has to be cheap, the window cannot be blown up by SQL, each step cannot be written as a novel. Together they make a Data Agent an enterprise can use. Miss any one, and on the surface it is still "a large model calling tools." Use it, and you will know it is not the same product.
I personally think: being able to write SQL is far from having built a Data Agent. This has to be looked at from the product hard parts, not only from the loop. A Code Agent that can write SQL is a good thing. It only means the loop layer is already through. The things that are actually hard are still behind it.