Agentic vs Human Query Patterns in Production Analytics

Agents don't just run more queries against production databases than humans do. They run queries in a different shape entirely, and that shape is what breaks systems built around how people ask questions.

How Agents Query Data

Start with the number, because it's the one everyone quotes first: agents ran 29 times more queries than humans in the most recent month, and that gap has roughly doubled each month. It's a striking trajectory.

Volume alone is a capacity problem. You can throw more compute at a capacity problem. Agents don't query the way humans query, and no amount of added capacity fixes a mismatch in behavior.

A human sits down at a query editor with an answer already half-formed in their head. They know roughly what they're looking for, write SQL to go get it, and read the result. An agent does something closer to the opposite. It opens a session with a task, not an answer, and uses a string of small queries to figure out what it even needs to ask. Scoop Analytics' 2026 guide describes this as planning and executing multi-step investigations without a human driving each click, and that investigation structure, the back-and-forth of probing before concluding, is the behavior itself, not just a byproduct of it.

That's the real divide. Humans query with a formed question. Agents query to form one. Everything that follows in this piece traces back to two specific habits that fall out of that difference: agents inspect a database's structure before they touch it, and agents query in short, intense bursts rather than steady streams. Both patterns are reasonable things for an agent to do. Neither is something most production analytics systems were built to absorb cheaply.

The schema-first behavior that production databases are not designed to serve cheaply

Before an agent writes a single analytical query, it checks its surroundings. That checking is itself a workload, and most analytics infrastructure treats it as background noise rather than something to design for.

The typical tool-use sequence for a database agent starts with calls like sql_db_list_tables and sql_db_schema, plus a few sample-row fetches, all before any real SQL gets written. This isn't the agent being careless or inefficient. It's correct behavior for a system that can't assume it already knows what a table looks like today. The MCP-mediated workflow that underlies a lot of this activity formalizes the sequence outright: schema exploration, then query generation, then remote execution, then interpreting what came back. For every query an agent runs to actually answer something, it has likely run several more just to find out what's answerable.

Column-oriented databases built around sparse indexing can handle this kind of probing well, but only if the schema is built with that probing in mind. These systems index blocks of rows rather than every single row, which keeps the index small enough to live in memory even for huge tables. Memory-resident lookups are fast and cheap. The moment an inspection query has to reach past memory into disk, or worse, into remote object storage, the cost changes completely.

The sorting key chosen for a table decides whether a quick probe can skip most of the data or has to scan the whole thing. That single decision, more than almost anything else in schema design, decides whether agent-facing tables stay fast under this kind of traffic.

Partitioning compounds the effect in a very concrete way. Partition a table by time interval, month or week, and the system can skip entire chunks of data when an agent is poking around in recent activity. That's where most probes land. The schema decision made at table-creation time quietly decides, months later, whether an agent's first ten queries take milliseconds or seconds.

Most teams never catch this gap, because they benchmark the big analytical queries and never benchmark the small inspection ones.

Burst-and-probe concurrency and the latency floor problem

Schema inspection is one half of the structural difference. Timing is the other structural difference. Agents don't spread their queries out evenly across a session the way people do. They fire them in tight clusters and then go quiet.

The numbers make the shape plain. The median gap between one agent query and the next is 4 seconds, compared to a full minute between human queries, a sizable difference in pacing.

The latency floor is visible in the fixed overhead every query carries. Every query, no matter how small, carries some fixed overhead: a cold compute start, a round trip through storage, a connection handshake. A system with a multi-second minimum response time doesn't just slow down big scans. It throttles the small, cheap probes that agents depend on most to keep their reasoning loop moving.

Architectures that route every query through S3 pay this penalty on every single probe, not just on large analytical queries, because the per-request cost structure of object storage makes frequent small reads expensive both in latency and in dollars, which is the core problem that architectures keeping hot analytics data in a distributed cache mesh rather than routing queries through S3 were built around.

The flip side of the burst pattern is that the quiet periods between bursts are real and long. MotherDuck's data shows bursts followed by genuine idle stretches, meaning agents aren't running continuously even when their total query count looks enormous. A cluster sized to handle peak agent concurrency sits mostly idle the rest of the time, and a system that can't scale down during those gaps turns bursty agent traffic into a cost that never really drops. Keeping frequently touched data in a local cache, NVMe storage rather than cold object storage, lets a system answer instantly the moment the next burst starts, without keeping full compute capacity running through the silence.

That caching approach pays off even within a single burst. When an agent asks several related questions about the same dataset back to back, each question would normally re-read the same underlying data from scratch. With a local cache, the first probe pulls from storage and every probe after it in that burst reads from memory instead, turning what would have been N separate storage costs into one.

Multi-step reasoning and query volume

None of this, the schema checking or the bursty probing, is a flaw an agent should be trained out of. It's the mechanism by which agentic analytics actually works, and trying to engineer it away removes the thing that makes the agent useful in the first place.

