Trace an AI SRE Agent: AURA Docker Quickstart with Phoenix and OTel
You get an answer from the agent and no way to check how it got there. The route it took is recorded, and so is the reason it gave for taking it.
Learn more about AURA → https://www.mezmo.com/aura
Get started today → https://github.com/mezmo/aura
Get deployment help → https://www.mezmo.com/contact
AURA emits OpenTelemetry spans, and the Docker quickstart wires them straight into Phoenix. Four services come up together: AURA Web Server as the persistent agent harness, LibreChat as a browser interface for chatting with the agent, Phoenix to receive the spans, and MongoDB to store stateful data for LibreChat. The Compose file arrives pre-configured to point AURA at Phoenix and to enable content recording for the local demo.
Setup is a clone, a copied environment file, a provider, a model, an API key, and docker compose up -d. LibreChat comes online once the health check passes and listens on port 3080. Phoenix starts alongside it on port 6006 and waits for traces.
The demo sends two requests: a short test, then an incident carrying just enough evidence for the coordinator to choose a route. The stock configuration has no MCP servers at all, so the coordinator analyzes what the prompt contains and responds directly. Even with no tools available, the run produces enough span data to follow end to end.
Each request produces two traces. The HTTP trace covers the request and response lifecycle from chat_completions, and it is where a client disconnect or a stalled stream shows up. The agent work sits in a separate trace rooted at agent.stream, kept as an independent root so the full execution stays together. Expanding it gives you the orchestration span holding the coordinator's route, orchestration.planning for the planning call, then agent.stream_chat and agent.turn for the model interaction, ending in an execute_tool span named respond_directly. Its attributes carry the routing rationale, that all three workers lack MCP access while the prompt already holds enough evidence, and the output confirming the direct response was recorded.
Phoenix also attaches OpenInference data. CHAIN marks request flow and orchestration, LLM marks model turns, and TOOL marks an action such as respond_directly or a configured tool call. Slow or expensive branches are findable from the header alone, without opening every span, wherever the provider reports those fields.
Two boundaries worth stating. The execute_tool span here is an internal AURA action, not an MCP request; a real external call appears as mcp.tool_call nested below the execution span only once you have configured an MCP server, and this run does not show one. And because content recording is on, trace details include the incident prompt and AURA's response, so check for sensitive data before sharing a trace. This video reads traces rather than running an investigation. AURA reaches no root cause here and applies no remediation.
0:00 What an AURA trace shows
0:10 The four services in the Docker quickstart
0:33 Clone, configure, and start the stack
0:56 LibreChat on port 3080
1:10 Two requests and a direct response
1:35 Two traces per request in Phoenix
2:03 Expanding the agent.stream span tree
2:22 Reading the execute_tool attributes
2:42 Where a real MCP call appears
2:58 OpenInference span kinds and header fields
3:23 Following the route behind a response
#AURA #OpenTelemetry #AIforSRE