Root

Tell it what broke. Root finds out why.

Comment

What it does

Root is an autonomous error investigation agent built on Google Cloud Agent Builder and powered by Gemini.

When a production error occurs, engineers normally spend 1 to 2 hours manually: searching through thousands of log entries, filtering by time, identifying error patterns, correlating services, and writing a summary. Root does all of that automatically.

You give Root one sentence describing the problem in plain English. Root investigates it by running a chain of Elasticsearch queries through the Elastic MCP Server, where each query result informs the next search. It then produces a structured incident report with the exact timeline, root cause analysis, and recommended actions.

The key distinction from a chatbot: Root decides what to search for. You do not guide it. You do not type follow-up questions. You give it a vague complaint and it returns a finished document.

How we built it

Stack:

  • Google Cloud Agent Builder with Google ADK (Agent Development Kit)
  • Gemini 2.0 Flash as the reasoning model via Vertex AI
  • Elastic Cloud (Elasticsearch) as the log data store
  • Elastic MCP Server (Docker) as the bridge between the agent and Elasticsearch

How the agent works:

  1. The user describes the problem in plain English
  2. Root uses list_indices to find available data in Elasticsearch
  3. Root uses get_mappings to understand the structure of the log index
  4. Root uses the search tool to find HTTP errors in the relevant time window
  5. Root narrows down to the most affected endpoint and finds the first occurrence
  6. Gemini synthesizes the findings into a structured incident report

The Elastic MCP Server is central to every step. Without it, the agent has no access to the log data. It is not a decorative integration - it is the core tool that makes the agent work.

Challenges we ran into

The main challenge was making the agent investigation deterministic. LLMs are non-deterministic by nature, meaning the same input can produce different outputs. For a demo, you need the same output every time.

We solved this by writing very specific step-by-step instructions in the agent prompt, specifying exactly what Elasticsearch queries to run in what order, and what format to use for the output. The more specific the instructions, the more consistent the agent behaves.

The second challenge was creating demo data that told a clean, single story. The Kibana sample data has scattered random errors with no narrative. We wrote a script that injects 300 checkout errors at a specific time with a traffic spike 5 minutes before, creating a clear cause-and-effect story that the agent can find and explain.

Accomplishments that we're proud of

The agent runs a genuine multi-step investigation where each step depends on the result of the previous one. It does not just answer a question. It decides what questions to ask.

The incident report it produces is document-quality output: structured, timestamped, specific, and actionable. An engineer could attach it directly to a ticket or send it to a manager.

The entire investigation takes under 60 seconds. The equivalent manual process takes 1 to 2 hours.

What we learned

The difference between an AI assistant and an AI agent is the reasoning chain. An assistant answers what you ask. An agent figures out what to ask.

Writing good agent instructions is more like writing a procedure for a junior employee than writing a prompt for a language model. The instructions need to be specific, ordered, and leave no ambiguity about what to do next.

The Elastic MCP Server made it possible to connect the agent to real data without writing custom API integration code. MCP is the right abstraction for giving agents access to external systems.

What's next for Root

Currently Root investigates a single time window in one Elasticsearch index.

Next steps:

  1. Automatic alerting: connect Root to Elastic's alerting system so investigations trigger automatically when error rates spike, with no human input needed
  2. Multi-index correlation: investigate across multiple services simultaneously to find cascading failures
  3. Historical pattern matching: compare current incidents to past incidents to identify recurring root causes and flag known-bad patterns
  4. Integration with GitLab MCP to automatically create an incident ticket and tag the commit that likely caused the failure

Built With

Share this project:

Updates

Submission history