OpenSearch as the data layer for AI

Why this conversation

Every AI system that answers a question or takes an action depends on retrieving the right data, quickly and at a cost someone can predict. For teams that run search, logs and monitoring as separate systems, agents change the arithmetic. At Open Source Summit Europe in Prague the host spoke with Bianca Lewis, Executive Director of the OpenSearch Software Foundation, about where OpenSearch came from and why the foundation now describes it as a data infrastructure layer for AI.

This is the whole conversation. The story of the week it was filmed is in Open Source Summit Europe 2026: who we met.

From fork to independent project

Some people still think of OpenSearch as a fork of Elasticsearch. She calls that a valid question, and confirms the origin: it was forked within AWS, which she sees as a strong home for the start of a project. It was intended from day one as a truly open source project. Two years later it was donated to the Linux Foundation, so that it is credible that no single vendor owns it.

The fork was five years ago. Today, she says, OpenSearch is its own independent data infrastructure platform for AI, different from anything else on the market in look and feel, in functionality and in the way it works.

No more data silos

What does a data infrastructure layer mean? In the old days, she says, data was discussed by use case: log analytics, application monitoring, tracing, search and security monitoring, each as its own silo. The scale is different now. With LLMs and agentic AI, hundreds of thousands of queries can run almost simultaneously, and “working in silos and paying the data tax by use case is not a scalable approach in this era.”

Her example is an online shoe shop. Its search application is mission critical, and it can be spun up on OpenSearch in minutes. But the shop also runs vector search, and agents in its warehousing, payment and financial systems, all talking to each other. So the business needs to know more than whether a customer found the right shoe: what the application costs to run, given that agents as well as people generate the load; whether it is secure; and which services the agents are calling. If observability and search live in separate systems, those questions cannot be answered together.

As an infrastructure layer, OpenSearch can take a search application, create an observability stack on top of it, enrich that with cost data and add security monitoring, giving one view across the whole thing.

Why vector search shows the wrong shoes

Agentic commerce, a personal agent that knows your taste and goes looking for a product, makes the relevance problem sharper. With pure vector semantic search, as it was a year ago, a query for brown shoes from brand X goes to the nearest neighbours: brown shoes from brand X, but also brown shoes from brand Y and blue shoes from brand X. Those are results the customer did not ask for.

OpenSearch uses hybrid search instead. It filters lexically on terms that should not be vectorised, so brand X stays brand X, and then applies vector search to what remains. The results are more relevant, and the cost of the infrastructure stays within reasonable limits at scale. She notes that the platform includes a workbench for working on search relevance.

Long-term support or a release every eight weeks

The host asked how a project reconciles long-term support for enterprises with a fast-moving field of new agent protocols and capabilities. She agrees these are opposing forces, and answers with choice. To her, sovereignty over a data platform means “that I have the choice.” A long-term supported version of OpenSearch has guaranteed support for at least 18 months, a stable base to build on. Other businesses prefer to follow the release cycle of a release every eight weeks. Either way, 105 vendors in the ecosystem can help.

Platforms built for AI scale

Most software, she argues, was built before the scale that AI now brings: first cloud native, then AI native, now agentic AI native. Modernising OpenSearch is a focus, and the just-released version 3.9 shows the trends: efficiency at agentic scale, control of cost, more accurate results, and storing vectors more efficiently while still recalling them quickly. Usability is the other half. Where users once had to code an alert for Prometheus metrics, they can now describe the alert they want in the interface and it generates the query that configures it.

The community behind it reports 2.4 billion downloads, 3,000 active contributors and 400 companies. Whatever attention goes to agents and AI security, she says, means little without the data infrastructure underneath that does the retrieval and processing.

Asked about the business of tomorrow, she expects that within five years the data infrastructure layer will drive business decisions and customer experiences, with fewer user interfaces and simpler, consolidated tools, so that businesses can concentrate on what brings in business for their customers.