Training Example: Mezmo – Review the Data, Give Your Score & Compare to the Real AI Evaluation

[H1] The intelligence layer for production AI
Mezmo's Active Telemetry reduces millions of raw events into curated, context-rich signals. AURA, the open-source control plane on your infrastructure, orchestrates agents that get smarter with every incident. Together, they give your AI the right data and the framework to act on it.Start building with AURATalk to an engineer
Mezmo
Active Telemetry shapes agent context

99.98%
data reduction before agents see it, saving tokens and money

Curated context via MCP
↕
Your infrastructure

AURA
Open-source agent control plane
Apache 2.0 · Rust · Your infra

<1min
total investigation

<1K
signals (vs millions of raw signals)

<$1
per investigation (vs $30+ with other solutions)

Where do you want to start?
[H2] Pick your entry point
Pick the one that matches where you are. We have something for you at each step of the journey.AURA
[H3] Single Agent
Pick a use case (incident triage, runbook RCA, or on-call assistant). Wire it up with a TOML config. Ship your first production agent in under an hour.OpenAI-compatible with streaming SSE: Point LibreChat, OpenWebUI, or any existing frontend at it—zero adapter code.LLM agnostic: OpenAI, Anthropic, Bedrock, Gemini, Ollama, etc.MCP tool discovery at runtime: Datadog, PagerDuty, Slack, internal APIs—dynamic discovery, no code changes.Pre-built agentic SRE workflows grounded in your runbooks: Triage agent fires first, passes curated context to RCA agent, remediation agent acts on confirmed root cause.< 1 hr to running an agent5 LLM providers0 boilerplateQuick start guideLive use cases[llm]
provider = "anthropic"
api_key = "{{ env.ANTHROPIC_API_KEY }}"
model = "claude-opus-4-6"
[agent]
name = "Ops Assistant"
system_prompt = "You're an SRE assistant"
turn_depth = 3
[mcp.servers.clickhouse]
transport = "http_streamable"
url = "http://clickhouse-mcp:8000/mcp"
[mcp.servers.clickhouse.headers]
Authorization = "Bearer {{ env.MCP_TOKEN }}"
# Optional: Connect to Mezmo's MCP Server
[mcp.servers.mezmo]
transport = "http_streamable"
url = "https://mcp.mezmo.com/mcp"
[mcp.servers.mezmo.headers]
Authorization = "Bearer {{ env.MEZMO_API_KEY }}"AURA
[H3] Agent Team
One agent handled one job. Now coordinate a team of specialized agents to triage, investigate, and remediate with an orchestrator managing handoffs.Multi-agent orchestration: Specialized workers coordinated by an orchestrator agent for complex, multi-step investigations.Safety controls: turn_depth, streaming timeouts, graceful shutdown, backpressure. Human-in-the-loop approval gates before any remediation action.OpenTelemetry + OpenInference tracing: Full audit trail across every agent—plans, prompts, tool calls, handoffs. Egresses to Arize Phoenix, Jaeger, Datadog, Mezmo.15 → 5 min MTTR60-80% toil eliminated4 hrs → auto post mortemQuick start guideLive use cases# Orchestrator routes to specialist agents
[llm]
provider = "openai"
api_key = "{{ env.OPENAI_API_KEY }}"
model = "gpt-5.2"
[[vector_stores]]
name = "runbooks"
type = "qdrant"
url = "http://{{ env.QDRANT_HOST | default: 'localhost' }}:6334"
collection_name = "sre_runbooks"
context_prefix = "Operational runbooks covering incident response procedures, known failure modes, and troubleshooting guides"
embedding_model = { provider = "openai", model = "text-embedding-3-small", api_key = "{{ env.OPENAI_API_KEY }}" }
[agent]
name = "SRE Orchestrator"
system_prompt = """
You are an SRE Orchestrator. Decompose incident response tasks and delegate:
- incident-responder: PagerDuty incident lookup, alert details, oncall schedules
- metrics-analyst: Prometheus queries to validate alerts and check trends
- log-analyst: Log search, error patterns, timeline correlation
Maximize parallel execution when tasks have no data dependency.
"""
turn_depth = 15
temperature = 0.3
[mcp]
sanitize_schemas = true
[mcp.servers.pagerduty]
transport = "http_streamable"
url = "https://mcp.pagerduty.com/mcp"
headers = { Authorization = "Token token={{ env.PAGERDUTY_API_KEY }}" }
description = "PagerDuty MCP for incident details, oncall schedules, and alert status"
[mcp.servers.prometheus]
transport = "http_streamable"
url = "http://{{ env.PROMETHEUS_MCP_HOST | default: 'localhost' }}:8080/mcp"
description = "Prometheus MCP for querying system metrics"
[mcp.servers.log_analysis]
transport = "http_streamable"
url = "https://mcp.mezmo.com/mcp"
description = "Log analysis MCP for searching and correlating log events"
[orchestration]
enabled = true
[orchestration.worker.incident-responder]
description = "PagerDuty incident triage: fetch incident details, parse alerts, check oncall schedules"
turn_depth = 8
mcp_filter = [
"list_incidents",
"get_incident",
"list_alerts_from_incident",
"get_alert_from_incident",
"list_services",
"get_service",
"get_current_time",
]
preamble = """
You are an Incident Responder. Use PagerDuty tools to fetch and parse incidents.
Extract: environment, alert category, severity, timestamp, metric value, RunBook URL, and triggering query.
Always use tools — do not fabricate incident data.
"""
[orchestration.worker.metrics-analyst]
description = "Prometheus metrics analysis: validate alerts, check trends, identify anomalies"
turn_depth = 20
mcp_filter = [
"execute_query",
"execute_range_query",
"list_metrics",
"get_current_time",
]
preamble = """
You are a Metrics Analyst. Query Prometheus to validate alerts, check trends, and identify anomalies.
Always get current time before range queries. Do not fabricate metric values.
Report query results clearly with metric names, labels, and values.
"""
[orchestration.worker.log-analyst]
description = "Log analysis: search logs, analyze error patterns, correlate events across time"
turn_depth = 20
vector_stores = ["runbooks"]
mcp_filter = [
"analyze_logs_*",
"deduplicate_logs_*",
"get_correlated_timeline_*",
"get_current_time",
"get_log_histogram",
"list_log_fields",
]
preamble = """
You are a Log Analyst. Search and analyze logs for operational investigations.
Search runbooks for known failure patterns when errors match documented scenarios.
Report findings with timestamps, error messages, and relevant context.
"""Mezmo
[H3] Engineered Context
Already using LangChain, CrewAI, or your own framework? The bottleneck is the data going in. Mezmo is the context layer that makes any agent smarter.Active Telemetry Pipeline: Deduplicate, cluster, enrich before agents see data. Up to 99.98% compression—every removed token saves inference cost.Agent-optimized MCP server: Returns curated, task-scoped data—not raw firehose. Just-in-time context delivery: Each workflow step gets precisely scoped data. Dynamic assembly as investigations unfold—not a dump of everything.~$1 per investigation99.98% data reduction50-70% more efficientContext engineeringAI SRE for RCATalk to teamAURA + Mezmo MCP (curated context)
[mcp.servers.mezmo]
transport = "http_streamable"
url = "https://mcp.mezmo.com/mcp"
headers = {
"Auth" = "Bearer {{ env.MEZMO_TOKEN }}"
}
# No local MCP server to run.
# Mezmo returns pipeline-processed signals,
# not raw API firehose.
# WITHOUT Mezmo (raw vendor MCP)
# → 2.4M tokens per investigation
# → 88% noise in context window
# → $30-36 per investigation
# → 14+ min MTTR
# WITH Mezmo pipeline + MCP
# → <1K curated signals
# → noise removed before agent sees it
# → <$1 per investigation
# → <5 min MTTRfrom langchain_mcp import MCPToolkit
from langchain_anthropic import ChatAnthropic
from langgraph.graph import StateGraph, MessagesState
# Connect to Mezmo's remote MCP server
mezmo = MCPToolkit(
transport="streamable_http",
url="https://mcp.mezmo.com/mcp",
headers={
"Authorization": "Bearer <YOUR_MEZMO_SERVICE_KEY>"
}
)
# Mezmo tools are now LangGraph-compatible
mezmo_tools = mezmo.get_tools()
# → search_logs, get_views, get_alerts,
# search_pipeline_components, ...
model = ChatAnthropic("claude-sonnet-4-20250514")
model_with_tools = model.bind_tools(mezmo_tools)
def agent(state: MessagesState):
return {"messages": [
model_with_tools.invoke(state["messages"])
]}
def tools(state: MessagesState):
# Mezmo returns curated, pipeline-processed data
return {"messages": [tool.invoke(tc) for tc in ...]}
graph = StateGraph(MessagesState)
graph.add_node("agent", agent)
graph.add_node("tools", tools) # ← Mezmo tools here
graph.add_edge("agent", "tools")
app = graph.compile()from crewai import Agent, Task, Crew
from crewai_tools import MCPServerAdapter
# Connect crew to Mezmo's remote MCP server
mezmo = MCPServerAdapter(
server_params={
"url": "https://mcp.mezmo.com/mcp",
"transport": "streamable_http",
"headers": {
"Authorization": "Bearer <YOUR_MEZMO_SERVICE_KEY>"
}
}
)
mezmo_tools = mezmo.tools
# → search_logs, get_views, get_alerts, ...
investigator = Agent(
role="Incident Investigator",
goal="Search Mezmo logs to identify root cause",
tools=mezmo_tools,
llm="anthropic/claude-sonnet-4-20250514"
)
responder = Agent(
role="Remediation Lead",
goal="Execute runbook steps based on findings",
tools=mezmo_tools + your_existing_tools,
llm="anthropic/claude-sonnet-4-20250514"
)
crew = Crew(
agents=[investigator, responder],
tasks=[
Task(description="Investigate alert: {alert}. "
"Search Mezmo logs for correlated errors.",
agent=investigator),
Task(description="Execute remediation.",
agent=responder),
],
)
result = crew.kickoff()from temporalio import workflow, activity
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client
from datetime import timedelta
@activity.defn
async def query_mezmo_logs(alert: dict) -> dict:
"""Search Mezmo logs via MCP.
Durable activity — retryable on failure."""
async with streamablehttp_client(
url="https://mcp.mezmo.com/mcp",
headers={
"Authorization": "Bearer <YOUR_MEZMO_SERVICE_KEY>"
}
) as (read, write, _):
async with ClientSession(read, write) as session:
await session.initialize()
result = await session.call_tool(
"search_logs",
arguments={
"query": alert["description"],
"from": "-1h",
"apps": alert.get("service_name"),
}
)
return {"logs": result.content}
@workflow.defn
class IncidentTriageWorkflow:
@workflow.run
async def run(self, alert: dict) -> dict:
logs = await workflow.execute_activity(
query_mezmo_logs, alert,
start_to_close_timeout=timedelta(seconds=30),
)
analysis = await workflow.execute_activity(
analyze_with_llm, logs,
start_to_close_timeout=timedelta(seconds=60),
)
return await workflow.execute_activity(
execute_remediation, analysis, ...
)from deep_agents import Agent, Tool, ReasoningChain
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client
class MezmoLogsTool(Tool):
name = "mezmo_logs"
description = "Search Mezmo logs via MCP"
async def execute(self, query: str, **kwargs):
async with streamablehttp_client(
url="https://mcp.mezmo.com/mcp",
headers={
"Authorization": "Bearer <YOUR_MEZMO_SERVICE_KEY>"
}
) as (read, write, _):
async with ClientSession(read, write) as session:
await session.initialize()
result = await session.call_tool(
"search_logs",
arguments={
"query": query,
"from": kwargs.get("from", "-1h"),
}
)
return result.content
agent = Agent(
model="claude-sonnet-4-20250514",
tools=[MezmoLogsTool(), your_datadog_tool,
your_pagerduty_tool],
reasoning=ReasoningChain(
strategy="tree_of_thought", max_depth=5
),
)
result = await agent.run(
"Investigate latency spike in checkout service"
)Mezmo
[H3] Control your data
Many teams start here. OTel migration, cost reduction, vendor consolidation. Get your data under control first, then layer agents on top when you're ready.Flexible telemetry routing: Ingest with OTel and route to Mezmo, Datadog, Grafana, Elastic, or S3. Migrate between destinations slowly or all at once.Cost profiling: Identify high-volume, low-value streams. Cut observability spend up to 70%.Proactive anomaly detection: Continuous monitoring for degraded signals and drift. Surface issues before they become incidents.Up to 70% cost reduction0 vendor lock-inProactive not reactiveOTel migrationAgentic SREPricingTalk to team
[H3] Examples
DevOps assistantDevOps assistantGitHubReviews PRs, explores repos, and manages code workflows.Build
Incident response agentIncident response agentPagerDuty + DatadogTriages alerts, pulls metrics, and correlates monitoring data.Build
Kubernetes SRE agentKubernetes SRE agentK8s cluster operations + monitoringInspects workloads, queries metrics, and assists with cluster troubleshooting.Build
The platform
[H2] Mezmo as the brain, AURA as the hands.
AI agents are only as good as the data they reason on. Mezmo makes that data clean, structured, and ready. AURA turns it into action.Mezmo is the data intelligence layerIngests, profiles, and understands telemetry in real-time with the ability to modify and alert in stream with pipelines. Easy to get started with over 100 integrationsIn-stream parsing and enrichment with intent-based directionOne-click oTel migrationAURA is the orchestration layerOpen-source agentic harness that orchestrates AI workflows across your stack. Forever open source & production ready.MCP-native tool connectivity, LLM agnosticSelf-correcting through: plan → execute → synthesize → evaluateCustom agentic runbooks
[H2] The right data for your agents. Faster resolution for your team.
From millions of signals to one root cause. Your agents are only as good as their data. Mezmo and AURA handle both. Get AURA on GitHubTalk to an engineer
[H2] Explore more
Why we need an open source system of context in the AI eraPressWhy we need an open source system of context in the AI eraRead now
Mezmo joins Agentic AI Foundation as a new memberPressMezmo joins Agentic AI Foundation as a new memberRead now
AURA in Practice: Real-world use cases for production AI Agent infrastructureBlogAURA in Practice: Real-world use cases for production AI Agent infrastructureRead now
Context Engineering for Observability - O'Reilly ReporteBookContext Engineering for Observability - O'Reilly ReportRead now
@2025 Copyright Mezmo Inc.

