Alongside

Witdem and Arize Phoenix

Different jobs on the same agentic stack — observability and evals vs product goals. Witdem does not replace Arize Phoenix.

What Arize Phoenix is strong at

Arize Phoenix is open-source observability and evaluation under Arize. Teams pick it for tracing, embeddings insight, and eval workflows for RAG and agents. They do not pick it as a product-job scorecard.

Checkable strengths that matter in practice:

• Open-source observability and evals under the Arize umbrella
• OpenInference and OTEL-friendly tracing for LLM and agent runs
• Embedding and eval tooling useful for RAG and agent quality
• Strong for teams already on Arize or Phoenix day to day

Those skills stay useful with or without an outcomes layer. They answer how a run behaved. They also show how it scores on your quality checks.

What Witdem adds

Witdem asks a different question. Did this run meet the product goal you named? That means a goal next to the code. It means evidence fields on the same run id. When useful, it also joins spend to that job.

A clean Phoenix trace can still leave the product question open. A solid eval score can too. Finished spans can be true. Embedding diagnostics can look fine. A green quality check can pass. The answer can still be empty, ungrounded, or outside the contract you shipped. Witdem closes that gap. It does not ask Phoenix to act as product analytics.

When you use both

The path is simple. Use Phoenix for OpenInference or OTEL traces, embedding insight, and eval workflows. Use Witdem when you need a clear answer to “did the job succeed?” on the same run. Wire both to one execution. Do not treat them as rivals for one slot.

The diagram is a map of jobs, not a ranking. Other tools can sit on either band. The labels mark where each product is typically strong.

Limits — when one alone is not enough

Witdem alone is not enough when you hunt a bad retrieval path. It is not enough for embedding checks or Phoenix-style quality evals. You still need that observability and eval surface. If tracing or RAG and agent quality checks are the main job this week, start with Phoenix.

Phoenix alone is not enough when product needs a named job outcome. You still need evidence and spend×job on one identity. Traces and eval scores show how the run and the quality checks behaved. They do not, by themselves, say whether the shipped product goal held. Use both when both questions matter.

What this means in practice

Picture one RAG or agent run from start to finish. You look at the same run twice. Once for Phoenix traces and quality checks. Once for the product job you promised.

First you open Phoenix. Spans look healthy. Embeddings and evals look fine. That only says the instrumented path completed and passed those checks.

Then you ask the Witdem question. Was the named goal met? Do the evidence fields support pass or fail? A clean trace with an empty answer is still a product fail.

Keep both on one run id. Trace and eval in Phoenix. Score the job in Witdem. That is complementary use, not a swap.

FAQ

Does Witdem replace Arize Phoenix? No. Witdem does not replace Arize Phoenix. Keep observability and evals. Add outcomes for the product job on the same run.

When do I use both? Use both when you need OpenInference or OTEL detail and a clear job result. Wire them to one execution identity.

What does Witdem add? A named product goal, evidence you can inspect, and spend joined to that job when useful.

Are quality evals enough? No. Eval scores show quality vs criteria. They do not, by themselves, say the shipped goal held.

Related

Tracing, evaluation, and product analytics · Witdem and Langfuse · Witdem and LangSmith · Agentic workflow observability

Framework guides: Haystack · LangGraph · LangChain · OpenAI Agents