Operations | Monitoring | ITSM | DevOps | Cloud

The bucket is right there and the function still cannot read it. AURA reads the failure, names the one missing action, and returns the policy to add. A permissions failure gives you the symptom and not the action name. The usual path is reading the error, guessing which actions the execution role is short, and widening the policy until the call goes through. Greg hands AURA a Lambda function that fails when it tries to reach an S3 bucket. AURA identifies the missing ListBucket permission on that particular bucket and returns the minimum policy needed to allow it.

AURA runs as a standalone service and knows nothing about Slack. A separate bridge streams events off its API, which is what makes the chat tool swappable. This is the implementation behind the automated PagerDuty investigation demo. Jeff Vogt walks the whole path an incident takes: a Grafana alert fires PagerDuty, PagerDuty opens a Slack channel and sends a webhook, and a service called AURA Bridge picks it up and calls AURA's API with an investigation prompt.

Two engineers can hold the same approve button and still not be allowed to make the same change. The key riding with the approval settles it. AURA's human in the loop config gates the create_pipeline tool on the Mezmo MCP server and sends each request to a webhook for review. A mock UI stands in for the approval system here, and Mike walks through the payload schema so you can point it at your own.

Nobody wants an API key sitting in an agent's config file on a shared server. Mike shows how AURA takes the credential off the request instead. AURA can hold your keys in its config file, but it does not have to. Mike Shearer, one of AURA's creators, walks through the alternative: AURA reads named headers off the incoming request and forwards them to the MCP servers it calls, so the credential never has to sit on disk.

Ingestion stops, and you start reading system tables by hand to find out why. This run checks disk, merges, and replication across every replica first.

3 a.m., the pager fires, and the runbook describes a service that shipped three versions ago. Ask the agent what the cluster actually has instead. Runbooks go stale because clusters change faster than documentation does. Every deploy, every new service, every renamed alert widens the gap between what is running and what is written down.

1,133 requests failed on one bad commit. The patch and the regression test are already written by the time anyone is asked to read the exact diff. This demo runs AURA as one step inside a Temporal workflow, alongside Codex. A GET request against a product catalog service goes from success to HTTP 500, and ClickHouse records the version, commit, trace ID, and exact error for every request. By the time AURA investigates, all 1,133 requests on that version have failed.

Checkout starts failing because the cart service keeps dying. The real cause is a recent pull request that let memory grow with every add to cart.

The same agent that reads a Kubernetes cluster reads a Windows machine. One MCP server, one config entry, and the questions are the ones you already ask.

You get an answer from the agent and no way to check how it got there. The route it took is recorded, and so is the reason it gave for taking it. AURA emits OpenTelemetry spans, and the Docker quickstart wires them straight into Phoenix. Four services come up together: AURA Web Server as the persistent agent harness, LibreChat as a browser interface for chatting with the agent, Phoenix to receive the spans, and MongoDB to store stateful data for LibreChat. The Compose file arrives pre-configured to point AURA at Phoenix and to enable content recording for the local demo.

Building an agent and not sure how to approach something? Bring it. AURA office hours are recurring working sessions with the people who build it. The team has been talking to people trying out AURA and hearing the same good questions come up more than once. Office hours are the answer to that: a standing slot on a schedule, rather than one conversation at a time. The format is deliberately loose. Nobody is arriving with thirty slides to spend an hour talking at you. The session goes wherever the questions go.

A big tool result does not have to be a big context cost. AURA moves it to disk and hands the model a pointer plus the tools to navigate what is there. A large MCP tool result can consume or overflow an agent's context window, and on a third-party server you do not control how much comes back. Scratchpad breaks the link between how big a tool result is and how much context it costs: the full output goes to disk, and only the slice the model asks for ever enters the window. Errors always pass through inline, so the model can react to them.

The model, the serving layer, and the agent asking questions all sit on local hardware. The first thing it debugs is the AI stack it is running on. No external inference provider in the path.

Give one agent every tool and every incident is a question of trust. This one hands each job to a worker that can only reach what that job needs. One AURA configuration defines a coordinator and three specialist workers. Qdrant stores the runbooks, Prometheus measures workload health, and Kubernetes provides inspection and remediation, and each of the three is wired to one worker.

An on-call question returns the threshold and the escalation owner from your own runbooks, and the answer comes back without a call to anyone outside. AURA runs against Bedrock as its model provider, using Claude Sonnet 5 served by AWS in the same region. Authentication is the normal AWS credential chain: a profile on a laptop, an IAM role in EKS.

You ask for a routine health check and expect a clean baseline. What came back was a pod that had restarted 788 times, unrelated to the question. AURA is connected to a Kubernetes cluster and to Prometheus through read-only MCP servers, running as one coordinator with two specialized workers. The prompt is one sentence: check the health of the cluster, and confirm whether all the pods are running. What comes back is not a baseline. AURA names the state as CrashLoopBackOff and attaches the restart count to it.

The platform shows you which service is failing and which paths it touches, and stops there. Point AURA at the same telemetry and the cause comes back too. Dash0 shows the product catalog service in a failed state across the selected window, with errors on the path from the frontend service.

Knowing why it broke is not the same as having it repaired. Point the agent at the repos behind the service and the change comes back as a pull request. A Govee integration crash-loops under Home Assistant because the container cannot write to a directory it does not own. That much was already established: the previous homelab video stopped at the root cause on purpose, so the next pass could improve the agent's configuration first.

A deployment fails validation and the sync stops. Argo CD hands the report to AURA, which finds the wrong version, fixes it, and re-runs the sync. Normally, a failed sync means a person opens the application, reads the hook logs, and works out which value is wrong. Here, the sync fail hook sends AURA a short failure report and an incident ID over the agent-to-agent protocol, then exits. It does not say how to investigate or what to change.

A scheduled Lambda quietly stops completing and nothing pages you. AURA finds the function, reads its logs, and comes back with a three-second timeout. The usual path is opening the console, tracking down the right log group, and reading CloudWatch by hand. Here AURA connects to AWS through the MCP proxy AWS publishes, run locally with uvx against an AWS CLI that is already configured, so there are no new credentials to issue.

Some agent work should pause for a person. This is the other case: a health check every two minutes, one bounded action, and a result nobody approved. Each scheduled run starts the normal AURA image in one-shot mode: check one workload, act if something is wrong, write the result to the job log, and exit. Overlapping runs are forbidden.

A coworker says checkout is broken and nothing else. That is the whole prompt. AURA reads the live logs and comes back with the payment service. Normally a message like this is the start of guessing at a service and opening dashboards until something looks wrong. Here it is the entire input: no service named, no error string, no time range.

A root cause is not a fix. AURA keeps working the problem, taking what you find on the host and coming back with the user ID mismatch behind the failure. What follows a root cause is normally manual: check the mount, compare ownership on the host against the user inside the container, and get it wrong at least once before it lands.

One integration token, one config file, no code. AURA routes the question to a runbook-reader worker, queries Notion, and answers from what your team wrote.

The most common question since we started 31 Days of AURA: how do you plan to make money? The short answer is the control plane, not the agent. Mezmo sells an enterprise-grade control plane for running large numbers of agents across large environments, where coordinating across environments, governance, access control, and the efficiency of preprocessing MCP data start to matter. If a hundred people run AURA and three or four of them need that, the model works. The more people running AI agents in production, the bigger the market for the tooling underneath them.

Wondering what the catch is on a free, vendor-backed agent? There is not one in the license. AURA stays Apache 2, fully capable, and free to run. If you are weighing an open source tool with a company behind it, the first question is what the catch is. You have seen the project that turns out to be open core, or that is quietly hindered in one key way. This is Mezmo's answer for AURA.

AURA does not have to live on your laptop. Install it into the cluster with Helm and it is still there the next time something breaks. AURA is a fully open source AI agent built specifically for SRE work. Rather than one general assistant, you configure workers: separate agent roles, each scoped to a job like inspecting the cluster.

Reaching a tool and being allowed to use it are two separate lists in the config. Put the mutable Kubernetes tools on the second one and each call pauses.