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, and its input and output token totals. 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 expand it in place and read the exact call: the Arguments the agent sent and the Result it got back, both as JSON, and the error message when the call failed. A tool call with none of those recorded doesn’t expand. Which of them a 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 don’t expand. 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. Tool calls that do not go through an MCP server, such as an agent delegating to a subagent, appear the same way.

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. Expand the tool call to read the error message 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.