AI SRE Agent End to End: Alert to Fix in One AURA Run

What AURA is and why it is open source

0:00 Hi, I'm Jeff. I work on AURA. AURA is a fully open-source harness that's specifically designed for building SRE agents. You 100% own it. You can run it air-gapped. Configuration is fully defined in code. Very extensible. You can define scoped workers, which can handle huge tool outputs without blowing up the context window.

We made it open-source because we believe that closed-source breaks the trust boundary, and it's too rigid to work in a landscape of unique SRE tools and processes.

The benchmark environment and today's failure

0:32 I'm going to show you an example of the art of the possible. This only took a few hours to set up.

This is one of the benchmark environments that we run AURA against. It's a simulated e-commerce environment that runs on Kubernetes with real-world telemetry that you might see in production.

Today's test is a load spike that breaks an upstream service and a downstream container goes into alert. This is a good root cause scenario to show how AURA works.

The cart service is the first thing to go. It's out of memory. It gets killed, goes into a restart loop. But the checkout service starts throwing 502s because its upstream keeps disappearing. The alert fires and an incident gets created.

How the incident reaches AURA

1:16 We have an automation where a Slack channel then opens, posts a summary, and then a webhook hands the incident to AURA to investigate. The coordinator dispatches workers to complete tasks to work towards a goal. In this automation, we're asking AURA for a root cause.

This is the Slack channel that got created during my incident. AURA was invoked automatically. You can see the coordinator wrote a plan and dispatched a number of workers. The workers write their responses as a typed artifact on disk, which can be handed out as a reference to the coordinator and any other workers that may depend on it.

The root cause across logs, metrics, and code

1:51 AURA found the root cause, provided an incident breakdown, and described next steps, as requested in the system prompt that AURA is configured with.

The initial incident points to the checkout service. The cluster worker finds the checkout pods are healthy, but its upstream isn't. The cart is crashing regularly. It's out of memory.

And then using Grafana, the metrics worker can see that the cart service actually has a memory growth issue. Every add to the cart, and it never comes back down.

The GitHub worker is asked to check for recent changes and finds a recent PR against the cart service. We gave the GitHub worker access to a stronger agent, and it's actually able to identify not just the recent change, but it diagnosed an unbounded per session regression on the add to cart method. Now we have an actual fix to propose.

So the symptoms came from the logs. The cause was identified using metrics and the root cause was identified through GitHub. This is a really important thing to consider. We're using workers and we're able to keep track of these multiple domains in parallel and we're doing all this with open-weight models with a fully open source harness.

From finding to a filed GitHub issue

3:04 So let's see about getting this fixed and then I'll give you a look at how I built it.

Here I'm asking AURA to dig into the code regression that it found. AURA found the exact line of code and the method that's causing the regression and it gives guidance on how to fix it.

Now I ask it to open a GitHub issue. And since creating an issue is guarded by human-in-the-loop, we need to approve it.

The issue includes the root cause, the proposed fix, the impact, and AURA's own suggestion on remediation. Now I can assign it to a developer, or just ask Claude to fix it.

Deploy, auto-resolve, and verify

4:00 I'll skip over the release automation, but you can see now that it's deployed, the alerts are returning back to normal.

Going back to the incident thread in Slack, we can see that PagerDuty has now auto-resolved the incident because the alerts stopped firing.

And I can ask AURA to double-check that the services are healthy. It dispatched workers to check the cluster, as well as Grafana metrics and logs, and everything looks good. It even recommended a minor issue for us to keep our eyes on.

Inside the AURA config

4:39 So I want to give you a quick overview of what an AURA configuration looks like. This is the live config file that I'm using for this demo environment, and you can see here I've got four MCP servers set up. Kubernetes, Grafana, PagerDuty, and GitHub.

All access tokens are read-only, except GitHub has permission to create issues. Human-in-the-loop is configured to guard specific tool calls, and it accepts wildcards.

Underneath that, I've got my main system prompt for the coordinator agent. I typically describe the environment it's working in, and I leave the rest to default configuration. The instructions govern on how it interacts with workers, what the response structure should look like, and how it should conduct investigations.

I use Baseten for inference, but any OpenAI-compatible API will work, even local models.

Scratchpad keeps large tool call outputs out of the context window. Any response over the token threshold gets written to disk. The workers get tools to investigate the artifact in small chunks.

Workers, tools, and models

5:36 Underneath that, I've got my individual workers. Workers are given their own prompt and a list of tools that they can access.

incident_responder can work with PagerDuty and Grafana alerts. cluster_inspector can reach the Kubernetes MCP. metrics_analyst and log_analyst are given different Grafana tools, and github_analyst is used to inspect code issues and recent pull requests. Any worker can use tools from any MCP, and workers can be configured to use different models.

What the harness actually gives you

6:06 So stepping back a bit, we showed AURA being invoked automatically in an incident response pipeline. But the pipeline is not the interesting part. We've all wired up automation before. Yours would look different anyway. And that's the whole point.

AURA has a specific bounded role to provide deep reasoning and take trusted actions per the configured worker instructions that are fully owned by your team. Your model choices, system prompts that you can read in a diff and iterate on to fit your use cases.

Workers take on any shape you want. You just need a name, a prompt, assign some MCP tools, and maybe choose a cheaper model, because reading PagerDuty payloads does not need a frontier model. If you want a worker that pulls runbooks out of Notion, that's just a config block. You could connect a vector store that has your entire knowledge base, or connect it to another agent using A2A. It's all the same shape.

None of these workers is smarter than the model behind it. The harness is what makes everything work. Scoped workers, parallel dispatch, large tool outputs protected from the context window. That's how we can use a non-frontier model to resolve a very specific multi-domain root cause.

Where to start, and what is next

7:12 If you want to try this, don't start with a pipeline. I run AURA standalone on my Mac as a copilot. I ask it questions every day about my homelab. We have a ton of content on setting AURA up. Through install, connect some MCPs, iterate from there. Only later, you could run it in Kubernetes and try to automate it.

Governance of agent goals is where we're headed next. Human-in-the-loop for every single action does not scale. Same with durable memory. Past investigations are incredibly valuable for SRE work, and that still rings true when you put AI in production.

If you have opinions on any of this, reach out. We're committed to keeping our work here done as fully open as possible. So, clone it, point it at your observability tools, ask it questions about your environment, and more importantly, give us your feedback. Thank you.