Agentic Query Patterns vs Human Query Patterns

The gap between how agents query data and how humans query it is now measurable, structural, and widening faster than most data infrastructure was designed to accommodate. That gap is not a curiosity. It determines whether a data layer serves both kinds of consumers safely, or fails one of them outright.

How agents actually query data, and why it differs from how humans do

MotherDuck's September 2026 analysis of query history across human and agent users found agents running many times more queries than humans in a single recent month, with the gap roughly doubling each month over the prior three months: 6x, then 16x, then 29x. Agents overtook humans as the dominant query source as recently as February of that year. The average organization now has twice as many agents as human users, and agents are the dominant consumers of the data platform.

The behavioral differences extend beyond raw volume. The median delay between queries is far shorter for agents than for humans, who pause to think and refine their approach. A human query is often vague, exploratory, and context-dependent, issued in pursuit of an answer to be discovered. An agent query is precise, structured, and action-oriented, issued to complete a task. Agents fire many small experimental queries to confirm assumptions and acquire metadata, which lowers the median query size while raising concurrency. Humans tend toward fewer, larger, more deliberate requests.

The caching implications follow from this asymmetry. Within sessions, agents repeat exact queries far less often than humans do, a finding from academic research rather than from MotherDuck's own data. That undermines traditional exact-match caching strategies, which depend on the recurrence of identical requests. What agents do repeat is their examination of the same underlying data across many differently phrased queries, a pattern that rewards a different kind of optimization altogether.

Why infrastructure optimized for human query patterns breaks under agentic workloads

These behavioral differences translate into specific failure modes. Agents fire queries in rapid bursts separated by periods of quiet. A system scaled for burst concurrency sits idle and expensive when the bursts stop. A system scaled down for quiet periods cannot absorb the burst when it arrives. The infrastructure was sized for human-paced use, and agentic workloads punish that sizing assumption continuously.

The small, highly concurrent queries agents depend on are the sharpest point of the mismatch. An agent checking schema, listing data types, or confirming a join has no need for a full compute cluster, yet a latency floor where even trivial queries take seconds makes those queries useless. Stateful connection architectures compound the problem. Under high concurrency, long-lived session objects prolong garbage collection and produce latency spikes at the tail. Every agent request that holds a stateful connection stays open through the quiet period after it, and it keeps using capacity while adding nothing.

The caching problem is equally asymmetric. Query-level caching yields less benefit for agents because exact queries recur so rarely. But data warmth, the practice of keeping hot data pre-loaded, becomes more valuable, because agents keep looking at the same underlying data in many differently phrased queries. A data layer that can sync the entire catalog locally makes the exploratory, metadata-heavy queries agents depend on instant and cheap, rather than forcing a round-trip to a remote engine for each one.

The deeper problem: agents querying raw tables produces divergent metrics with no arbitrator

Performance failures are visible and diagnosable. The correctness failure that follows is quieter and more consequential: when agents query raw tables without a governed semantic layer, the same business metric can be calculated in as many ways as there are agents querying it, and there is no mechanism to determine which answer is right. Three agents independently querying for Monthly Recurring Revenue will each write different SQL and return different numbers. No one can tell which one leadership should act on.

The failure is infrastructural, not intellectual. The contract for what MRR means was never made explicit anywhere the agents could access it, so each agent reconstructs its own interpretation. Auto-generating metric definitions from raw tables and query logs does not solve this. It reproduces the ambiguity rather than removing it, because the ambiguity lives in the raw data model, not in the agent's ability to read it.

The validation problem has no human equivalent. When human analysts produce a wrong answer, it surfaces through review: someone downstream checks the number against intuition or a known benchmark. When agents produce answers at speed and volume, that review loop is missing by design. A bad metric definition propagates through every automated report, every downstream agent decision, and every board-facing summary before anyone notices. Research from UC Berkeley and Stanford identifies the related persistence problem: even the strongest agents must repeatedly re-acquire context about their environment, schema, join paths, data semantics, because that knowledge is external to the model and changes as data changes.

What persistent semantic context is and why it is the enduring infrastructure requirement

The UC Berkeley and Stanford paper argues that as model reasoning capabilities improve, the bottlenecks that remain are not failures of reasoning but failures of knowledge about a particular data environment. That knowledge is external to the model, changes as data changes, and is wastefully re-derived on every query. The paper calls this persistent semantic context and frames it as a first-class system abstraction that future data infrastructure must natively serve, not a bolt-on layer but a core design requirement.

The most durable infrastructure investment for agentic data access is therefore not a faster query engine or smarter caching. It is a stable, machine-readable representation of what the data means, maintained outside any single agent session. Even simple, agent-authored context files written offline from historical traces and data access significantly improve accuracy and reduce per-task exploration. The benefit is real and measurable even before sophisticated semantic infrastructure is in place.

The semantic layer is the mechanism that makes metric definitions stable across both human and agent consumers. It provides one central place where MRR, CAC, churn, and gross margin are defined. Update a calculation once, and every consumer, whether a human dashboard, an automated report, or an agent query, gets the same answer. An agent that receives semantic context alongside query access understands the analytical contract it is operating under. It can retrieve a metric definition, confirm allowed dimensions, run a governed query, and receive a response with provenance, rather than guessing at what the raw tables mean.

How MCP makes a governed semantic layer accessible to agents without touching production

The Model Context Protocol gives agents a standard way to consume governed data. Its July 2026 revision to a stateless request/response model directly addresses the concurrency and session-management failures that agentic workloads expose in stateful infrastructure. The University of Luxembourg survey on the Web of Agents places the November 2024 MCP launch and subsequent specification revisions within a multi-decade effort to make agent-to-data access reliable and interoperable.

