DEV Community: Yurii Serhiichuk

Building an Autonomous SRE Agent with Google ADK and the Antigravity SDK

Yurii Serhiichuk — Thu, 09 Jul 2026 16:58:44 +0000

One of the most stressful parts of being an on-call engineer is triaging a production incident in the middle of the night. Modern distributed systems amplify the pain with extra cognitive overload of, well, the distributed systems: logs scattered across dozens of microservices, traces potentially stored in multiple different locations and a dozen of observability tools and dashboards on hand. While this (usually) makes total sense for SREs to design and develop this the way it is (maybe because of the costs or being knowledgeable in this or that tool, or just optimizing for a particular concern), this adds a lot of load for any on-call engineer.

So in era of AI, it makes total sense to get some aid from the autonomous and smart systems that are fine-tuned for your setup, that remember all the bits and pieces that are suitable for your infrastructure.

In this post I'm trying to go over a blueprint of such an autonomous SRE system - an AI agent that can be hosted near your main system and fine tuned to work with a set of tools you use.

I will be using Google Agent Development KIT (ADK) for multi-agent diagnostic reasoning and Google Antigravity SDK for the agent runtime - tool wiring, easy-to-apply safety policies and agentic orchestration. The setup will be deployed as a set of Google Cloud Run services but while being containerized can be easily ported to any other containerized platform. The entire stack runs locally as well with zero GCP credentials in a mock-telemetry mode, so you can try it in under a minute.

The Core Architecture: Reasoning + Safety

A proper SRE assistant has to get two things right at once: reasoning orchestration (which diagnostic step happens when) and environmental safety (the agent must never be able to mutate production while it pokes around). The blueprint splits these concerns across four small Fast API services that talk to each other over Agent-To-Agent protocol with results being streamed back as Server-Sent Events (SSE).

I'm using Google Antigravity SDK as an orchestrator and front-facing agent while it provides superior safety gates out of the box and is smart-enough to handle user requests.

safety_policies = [
    deny("*"),  # nothing is allowed by default
    allow("diagnose_sre")  # …except delegating to the SRE sub-agent
]

The config above basically gates whatever tools we want to allow for the agent to use.

And Google ADK agents fulfill the diagnostic workflows. ADK v2 which I am using is graph-based and the SRE sub-agent runs two-node graph:

TraceAnalyzer - scans recent trace summaries, filters for transactions that errrored or breached the latency budget (>5000ms), and isolates the single failing traceId.
LogCorrelator pulls the spans and the logs tagged with that traceId, then reasons over them with metric queries, cascade analysis, and post-mortem generation tools to produce the root-case report.

The third agent is an inventory agent that aids the SRE with aggregated knowledge of resources available in the GCP project. This helps grounding diagnostics and makes sure the agent works against particular resources instead of trying to look around too much.

Anatomy of a Diagnosis

When an alert fires, here's what actually is going to happen end to end from the on-call prompt to a finished post-mortem.

The Orchestrator does the one thing its policy allows: it hands the problem to the SRE sub-agent and steps back. From there the sub-agent streams its progress back as Server-Sent Events, so the on-call engineer watches the investigation unfold live instead of waiting on a spinner.

It starts by pulling the project topology — which services exist, how they call each other, and where their databases sit — from the Inventory agent's Firestore-backed cache; that map tells the diagnosis where to look. It then fetches the recent traces and runs them through the two-node graph: TraceAnalyzer collapses thousands of spans down to the single failing trace worth investigating, and LogCorrelator pulls every span and log line sharing that trace's ID to name the actual root cause — not just "the database was slow," but which span failed, with which error, and why.

Only then does it run the cascade analysis and draft the post-mortem, streaming the finished report back through the Orchestrator to the chat UI, where it lands as a rendered dashboard with a one-click download.

The beauty of such approach is extensibility of the setup. You can add new sub-agents or expand existing tools easily with ADK and A2A protocol.

Deep Dive: Cascade Latency & Bottleneck Analysis

