OpenSearch 3.6: Agentic Applications Meet Long-Term Support

With each release, OpenSearch grows more capable as infrastructure for AI applications. OpenSearch 3.6 pushes that further in two directions at once: it makes agentic applications production-ready, and it's the project's first Long-Term Support (LTS) release. Teams can build AI applications on 3.6 and depend on it, knowing it has multi-year support behind it.

Agentic apps, ready for production

OpenSearch 3.5 brought agentic capabilities into the platform; 3.6 is about making them perform. What matters is how fast you can go from an idea to a running app, and 3.6 introduces the AI-powered OpenSearch Launchpad to help automate search application development. It takes a sample document, asks a few questions about your requirements, and provisions a complete search application in minutes, taking care of the retrieval strategy, mappings, ML pipelines, and a working UI. It's the first of the new OpenSearch Agent Skills, and it plugs straight into IDEs like Claude Code and Cursor over MCP. The experimental Relevance Agent does the same for tuning: it analyzes user behavior, proposes changes, and validates them, cutting relevance work significantly, especially for teams new to OpenSearch.

Underneath, the building blocks got sturdier. Agentic search now supports reranking, fallback queries, and agentic memory that carries context across interactions. A unified registration API collapses connector, model, and agent setup into a single call.

OpenSearch has become faster, too. 3.6 makes 1-bit scalar quantization the default at 32x compression, and on Faiss that delivers 24% better recall and 15% lower latency than the previous binary methods, not a trade-off against them. Faiss quantization optimizations cut search latency by another 40%, and prefetch halves it again in memory-constrained setups. These improvements make the difference when you're indexing the embeddings an agent depends on.

Long-Term Support teams can rely on

Shipping fast-moving features is one thing. Relying on a technology for a multi-year roadmap is another, and that's the question that usually stalls adoption. 3.6 is the first LTS-designated release, and the support program is extensive:

• 18 months of support minimum, so a version won't go end-of-life mid-project.
• SBOMs across all ~150 repositories, providing the provenance and compliance evidence that regulations like the EU Cyber Resilience Act (CRA) expect.
• A 60-day commitment to address medium- and high-severity vulnerabilities, with early notifications.
• An upstream-first commitment. Every LTS fix goes back into the main OpenSearch project, so there's no lock-in and no divergent codebase.

For anyone evaluating OpenSearch for real workloads, this is the part that matters. The old trade-off, fast-moving open source versus a stable, supported platform, is gone. OpenSearch 3.6 now offers both.

Get building

This is the combination our managed OpenSearch is built around: the agentic feature set, without teams wasting time managing the infrastructure. Prototype on the Developer tier, then scale for production, moving fast early and committing later, on the same managed platform, with upgrades and security patching handled for you.

To see how quickly this comes together, take a simple example: a semantic search app for Hacker News stories that finds results by meaning rather than keywords. Instead of hand-building the index mappings, embedding pipeline, and query logic, we used the OpenSearch Launchpad and Aiven Apps to speed up the app development.

At the core of that app is the search itself. The method below takes a user's query, turns it into an embedding, and runs a kNN vector search against the OpenSearch index to return the most semantically similar stories along with their relevance scores (see the full project on GitHub):

Loading code...