[Feature Request] Flow execution traces / observability endpoint

[ameet]

Problem

When a flow completes, there's no structured way to see what happened: which steps ran, which were skipped, which failed, how long each took, and what the intermediate outputs were. The only output is the final workflow:result event.

For debugging and quality improvement, we need execution traces.

Current Workaround

We built a custom trace collection system:

1. Individual flow steps write execution data to JSON files
2. A separate analysis service reads the traces and produces quality reports
3. A feedback flow queries the analysis service for improvement suggestions

This works but is entirely custom — every flow needs manual trace instrumentation.

Proposed Solution: Integrate with traces.com

Rather than building a custom tracing system, One CLI should integrate with traces.com (docs) — an existing platform purpose-built for capturing and analyzing AI agent execution traces. It already supports Claude Code, Cursor, and other AI agents.

How it could work:

# Enable tracing for a flow execution
one --agent flow execute my-flow --trace

# Or configure globally
one config set traces.enabled true
one config set traces.namespace @my-org

One CLI would emit structured trace events to the traces.com API:

• Step start/complete/error events with timing
• Input/output sizes (not content, for privacy)
• Step status (success, error, timeout, skipped)
• Parallel block coordination (which branches completed, which timed out)
• Sub-flow nesting (trace spans for flow-in-flow calls)

Benefits of traces.com integration over custom:

• Already handles AI agent traces (designed for Claude Code, Cursor, etc.)
• Has a web UI for browsing and searching traces
• Supports namespaces and organizations
• Session sharing with visibility controls (private/direct/public)
• SQLite local index + cloud sync
• No infrastructure to maintain
• Discord community: https://discord.com/invite/hR8Syd9ZcJ

Minimal integration:

At minimum, One CLI could write trace data in a format traces.com can ingest:

{
  "event": "step:complete",
  "flowKey": "my-flow",
  "stepId": "research",
  "status": "success",
  "durationMs": 120000,
  "outputSize": 85000,
  "timestamp": "2026-04-06T10:02:00Z"
}

The traces.com CLI (traces — installable via Homebrew, npm, or curl) could then index these alongside Claude Code session traces, giving a unified view of both interactive development and automated flow execution.

Use Cases

1. Performance profiling: Which steps are slow? Where does time go?
2. Failure diagnosis: Which step failed and why? Was it retried?
3. Quality feedback loops: Analyze trace patterns across runs to identify systemic issues
4. Cost tracking: Which LLM calls (bash steps with claude --print) are most expensive?
5. Cross-session correlation: Link a Claude Code session (where a flow was triggered) to the flow's execution trace

Impact

We spent significant time building custom trace infrastructure (trace collection steps, analysis service, feedback flow). traces.com already solves the storage, UI, and search problems — One CLI just needs to emit the events. This would give every One CLI user observability into their flow executions with zero custom tooling.