Skip to main content
search

With OpenSearch 3.3, we are excited to introduce agentic search, a major evolution in the way you interact with your data. Agentic search lets you explore your data using a natural language interface, without needing to construct query domain-specific language (DSL) queries manually.

Agentic search core concepts

Agentic search operates using two key components: agents and tools.

Agents

An agent is a system powered by a large language model (LLM) that can interpret your request, plan the necessary steps, and decide which tools to use. It understands intent, breaks tasks into actions, and adapts based on intermediate results.

Tools

Tools are capabilities the agent can invoke, such as listing indexes or performing search. The agent selects the tools to use based on the query intent. For a full list of built-in tools, see Tools.

How agentic search works

Agentic search is powered by an intelligent, agent-driven system that interprets your natural language queries, selects the appropriate tools, and generates optimized search strategies automatically. You can run agentic search using the agentic query type, allowing you to explore your data without needing to know query syntax or internal data structures.

For example, you can ask questions such as:

  • “Find red cars under $30,000.”
  • “List last quarter’s sales trends for shoes.”
  • “What are the top-performing products in the electronics category?”

The agent then carries out the necessary steps—such as identifying relevant indexes, planning the query, or gathering supplemental information—and returns results aligned with your intent. It also provides a detailed explanation of the tools and decisions involved.

OpenSearch 3.3 introduces several key capabilities that enable this natural, conversational interaction with your data while providing advanced orchestration across systems.

Conversational search experience

Maintain context across queries using memory IDs, enabling seamless multi-turn interactions that build on previous queries. The agent keeps track of context and updates the query plan accordingly, so you can refine or follow up on queries naturally without repeating details. For more information, see Using conversational agents for agentic search.

Built-in tools

Agentic search uses built-in tools to retrieve, understand, and enrich information. The ListIndexTool identifies which indexes exist in your cluster, while the IndexMappingTool helps the agent understand their structure and fields. The QueryPlanningTool generates optimized queries from your natural language questions. When a query can’t be fully answered using local data, the WebSearchTool retrieves relevant external information.

For example, you can ask the following questions:

  • “Show me shoes similar to Ronaldo’s favorite.”
  • “What items do I need to play golf?”

If the agent can’t find enough information in your indexes, it performs a web search to gather additional context and then compares that information against your local data to return the most relevant matches.

Custom search templates

As an advanced user, you can define custom search templates that capture known query strategies or domain-specific logic. The agent automatically selects and fills in the most appropriate template based on your question and conversation context. This hybrid approach lets you apply your domain knowledge while still interacting through a natural language interface.

External system integration

Connect to external systems using Model Context Protocol (MCP) connectors (a standardized way to integrate with external data sources and services) to expand search capabilities beyond your OpenSearch cluster. By connecting to external MCP servers or compute environments, the agent can orchestrate broader query planning and execution across multiple systems, enabling advanced workflows that enrich queries with data from third-party services. For more information, see Using external MCP servers.

How agentic search differs from other search types

You can experiment with queries and their results using the Compare Search Results tool in OpenSearch Dashboards. For more information, see Comparing single queries.

To understand why agentic search represents a significant advancement, consider the query “I want to buy black shades for my dad” (entered as %SearchText% in Compare Search Results). The following queries demonstrate how agentic search differs in practice.

Agentic search and keyword search compared

To compare agentic search with keyword search, run the following queries.

Agentic query:

{
  "query": {
    "agentic": {
      "query_text": "%SearchText%",
      "query_fields": []
    }
  }
}

Keyword query:

{
  "query": {
    "multi_match": {
      "query": "%SearchText%"
    }
  }
}

The results for agentic search (left) and keyword search (right) are shown in the following image.

Agentic search accurately interprets intent by recognizing that “shades” means sunglasses and that the request is to buy the item, not to match the word “dad”. It uses the product category in the index to return the correct sunglasses products.

Keyword search matches individual tokens like “want”, “buy”, “black”, “shades”, and “dad”, potentially returning irrelevant results about window shades or other black objects.

Agentic search and semantic search compared

To compare agentic search with semantic search, run the following queries.

Agentic query:

{
  "query": {
    "agentic": {
      "query_text": "%SearchText%",
      "query_fields": []
    }
  }
}

Semantic query:

{
  "query": {
    "neural": {
      "content_embedding": {
        "query_text": "%SearchText%",
        "k": 100,
        "model_id": "IX-eM5oBVLB2ECqF42kS"
      }
    }
  }
}

The results for agentic search (left) and semantic search (right) are shown in the following image.

Agentic search provides more comprehensive understanding by interpreting the full context and your goal, focusing specifically on black sunglasses suitable for gifting.

Semantic search understands semantic meaning and correctly identifies “shades” as sunglasses. However, it may also return results for anything black in color because it processes all query terms without understanding your complete intent.

These comparisons illustrate agentic search’s core advantage: going beyond keyword matching or simple semantic similarity by deeply understanding intent, selecting the right tools, and incorporating external information when needed.

