[Feature]: browser-session correlation for LLM workflow observability

[TheEleventhAvatar]

The Feature

As LLM workflows become more agentic and UI-driven, it feels like backend traces alone sometimes miss important execution context.

Would there be value in correlating Playwright/browser sessions with Helicone traces?

Interesting possibilities:

• replay failed UI + LLM interactions together
• inspect browser state transitions alongside model/tool spans
• debug flaky multi-step workflows
• identify divergence points between frontend and backend behavior

Motivation, pitch

This could become especially useful for:

• autonomous workflows
• agent copilots
• async state mutations
• non-deterministic failures

Feels adjacent to observability/replay tooling rather than traditional testing.

Twitter / LinkedIn details

@rewantrex / https://www.linkedin.com/in/rewant-goenka-9351a81a0/

[TheEleventhAvatar]

The client-supplied correlation-id point makes a lot of sense — especially because replay/divergence systems seem like they become fragile very quickly if correlation depends on temporal proximity rather than stable execution identity.

The async handoff case also feels important. Once workflows become long-running/backgrounded, the “browser session” and the eventual LLM/tool execution may no longer share runtime locality at all, so the workflow identity probably has to exist above both systems rather than being derived from either one.

Feels increasingly like observability/replay systems may need workflow-level execution identity as a first-class primitive rather than stitching together independent traces after the fact.

[TheEleventhAvatar]

The OpenTelemetry/span-tree analogy clarified the architecture a lot for me — especially the point that workflow identity has to exist above both the browser runtime and the trace backend rather than being derived from either.

The flat step_id + parent_step_id approach also feels much cleaner long-term than hierarchical IDs. Otherwise replay/comparison systems end up coupling execution topology directly into storage semantics, which seems fragile once workflows become dynamic or concurrent.

Right now my prototype is closer to a script-side broker sitting above Playwright rather than a dedicated orchestration harness. The workflow/session identity gets created before the browser interaction starts, then propagated through the replay/event system alongside snapshot references and mutation events.

But this discussion is making me think the broker layer itself may eventually become the actual “source of truth” for replay/debugging systems — with traces/browser sessions/tool calls all becoming indexed projections of the same workflow execution graph rather than separate systems being stitched together afterward.

Building the prototype also made me realize replay/debugging systems increasingly start looking like “execution graph systems” rather than traditional tracing systems once retries/concurrency enter the pictur

btw I’ve been experimenting with something similar with this direction here as well: https://github.com/TheEleventhAvatar/convextwin