An agent run should be easy to replay, understand, and share.

When one run needs a closer look

Free, open-source, hosted, and self-hosted observability platforms are excellent at collecting many traces, searching across them, running evaluations, and supporting production teams.

Sharing, reviewing, or archiving one specific run is a different workflow. Sometimes the clearest handoff is simply: “Open this file and replay what happened.”

A visual replay anyone can follow

WizardFlow shows the agent’s graph and replays one message at a time through the nodes it visited. The graph, message timeline, and node inspector remain synchronized as the run advances, making the execution understandable without requiring someone to read raw logs or interpret a span list.

Play, pause, change speed, step through nodes, and move between messages with controls that feel like a familiar music player.

The trace is the artifact

A WizardFlow trace is an ordinary file. You can:

• attach it to a bug report;
• send it to a teammate;
• commit or archive it;
• inspect or diff it with ordinary tools;
• preserve representative runs as benchmarking artifacts;
• replay it without connecting to a trace backend.

Keep the evidence behind your benchmarks and demos

Scores show whether performance changed. Replayable traces help explain why.

When those runs live only inside an observability platform, reviewing a benchmark can depend on accounts, retained data, shared access, and a specific vendor’s interface. WizardFlow keeps each run as a portable file that can travel with the benchmark and be replayed independently.

WizardFlow preserves the evidence. Your benchmarking tools handle scoring.

For demos, the same replayable file lets people inspect the actual path, timing, and payloads behind the final result instead of only watching a recording.

Two ways to replay the WizardFlow JSONL

File-first, with optional OpenTelemetry export

The JSONL trace remains the durable, transport-neutral source of truth. It preserves the graph, messages, node executions, timing, and recorded payloads without tying the artifact to an observability vendor.

When you also need centralized traces, the Python SDK can export node executions as OpenTelemetry spans over OTLP. That lets tools such as Phoenix and Langfuse ingest the run through their trace pipelines while WizardFlow keeps the replayable file.

• Node spans retain the original WizardFlow timestamps.
• LLM, agent, tool, and retrieval semantics map conservatively.
• Prompt and output content export is disabled by default.
• JSONL and OpenTelemetry can be enabled independently.

Importing existing OpenTelemetry traces into WizardFlow is planned for a future release.

A different starting point

WizardFlow starts with portable, graph-based replay and can grow into centralized observability. Most observability platforms start with centralized traces, search, and operational monitoring.

Where operations-focused platforms win

Observability platforms may be free or paid, hosted or self-hosted. They are the better fit for continuous production monitoring, organization-wide search, retention, dashboards, evaluations, and alerts.

WizardFlow is especially useful while prototyping and debugging individual runs, and when a run should become a durable artifact for a demo, benchmark, bug report, or straightforward handoff to a colleague.

WizardFlow provides the portable, graph-based replay; a backend provides the operational view across many runs. Through OpenTelemetry, you can use both.