Operations | Monitoring | ITSM | DevOps | Cloud

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.

AURA is a fully open-source agentic harness built for SRE and production operations work. In this walkthrough, Mezmo forward deployed engineer Jeff iinstalls AURA on a local desktop, runs `aura init` to generate the config and connect it to an Anthropic Sonnet model, then wires in a Grafana MCP server pointed at his homelab. He hands AURA a live incident: a set of addressable LED lights that stopped responding to Home Assistant.