# mezmo/aura: a Rust SRE agent platform you configure in TOML > AURA is an Apache-2.0 Rust agent platform aimed at SRE work on production infrastructure. Its selling point is not the model, it is the operator boundary: agents, tools, approvals and telemetry all live in reviewable TOML. **mezmo/aura** — 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. - Repository: https://github.com/mezmo/aura - Website: https://www.mezmo.com/aura - Stars: 392 · Forks: 37 - Language: Rust - License: Apache-2.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/mezmo-aura ## What mezmo/aura is used for, and who it is actually for AURA targets one job: letting an LLM read your production telemetry and act on it without handing the model an unbounded shell. The README frames it as a "production-tested SRE agent platform you can deploy in minutes", and the repository backs that framing with a specific claim: AURA started as Mezmo's internal harness for operating its own SaaS, and the README states that engineering and SRE teams at Mezmo still use it for production operations, with teams outside Mezmo running it in their own environments. The intended user is an SRE or platform engineer who already has observability data and wants an agent to correlate it. The demo described in the README is concrete: AURA investigates a payment failure by correlating Mezmo traces and logs, Prometheus latency, and Kubernetes deployment history; three specialist agents identify an N+1 regression introduced by productcatalogservice 1.13.2 and recommend rolling back to 1.13.1. That example also defines the boundary. Nothing in the README suggests AURA replaces your observability stack. It reads from tools you already expose through MCP servers, and the integrations table lists AWS, Azure, GCP, Datadog, New Relic, Kubernetes, Docker, Kafka, GitHub, GitLab, Jira, Confluence and Notion among the targets. If your telemetry is not reachable through one of those paths, AURA has nothing to investigate. ## The TOML configuration model and the multi-agent task graph The design choice that separates AURA from a chat wrapper is that the agent system is a configuration artifact. The README states that models, specialist agent teams, per-agent prompts, tools, approval policies and guardrails live together in TOML that can be versioned and reviewed. The repository layout matches this: a configs/ directory, a quickstart.toml at the root, and an examples/ tree with minimal, complete, multi-agent, quickstart-k8s-sre and quickstart-orchestration-math variants plus a reference.toml. On execution, the README describes dependency-aware task execution across specialist agent teams, with oversized tool results parked on disk for selective retrieval rather than pushed whole into context. Agent Skills load task-specific instructions and supporting files only when needed. Tool discovery happens over MCP using Streamable HTTP, SSE or STDIO, and grounding can come from Qdrant or AWS Bedrock Knowledge Bases. Two details matter more than the feature list. First, provider choice is a configuration change, not a rewrite: the README names OpenAI, Anthropic, Bedrock, Gemini, Ollama and OpenRouter, and says different models can be assigned to different roles. Second, the source is a Cargo workspace split into crates/aura, aura-config, aura-events, aura-telemetry, aura-web-server and aura-cli, so the runtime can be embedded rather than only run as a server. The workspace pins a Mezmo fork of rig-core at a fixed git revision, and the Cargo.toml comments explain why: crates.io 0.3.11 and later pull a rig-core that is semver-incompatible with the fork. That is a real supply-chain constraint, not a stylistic preference. ## Installing AURA and running a first agent The README gives an install script for Linux and macOS that downloads published release artifacts and verifies their checksums: ```bash curl -fsSL https://raw.githubusercontent.com/mezmo/aura/main/scripts/install.sh | bash ``` After that, initialize a local agent. The README says this step asks you to choose an LLM provider and an initial model, and writes the initial config file: ```bash aura init # Choose an LLM provider and initial model, and write the initial config file ``` Then start it: ```bash aura ``` The repository also ships a Docker path. The compose file defines an aura service on image mezmo/aura:latest, running the webserver subcommand, publishing port 8080, reading CONFIG_PATH=/app/config/quickstart.toml, and mounting the local quickstart.toml read-only into the container. A healthcheck curls http://localhost:8080/health, and the service restarts unless stopped. ```yaml services: aura: image: mezmo/aura:latest command: - ./aura - webserver - --verbose ports: - "8080:8080" ``` The same file sets AURA_CUSTOM_EVENTS to "true" so the orchestrator's plan and worker events render, and points OTEL_EXPORTER_OTLP_ENDPOINT at a Phoenix instance. The comment notes this is safe for LibreChat as of v0.8.6, whose SSE parser skips unknown event types instead of failing on them. If you are wiring a different client, that compatibility note is worth reading before you turn custom events on. ## Approvals, fail-closed behaviour and the prompt-injection caveat The production safety section is the part worth reading twice. Sensitive tool calls can require explicit human approval through a webhook or in-conversation, and the README states that denial, timeout and transport failures are handled fail-closed. Fail-closed is the right default here: if the approval service is unreachable, the safe outcome is that the tool call does not run. The data-handling disclosure is unusually direct for a project of this kind. AURA sends agent prompts and tool data to the model providers, MCP servers, approval services, storage backends and tracing destinations you configure. Enabled client-side tools and STDIO processes can initiate additional network traffic unless system-level network policy prevents it. The README also draws a line that is easy to miss: credentials supplied through environment variables or secret mounts stay outside prompts only when referenced from designated authentication fields, and environment substitution in prompt-bearing fields places those values into model context. That last sentence is the practical trap. If you substitute a token into a prompt template, you have put the token into the model's context, and the README points to SECURITY.md for prompt-injection risks and supply-chain verification. Air-gapped operation is listed as possible, but only when model providers and MCP servers are locally reachable, which in practice means a local model through Ollama or similar rather than a hosted API. ## Where AURA is the wrong tool AURA assumes you have production infrastructure worth investigating and a boundary you can define. If neither holds, the platform is overhead. A team that wants a general coding assistant, a documentation chatbot, or a single-shot question-answering tool gets nothing from multi-agent task graphs, approval webhooks or OpenTelemetry spans for every LLM turn. The second limit is deployment shape. The README positions AURA as something you run inside your own security boundary, and the Dockerfile is a full Rust cross-compilation pipeline with cargo-zigbuild, nfpm packaging and Cloudsmith publishing. That is a serious build. If you cannot run a container or a binary in the network segment where your telemetry lives, the air-gapped story does not apply to you, because AURA still needs to reach whatever serves the model. Third, the project is young and moving. The workspace version is 0.2.17, and releases v0.2.13, v0.2.14 and v0.2.15 landed within roughly two days of each other in early September 2026. The README does not document a configuration migration path between versions. Treat your TOML as code that will need edits, and keep the version you validated pinned rather than tracking latest. ## How AURA differs from a general-purpose agent framework The obvious comparison is a general agent framework such as LangChain or a hosted assistant built on it. The difference is not capability, it is where the safety logic lives. In a typical framework you write the approval check, the retry policy and the trace export yourself, and the agent's definition is scattered across code. AURA puts those in the platform and exposes the agent definition as TOML, so the reviewable artifact is the configuration rather than the orchestration code. The second difference is the interface surface. AURA serves agents through an OpenAI-compatible API, so clients such as LibreChat and OpenWebUI work unchanged, and it can connect to other agents over A2A or be embedded through its Rust core. A framework that expects you to build the server first has a longer path to the same point. The trade-off is real. Choosing AURA means accepting its configuration schema, its pinned rig-core fork and its Rust workspace as your substrate. If you want to write orchestration in Python and own every line of it, a general framework is the better fit, and AURA's TOML abstraction will feel like a constraint rather than a guardrail. ## Licence, maintenance and what an upgrade actually costs AURA is licensed under Apache-2.0, and the Cargo workspace declares the same identifier at the package level. The README links SECURITY.md for telemetry defaults, permission boundaries and supply-chain verification. Mezmo CLI product telemetry is described as separately disclosed and controlled. Apache-2.0 permits commercial use and modification with the usual notice and patent terms; this is a description of the licence, not legal advice, and the SECURITY.md and LICENSE files are the authoritative sources. Maintenance is active by the only measure available: the last push to the default branch was on 2026-09-10, and the repository is not archived. The release cadence is fast, with three releases in the first days of September 2026 and a workspace version of 0.2.17. The upgrade cost is concentrated in two places. Your TOML configuration is the contract with the runtime, and the README does not describe a migration tool or a schema-version key, so a version bump may require manual edits. The dependency graph is the second: the workspace pins rig-core and rig-bedrock to a specific commit of a Mezmo fork because newer crates.io versions are semver-incompatible. Any upgrade that moves that revision can change model-provider behaviour in ways your configuration does not express. ## Conclusion Adopt AURA if you already run Kubernetes, Prometheus or cloud telemetry and you want the agent definition to be a file your team reviews in a pull request, with sensitive tool calls gated behind approval. Do not adopt it if you want a hosted assistant, or if you need a stable configuration schema: the workspace version moved from 0.2.15 to 0.2.17 across three weeks of releases, so before committing, run aura init against your own provider and confirm which approval and telemetry keys your build actually accepts. ## FAQ ### How do I install mezmo/aura on Linux or macOS? The README gives a single install script that downloads published release artifacts and verifies their checksums: curl -fsSL https://raw.githubusercontent.com/mezmo/aura/main/scripts/install.sh | bash. After that, run aura init to choose an LLM provider and initial model, then run aura to start the agent. ### What is Mezmo AURA used for? It is an SRE agent platform for investigating production incidents. The README's demo shows AURA correlating Mezmo traces and logs, Prometheus latency and Kubernetes deployment history, with three specialist agents identifying an N+1 regression and recommending a rollback. ### Does mezmo/aura require a hosted model provider? No. The README lists OpenAI, Anthropic, Bedrock, Gemini, Ollama and OpenRouter as supported providers, and says air-gapped operation is possible when model providers and MCP servers are locally reachable. The provider is selected during aura init and can be changed in configuration. ### How does mezmo/aura keep sensitive tool calls under human control? Sensitive tool calls can require explicit approval through a webhook or in-conversation, and the README states that denial, timeout and transport failures are handled fail-closed. Credentials stay outside prompts only when referenced from designated authentication fields, not when substituted into prompt-bearing fields. ## Sources - [License: Apache-2.0](https://github.com/mezmo/aura/blob/main/LICENSE) - [mezmo/aura on GitHub](https://github.com/mezmo/aura) - [Project website](https://www.mezmo.com/aura) - [README](https://github.com/mezmo/aura/blob/main/README.md) - [Releases](https://github.com/mezmo/aura/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mezmo-aura