Knowi's 2026 comparison of agentic business intelligence tools lays out what real agentic behavior requires: multi-step reasoning, where the system runs a sequence like query, detect an anomaly, cross-reference it, format a result, rather than handing back a single-pass answer; persistent context, where the agent keeps the data model and user preferences across interactions; and proactive delivery. Multi-step reasoning, by definition, needs intermediate queries. The result of step one becomes the filter for step two, and so on down the chain. One question a person asks out loud can quietly expand into a long sequence of queries the user never sees and the database still has to serve at full speed.

Scoop Analytics puts a number on how far that expansion can go: a single analytical run can involve hundreds of discrete agent instructions, each one a small directed action, with the final structured output built step by step rather than produced in one shot. A team counting "queries per user request" will badly undercount what's actually hitting the database once an agent is doing the asking.

Persistent context makes the compounding worse over time, not better. An agent that remembers the data model and a user's preferences across sessions doesn't settle into fewer, more efficient queries as it learns. It uses that accumulated context to dig deeper into whatever it's already found interesting. Each new session can build on the last, so investigation depth keeps growing rather than leveling off.

So the honest framing here: this behavior cannot be optimized away by asking agents to query less. The schema checks and the burst probing are how multi-step reasoning happens. The only real lever left is building infrastructure that can absorb the pattern instead of fighting it.

Where production analytics infrastructure breaks under these patterns

Infrastructure built for human query patterns tends to fail in three specific, foreseeable ways once agents are the ones doing the querying: concurrency limits, cold-path latency, and cost models that move in the wrong direction.

Concurrency limits are usually set for some expected number of simultaneous human sessions. They are not set for the fan-out of parallel sub-queries a single agent task can generate in a few seconds. When those limits get hit, queries start queuing, and a queued probe stuck in the middle of a multi-step reasoning chain doesn't just delay itself. It stalls the entire chain behind it.

Cold-path latency tells a similar story. A human analyst submits a query and waits a couple of seconds without noticing. An agent running a 20-step investigation multiplies that same wait across every one of those steps, so performance that felt perfectly fine for a person produces an unacceptably slow end-to-end result for an agent working through a chain of dependent queries. Architectures that route every query, including routine schema lookups that should return almost instantly, through remote object storage bake that cold-path delay into the very first step of the agent's process.

Cost is where the mismatch gets expensive fastest. Object storage pricing that charges per PUT, GET, and LIST operation was designed around how storage gets accessed in general, not around the frequency with which agents probe data in small, repeated reads. At the query volumes MotherDuck is documenting, those per-request charges start compounding faster than the charges tied to data volume, which makes pricing that looks simple on paper turn out to be misleading once agentic traffic is the dominant load. Per-query pricing models carry the same problem from a different angle: every intermediate probe in an agent's reasoning chain costs the same as the final answer it's building toward, which directly penalizes the probe-and-refine behavior the whole approach depends on.

Most teams won't see any of this coming until it's already a problem. Monitoring systems built to track query counts by human session don't surface agent-driven load increases until performance has already degraded. And the shift isn't theoretical. A cloud analytics provider's trajectory, crossing a significant revenue milestone and announcing new agent features at an industry event in 2026, is a sign that production teams are building for agentic workloads now, not preparing for some future version of them.

The write-access and security surface that read-only assumptions leave exposed

Everything so far has assumed agents are reading data, not changing it. That assumption no longer holds, and it will become someone's incident report if it isn't taken seriously now.

MotherDuck has shipped a query_rw tool for its remote MCP server that lets agents run INSERT, UPDATE, and DELETE statements, create tables, and modify schemas, not just run SELECT queries. This is live in production today. The same MCP interface that lets an agent explore a schema and fire off small probes can, if it's permissioned to, go on to modify the very data it was just exploring. An analytics pipeline built on the assumption that agents only look at data and never touch it is now working from an assumption that's already out of date, and the autonomous execution pattern that makes an agent genuinely useful is the same pattern that widens what can go wrong when it isn't contained by design rather than by instruction.

Telling an agent in its system prompt not to delete anything isn't a real safeguard once that agent has write privileges. The PARALLAX paper makes the underlying argument: prompt-level guardrails run on the same computational substrate as the threats they're meant to stop, because instructions and adversarial input both pass through the same attention mechanism, with no architectural wall separating trusted commands from untrusted data. A prompt injection that compromises an agent doesn't have to defeat a safety instruction sitting beside it in the same context. It just has to be convincing enough to get treated as a legitimate instruction, because nothing in the architecture distinguishes the two.

What does hold up is permissioning enforced outside the agent's own reasoning: scoped credentials, read-only roles where write access isn't actually needed, and database-level controls that don't rely on the agent choosing to behave. An agent with query_rw access and no architectural boundary around it is one convincing prompt away from a schema change nobody approved. The query patterns described throughout this piece, the schema checks, the bursts, the long reasoning chains, were never the risk by themselves. The risk starts the moment an agent that queries like this is also allowed to write, and the only real safeguard sits in the architecture, not in whatever the agent has been told to do.