Query Less. Reason More: Why Agentic AI Changes the Economics of Data Infrastructure

Traditional data infrastructure optimizes the query, however Agentic infrastructure must optimize the investigation.

This distinction may become one of the most important infrastructure changes created by AI agents.

For decades, analytical systems have largely been designed around human-paced interaction. An analyst asks a question, executes a query, reviews the results, modifies the query and perhaps runs another one.

AI agents behave much differently.

An agent can inspect a schema, retrieve metadata, sample data, formulate a query, evaluate the result, discover that something is missing, generate another query, compare competing explanations, validate its conclusion and continue down additional branches—all in response to a single request from a human.

One question can become an entire machine-generated investigation.  And every step has a cost.

The “Agentic Query Tax”

Databricks CEO Ali Ghodsi recently described the effect very simply:

“The agents are generating way more queries.”

That observation came as Databricks discussed the effect that increasing AI-agent usage is having on infrastructure consumption and margins.  This is an early indication of a much larger change.

When humans were the primary consumers of analytical infrastructure, the natural unit of measurement was often the query: How quickly did it run? How many bytes did it scan? How much compute did it consume?

But an autonomous agent can generate dozens of interactions in pursuit of a single outcome.

The economics therefore begin to shift from cost per query to something much more meaningful:  Cost per trustworthy answer. That includes more than model tokens. It may include database queries, metadata requests, scans, joins, vector searches, API calls, tool invocations and the reasoning necessary to connect them.

The next AI infrastructure battle won't simply be about tokens per dollar.  It will increasingly be about how many queries, scans and reasoning steps are required to reach a trustworthy answer.

Why Lightweight Query Engines Are Getting Attention

This emerging workload helps explain the interest in technologies such as DuckDB.  DuckDB is an embedded analytical database. Instead of requiring a separate database server for every interaction, it can execute directly within an application process and query formats such as Parquet where the data already resides.

DuckDB describes one advantage of its embedded architecture as enabling “high-speed data transfer to and from the database.”

So when querying Parquet, DuckDB can automatically push filters and projections into the scan so that only the necessary columns and relevant portions of the data are read.

This makes their model is attractive for agentic systems.  Instead of routing every exploratory request through heavyweight analytical infrastructure, some computation can potentially move closer to the data. For certain workloads, that can reduce latency, data movement and execution overhead.

This doesn't mean traditional warehouses disappear. Large-scale warehouses, lakehouses and cloud data platforms solve problems that lightweight embedded engines do not.

But it does suggest that the architecture surrounding them is likely to change.  Agents create a new premium on cheap, selective, distributed access to data.

But…there is just one problem.  Making queries cheaper doesn't necessarily mean agents need to make fewer of them.

The Bigger Problem Is Rediscovery

Consider what an agent needs to determine before it can answer a meaningful question about a complex environment.

·       Which data source is authoritative?

·       What does this identifier represent?

·       Which entities are related?

·       What happened before this event?

·       Is this behavior normal for this particular environment?

·       Have we seen it before?

·       Was it previously investigated?

·       What was the conclusion?

·       Which relationships matter to the current investigation?

If those answers aren't already represented in the data, the agent has to reconstruct them.

That requires queries. And more queries. And frequently more model reasoning to interpret the results of those queries. This creates a second economic problem beyond the agentic query tax:  the “rediscovery tax.”

That is because much of what an agent is trying to discover may already be implicitly contained within the organization's data. But if that knowledge hasn't been derived, structured and preserved, every new agentic workflow has to reconstruct it again.

The infrastructure may remember the events, but it does not necessarily remember what those events mean.  And that distinction becomes increasingly expensive when machines, not humans, are conducting investigations continuously.

Cheap Queries Don't Solve Governance Either

So here is another complication to this issue.  As agents gain direct access to data and tools, organizations have to answer questions that are considerably harder than traditional database permissions:

·       Who is this agent?

·       On whose authority is it operating?

