Agentic SDLC: How OpenSearch accelerates engineering with its own engine - OpenSearch

Search

Close Search

Blog<br>Agentic SDLC: How OpenSearch accelerates engineering with its own engine

By Chenyang Ji, Pallavi Priyadarshini, Fanit Kolchina, Sudeep Ghiya, Akash Sant, Frank DattaloMay 14, 2026No Comments

Notes from experimenting with agents in knowledge-base, development, performance, and on-call workflows—and the verification loops that make them trustworthy.

Efficiency gains are a priority for every engineering team. The OpenSearch team has been experimenting with AI agents across our software development lifecycle (SDLC). The goal: let agents do the repetitive work so engineers can focus on higher-order tasks—defining vision, designing architecture, and deciding what to build. In this blog post, we’ll share what we’ve built and what we’ve learned.

TL;DR: The OpenSearch team built four AI agents that automate SDLC work, each validated by its own verification loop rather than human review alone.

Atlas —living knowledge base, deduplicated on every update

Ralph —parallel dev pipeline, verified against a live local stack

Nitro —performance optimizer, A/B-tested against benchmarks

Sentinel —on-call triage, gated by human approval before execution

From generation to trust

Across all SDLC phases, AI agents now generate code, root-cause analyses, remediation plans, performance fixes, and standard operating procedures (SOPs) faster than humans can meaningfully review them. The bottleneck is no longer generation; it’s deciding whether to trust what has been generated.

To build trust in agent output, we built four agents that work together across the SDLC: a foundational knowledge base, plus three phase-specific agents for development, performance, and on-call operations. Each agent runs inside its own automated verification loop (harness) that validates agent output before accepting it. These loops take different forms: deduplication for knowledge bases, live integration testing for development, benchmarks for performance, and human approval for operations. All four agents share one design principle: the loop encodes quality standards and the agent generates output that the loop validates.

These agents are currently internal experiments rather than open-source releases. We’re sharing what we learned while developing these agents because the underlying patterns can be generalized beyond a single system. The patterns include harness-first verification, plan-then-approve safety, ticket-to-SOP extraction, and production-data grounding. If you’re building agentic tooling for OpenSearch or any other large system, you can adapt these approaches.

The four agents and how they work together

The following diagram shows how the four agents work together across the SDLC.

Figure 1: The four agents—Atlas, Ralph, Nitro, and Sentinel—working together across the SDLC and sharing a common knowledge base.

Each agent serves a distinct role:

Atlas (a real-time knowledge base) – Automatically updates itself using source code, wiki articles, runbooks, and resolved tickets.

Ralph (a test-driven parallel development pipeline) – Launches the service stack locally, decomposes a feature specification into tasks, and distributes tasks across coordinator, developer, quality assurance (QA), and validator agents that verify output against a live integration stack at each iteration.

Nitro (an autonomous performance optimization agent) – Profiles the running system, discovers bottlenecks, and A/B-tests candidate fixes.

Sentinel (an autonomous on-call agent) – Runs on a cron schedule, reads tickets, proposes remediation plans, and executes after human approval.

The agents run autonomously at different stages of the lifecycle and use the shared knowledge base as a consistent source of truth. Thus, Sentinel’s root cause analysis (RCA), a developer’s chat session, and a new hire’s onboarding workflow all operate from the same knowledge base.

Atlas: The living knowledge base

All agents depend on a current, grounded understanding of the system. Wiki articles and design docs drift. The code is authoritative but difficult for newcomers to approach without context. The most valuable operational data—resolved tickets—exists in unstructured comment threads that are difficult for embedding models to search effectively.

Atlas is a set of workflow skills that converts source code, wiki articles, runbooks, and resolved tickets into a structured, continuously updated shared knowledge base , built on OpenSearch. Each document—a service reference page, an SOP, a design flow—is indexed with its full text alongside nested vector embeddings of its chunks. Retrieval uses hybrid search : BM25 lexical scoring combined with dense-vector similarity. This matters for technical content. A query such as "why is the sort+term aggregation slow on geopoint" combines natural language with specific identifiers (sort+term and geopoint). Pure vector search...