Thu, Oct 22 · 6:00 PM EDT
Agenda:
6-6:30 pm: Networking and food/drinks
6:30-7:15 pm: Announcements and presentation
7:15 pm-7:30 pm: Q&A and close-out
Teaching your Agent to Read a Cluster Agentic performance analysis for OpenSearch, from MCP to source graphs to a knowledge base of the whole project
Most engineers who use OpenSearch do not operate it. They write queries, own a search pipeline, or ship a feature against a cluster somebody else runs. When performance degrades, the evidence already exists, sitting behind APIs, metric graphs and logs that all assume developers already know which one to read.
First, the OpenSearch project's official MCP server and its agent skills repository. Developers install one package, point it at a cluster endpoint, add a few lines to their agent configuration, and start asking questions in plain English. There is no plugin to build, no skill to write, no model to fine tune, and nothing to change on the cluster itself, so no approval is needed from whoever owns it. Whatever harness a team already uses stays the harness they use.
Second, structural context. Knowledge graphs built over the latest OpenSearch source tree and its Apache Lucene dependency, so the agent can reason about why a symptom occurs instead of only reporting that it does.
Third, grounded knowledge on top of both. The graphs stay in place, and the agent also gets the full OpenSearch documentation and Lucene query cost semantics through a Bedrock knowledge base backed by an OpenSearch vector store. All three layers working together are what make the analysis accurate enough to trust on a live cluster or after an incident.
The session closes with how to package all of it into a repeatable workflow. The goal is accurate root cause identification without first becoming an OpenSearch internals expert.