In order to showcase the agent, I have also built another Fast API service that emulates real database errors with timeout exceptions and telemetry spans. As it is just a simulation, quite a lot of actual problems are quite similar to this one and frequently the initial gateways/backends latency or errors are hidden downstream. But of course this is a textbook example still: a gateway request that looks 10-second-slow, but where 99% of the time is actually trapped in a database call three levels down.

All three spans look ~10 s slow (inclusive), but the red /api/database bar is where the time is actually spent.

The cascade-analysis tool builds the span parent/child map and computes, for every span:

Inclusive duration — wall-clock time of the span including its children.
Exclusive (self) duration — the active time spent in that span alone:

ExclusiveTime(s) = InclusiveTime(s) - sum of InclusiveTime(children)

The span with the largest exclusive time is the true bottleneck. Here is the actual, verified output from incident simulator (available in the repo):

### 🔍 Span Latency Breakdown
Service / Span Name     Span ID             Parent ID           Status   Inclusive Time   Exclusive (Self) Time   Contribution
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
/api/gateway            span-gateway-111    None                ERROR    10270 ms         20 ms                   0.2%
  └── /api/backend      span-backend-222    span-gateway-111    ERROR    10250 ms         50 ms                   0.5%
      └── /api/database span-database-333   span-backend-222    ERROR    10200 ms         10200 ms                99.3%

### 🚨 Identified Bottleneck
*   Bottleneck Span:     /api/database (span-database-333)
*   Self-Execution Time: 10200 ms (99.3% of total trace)
*   Status:              ERROR
*   Error Message:       ConnectionTimeoutError: Failed to connect to db-primary.gcp.internal:5432 after 10000ms

The gateway and backend each look "slow" at 10 s inclusive, but their self time is a rounding error. The agent ignores the noise and points straight at /api/database — 99.3% of the budget, burned in a single connection timeout.

Automated Post-Mortem & One-Click Export

Diagnosis is only half the job; the deliverable on-call engineers actually need is a post-mortem. After the cascade analysis, a post-mortem generator drafts a complete Markdown document with an Incident Overview (time, root service, Trace ID, impact duration), a Timeline, a Root Cause Analysis, and a Prevention Plan — all populated from the real trace and log data.

That Markdown is then rendered via A2UI protocol

From SRE report markdown to a one-click, client-side post-mortem download.

A server-side translator spots the post-mortem heading and appends a download-button component; the browser renders it as a styled button that builds the file entirely in the browser — no server round-trip — from the Markdown it already holds.

One click exports post_mortem.md, ready to drop into your incident-review wiki.

And here is how this actually looks like in the deployed UI.

Least-Privilege IAM on Cloud Run

Handing an autonomous agent unrestricted cloud access is a non-starter. The deploy pipeline gives each Cloud Run service its own service account with the narrowest possible role set:

The write-only target app and the read-only SRE agent can never act on each other's plane.

The split is the whole point: the app that generates the chaos can only ever write telemetry, and the agent that investigates it can only ever read. Neither can act on the other's plane. (The deploy also provisions an inventory-agent-sa for topology discovery and a dedicated sre-build-sa for Cloud Build, each similarly scoped.)

Try It Yourself in 60 Seconds

You can run the entire scan → correlate → analyze → post-mortem loop locally. No GCP account or credentials required.

# 1. Clone the repo
git clone https://github.com/xSAVIKx/sre-agent.git
cd sre-agent

# 2. Install uv and sync the workspace (app, agent, sre_agent, inventory_agent, sre_common)
pip install uv
uv sync --all-packages

# 3. Run the incident simulation
uv run simulate_incident.py

The simulation triggers a database-timeout incident in the target app, writes mock traces and logs to mock_telemetry_data/, boots the Orchestrator in mock mode, runs the diagnostic workflow in-process, and prints the report to your terminal. You will see the structured telemetry logs (gateway → backend → database, ending in a CRITICAL ConnectionTimeoutError) followed by the full diagnosis: the 99.3% /api/database bottleneck table and the complete # 🚨 Incident Post-Mortem shown above.

