Arize Phoenix
The Observability Platform That Traces Agents, Not Just Text
The most mature open-source platform for AI observability that actually traces multi-step agent behavior.
The difference between an AI application you can debug and one you cannot is whether you can replay a single request from end to end and see every step that happened. Most observability tools give you the LLM call. Some give you the retrieval step. Almost none give you the full agent trajectory tool calls, sub-agent invocations, retry logic, and the chain of decisions that produced the final output. Arize Phoenix fills that gap.
Phoenix is not the only observability option in the enterprise AI stack. Langfuse is simpler to deploy and has a stronger GDPR compliance posture. WhyLabs speaks the language that CFOs and CISOs expect to hear. OpenLLMetry integrates into existing Datadog or Grafana pipelines with minimal friction. What Phoenix does that none of these do is trace agents as agents, not as sequential text-in-text-out operations. It understands that an agent’s work is a tree of decisions, not a line of LLM calls.
The current version as of this writing is v17.21.0, released on July 8, 2026. The jump from v17.12.0 at planning time reflects Phoenix’s shipping cadence roughly nine releases in twelve days, with features like end-to-end PXI turn tracing from browser to backend, a global search command palette, session stats side panels, and read-only UI styles. That cadence matters for a tooling decision because it signals a project that is responsive to production issues and actively maintained. Ten thousand stars on GitHub confirm the community presence, but the release frequency is the signal I trust more.
The architecture that makes Phoenix different is its foundation on OpenTelemetry. Most AI observability tools instrument the LLM call and stop there. They capture the prompt, the response, the token count, and the latency. That is useful for monitoring but useless for debugging a five-step agent sequence where the third tool call returned an unexpected error and the agent silently retried with different parameters. Phoenix traces every span in the OpenTelemetry sense of the word, and those spans form a tree that mirrors the agent’s execution structure. You can expand each node and see the exact inputs, outputs, and timing of that specific step.
This matters most in production when an agent does something unexpected and you need to reconstruct why. A single LLM call trace tells you the model said something wrong. An agent trace tells you which tool returned bad data, how the agent interpreted that data in its next reasoning step, and what decision chain produced the final output you are now investigating. Without that tree, you are guessing. With it, you have evidence.
The OpenTelemetry-native approach also means Phoenix integrates with anything that speaks OTLP, which is almost everything in the modern observability ecosystem. LiteLLM, LangChain, LlamaIndex, DSPy, CrewAI, the OpenAI Agents SDK, the Claude Agent SDK, and the Vercel AI SDK all have native OpenInference instrumentations that pipe traces directly into Phoenix. For the integrations that do not have a dedicated instrumentation package, the OpenTelemetry collector can translate standard OTLP spans into OpenInference format. The practical result is that Phoenix is the sink your entire AI stack can drain into without custom adapters.
The evaluation layer is where Phoenix goes beyond tracing into something closer to a testing platform. You can define evaluators that run against every trace: response relevance, retrieval relevance, toxicity, hallucination detection, correctness against a ground truth. These run asynchronously after the trace completes, so they add no latency to the request path. The evaluator results attach to the trace and become queryable. When a regression gate in your CI pipeline needs to know whether the latest model deployment degraded response quality, it queries Phoenix for the evaluator score distribution and compares it against the baseline.
That semantic drift detection is the feature that separates teams that ship AI confidently from teams that ship AI nervously. Without it, a model update that subtly changes the style or content of responses goes undetected until users complain, assuming they notice and report it. With it, a shift in the evaluator score distribution or the embedding distance from the baseline triggers an alert before the deployment completes. Phoenix supports both approaches: LLM-as-judge evaluators that score responses against criteria, and embedding-based drift detection that measures how far the latest traces are from the distribution of the previous deployment.
The prompt management layer was added in the v17.x series and closes a gap that Phoenix previously left open. You can version prompts, tag them for different deployment environments, and run experiments that compare prompt variants against each other with the evaluation framework. A prompt change becomes a testable artifact with a score attached, not a conversation over Slack about whether the new system prompt sounds better. The integration is not as deep as Langfuse’s dedicated prompt management workflow, but it is close enough that a team that already runs Phoenix does not need to add another tool for prompt versioning alone.
The self-hosting story is straightforward. Phoenix runs as a Python package that launches a web server on your machine, as a Docker container for single-node deployments, and as a Helm chart on Kubernetes for production-scale deployments. The cloud version at app.phoenix.arize.com is available for teams that do not want to self-host, but the self-hosted option is fully functional with no feature gating. For enterprise deployments with data residency requirements, the Docker Compose path with a Postgres backend is the standard choice. No telemetry from the self-hosted instance sends trace data to Arize. The telemetry that Phoenix collects by default is limited to UI interaction analytics, which you can disable with an environment variable.
The honest limitation is that Phoenix’s depth comes with a complexity cost. Langfuse can be deployed with a single Docker Compose file and produce a usable dashboard in ten minutes. Phoenix requires more configuration to get the full picture: the collector pipeline, the instrumentation setup per framework, the evaluator definitions, and the dataset management for experiments. The ROI on that configuration is the trace tree depth that Langfuse does not provide. Whether the tradeoff is worth it depends on whether your agents are simple enough that a flat list of LLM calls tells you what you need to know, or complex enough that you need the tree.
For most teams running multi-step agent architectures where a single user request triggers tool calls, sub-agent invocations, and conditional logic branches, the answer is clear. You need the tree. Phoenix provides it in a way that no other open-source observability platform currently matches. The team at Arize has been shipping on this thesis since before agents were the dominant AI deployment pattern, and the project’s maturity shows in the integration surface, the documentation quality, and the release cadence.
If you are building agents in production and your debugging workflow currently ends at the LLM response log, Phoenix fixes the gap. It will not fix your agent’s failure modes. It will show you exactly where they happen.
If this was useful, forward it to one engineer who needs less noise in their feed.