Keeping instrumentation one level below the AG-UI event stream, so a third transport inherits tracing for free, is a clean call. I have hit the same approval-boundary issue where a pause and its resume split into two disconnected traces, and stable session keying is the only thing that makes latency there measurable. Are you capturing human wait time separately from model latency in that session?
First pass: diff the two trace timestamps directly → 17.99s ≈ 18s. That's what I almost replied with.
Problem: that folds in the 2.63s of model latency from the awaiting_approval trace itself - the exact thing your question is getting at.
Corrected: using the trace's end (start + latency) instead of its start:
08:44:10.000 − 08:43:54.64 ≈ 15.4s — that's the actual human decision time.
Not wired up as a derived metric yet, but fully recoverable from data Langfuse already has - threadId gets you the session, start+latency on each trace gets you the boundary. Computing this automatically per session and attaching it as a score would be the natural next step, same pattern as the finish_reason metadata.
Kartik N V J K
AI Developer | Making AI reliable, trustworthy & accessible to everyone | Active community contributor
Keeping instrumentation one level below the AG-UI event stream, so a third transport inherits tracing for free, is a clean call. I have hit the same approval-boundary issue where a pause and its resume split into two disconnected traces, and stable session keying is the only thing that makes latency there measurable. Are you capturing human wait time separately from model latency in that session?