AURA: a Rust SRE agent platform configured in TOML
AURA is a production-tested SRE agent platform you can deploy in minutes. AURA handles the guardrails, APIs, state management, streaming, and failure handling required to put AI to work safely on production infrastructure.
At a glance
- What is it?
- Mezmo's AURA wraps LLM agents in operator-defined guardrails, approval gates and OpenTelemetry tracing so they can touch production infrastructure. The trade-off is that the whole agent system lives in reviewable configuration, which is the point and also the work.
- Who is it for?
- Adopt AURA if you want agent behaviour expressed as reviewable TOML and you can run the model providers, MCP servers and storage backends inside your own network boundary. Do not adopt it if you want a hosted agent that works out of the box, or if you cannot staff the approval workflow that fail-closed tool calls depend on.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap AURA fills between an LLM and a production cluster
Most teams that want an agent to look at Kubernetes events, Prometheus latency and deployment history end up writing the same plumbing: a tool registry, a conversation loop, retry handling, a place to park oversized tool output, and some way to stop the agent from running a destructive command. AURA ships that layer. The README describes it as handling "the guardrails, APIs, state management, streaming, failure handling, and observability needed to connect AI models to production tools within operator-defined boundaries." The target reader is an SRE or platform engineer who already runs the observability stack and wants an agent on top of it, not a product team building an assistant for end users. Mezmo states the project began as its internal harness for operating its own SaaS and that it still runs that way internally, which is the strongest claim in the repository and also one you cannot verify from the README alone.
TOML as the control plane for models, agents and approvals
The architectural decision that shapes everything else is that the agent system is declared in configuration rather than code. Models, specialist agent teams, per-agent prompts, tools, approval policies and guardrails all live in TOML files that can be versioned and reviewed. That means a change to what an agent is allowed to do shows up as a diff, which is a meaningful difference from frameworks where the tool list is assembled at runtime in application code. The README's demo describes three specialist agents correlating Mezmo traces and logs, Prometheus latency and Kubernetes deployment history to identify an N+1 regression in productcatalogservice 1.13.2 and recommend a rollback to 1.13.1. Multi-agent coordination is described as dependency-aware task execution, and oversized tool results are parked on disk for selective retrieval rather than being pushed into the context window. Model providers are swappable by configuration: OpenAI, Anthropic, Bedrock, Gemini, Ollama or OpenRouter, with the option to assign different models to different roles. Tools come from MCP servers over Streamable HTTP, SSE or STDIO, and grounding can come from Qdrant or AWS Bedrock Knowledge Bases. The same TOML carries approval policy: sensitive tool calls can require webhook or in-conversation approval, and the README states that denial, timeout and transport failures are handled fail-closed.
Getting it running: install script, aura init, aura
Installation on Linux or macOS is a single command from the README: curl -fsSL https://raw.githubusercontent.com/mezmo/aura/main/scripts/install.sh | bash. The script downloads published release artifacts and verifies their checksums, which is the supply-chain step worth confirming against SECURITY.md rather than taking on faith. From there, aura init prompts you to choose an LLM provider and an initial model and writes the initial config file. Running aura with no arguments starts the agent. Two paths exist for consuming it: the CLI, or an OpenAI-compatible API endpoint that the README says lets clients such as LibreChat and OpenWebUI work unchanged. A2A is supported for agent-to-agent connections, and the Rust core can be embedded directly in an application. Agent Skills following the agentskills.io format load task-specific instructions and supporting files only when needed, which keeps unrelated skill text out of context. The integrations table lists AWS, Azure, GCP, Kubernetes, Docker, Datadog, New Relic, Kafka, GitHub, GitLab, Jira, Confluence, Notion and Mezmo, all reached through compatible MCP servers rather than native connectors.
Where the boundary actually sits, and where it leaks
AURA's security story is an operator-managed boundary, and the README is unusually direct about its edges. The agent sends prompts and tool data to whichever model providers, MCP servers, approval services, storage backends and tracing destinations you configure. Enabled client-side tools and STDIO processes can open additional network connections unless system-level network policy stops them. The paragraph on credentials is the one to read twice: secrets supplied through environment variables or secret mounts stay out of prompts only when they are referenced from designated authentication fields, and environment substitution in prompt-bearing fields places their values into model context. That is a configuration mistake with a quiet failure mode, since the agent will keep working normally while your token sits in a request to a third-party model. The README also points to prompt-injection risk in SECURITY.md. Air-gapped operation is possible, but only when model providers and MCP servers are locally reachable, so a team expecting to point AURA at a hosted API and still call the deployment air-gapped is mistaken. Mezmo CLI product telemetry is described as separately disclosed and controlled, which implies a default you should check rather than assume.
What AURA is not: no built-in knowledge base, no opinion on your runbooks
Two absences stand out. First, retrieval is delegated. Grounding comes from Qdrant or AWS Bedrock Knowledge Bases, so if you have no vector store and no appetite for running one, the RAG path is unavailable to you until you add that dependency. Second, AURA supplies no runbook content. The Confluence and Notion integrations let agents search and maintain operational runbooks, but the quality of an investigation still depends on what your organisation wrote down and how well the MCP server exposes it. A team with thin documentation will get a confident-sounding agent with nothing to ground on. The approval gate is also a staffing commitment, not a checkbox: fail-closed behaviour means an unreachable approval webhook blocks the tool call rather than letting it through, so someone has to be reachable when the agent wants to act. Release cadence is worth noting too. Three releases landed in September 2026 alone, v0.2.13 through v0.2.15, and the version numbers say the project is still pre-1.0. Pin a version and read the release notes before upgrading rather than tracking main.
Alternatives: LangGraph, CrewAI and the DIY harness
The closest comparisons are general agent frameworks such as LangGraph and CrewAI, and the alternative of writing your own harness. The difference is where the policy lives. In a general framework you typically compose agents, tools and control flow in Python or TypeScript, which gives you arbitrary logic and a large ecosystem, but approval policy, audit tracing and fail-closed semantics are things you build or bolt on. AURA puts those in TOML, which constrains what you can express and buys reviewability in return. The DIY route gives complete control and no upgrade treadmill, at the cost of owning state management, streaming, oversized-result handling and tracing yourself. If your agents only read from systems and never act, a general framework is the lighter choice. AURA's premise is that agents will act on production infrastructure, and that the guardrail layer is not optional once they do.
Licence, maintenance and what a version bump costs you
AURA is Apache-2.0, which permits commercial use, modification and redistribution with the usual requirements around notices and patent terms. This is not legal advice; check the LICENSE file and your own counsel if you plan to redistribute a modified build. The practical maintenance cost is not the binary. It is the TOML. Every model provider you add, every MCP server you wire in, every approval policy you tighten and every per-agent prompt you edit is configuration that has to be reviewed and kept current, and the pre-1.0 release cadence means config keys can move between minor versions. Treat the TOML as code: keep it in version control, pin the AURA version in your deployment, and read the release notes between v0.2.x tags before upgrading. The install script's checksum verification covers artifact integrity at download time and nothing after it.
Editorial conclusion
Adopt AURA if you want agent behaviour expressed as reviewable TOML and you can run the model providers, MCP servers and storage backends inside your own network boundary. Do not adopt it if you want a hosted agent that works out of the box, or if you cannot staff the approval workflow that fail-closed tool calls depend on. Before committing, read SECURITY.md end to end, then run aura init and check which fields your provider credentials land in: values substituted into prompt-bearing fields go into model context, and only designated authentication fields keep them out.
Community notes