PXI

PXI is an agent built into Phoenix. It helps you investigate traces, iterate on prompts, and navigate the product without leaving the page you are working on.

PXI is in beta. It can and will make mistakes, its behavior may change between releases, and it should be used with care — especially on production data. Review the Privacy and observability and Safety sections before turning it on.

What PXI is

PXI (pronounced “pixie”) is an agent built into Phoenix. It sees what you are looking at and acts on your behalf:

• Drives the product. PXI navigates, filters, and pivots through your Phoenix data the same way you would — only faster.
• Iterates with you on prompts and traces. It reads, edits, and explores prompts, spans, and traces directly in context.
• Investigates failures. Built-in skills walk failing traces and propose root causes instead of leaving you to grep through spans.
• Reasons over your data. A sandboxed runtime lets PXI query your Phoenix instance to answer questions evals and dashboards cannot.
• Knows the product. Phoenix’s own documentation is wired in as a first-class source, so answers are grounded rather than guessed.

Because PXI is grounded in your current context, what it can do adapts to the page you are on — its capabilities on a trace are different from its capabilities in the prompt playground.

When to use it

• Debugging. Hand off a failing trace and get a root-cause hypothesis, not a list of spans to read.
• Exploring data. Describe the view you want and let PXI set up the filters, time range, and pivots.
• Sharpening prompts. Co-iterate on playground prompts with diffs you review before anything lands.
• Learning Phoenix. Ask product questions and get answers grounded in the live docs, not in training-data folklore.

PXI accelerates the loop you already run. Evals, experiments, and human review still belong at the end of it — PXI just gets you there faster.

Enabling PXI

PXI is off by default. To turn it on, set the following environment variable on the Phoenix server and restart:

PHOENIX_DANGEROUSLY_ENABLE_AGENTS=true

The DANGEROUSLY_ prefix is intentional. Enabling PXI gives an LLM the ability to read Phoenix data the signed-in user can already see, and to call tools that modify UI state. Only enable it in environments where that trade-off is acceptable.

PXI needs a model to talk to. Configure credentials for at least one provider via environment variables or Phoenix secrets:

• OPENAI_API_KEY
• ANTHROPIC_API_KEY
• GEMINI_API_KEY
• AWS Bedrock credentials
• Or a custom provider configured under Settings → Models.

Use a recommended model

PXI relies heavily on tool calling — almost every action it takes is a tool call (set a filter, edit a prompt, read a span, run a debug skill). Models that are weak at tool use will produce broken sessions, even if they handle free-form chat well.

We curate a short list of models that PXI has been validated against. Pick one of these unless you have a specific reason not to:

• Anthropic — claude-opus-4-6, claude-sonnet-4-6
• OpenAI — gpt-5.5, gpt-5.4, gpt-5.4-mini
• Google — gemini-3.1-pro-preview, gemini-3.5-flash

Other built-in or custom-provider models can be selected from the model menu, but they are untested with PXI and may fail to invoke tools correctly. If you swap in a non-curated model, expect rougher behavior.

The first time a user opens PXI they are shown a consent gate that explains what gets recorded and where it is sent. Acknowledging the gate enables the chat surface for that user.

How it works

PXI is modeled after a coding agent — the same shape as Claude Code, Cursor, or Codex — but pointed at Phoenix instead of a code editor. It has:

• A harness of tools for taking action in the product (set the time range, apply a spans filter, read a span, edit a playground prompt, render generative UI, ask the user a question).
• An MCP server that exposes the Phoenix docs to the agent — served by Mintlify, the same provider that hosts the public Phoenix documentation — so PXI can look up product behavior the same way a coding agent looks up library docs.
• Skills — reusable, multi-step playbooks for common investigations. The first built-in skill is debug_trace, which walks a failing trace and proposes root causes.
• A sandboxed bash tool for running ad-hoc queries, scripting against the Phoenix API, and storing intermediate files inside the agent’s working directory.

PXI is split between the Phoenix server and the browser:

• The server owns everything the model sees — tool definitions, system prompt, skills, and capability guidance. This is the source of truth for what PXI can do.
• The browser executes tool calls that need to touch the page (filters, navigation, prompt edits) and dispatches server-side tools through the data stream.

Capabilities are gated by context. PXI only advertises a tool when the required Phoenix UI context is present — for example, the prompt-edit tool is only offered while you are on a playground page with a selected prompt. This keeps the model from offering actions that cannot succeed on the page you are viewing.

Architecture

The browser owns the chat UI and a sandboxed bash environment. Inside that sandbox, PXI uses the phoenix-gql CLI to query the Phoenix GraphQL API on the server, the same authenticated endpoint a logged-in user hits from the UI. The server hosts the PXI agent along with its model-facing surface — tools, skills, and an MCP client — and calls your LLM provider with your API key. The only external dependency is the Mintlify-hosted Phoenix docs MCP, reached through the server’s MCP client.

Runs entirely on your Phoenix

PXI runs inside the Phoenix process you are already running. Concretely:

• Tool calls execute against your Phoenix server and your data — no separate Arize service is involved.
• The LLM behind PXI is your model provider, called with your API key (OpenAI, Anthropic, Google, Bedrock, or a custom provider you configured). Arize is not in the request path.
• Documentation lookups go to the Mintlify-hosted Phoenix docs MCP server, the same public docs surface you can read in a browser. It serves docs only.
• Arize receives PXI session traces only if you explicitly opt in under Settings → Agents (“Share PXI session traces with the team improving PXI”), and that opt-in is only available when a remote collector has been configured for your instance. If you never enable it, Arize never sees your traces, prompts, or tool outputs.

Privacy and observability

Every PXI conversation is captured as a Phoenix trace. By default these traces are written to a dedicated PXI project in the Phoenix instance you are using — no data leaves your deployment.

From Settings → Agents you can:

• Turn local PXI tracing on or off.
• Opt into sharing PXI session traces with the team building PXI (only available when a remote collector is configured).

Tool inputs and outputs are recorded on the corresponding spans, which makes it easy to audit what PXI did during a session and to evaluate PXI the same way you evaluate any other agent in Phoenix.

Safety

PXI is a beta feature. Keep these limits in mind:

• Verify before you act. PXI can apply filters, edit prompts, and run bash. Review proposed changes — especially prompt edits — before accepting them.
• Don’t point it at sensitive production data without controls. PXI sees whatever the signed-in user can see. Use it against scoped projects or staging data while it is in beta.
• Treat outputs as suggestions. PXI hallucinates, especially on long traces or unfamiliar frameworks.

Feedback

PXI is early and we are actively looking for improvements and ideas. If you have feedback, run into a rough edge, or want to suggest new capabilities, please open an issue or start a discussion on GitHub. We read everything.