Example use cases

The following examples show how agentic search supports real-world scenarios across industries, without requiring you to understand index structures, query syntax, or search optimization.

Note: MCP servers can be sourced from Awesome MCP Servers.

Personalized shopping recommendations

Query: “Show me running shoes I might like based on my past orders and browsing behavior.”

Process:

  • The agent identifies relevant indexes such as products through the ListIndexTool.
  • It invokes the get_order_history MCP tool to gather past purchases, preferred brands, sizes, and price ranges.
  • Using index mappings and MCP-provided order data, the agent automatically builds an optimized DSL query using the QueryPlanningTool.

Outcome:

Highly customized, context-aware product recommendations that blend behavioral data, semantic signals, and trends—without manual query creation.

Observability and incident correlation

Query: “Show me which customers were impacted by the power outage this morning.”

Process:

  • The agent selects relevant operational indexes, such as logsmetrics, and alerts, using the ListIndexTool.
  • Using a custom incident management MCP tool, it retrieves official incident details and correlates them with log data.
  • It uses the IndexMappingTool to interpret timestamps, service fields, and customer identifiers.
  • If needed, WebSearchTool validates external references such as public outage announcements.
  • The agent then creates a DSL query using the QueryPlanningTool that filters logs for the outage window and identifies customers showing error spikes or activity drops.

Outcome:

A complete, correlated view of affected customers, automatically combining logs, metrics, incident data, and optional external context.

Fraud detection and risk investigation

Query: “Find potential fraudulent transactions in the past 24 hours.”

Process:

  • The agent identifies the transactions index using the ListIndexTool.
  • Using the IndexMappingTool, it recognizes key fields such as amount, location, device_id, merchant, and timestamp.
  • Using a custom fraud-rule-engine MCP tool, the agent retrieves defined rules and ranks results by risk score.
  • It constructs an optimized DSL query using the QueryPlanningTool that detects anomalies—such as geo-distance deviations or unusual transaction frequency.

Outcome:

Automated fraud triage that merges OpenSearch anomaly detection, external rule engines, and enrichment—significantly reducing manual investigation time.

Try agentic search on the ML Playground

To explore agentic search, use preconfigured agents and sample data on the Machine Learning (ML) Playground.

Set up agentic search locally

To configure agentic search locally, follow the agentic search setup documentation.

To enable detailed explanation of search results, configure the agentic context processor. The explanation contains information about steps the agent took to generate the results and the tools it used, as shown in the following image.

Use agentic search in OpenSearch Dashboards

To use agentic search in OpenSearch Dashboards, follow these steps:

  1. Navigate to OpenSearch Plugins > AI Search Flows.
  2. Select Create new workflow and then select Agentic Search.
  3. Provide a workflow name to save your configuration.
  4. Select Create to open the agentic search interface.

The interface has two main sections:

  • Left panel: Configure and create agents.
  • Right panel: Run searches and analyze results.

For detailed instructions, see the agentic search documentation.

What’s next

We’re currently implementing further performance optimizations for agentic search, including prompt caching, multi-agent architecture, and improved agent tracing. We’re planning to publish additional blog posts that describe our evaluation framework, query accuracy, and user experience.

If you have feedback, questions, or ideas for additional use cases you’d like to see implemented, we’d love to hear from you. Join the discussion on the OpenSearch forum or OpenSearch Slack workspace.

To track ongoing development and design updates, see the agentic search RFC.

Social Share or Summarize with AI

Authors

  • Author Rithin Pullela

    Rithin Pullela is a Software Engineer at AWS working on the OpenSearch Project. He primarily works on OpenSearch ML Commons and Learning-to-Rank. He is passionate about machine learning and distributed systems.

    View all posts
  • Tyler Ohlsen is a software engineer at Amazon Web Services focusing mostly on the OpenSearch Anomaly Detection and Flow Framework plugins.

    View all posts
  • Josh Palis is a software engineer at Amazon Web Services focusing mostly on the OpenSearch Flow Framework plugin.

    View all posts
  • Alec is an Applied Scientist on the OpenSearch ML team, where he leads the evaluation efforts underlying the team’s focus on iterative improvement of generative AI experiences. Previously, he developed methods for anomaly detection, monitoring of large scale events, and correlation of diverse metrics. Alec earned his Ph.D. in Statistics from the University of Washington, focusing on the analysis of memory in language models, music, and neuroscience.

    View all posts
  • Mingshi Liu is a software development engineer at AWS working on OpenSearch.

    View all posts
  • Sean Zheng is an engineering manager at Amazon Web Services working on OpenSearch, with a focus on machine-learning-based plugins, including Anomaly Detection, k-NN, and ML Commons.

    View all posts
  • Fanit Kolchina is a senior programmer writer at AWS focusing on OpenSearch.

    View all posts
  • Owais Kazi is a Software Engineer at AWS, focusing on OpenSearch and OpenSearch plugins.

    View all posts