Want the full multi-service experience with the web chat UI? docker-compose up --build brings up the Orchestrator, SRE agent, Inventory agent, a Firestore emulator, and the target app together — then open the chat at /chat.

Project Resources

The complete, runnable source — plus a step-by-step CODELAB that builds this from scratch — lives on GitHub:

👉 github.com/xSAVIKx/sre-agent

Open Knowledge Format - portable digital map of your data as code

Yurii Serhiichuk — Mon, 15 Jun 2026 07:38:08 +0000

Yesterday Google dropped an article describing an interesting idea - a portable format for knowledge sharing as markdown. This is not new or unique (llm wiki, obsidian values and even agents/claude.md are similar concepts). What stands out here is the openness of the proposed standard (also, just a v0.1 draft now) and actual ability of Google to make it a de-facto standard.

I've spent quite some time as GDE and AI integrator helping teams wire data into the LLM agents, and I keep hitting the same wall. The model is brilliant and the data is right there, but the knowledge about the data - what a table means, how a metric is defined or why a column was deprecated is, unfortunately, scattered across hundreds of different places. Something is available in company google docs or drive, the other things are available directly in readme and the extra missing piece is actually in that one engineer's head. Unfortunately, we can't write a connector for the last piece, but as Sam McVeety and Amir Hormati highlights in the blogpost we can at least help the agents (and developers) navigate through such knowledge better by introducing some shared and well known way of sharing the knowledge. And don't get me wrong, almost every team has probably already solved this in that or another proprietary way, rebuilding that same plumbing again and again from scratch.

OKF's wager against that mess is almost provocatively simple. If you can cat a file, you can read it. If you can git clone a repository, you can ship it. The spec only enforces one field to be explicitly provided - type , and that's exactly the trick: standardize only the smallest possible interoperability surface while leaving everything else to the people producing the data.

The reference repository indeed provides only the bare minimum - a pretty simple spec, example agent (which is BigQuery-oriented and pretty opinionated) and some sample bundles. And while this is a great starter pack, the idea of OKF how I see it is that knowledge lives everywhere. My SQLite file has knowledge. My Postgres instance has knowledge. My ~/notes folder and my Git history as well. If OKF is going to be a lingua franca, it needs producers for the messy real data the most of us actually work with, and it needs consumers that are not tied to any one vendor's agent.

So I built that: the OKF Skills, a vendor-neutral fleet of producers and consumers for OKF.

The idea is simple - any source in, any agent out.

What I built already is just a small baseline that I hope would be useful moving forward. That's six connectors - SQLite, MySQL, PostgreSQL, BigQuery, the local file system and Git. Each is a single portable Go binary with the same three commands: produce a bundle from the source, ingest a bundle to verify it (or --sync curated descriptions back to the source), and schema to describe itself. The SQL connectors can embed a per-column data profile and sample rows right in the concept docs.

Then three guidance skills with zero extra runtime. reader teaches an agent how to traverse any OKF bundle cheaply (index first, frontmatter only, grep before you read). The enricher teaches your harness to write good descriptions grounded in the schema, profile, and samples. And finally the producer-generator to bootstrap other connectors real fast.

I also decided to rebuild the visualizer Google team embedded into their agent. The viz renders any bundle into a single self-contained index.html near your OKF data. It produces a three-pane explorer with an interactive graph, navigator and content reader. Now there's no need to reach for Google-provided agent just to create a visualization if you just want that.

Finally, there's the mcp server that is capable of discovering every installed connector and exposes them as relevant tools. Point Claude Code or Antigravity at it and you're ready to rock. You can install all of them today with:

npx skills add xSAVIKx/okf-skills

Now you should be able to just ask your harness nicely to create, enrich and visualize the OKF bundle.

I hope this agentic tooling would allow the community to embrace the new format and truly make it a widely used standard. And also warmly welcome any new contributions to the existing connectors.

Useful links: