[Session Report] Search Evolves with Agents: Agent Capabilities of Amazon OpenSearch Service [ANT407] #AWSSummit

Introduction

This is a report on session ANT407 from Amazon OpenSearch Service, which I attended at AWS Summit Japan 2026.

Search has evolved from full-text search to vector search, and then to hybrid search combining both. Challenges that still remain unsolved are where agents come in. This session covered the mechanisms behind this evolution and improvements in search accuracy.

The session overview is as follows.

• Session number: ANT407
• Title: Search Evolves with Agents - A Deep Dive into Amazon OpenSearch Service's Agent Features -
• Speaker: Takayuki Enomoto (Senior Analytics Solutions Architect, Amazon Web Services Japan G.K.)
• Date and time: June 25, 2026, 13:30 to 14:10

Traditional Search Technologies and Their Challenges

The session looked back at the evolution of search technology using a fictional e-commerce site as an example.

LIKE searches in RDBMS make it difficult to handle synonyms, spelling variations, and typos, and also come with performance limitations. This led to the introduction of full-text search engines, and further to hybrid search combining vector search, which matches based on semantic similarity.

In the demo, "lightweight material tops" returned zero results in full-text search, but in hybrid search it matched items like linen shirts.

However, there are challenges that even hybrid search cannot solve.

One is handling complex requests. For example, a query like "waterproof jacket from Company A for under 20,000 yen" requires extracting price filter conditions and switching between full-text and vector search as appropriate. Another is conversational search — the need to narrow down conditions based on prior context, such as "something a bit cheaper" or "the same brand as last time."

How Agent-Based Search Works and Accuracy Improvements

Agent-based search is the answer to these challenges.

Using the user's input, purchase history, and other context, the agent constructs search queries. In the example above, this means automatically routing to a price filter of under 20,000 yen, terms for full-text search, and terms for vector search.

There are two types of agents. The Flow Agent handles simple query transformation with a single LLM call. The Conversational Agent uses multiple tools such as memory, web search, and MCP (Model Context Protocol) to handle complex processing involving dialogue and external integrations. Both use the Query Planning Tool for query transformation.

Agents also assist with improving search accuracy. UBI (User Behavior Insights) for user behavior logs, Search Relevance Workbench as an evaluation tool, and Learning to Rank for building ML-based rankings can all be accessed by agents via OpenSearch's MCP server. In the demo, the agent was able to extract queries where hybrid search was underperforming and even suggest features to add to Learning to Rank.

Summary

Throughout the session, I got the sense that search is evolving into something that can be handled in natural language as-is. Agents construct queries and even help with accuracy improvements. At the same time, the slides also highlighted tradeoffs with latency and LLM call costs, and I felt it is important to carefully consider the use case before adopting this approach.

Reference Links

• Amazon OpenSearch Service introduces Agentic Search
• Agentic search - OpenSearch Documentation
• Query Planning tool - OpenSearch Documentation
• User Behavior Insights - OpenSearch Documentation
• Search Relevance Workbench - OpenSearch Documentation

©2026, Amazon Web Services, Inc. or its affiliates. All rights reserved.