[H1] AURA in practice: real-world use cases for production AI agent infrastructure
Topics:Root Cause AnalysisAURAAI Agent InfrastructureAgentic ObservabilityHow 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 readWhen we open-sourced AURA 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) 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 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.
[H2] 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 AURAAURA 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‍The key here is that AURA plugs into your existing ecosystem rather than replacing it. Your team keeps the chat UI they already know. And while AURA does take over the MCP tool layer, that's intentional: instead of managing tool connections scattered across individual agents, you configure them once in AURA and every agent benefits. Mezmo, PagerDuty, your own internal services are all registered in one place, with one schema, and AURA handles the orchestration, translation, and vector search from there.Any service your agent needs to interact with must expose an MCP endpoint. AURA connects to tools through MCP — that is the integration contract. If a tool has an MCP server, AURA can discover and invoke it. If it doesn't, that's the piece you'd need to build or find.
[H2] 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 AURAAURA'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, which in our experience hurt more than it helped outside of pure knowledge base scenarios.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 of what the collection contains and when to search it. 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 snapshotThe query-based approach keeps the agent's context window clean. Instead of stuffing every potentially relevant document into the prompt before the conversation starts, the agent searches the vector store as needed and pulls in targeted results. When the agent tells your on-call engineer to restart a specific service, the engineer can see that the recommendation was informed by the collection labeled "Company incident response runbooks" rather than by the model's general training data. This is the difference between an agent your team trusts and one they ignore.
[H2] 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. Or maybe you want to run the same model through AWS Bedrock instead of directly through the provider for compliance reasons. You need the flexibility to make these choices in configuration, not in code.With AURAAURA 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. That said, it's worth being honest about what "configuration change" means in practice. Swapping from Anthropic direct to Anthropic via Bedrock is genuinely straightforward since you're running the same model family. Switching between fundamentally different model families (say, from Claude to Gemini) will often require prompt adjustments as well, because models don't all respond to the same prompting patterns in the same way.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.Because AURA automatically sanitizes MCP tool schemas to conform to each provider's function-calling requirements (handling quirks like anyOf wrappers, missing types, and optional parameter formats), your tool integrations remain stable across provider changes. The schema translation happens at discovery time, so the tools themselves don't need to know which LLM is on the other end.Open-source model supportWe actively test AURA against leading open-source models using platforms like Ollama (via the Ollama provider) and llama.cpp (via the OpenAI provider). 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.
[H2] 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. Different users should only be able to access what their own tokens authorize. You need the auth context to flow through AURA and into the downstream tool calls cleanly.With AURAAURA'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, enabling per-tenant isolation without any custom middleware.Configuration snapshotThe mapping is explicit: each key is the header name from the inbound request, and each value is the header name to send to the MCP server. In the example above, both Authorization and X-Tenant-ID headers are propagated to the MCP server, which can then enforce access control per customer.This keeps AURA stateless. It doesn't manage sessions, store tokens, or make authorization decisions. It routes the caller's credentials to the tools and lets each service enforce its own policies. For platform teams operating AURA as shared infrastructure, this is the cleanest pattern: the agent layer handles orchestration, and auth stays with the services that own the data.
[H2] 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. Standard application tracing tells you that an HTTP request took 4 seconds, but it doesn't tell you which tools the agent called, what context was retrieved from the vector store, how long the LLM took to respond, or what reasoning led to the final output.With AURAAURA ships with OpenTelemetry support enabled by default, and we chose the OpenInference semantic conventions (llm.*, tool.*, input.*, output.*) for our span attributes. We went with OpenInference because it was purpose-built for AI observability. It captures the semantics that matter for debugging agent behavior: LLM invocations, tool calls, retrieval operations, and the relationships between them.This means AURA traces are natively compatible with Arize Phoenix and any other OpenInference-aware observability tool — but they also export cleanly to any OTLP-compatible backend. Set your OTEL_EXPORTER_OTLP_ENDPOINT environment variable and traces flow to Jaeger, Grafana Tempo, Datadog, Mezmo, or wherever your team already looks.Backend agnostic: your AI observability data goes wherever your existing telemetry goes. No vendor lock-in on the tracing side either.
[H2] 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, calling the agent builder programmatically, customizing the tool orchestration logic, and integrating at the library level.With AURAAURA is not a monolith. It's structured as three independent Rust crates with clear separation of concerns:aura — The core agent builder library. Runtime agent composition, MCP integration, tool orchestration, and vector workflows. No config file dependencies.aura-config — Typed TOML parsing and validation. Can be extended to support JSON, YAML, or any other format.aura-web-server — The OpenAI-compatible REST/SSE serving layer. Use it as-is or replace it with your own HTTP layer.If you only need the agent builder, depend on the aura crate directly. You get MCP tool discovery, schema sanitization, vector search, and multi-provider LLM support without pulling in any web server or config-file machinery.
[H2] 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 product. The same codebase that runs in our production clusters is what ships on GitHub under the Apache 2.0 license.What this means concretely:Mezmo is the primary contributor. We maintain the project, merge PRs, publish releases, and run the CI pipeline. The repo has a CLA, a code of conduct, and contributing guidelines because we take community participation seriously.Production-hardened by default. Features like graceful shutdown, streaming backpressure controls, request cancellation, and timeout configuration exist because Mezmo needs them in production. You get those same guarantees.No vendor lock-in by design. AURA doesn't require Mezmo as a backend. Use it with any compatible LLM provider, any MCP servers (over HTTP), and any OTLP-compatible observability platform. If you're already a Mezmo customer, AURA integrates natively with our telemetry pipeline and MCP server. If you're not, it integrates just as cleanly with whatever you do run.The roadmap is visible. Multi-agent orchestration is actively being developed on the feature/orchestration-mode branch. It's in open alpha today, and issues and feature requests are welcome on GitHub.
[H2] Getting started
Access our quickstart guide here: https://github.com/mezmo/aura/tree/main/examples/quickstartTo build and run AURA locally:Clone the repo: git clone https://github.com/mezmo/auraCopy the reference config: cp examples/reference.toml config.tomlSet your API key: export OPENAI_API_KEY="your-key"Build and run: cargo run --bin aura-web-serverOr use Docker: docker compose up --buildThe examples/ directory includes minimal per-provider configurations and complete agent examples. The development/ directory has ready-to-go setups for LibreChat and OpenWebUI integration.
[H2] 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/auraLearn more about AURA: https://www.mezmo.com/aura‍Table of ContentsShare ArticleRSS Feed
[H2] Similar blog posts
Builder in the loop: Eric Lake on making AURA smarter after every incidentBuilder in the loop: Eric Lake on making AURA smarter after every incidentAURAAlerting & Incident ResponseBuilder in the loop: Henry Andrews on building AURA like production softwareBuilder in the loop: Henry Andrews on building AURA like production softwareAURAAgentic ObservabilityWhy SRE agents need orchestration, not just more toolsWhy SRE agents need orchestration, not just more toolsAURAAgentic Observability@2025 Copyright Mezmo Inc.

[H1] Connect Mezmo to your favorite data sources and destinations
[H2] Telemetry ingestion sources
For a complete list and instructions, please visit our developer documentation.
[H2] Telemetry data destinations
For a complete list and instructions, please visit our developer documentation.
[H2] Ready to get started with AI powered observability?
Shift into Active Telemetry to see real outcomes✔ Schedule a 30-minute session✔ No commitment required✔ Free trial availableSchedule demoSee pricing@2025 Copyright Mezmo Inc.

[H1] Built on open source. Powered by the right data.
AURA + Active Telemetry—the complete agentic stack for SRE, platform, and dev teams.50-70%workflow cost reduction adding Mezmo data to AURA~$1per investigation vs $25+ with other toolsSpeed → agents in production fasterAURA is the open-source agent harness that handles orchestration, safety, and integrations. Your team focuses on the 20% that actually matters.Efficiency → do more with the team you haveContext-engineered telemetry means agents get exactly the right data, just in time—never a Costco pallet when a single roll will do.Risk → safe by default, not by accidentProduction SRE workflows live in the highest-risk environment. AURA's tested, hardened workflows keep agents from touching things they shouldn't.Trusted by
@2025 Copyright Mezmo Inc.