The July 2026 specification revision made MCP stateless at the protocol layer, transforming from a bidirectional stateful protocol into a request/response stateless protocol. That change solves the session-management overhead that agentic burst patterns create. A remote MCP server that previously required sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer. Stateless architecture makes every request object short-lived and immediately eligible for garbage collection, eliminating the p99 latency spikes that stateful connections produce under concurrency.

Stateless at the protocol layer does not mean context-free. Identity, permissions, approved datasets, and audit correlation must still be carried in signed tokens, request metadata, and durable logs. An MCP server that becomes a thin proxy loses accountability along with state. A well-governed MCP analytics server exposes semantic resources and query tools together. The agent retrieves a metric contract, asks for allowed dimensions, runs a governed query over pre-modeled data, and receives a response with provenance, never touching the production database directly.

Dreambase takes this approach by pre-modeling datasets and serving them via MCP and API, so agents never touch production databases and avoid the latency floor and connection overhead that plague raw-table query patterns under agentic load. The separation matters especially for Supabase teams. Every Supabase project exposes a standard Postgres endpoint that application traffic depends on. An agent running analytical queries against that endpoint competes for connections, can bypass Row Level Security by accident, and can trigger full table scans that degrade production performance.

What Supabase teams get wrong when agents start querying their Postgres database

Supabase's Postgres endpoint is designed for application traffic, and the failure modes agents trigger there are the same ones that surface across production deployments at scale: missing indexes, RLS bypasses, table locks, and connection pool exhaustion. Supabase released Agent Skills for Postgres Best Practices, 30 rules across 8 categories, to close the gap between what agents generate and what production Postgres requires. The most recurrent failure modes across Supabase deployments are missing indexes on foreign keys, queries that bypass Row Level Security by accident, migrations that lock tables in production, connection pool exhaustion from poorly managed clients, and full table scans hidden behind ORMs. An agent generating SQL against a Supabase database without this context might create a query that causes a full table scan, suggest an index that slows writes, or miss RLS entirely. Each of these is a correctness or safety failure, not just a performance one.

Supabase articulates a design principle of separating capability from correctness. The MCP server gives agents the ability to work with the database. Best practices teach them to do it correctly. The MCP server is the steering wheel, the best practices are the driving lessons. But best practices alone do not solve the production safety problem. They reduce the probability of a bad query. They do not eliminate the consequence when a bad query reaches production at agent volume and tempo. The structural answer is not to make agents better at querying production. It is to give agents a separate, governed data surface so production is never in the blast radius.

Building a single source of truth that both humans and agents can trust

The goal is not separate infrastructure for agents and humans. It is one governed data layer with pre-defined metrics that both consume from the same source, so the numbers are identical regardless of who or what is asking. Without a single source of truth, metric definition drift is what you get. One engineer writes revenue one way, another writes it differently, and the discrepancy surfaces only when an investor asks for audited numbers.

The prescription from practitioners is a small set of actionable KPIs, for most B2B SaaS teams those are CAC, LTV, monthly churn, ARR, and gross margin, each with a single owner who is the final arbiter of its definition. Without a named owner, drift returns within weeks regardless of tooling. The tooling enforces the definition, but the definition requires a human decision first.

The semantic layer operationalizes that decision. Complex calculations are defined in one central place, queryable by human dashboards and agents alike, so updating a calculation once propagates everywhere. When sales, finance, and product each maintain their own version of ARR, the executive team argues about numbers instead of decisions. The governed layer eliminates that argument by making the calculation authoritative and shared.

Dreambase implements this pattern for Supabase teams specifically: pre-modeled metrics calculated from Postgres and connected external data sources, stored as governed Parquet datasets, queryable via DuckDB at low cost, and exposed through a single MCP server. There is no ETL pipeline, no separate warehouse, and no data team required. Agents querying that MCP server get the same metric a human sees in a dashboard: the same definition, the same calculation, the same provenance. Metrics are calculated ahead of time and pushed to where people work, whether inbox, Slack, or wherever the team operates, rather than pulled on demand by whoever remembers to check. The agent and the founder are always working from the same current number.

Designing for both: the practical checklist for a data layer that serves humans and agents without conflict

A data layer that serves both humans and agents safely is not twice the infrastructure. It is one governed layer designed around four properties: semantic stability, production isolation, concurrency tolerance, and push delivery. Semantic stability means every metric has one definition, stored in one place, versioned, and accessible to any consumer without requiring the consumer to interpret raw schema. This is a governance decision before it is a technical one: name an owner, write the definition, make it machine-readable. The tooling enforces it. The team decides it.

Production isolation means agents never hold a connection to the production database. The governed data layer, pre-calculated, Parquet-serialized, queryable via a stateless interface, is the only surface agents touch. This eliminates the RLS bypass, connection pool exhaustion, and full table scan risks that agent-volume querying creates on a shared Postgres endpoint.

Concurrency tolerance means the query interface for agents must handle burst concurrency without stateful session overhead. A stateless MCP server behind a round-robin load balancer is the architecture the July 2026 MCP specification enables. Small experimental queries such as schema checks, metadata reads, and dimension lookups must be fast and cheap. If the latency floor is high, agents burn tokens and time on queries that should be instant.

Push delivery means metrics should arrive where people work on a schedule, not wait for whoever remembers to query. For human teammates this means inbox or Slack delivery of the numbers that matter. For agents it means the governed dataset is refreshed and available before the agent needs it, not computed on demand under query pressure. The UC Berkeley and Stanford research frames persistent semantic context as a first-class system abstraction, not a nice-to-have layer but the core infrastructure requirement for data agents working at scale. The four properties are the practical implementation of that abstraction for a Supabase team that needs it today.