Agentic Search: The next frontier

Traditional search systems

For the last couple of decades, search systems have operated around a simple interaction model. A user issues a query. The system retrieves results. Ranking algorithms determine which results are most relevant.

This model shaped early web search, enterprise search systems, observability tools, and many internal data platforms. Whether the interface was a search box, a dashboard, or a log index, the underlying assumption was the same: the user provides a query, and the system retrieves relevant information.

But the query has never actually been the starting point. Behind every query is something else: a task the user is trying to complete.

• A developer searching for an error message is trying to fix a failing service.
• A product manager querying event data is trying to understand a change in user behavior.
• An analyst filtering transaction records is trying to evaluate the impact of a promotion.

The query is not the goal. It is simply a step toward completing the task. Search systems have always operated on queries, but queries were only proxies for task intent.

Ranking was an attempt to infer intent

Because traditional search systems could only see the query itself, they relied on ranking and relevance signals to approximate what the user was actually trying to do. Term frequency, document structure, click behavior, and other ranking features all served the same purpose: estimating which results were most likely to help the user accomplish their task.

This worked remarkably well for many use cases. A query like database connection timeout error might surface documentation, forum discussions, or log messages that help the developer diagnose the problem. But the system never understood the task directly — it only inferred intent indirectly through the query and the behavior of previous users. As a result, users often ran multiple queries in sequence, gradually refining their search until they found what they needed.

Tasks naturally produce multiple queries

Consider a simple product question: *"Which users who tried the new onboarding flow eventually upgraded?"*

The user asking this question is not thinking about queries. They are thinking about the outcome they want to understand. To answer the question, the system might need to:

• Identify users who triggered the onboarding event.
• Retrieve subscription upgrade records.
• Join those datasets.
• Apply a time window.
• Compute the final set of users.

Each step corresponds to a query over a dataset. Taken together, these queries complete the task. The same pattern appears across many domains — business, support, operational. From the user's perspective, these are single questions. From the system's perspective, they require multiple queries across different datasets.

Data systems reflect different data models

Part of the reason tasks produce multiple queries is that modern systems store information in specialized systems.

• Relational databases manage structured records such as users, orders, and subscriptions.
• Search systems index documents, logs, and messages.
• Time-series systems store metrics.
• Analytics engines aggregate large event streams.

Each system is optimized for a particular data model. But the tasks users care about rarely align neatly with those boundaries. For example: *"Which customers contacted support after installing version 5.2 of the mobile app?"*

Answering this might require:

1. Identifying users who installed version 5.2.
2. Retrieving support tickets associated with those users.
3. Filtering tickets created after installation.

Those steps may involve multiple datasets and different query systems. Yet from the user's perspective, it is still a single task. The complexity arises because the task spans several data systems.

Natural language changes the interface

For most of the history of computing, users had to translate their tasks into queries manually. That translation step meant the system only saw the query — not the intent behind it.

Natural language interfaces change this dynamic. Instead of writing SQL or navigating dashboards, users can express what they want to know directly: *"Did the holiday promotion increase repeat purchases?"* or *"Which customers contacted support after installing version 5.2?"*

These inputs describe the task itself, not the queries required to answer it. Once task intent becomes visible, the system can reason about the steps required to complete it.

Tasks decompose into query graphs

A task rarely corresponds to a single query. Instead it decomposes into a set of smaller operations. Consider: *"Did the pricing change affect churn for enterprise customers?"*

To answer this, a system might need to:

• Retrieve enterprise customer accounts.
• Retrieve subscription cancellations.
• Identify the date of the pricing change.
• Compute churn rates before and after that date.
• Compare the results.

Each step corresponds to a query over a dataset. Some queries depend on earlier results. Others can run independently. The final answer emerges from combining their outputs. What appears to be a single question from the user's perspective often corresponds to a structured set of queries across multiple data systems.

From query interfaces to task interfaces

Traditional search systems operate primarily at the level of queries. A user provides a query. The system retrieves results. Ranking algorithms attempt to infer the user's underlying intent. But when systems can observe task intent directly, the interaction changes. Instead of asking users to construct queries, the system can begin with the task itself and determine the queries required to complete it.

This moves search systems one level higher in the stack. Rather than retrieving documents in response to queries, they translate task intent into graphs of queries across data systems.

The first step: RAG

When large language models first began interacting with external data, the most common architecture was retrieval-augmented generation (RAG). In a typical RAG system, the model issues a query, a retrieval system fetches relevant documents — often using a vector database — and those documents are inserted into the model's prompt.

While RAG can support many document-oriented use cases, production deployments typically require substantial infrastructure — embedding pipelines, chunking strategies, retrieval tuning, and prompt orchestration — to achieve reliable results. The issue is that RAG systems still inherit a core assumption from traditional search:

query → retrieve context → generate answer

The retrieved documents are treated as the context from which the model constructs a response. This works when the answer is contained within those documents. But many tasks do not work that way. Questions like:

• Which users who tried the new onboarding flow eventually upgraded?
• Did the pricing change affect churn for enterprise customers?

cannot be answered by retrieving documents alone. They require queries over structured data, correlations across datasets, and aggregations over records.

This limitation becomes acute in regulated environments. For multi-hop queries across financial or clinical data, standard RAG pipelines produce hallucination rates that are fundamentally incompatible with SOC 2 Type II data residency requirements, or environments where PII must never leak into model weights. When a compliance officer asks *"Show me every trade that triggered a threshold alert last quarter,"* the system cannot afford to approximate — it must produce a verifiable, auditable answer with precise citation lineage.

In these cases, retrieval is only one step in the process. The system must determine what queries need to be run and how their results should be combined. Once tasks are expressed at that level, the system is no longer simply retrieving documents — it is coordinating a set of queries required to complete the task.

The next step: tasks

Search originally emerged as a way to navigate documents. Over time it expanded into a general mechanism for retrieving information. The next step is now beginning to appear.

Instead of expecting users to translate tasks into queries themselves, search systems can start with task intent, determine the queries required to complete that task, and combine the results. Queries become components within a larger task graph. The answer emerges from the interaction of those queries rather than from retrieving a single document.

As this shift continues, the boundaries between search systems, analytics systems, and data infrastructure will become less distinct. Search will still retrieve information. But it will increasingly help translate intent into the coordinated queries needed to complete a task.

Agentic search: the new frontier

This architectural pattern is increasingly described as agentic search. Agentic search systems begin with task intent rather than a predefined query. The system determines the queries required to complete the task, runs them across the relevant datasets, and combines the results.

Retrieval remains an important capability, but it becomes just one step within a larger workflow. The system must also support:

• Queries across structured and unstructured data.
• Correlations across datasets.
• Aggregations and statistical operations.
• Tasks decomposed into sub-query graphs.
• Coordination across multiple data systems.

Agents are one implementation of this pattern, but the architectural shift is broader. Consider what a query plan looks like when the system reasons at the task level:

task: "Which customers exceeded their credit limit after the rate change?"

plan:
  step_1: query accounts WHERE type = 'enterprise'
  step_2: query rate_changes WHERE effective_date > '2024-01-01'
  step_3: join step_1, step_2 ON account_id
  step_4: filter WHERE current_balance > credit_limit
  step_5: return results WITH audit_trail, citation_sources

Every step is logged. Every data access is scoped to the caller's permissions. The output includes not just the answer, but a verifiable record of how the system arrived at it.

The key change is that search systems are moving from query interfaces to task interfaces. The search systems of the future will be built around this.