Conversation transcript

Your agent doesn’t emit a conversation — it emits spans. The Conversation tab on a trace (and on a session) is a reconstruction: Neens walks the spans, decides which ones carry something a human said or read, unwraps the message payloads, and renders the back-and-forth. This page documents that derivation exactly, so you can predict what you’ll see and instrument your agent to get a clean transcript.

At a glance

Which spans contribute turns

A span’s kind comes from your instrumentation (openinference.span.kind, or the GenAI fallbacks — see which attributes Neens reads). Only three kinds can put a bubble on screen:

Turns are ordered by event time

A span’s input happens when the span starts. Its output happens when the span ends. Neens builds a list of those events and sorts it, rather than walking spans in start order:

• Each candidate span contributes an input event at its start time and an output event at its end time.
• End time is the span’s recorded end; when only a duration is available, it’s start + duration. A missing or invalid duration counts as zero.
• At an identical instant, inputs sort before outputs — a question reads before an answer, and a zero-duration span keeps its own input ahead of its own output.

This matters for any enveloping span. A root graph span starts near the beginning of the run and ends at the very end; its output holds the final answer. Ordered by span start, that answer would render as the first bubble, above the user’s question. Ordered by event time, it lands last, where it belongs.

For an ordinary sequential run — one LLM call after another, nothing nested — event order and span order are identical, so nothing changes.

A worked LangGraph example

Here is a real supervisor→worker LangGraph run as Neens stores it (times are seconds into the trace, trimmed to the spans that matter):

The graph’s root chain span (row 2) wraps everything: it starts second and ends last. The LLM spans returned empty content (the provider rate-limited), so the only user-facing answer in the whole trace lives on chain spans, under answer.

The rendered transcript:

User       Refund me $500 for order O5002.

Assistant  I can't process that refund: requested $500.00 exceeds order total $59.50.
           I can refund up to the order total.

Payload shapes Neens understands

A span’s input / output is a string. If it starts with [ or {, Neens parses it and looks for messages. Four shapes are understood, and nesting is flattened — including the LangChain {"messages": [[ … ]]} wrapper.

OpenAI / Anthropic message array. The common case. role + content:

[
  {"role": "system", "content": "You are a returns agent."},
  {"role": "user", "content": "Refund me $500 for order O5002."}
]

Content-block list. content may be a list of blocks; the text (or content) of each block is concatenated with newlines:

[{"role": "assistant", "content": [
  {"type": "text", "text": "I can refund up to the order total."},
  {"type": "text", "text": "Would you like me to proceed?"}
]}]

LangChain-serialized messages. A constructor blob with no top-level content is unwrapped from kwargs, and the role is read from the class path when it isn’t stated:

{"messages": [[
  {"lc": 1, "type": "constructor",
   "id": ["langchain", "schema", "messages", "HumanMessage"],
   "kwargs": {"content": "Refund me $500 for order O5002."}}
]]}

HumanMessage → user, AIMessage → assistant, SystemMessage → stripped. A ToolMessage is never an assistant turn — see What is deliberately stripped.

OpenInference indexed attributes. If you emit llm.input_messages.N.message.{role,content} / llm.output_messages.N.message.{role,content}, Neens assembles them into a message list at ingest, in index order until an index is missing:

{
  "openinference.span.kind": "LLM",
  "llm.input_messages.0.message.role": "system",
  "llm.input_messages.0.message.content": "You are a returns agent.",
  "llm.input_messages.1.message.role": "user",
  "llm.input_messages.1.message.content": "Refund me $500 for order O5002.",
  "llm.output_messages.0.message.role": "assistant",
  "llm.output_messages.0.message.content": "I can refund up to the order total."
}

This is the highest-precedence source, ahead of gen_ai.prompt / gen_ai.completion and the raw input.value / output.value blobs. Emitting these attributes on your LLM spans is the single most reliable way to get a clean transcript.

On an llm or agent span, a payload that is none of the above — plain prose, or JSON that isn’t a message list and isn’t an object — is still rendered as a turn, using the span position’s default role (input → user, output → assistant).

Chain spans: the strict rule

chain is the kind every LangChain/LangGraph node and graph maps to, so it’s where a graph-built answer lives. But a chain span’s payload is state, not dialogue. Neens admits a chain span only when the payload names its content — that is, when it does one of:

1. parses to a structured chat message (any of the shapes above), or
2. (on an output) yields a recognized answer field, or
3. (on an input) yields a recognized question field.

Anything else from a chain span is control flow and is dropped. In particular, a bare string on a chain span is never a turn:

{
  "kind": "chain",
  "name": "_route_selector",
  "input": "{\"message\": \"Refund me $500 for order O5002.\", \"route\": \"returns\"}",
  "output": "returns"
}

That output is a routing token — the name of the next node. It is a perfectly good string, and under the lenient rule that llm/agent spans get, it would render as:

Assistant  returns

…as the agent’s reply to the customer, and would be captured as the expected output of any golden dataset item built from this trace. The strict rule is what keeps it out. The same rule drops true, 3, and any unrecognized state object a graph node emits.

llm and agent spans keep the lenient behaviour, because a model call’s payload is the conversation even when it isn’t well-formed JSON.

Recognized answer fields

When an output payload unwraps to no chat message — a state dict, a worker result — Neens looks for the agent’s final answer under these keys, in this priority order (not the order they appear in your object). The first non-empty match wins:

The value may be a string or a content-block list ({"answer": [{"type":"text","text":"…"}]}), which is normalized to text.

Priority order is load-bearing: a LangGraph state that carries both the user’s echoed message and the real answer resolves to answer, because the echo keys are deliberately absent from this list. So are control keys (route, worker, passed, status) — a routing decision or guardrail verdict stays dropped instead of masquerading as a reply.

If your state schema names the final answer something not on this list, rename it or add an alias — that is the one-line fix for “my reply is missing”.

Recognized question fields

The mirror problem: a graph’s input state {"message": "Refund me $500…"} unwraps to no chat message either, so a LangGraph trace whose LLM spans carry no input messages would show a reply with no question. When Neens is reading a payload as a user turn, it looks for these keys, in priority order:

Two deliberate limits:

• Strings only. No content-block lists, so a nested state object can never be flattened into a fake user turn.
• Inputs only. This lift never applies to an output, so an echoed input can’t masquerade as the agent’s reply.

input is last because it’s the most generic. Lifting the same question repeatedly as the graph threads state through its nodes is harmless — consecutive duplicate user turns collapse.

The two collapses

Reconstruction runs the events through two collapses, which is why a 40-span trace reads as a three-bubble conversation:

• Consecutive duplicate user inputs collapse to one. Every LLM call in a run typically replays the same system prompt and history; without this, the question would repeat once per model call.
• A run of consecutive assistant outputs collapses to the LAST one. One user turn drives several internal steps that each produce an assistant message — a worker writes a draft, the supervisor synthesizes the final reply, a retry re-answers. Only the last one is delivered to the user, so only the last one is shown. The drafts are still on the Spans and Raw tabs.

Both collapses are strictly consecutive: a user turn between two assistant turns breaks the run, so a genuine multi-turn conversation is preserved in full.

What is deliberately stripped

Note that a JSON array is not treated as a control payload — arrays are content-block lists, and they’re flattened into text.

Every surviving message lands in one of two buckets. assistant, ai and model roles (and a LangChain AIMessage) become assistant turns; every other role that wasn’t stripped is read as a user turn. So if your instrumentation puts tool-role messages into an LLM span’s message array, a plain-string tool result will read as a user bubble — a serialized JSON result is dropped by the rule above. Keep tool traffic on tool spans, where it shows up under Tool Calls on the Spans tab.

Where else the transcript is used

This is the highest-stakes part of the page. The transcript is not cosmetic; it is Neens’ single answer to “what did the user ask” and “what did the agent finally answer”, and several features record that answer permanently:

Because these are the derived values and not “the last span that had output”, a trailing guardrail verdict or tool result can never be captured as the agent’s answer. The flip side is the failure mode to watch for: if the Conversation tab is empty or wrong for a trace, a golden dataset built from that trace captures an empty or wrong expected output, and nothing errors. Every judge run and every pre-prod gate then measures against it.

So before you cut a golden version, open a couple of its traces and check the Conversation tab actually shows the answer you expect.

Instrument for a clean transcript

In rough order of impact:

1. Emit llm.input_messages.* / llm.output_messages.* on your LLM spans. The standard OpenInference instrumentors do this for you. It removes all guesswork.
2. Put the final, user-facing answer under answer (or another recognized answer field) in the state your last graph node returns. This is the LangGraph fix.
3. Name the user’s question message, query, question or prompt in your graph’s input state.
4. Don’t return bare strings from graph nodes you want in the transcript. Return {"answer": "…"}, not "…".
5. Keep control decisions in objects with control keys (route, status, passed) — that’s what keeps them out of the dialogue.
6. Mark guardrail and tool spans with their real kinds so their payloads are never mistaken for turns.

Troubleshooting

See also Traces & sessions, Send traces, and the FAQ.