·       What information should it be allowed to access?

·       Which tools can it invoke?

·       What did it query?

·       Why did it query it?

·       What information influenced the conclusion?

·       Can the organization reconstruct the investigation later?

These are no longer theoretical concerns. 

In February 2026, NIST published a concept paper specifically addressing software and AI-agent identity and authorization. NIST highlighted the risks of giving agents access to “diverse data sets, tools, and applications” and called attention to identification, authorization, auditing and non-repudiation for AI agents.

The major data platforms are responding as well.  Databricks' Unity AI Gateway now provides centralized controls around models, agents and MCP services, including permissions, rate limits, budgets and usage tracking. Its governance system can evaluate individual tool calls, block them, require approval and monitor call volume, errors and latency.

And that evolution is particularly revealing. 

• Because the AI infrastructure problem is no longer simply:  Can the model reach the data?

• It is fast becoming:  Can the agent access the right data, under the right authority, with enough context to reason correctly, without generating unnecessary cost and risk along the way?

From Query Efficiency to Knowledge Efficiency

This leads to a different way of thinking about AI infrastructure.  There are at least three layers to optimize.

1.       Execution efficiency asks: How quickly and economically can the agent retrieve or analyze data?

Technologies such as DuckDB, serverless query engines, pushdown processing and distributed compute can help here.

2.       Governance efficiency asks: Who can access the information, which actions are permitted and how is agent activity controlled and observed?

Identity platforms, catalogs, AI gateways and policy systems are rapidly developing to address this layer.

But there is a third layer that deserves equal attention:

3.       Knowledge efficiency.

Knowledge efficiency asks:  “How much work does the agent have to perform before it understands enough about the environment to reason?”

This is where the underlying representation of the data becomes critical.  If every agent begins with raw events, tables and logs, then each investigation must reconstruct entities, relationships, temporal behavior, historical context and prior findings.

If those elements have already been derived and preserved as durable knowledge, the agent can begin much further along the reasoning process.  That changes both accuracy and economics.

The Cognitive Data Layer

This is the problem Knowledge Grid's Cognitive Data Layer is designed to address.

Rather than waiting for an agent to repeatedly reconstruct context from raw telemetry, the Cognitive Data Layer transforms data as it enters the environment—preserving structure, relationships, temporal behavior, features, anomalies and environmental context that can be reused by subsequent analytics and AI workflows.

The objective isn't to replace the warehouse, the lakehouse, DuckDB or the AI model.

It is to give those systems—and particularly AI agents—a better representation of the environment from which to reason.

That creates a different model:

Raw Data → Cognitive Data Layer → Context → Durable Knowledge → AI & Agents

The implications become even more significant when knowledge produced during one investigation can be persisted and made available to the next. 

Instead of every agent starting from zero, the environment begins to remember.

·       A prior finding can become context.

·       A prior verdict can influence the next investigation.

·       Behavioral baselines can persist.

·       Entity relationships don't have to be reconstructed repeatedly.

The system moves from repeated discovery toward accumulated knowledge.

The Cheapest Query May Be the One You Never Have to Run

Much of the AI infrastructure conversation today is focused appropriately on faster models, smaller models, token efficiency, inference costs and more efficient database engines.

All of those matter.  But there is another optimization opportunity hiding underneath them, which is reduce the amount of work required to reason in the first place.  If an agent needs twenty queries to reconstruct something the environment could already know, making those twenty queries 30% cheaper is useful.  And giving the agent the answer to that contextual question before it begins may be considerably more valuable.

That is why we believe agentic infrastructure needs a different optimization target.  Traditional infrastructure optimized the query, but Agentic infrastructure must optimize the investigation.

The winners in the next generation of AI infrastructure may not simply be the systems capable of processing the greatest number of queries.  They may be the systems that enable agents to reach reliable conclusions while making fewer of them.

The next generation of Agent architecture may soon be: Query less. Reason more.