# AURA in practice: real-world use cases for production AI agent infrastructure _How platform and SRE teams are using Mezmo's open-core agent framework — with any LLM, any tools, any observability backend._ **By the Mezmo Engineering Team  •  March 2026  •  8 min read** When we [open-sourced AURA](/content/blog/why-we-open-sourced-aura-infrastructure-for-production-ai/index.html) under the Apache 2.0 license, we made a deliberate choice: the agent infrastructure that powers Mezmo's own agentic SRE capabilities should be available to every team building production AI workflows. Not a stripped-down SDK. Not a managed-only service. The same framework we run internally, released as an open-core project where Mezmo is the primary contributor and steward. AURA (now available at [https://github.com/mezmo/aura](https://github.com/mezmo/aura)) is a production-ready framework for composing AI agents from declarative TOML configuration. It is built in Rust, with MCP tool integration, vector search, and an OpenAI-compatible streaming API. It is intentionally agnostic: you choose your LLM provider, you connect your tools through MCP, and your telemetry goes wherever you send it via OpenTelemetry. This post walks through concrete use cases where [AURA](/content/aura/index.html) is already delivering value. Each scenario includes the architectural pattern, the relevant AURA configuration, and the operational outcome so you can evaluate whether this fits your own stack. ## Use case 1: Drop-in AI agent for existing chat UIs Your team has already standardized on a chat interface like LibreChat, OpenWebUI, or a custom frontend that speaks the OpenAI protocol. You want to add an AI agent that can call operational tools (query logs, check dashboards, pull runbooks), but you don't want to rewrite your frontend or build custom API integrations. **With AURA** AURA exposes a fully OpenAI-compatible `/v1/chat/completions` endpoint with streaming SSE support. Point your existing frontend at AURA's address and it works immediately, with no protocol translation and no adapter code. Behind that endpoint, AURA routes requests to whichever LLM provider you've configured (OpenAI, Anthropic, Bedrock, Gemini, or Ollama for local models) and dynamically discovers MCP tools at runtime. Beyond tool connectivity, AURA also provides native vector search support for incorporating company knowledge bases and runbooks directly into your agent's context. Vector stores are configured in your TOML alongside everything else, with Qdrant as the currently supported external provider. This means your chat agent doesn't just call tools — it can query your team's operational documentation to ground its responses in institutional knowledge. **Configuration snapshot** .png) ## Use case 2: Runbook-grounded incident response agent When an incident fires at 3 AM, the on-call engineer doesn't need a chatbot that guesses. They need an agent that references the team's actual runbooks, understands the service topology, and provides grounded recommendations rather than hallucinated ones. **With AURA** AURA's vector search is ready to go out of the box. We intentionally moved away from traditional RAG (where retrieved chunks are injected into the context window upfront) in favor of a query-based approach. The agent queries vector stores on demand during a conversation, pulling in only the information relevant to the current question. This avoids pre-polluting the context window with documents that may not be relevant. Currently, Qdrant is the supported external vector store. You configure your collections directly in TOML, and each collection gets a `context_prefix` that gives the LLM a concise description. Think of it as a label — something like "Mezmo Operations Manual" or "Payment Service Architecture" — that tells the model which knowledge base is relevant for a given question. **Configuration snapshot** .png) ## Use case 3: Flexible LLM provider selection Different teams, different use cases, and different cost profiles call for different models. Maybe your incident response agents need a frontier model on Anthropic, but your log summarization workflow runs fine on a local open-source model. **With AURA** AURA supports five LLM providers out of the box: OpenAI, Anthropic, AWS Bedrock, Google Gemini, and Ollama. Changing providers is a configuration change, not a code change. Where this flexibility really shines is with models available across multiple providers. Claude models, for example, can be accessed through both Anthropic's API and AWS Bedrock. AURA lets you make that routing decision in config based on your compliance, latency, or cost requirements — without touching any application logic. **Open-source model support** We actively test AURA against leading open-source models using platforms like Ollama and llama.cpp. Local quantized models can sometimes emit malformed structured outputs, which breaks tool-calling workflows. AURA includes fallback tool-call parsing that works around these known issues so open-source models remain viable in production. ## Use case 4: Authorization delegation to downstream tools Your agent calls MCP tools that require authentication, and the credentials need to come from the original user's request — not from a hardcoded service account. **With AURA** AURA's `headers_from_request` configuration forwards incoming HTTP headers to downstream MCP servers on a per-request basis. This means the authentication token from the original user request flows through to every tool call. ## Use case 5: Understand what your agent is doing and why You're running AI in production and struggling to understand why it behaves a certain way. **With AURA** AURA ships with OpenTelemetry support enabled by default, and we chose the OpenInference semantic conventions for our span attributes. It captures the semantics that matter for debugging agent behavior: LLM invocations, tool calls, retrieval operations, and the relationships between them. ## Use case 6: Embedding AURA's core in your own Rust application You don't want a standalone HTTP server. You want to embed AI agent capabilities directly into your own Rust service. **With AURA** AURA is structured as three independent Rust crates with clear separation of concerns: - **aura** — The core agent builder library. - **aura-config** — Typed TOML parsing and validation. - **aura-web-server** — The OpenAI-compatible REST/SSE serving layer. ## Mezmo's open-core model: what it means in practice AURA is not a side project or a marketing exercise. It is the agent infrastructure layer that powers Mezmo's own [Agentic SRE](/content/agentic-sre/index.html) product. What this means concretely: - **Mezmo is the primary contributor.** We maintain the project, merge PRs, publish releases, and run the CI pipeline. - **Production-hardened by default.** Features like graceful shutdown, streaming backpressure controls, request cancellation, and timeout configuration exist because Mezmo needs them in production. - **No vendor lock-in by design.** AURA doesn't require Mezmo as a backend. Use it with any compatible LLM provider, any MCP servers, and any OTLP-compatible observability platform. - **The roadmap is visible.** Multi-agent orchestration is actively being developed on the [feature/orchestration-mode](https://github.com/mezmo/aura/tree/feature/orchestration-mode) branch. ## Getting started Access our quickstart guide here: [https://github.com/mezmo/aura/tree/main/examples/quickstart](https://github.com/mezmo/aura/tree/main/examples/quickstart) To build and run AURA locally: 1. Clone the repo: `git clone https://github.com/mezmo/aura` 2. Copy the reference config: `cp examples/reference.toml config.toml` 3. Set your API key: `export OPENAI_API_KEY="your-key"` 4. Build and run: `cargo run --bin aura-web-server` 5. Or use Docker: `docker compose up --build` The `examples/` directory includes minimal per-provider configurations and complete agent examples. The `development/` directory has ready-to-go setups for LibreChat and OpenWebUI integration. ## The foundation, not the ceiling AURA is the infrastructure layer we wish we'd had when we started building AI into Mezmo's own platform. It handles the production engineering that usually kills AI projects after the demo: provider interoperability, schema sanitization, timeout and backpressure controls, observable tracing, and declarative configuration that lives in version control. We're releasing it as open-core because we believe the orchestration layer between your data and your models should be something you own, inspect, and extend — not something you rent. **Explore the repo:** [https://github.com/mezmo/aura](https://github.com/mezmo/aura) **Learn more about AURA:** [https://www.mezmo.com/aura](/content/aura/index.html)