Observability tools tell you what went wrong. They rarely help you fix it. When responding to an incident, engineers split their time across Kibana, Slack, and the terminal. At each step, the AI assistant stays behind in the previous surface, and the investigation starts over from scratch.
Elastic Ramen (Root-cause Analysis & Monitoring Engine) bridges that gap. It is a local CLI agent that connects directly to Elastic Agent Builder, carrying the same conversation, skills, and Elastic context into the terminal. Ramen operates directly in the environment where fixes actually happen. No handoff. No re-auth. No translation layer. Ramen is open source and available at elastic/elastic-ramen.
Why the terminal matters
Agent Builder gives engineers a strong environment for querying observability data. Ramen takes that same capability to the two workflows that need it most.
Onboarding. Configuring collectors, managing credentials, and validating data flow all happen in the shell. A local agent can guide that work right where the credentials and tools already live.
Mitigation.
The actual fix, whether restarting pods, scaling deployments, or rolling back releases, requires kubectl, gcloud, git, or internal scripts.
A CLI agent runs on hardware the team already trusts, using the credentials already present on the engineer's machine.
How Ramen works
Ramen is a CLI client for Agent Builder. It is not a separate assistant with its own memory. It connects your local environment to the same conversations, skills, and tools you already use in Kibana through a simple authentication flow.
On first launch, Ramen connects to your Elastic deployment and gives you everything out of the box:
- LLM inference through the Kibana gateway, using your existing AI connector
- Native Kibana tools for managing workflows and agents
- The Agent Builder MCP server for ES|QL queries and documentation search
- An embedded
elasticCLI for cluster health, data streams, and SLOs - Built-in skills for root cause analysis and SLO management
The agent carries your investigation history across surfaces, so you never re-explain the incident when moving from the UI to the CLI. Terminal interactions sync back to Elastic automatically, building a searchable record of operational knowledge for the team.
Get started
You need an Elastic Observability Serverless project.
In Kibana, open Stack Management, then Advanced Settings, or go directly to https://<your-kibana-url>/app/management/kibana/settings?query=ramen.
Enable elasticRamen:enabled, then install the CLI:
npm i -g @elastic/ramen
bun add -g @elastic/ramen
You can also use the install script or download a pre-built binary from GitHub Releases:
curl -fsSL https://raw.githubusercontent.com/elastic/elastic-ramen/dev/install | bash
Once installed, connect to your deployment:
elastic-ramen --kibana-base=https://<your-kibana-url>
Ramen opens a browser auth flow, generates credentials, and stores them locally.
After that, it reconnects automatically.
Start a conversation in Agent Builder and resume it in the terminal with /kibana-conversations.
What is next
Ramen is the first surface of a multi-surface agent system. The same architecture extends to every surface engineers already use:
- Space-scoped collaboration for shared agent context during outages
- Slack, Teams, Jira, PagerDuty integration: start from an alert, collaborate in chat, mitigate in the terminal, one thread
- Shared memory: progressively distill conversations into durable operational context that improves future investigations
Beyond incident response, the same model applies to deployment risk analysis, production debugging, CI/CD policy checks, and cost anomaly investigation.
Summary
Ramen connects signal to action: Elastic data and Agent Builder context, plus the ability to act with local tools, in one continuous thread. Elastic as the persistent context layer, every surface you use as the interface.
Try it out on GitHub and let us know what you think.