See What Your Agent Did

The User filter matches exactly. It doesn’t ignore case, and a partial identity matches nothing. It matches a conversation when any of its turns recorded that end user, so a conversation can match on a turn whose user isn’t the one in the User column. Like the search box and the status filter, it’s kept in the page URL.

The User filter isn’t available in every environment. If Status is the only filter beside the search box, your environment doesn’t have it.

The list is paged, with a rows-per-page selector in the footer. Use the page controls to move through older conversations, and use the refresh control to pick up new ones. The page you are on and the rows-per-page setting are kept in the page URL too, so a link to the list reopens the view you shared.

The User column, the initiator in a transcript’s summary header, and the label on each turn all report the same thing: the end user the agent’s runtime recorded for that turn.

The agent asserts that value, and nothing checks it. Read it as a label the agent chose, not as proof of who acted: an agent can send any string, and the reach of a wrong value stops at its own environment’s transcripts. Access policies, budgets, and cost reporting read the identity derived from the agent’s credential instead. Wherever no value was recorded, a transcript reads Unattributed.

A conversation can involve more than one person, such as an agent answering in a shared channel, so each turn carries its own end user and the summary header reports the first turn that recorded one.

For a managed agent, the runtime records the email address of the caller it authenticated, so the value reflects who called rather than a label the agent picked. When one agent runs on a person’s behalf, it records that person’s address rather than the calling agent’s service account. A run that carries no authenticated email address records nothing, and its turns read Unattributed.

For a self-managed agent, the value is whatever the agent’s own instrumentation sets. See End user attribution.

To read only the conversations one end user took part in, filter the list by user. See Filter the list.

The summary header reports:

If the conversation ended in failure, the status badge reads Error, and the detail is on the turn or tool call that failed. See Errors.

The conversation is grouped into turns. A turn pairs a user message with the agent’s response and any tool calls the agent made to answer it. When a system prompt was recorded, it appears in its own block at the start of the conversation.

Detailed view shows each turn as a card with the user message, the agent’s response, and a side panel. The side panel lists the turn’s tool calls, each with a status indicator and its duration, followed by the turn’s metrics: its latency, its LLM and tool call counts, its input and output token totals, and its context size. See Context size of a turn. The LLM call count is the number of calls the agent made to the model to finish that turn, which is often more than one. Tool calls are counted separately. The user side of the card is labeled with that turn’s end user, so a conversation with several senders attributes each turn to its own. See Who a conversation ran for.

A turn’s response carries the text from every one of those model calls, in the order the agent produced them, one paragraph per message. An agent that says what it is about to do, calls a tool, and then answers shows both messages in the turn rather than the final answer alone. A message that repeats the one before it appears once. A turn already recorded isn’t rewritten unless its conversation records more activity, so a conversation that finished earlier can still show only the last message of each turn.

The three columns are resizable. Drag either divider in a turn card, or focus a divider and use the arrow keys, to widen the column you are reading. The change applies to every turn in the conversation at once, and the browser you are working in remembers the widths for your next visit. Each column keeps a minimum width, and on a narrow screen the columns scroll sideways rather than being cut off.

Click a tool call to open it in a Tool call dialog and read the exact call: its status, how long it took, the Arguments the agent sent, and the Result it got back, both as JSON. A call that failed also shows an Error section with the error code and message the call returned.

A tool call that ran but returned an error shows the Error status, not Completed. Conversations recorded earlier keep the status they were stored with, so an older transcript can still show such a call as Completed. The dialog opens for every tool call, and names each piece the transcript didn’t record rather than hiding it. What the transcript holds depends on the agent’s recording mode: an agent set to Metadata only strips tool content, so its tool calls keep their name, status, and duration, and the dialog reports the arguments and result as not recorded. See Transcript recording.

Chat view reads the turns as a message thread between the user and the agent, with each turn’s tool calls shown as labeled indicators above the agent’s response. The first message in each user block is labeled with the end user whose turn it was, or User when the turn recorded none, and a change of sender starts a new block, so a conversation that several people took part in shows who said what. See Who a conversation ran for.

Each tool call is labeled with the name the model called. For a tool served by an MCP server, that name includes the server it came from, such as servicenow__lookup_user.

When an agent hands work to a subagent, the turn’s tool list gives the delegation its own row rather than showing it as an ordinary tool call. The row carries the subagent’s name, a Delegated badge, how long the delegation took, and the tokens the delegated turn used, split into input and output.

