jq, so it can build its own troubleshooting workflows — creating scratchpads, saving intermediate findings, and breaking large, messy investigations into steps rather than holding everything in a single context window.
What PXI can do
- Investigate failures: inspect traces, find root causes, and track down what went wrong without leaving the page.
- Iterate on prompts: propose prompt changes as reviewable diffs and compare prompt versions.
- Run and compare experiments: kick off experiments, author evaluators, and compare results.
- Annotate and navigate: annotate spans, apply filters, inspect outputs, and navigate Phoenix on your behalf.
Context-aware by default
PXI knows the trace you opened, the prompt you’re editing, the filters you’ve applied, and the project you’re in. It also has access to the tools and history already in Phoenix — prompt versions, experiment results, datasets, evaluations, annotations, and trace data — so it can move past generic advice and actually help you do the work. Under the hood, PXI runs in a sandboxed environment with authenticated access to Phoenix, a growing library of reusable skills, and direct access to Phoenix documentation through MCP so it stays current as the product evolves. When enabled, PXI can also access the web for additional research.Built-in controls
- Approval by default: state-changing actions require your approval before they run.
- Runs on your deployment: everything executes on your own Phoenix instance.
- Fully optional: PXI can be disabled entirely if you don’t want it.
PXI Agent
Learn how to enable and use PXI in your Phoenix deployment.

