Agents don’t write code like humans do. They grep around endlessly, use pip instead of uv (sad), and strain our most important systems. Agents in data use the same trusty SQL we do, but maybe they wield it differently. How DISTINCT are they from humans, really? Once we know, what should we do about it?
We wanted to find out by analyzing a slice of query history across human and agent users. Here’s what we uncovered. Our systems can’t afford to stay the same.
On methodology, a quick note: here we’re comparing queries written during a two week period in the MotherDuck UI (“human”) versus those written through the MCP server (“agent”). This is the most consistent way to segment with a high degree of confidence between human and robot authorship.
The most visible difference between agentic query patterns and humans is just the sheer volume of queries. Agents ran 29 times more queries than humans in the last month. By itself that is quite astonishing. If you look at the chart though, the trend shows no signs of slowing down. Each month in the last three, the gap has roughly doubled: 6x, 16x, 29x. If that pattern holds, in 2 more months agents will be issuing a full 2 orders of magnitude more queries than are run in the UI manually (the “old fashioned way” - it feels crazy to say that!).
Another interesting observation is that as recently as January of this year, humans did more of the querying. Then agentic queries overtook manual queries in February and haven’t looked back.
Efficient agent ergonomics are no longer optional. The accuracy of robot-authored queries matters tremendously. The importance of investing in the context layer is increasing dramatically month on month. Context can both boost accuracy and reduce how many tokens it takes to reach the right answer.
Agents are now the dominant consumers of the data platform.
Self service analytics has long been a holy grail in data. Some have quested after it for many years (I count myself among them, having helped build a self-service platform!). Others consider it a myth, too high a risk, or at best an inefficient approach.
Our data shows twice as many agents as human users on average per organization. At the extremes there is an even larger difference. The organization with the most agent users has 7 times as many agents as the org with the most human users has humans! More and more people are learning about their data by using agents to interpret it.
As a self-service-maximalist, this is music to my ears! However, I am not naive. I have seen plenty of data misinterpretation and have certainly been guilty of it myself more than a few times.
New types of folks across your company are asking data questions, or rather, new agents from across your company are asking questions on their behalf. The context layer helps here too, but as adoption increases across new teams, it needs to be as automatic as possible. People are connecting up agents on their own and just firing away questions independent of any central training program.
Like it or not, agents have accelerated data democratization.
The gap between queries is far shorter for agents than humans. The median delay between queries for agents is 4 seconds, but 60 seconds for humans. This makes agentic workloads far burstier than their human equivalents. I see this myself as well: I am far better at building one query at a time, but with a few subagents, agents can be highly parallel.
This has significant system implications. Your data platform has to be ready to handle higher concurrency than before, but is also more likely to have periods of quiet after each burst. Can your system scale down in between those bursts of queries, or do you have a cluster that is running even when the agent is “Razzmatazzing”? If you are scaling up to handle that concurrency, those idle times get expensive quickly.
However, the opposite extreme has high costs as well. Those queries run in short succession often examine the same data. A completely fresh compute environment for each query sacrifices all the benefits of pre-warmed data. Keeping your data warm can boost performance and lower costs.
Agents fire off queries in rapid bursts that can be taxing to rigidly configured data infrastructure.
We’ve seen this behavior in coding. Agents like to do small experiments to confirm their assumptions. Our dataset shows this behavior extends to data analysis. The median query by an agent only scans 7000 rows of data vs. 200,000 by humans. Agents issue large requests too, but they issue so many small ones that it lowers the median. Similarly, many agent queries are acquiring context and metadata by reading table schemas.
Is your data system prepared for many small, highly concurrent queries? Or is there a latency floor where even the smallest queries take multiple seconds? Agents love to experiment, and the faster they can do that, the quicker your company’s data questions get answered.
Using a full compute cluster just to list the data types in a table is overkill. Does your data platform have the ability to cache data locally? Then when an agent asks 3 specific questions about the same dataset, it will only be pulled once. If the entire catalog could be synced locally (it can!) then exploratory queries become instant and free.
The small experimental queries that agents depend on need to be both fast and cost efficient.
Taken together, these agentic workload patterns should change how we design and implement our data platforms.
Organizing the context of your data is an investment with far greater returns than ever before. Not only does context dramatically increase agent query accuracy, it also reduces costs (55% savings in those same benchmarks) by requiring fewer tokens to complete the same analysis.
Having a well constructed context layer also makes it far easier for all teams (executive, operational, and everything in between) to begin uncovering data insights on their own. This can lead to tremendous value and far better decisions across the company. Agents open the door, but inside will they find a dusty antique shop or an orderly library?
Small, highly concurrent query patterns are the norm with agents. Those patterns are also burstier than human ones and require faster scaling up and scaling down. Having a data platform that can handle that very different load shape in a performant and cost effective manner will become more and more critical.
Finally, how can we take better advantage of compute and caching where agents are running? Any round trips that are saved on background schema research or follow up questions on similar datasets directly translate into performance and cost wins.
We’ve been architecting MotherDuck specifically for the agentic reality we all live in. Give us a test - there’s nothing quite like benchmarking with your own data and workload.
2026/08/28 - Alex Monahan
If your laptop has 16GB of RAM, your agent can write SQL locally for free with Qwen3.8 27B. On the DABstep SQL benchmark, Qwen beat GPT 5.6 Luna and cost under 50 cents in electricity, over 17x less. Add DuckDB and you have a data analyst that runs on your own machine. This post covers the benchmark results and walks through the setup, including which quantized model to download for your laptop.
2026/09/02 - Simon Späti
A primer on the context layer, semantic layer, and ontology: what each term means, how they fit together, and why AI agents still need a human to decide what's true.