Click the row to open the delegated turn: its model, latency, call counts, and tokens, the message it received, the response it returned with its own failure notice when it failed, and its own tool calls, which you can expand. The Arguments and Result of the delegating call are collapsed under the turn when the transcript recorded them. A delegated turn that hasn’t reached the transcript yet says so in place of the turn.

A delegation is recorded from the subagent’s own execution, not from the tool’s name, so a tool that merely looks like a delegation stays an ordinary tool call. An older conversation, recorded before transcripts kept that link, shows its delegations as ordinary tool calls.

In Detailed view, each turn card shows a context chip beside the turn’s latency, reporting how much of the model’s context window the turn filled. Click the chip for the exact figure: the tokens the prompt used, the window they were measured against, and the share of the window they took. The turn’s metrics repeat the same figure as a Context row.

A turn’s context size is the prompt the model read on the turn’s last call, including anything served from the provider’s prompt cache. It is not the turn’s input token total, which adds up every call the agent made to finish the turn and is what the turn costs. A turn that took several calls therefore reports a context size smaller than its input total, and the two are answering different questions: context size tells you how close the turn came to the window, and the input total tells you what it spent. For spend, open Cost and usage. See Analyze Cost and Usage.

Redpanda reads the window from the model catalogs of the OpenAI, Anthropic, Google Gemini API, and AWS Bedrock provider types. A model none of those catalogs lists, for example one served through an OpenAI-compatible endpoint, has no known window, so the chip reports the context size on its own and says the window is unknown for that model. A turn whose model steps recorded no token usage, and any turn recorded before Agentic Data Plane began storing context size, shows no chip and no Context row.

Use the context size next to the compaction markers in the same conversation: a turn running close to its window is the one whose next step is likely to compact. See Context compaction.

When an agent reduces its own context to stay inside the model’s window, the conversation shows a Context compacted marker at that point in Detailed view, with the estimated request size before and after the pass. A long conversation can hold several markers, and a single turn can hold more than one, because the agent compacts either when its own estimate nears the limit before a step, or after the provider rejects a request as too large. Hover over the marker to see which pass ran. See Context window limits.

Expand a marker to see what the pass removed:

These sizes are the agent’s own estimates of how many tokens it was about to send, not billed usage, so they don’t match the turn’s token totals. Use them to understand what the agent dropped, and Cost and usage for spend. A marker appears only for an agent that records compaction, so a conversation with no markers either never compacted or runs an agent that doesn’t report it.

A conversation that ended in failure shows an Error status badge in the summary header. The failure detail is on the turn or tool call that failed, not in a conversation-level notice.

A turn that failed carries its own Turn failed notice, under the agent’s response in Detailed view and in the agent’s message in Chat view. The notice names the failure’s error code when one was recorded, and shows the message the failure returned, or says the turn failed without error details when the failure recorded no message. A turn that failed before producing a response or a tool call still appears, with the notice in place of the response.

A tool call that failed shows an error status indicator on that tool call in its turn. Click the tool call to read the error it returned.

Open a transcript in the Detailed view to read each turn’s tool calls in its side panel, with the tool name, a status indicator, and the call’s duration. Expand a call to see the arguments it was given and the result it returned. Each tool call is grouped with the turn whose response it produced, including tool calls that do not go through an MCP server, such as an agent delegating to a subagent.

The transcript shows token usage per turn. For spend analysis across agents, models, and users, open Cost and usage in the sidebar (see Analyze Cost and Usage), or use breakdown queries through SpendingService.

A transcript shows Running while any of its turns is unfinished. Common causes:

For a self-managed agent, a transcript shows only what the agent’s own instrumentation exports, and some frameworks don’t emit model steps, token counts, or tool arguments as attributes a transcript can read. See Framework caveats and Message content capture. For a managed agent set to Metadata only, tool calls keep their name, status, and duration but not their arguments and results. See Transcript recording.

Opening a conversation that has no stored transcript reports No transcript found, with the note that no recorded transcript is available for this conversation. The state offers Try again, and Error details for the underlying response. On an agent’s Transcripts tab, the back arrow (Back to transcripts) above it returns to the conversation list. It is a warning rather than an error, because a conversation can legitimately have no transcript: the agent’s recording mode may have been off when it ran, the conversation may still be assembling, or its retention window may have passed. A request that fails for any other reason reports Transcript unavailable instead, with the error the call returned. You can reach this state from a link into a specific conversation, such as the Transcript link on a schedule trigger’s run. See Run an Agent on a Schedule.

To work out why a transcript is missing: