Skip to main content

Every action, as it happens and afterwards

An agent's tool calls - actions, in the product - are recorded before they run and finalised when they return. That record is what you read in a session, what the Activity tab is built from, and what the integration's usage page lists across every session. This page is about reading it.

The actions drawer: one row per tool call with its name, integration, status and duration, the failed call open to show what was sent and what the service answeredThe actions drawer: one row per tool call with its name, integration, status and duration, the failed call open to show what was sent and what the service answered

While a turn runs​

Open a conversation with a turn in flight and a card above the composer follows it from the first moment: …is working with Thinking… before any tool has run, then the step it is on, then …is responding once the reply starts to arrive. Each action is added the moment it starts - a spinner, then a tick or a cross once it settles - named for a person, with its integration. A call that started another agent or flow links to that agent's session as soon as it exists, and View all opens the Activity tab. The card stays put for the whole turn rather than riding beneath the growing reply. When the reply lands, the same calls are filed under it and the card goes away - the stored message is the authoritative record.

For API consumers the same signal is the session stream: tool_call.started names the row and the tool, and tool_call.finished closes it with a status and a duration. See the API reference.

Reading a turn​

Beneath an assistant reply, one line sums up what the turn did: the marks of the integrations it used, Used N tools, how many subagents it started and whether they have come back, how many calls failed, and the time the calls took. The calls never expand inside the conversation, so a reply that used forty tools takes the same space as one that used two.

Select the line and the actions open in a drawer, one row per call:

  • the tool by its name - Append rows, not yekar.google-sheets.append-rows - with its integration and whether it reads only or makes changes;
  • a status chip - succeeded, failed, awaiting approval, or running;
  • the duration.

Open a row to see what the agent sent and what came back, as labelled fields rather than JSON. Long lists and nested values are summarised (List of 212 items); View raw JSON shows the input and output exactly as recorded - indented, coloured, and with a copy button in each block's top-right corner - with the tool's full id beneath. A failed call opens by itself, with its error first and, where the integration made HTTP requests, the service's own answer - method, host, path, status and error code - under What … answered.

A tool call opened in the actions drawer with View raw JSON: its input and output as indented, coloured JSON, each with a copy button in the cornerA tool call opened in the actions drawer with View raw JSON: its input and output as indented, coloured JSON, each with a copy button in the corner

When a reply did a lot, Search tools finds a call by the name you read (append rows) or its id, and the Failed and Changes filters narrow the list. Search and filters run on the server over every call behind the reply, the counts on the filters are the server's, and a long reply loads in pages with Show more.

A row still marked running after the turn has ended is not a live call. It means the record was opened but never finalised - the run was interrupted mid-call - and it is the evidence you would otherwise lack.

Credential material never appears in a recorded input or output. Keys are removed by name and known secret formats by value, and the shape is kept, so Authorization: Bearer [REDACTED] still tells you which header the tool used. A call that failed at the turn level shows its error code and message on the reply itself.

Calls that started another agent​

A call that spawned an agent or flow says so in its row - the agent or flow's name, its current state, and Open its session. While the child is waiting on something the row says what, in the child's own words: the question it asked, or the write it wants approved. Consecutive spawning calls fold into one row with a tally of how many returned, failed, wait or still run. The whole model is in Calling other agents.

Activity​

The Activity tab is the whole session's record, turn by turn. The tiles across the top - turns, tool calls, failed, tokens and span - are counted over the entire session in the database, so they stay true however long the conversation grows. Span is the time from first message to last, not execution time.

Tools used lists every tool the session has called, most used first, with its failures - counted over the whole session, not what the tab has loaded; select one to search for it. Beneath it, each turn is one row - newest first, the newest already open - with its time, the message that started it, how many tools and subagents it used, how many failed, its status and how long it took. Open a turn and each step is a row with its offset from the start of the turn and a bar on that turn's own time axis, so a slow step stands out however far apart the turns were. Model rounds appear as steps too. A bar that fades out is still running at the time of the fetch - the tab never pretends something ended. Select a tool call to open it in the same drawer the conversation uses.

The Activity tab: tiles for turns, tool calls, failed, tokens and span, the tools used, and the newest turn open with each step as a bar on the turn's own time axisThe Activity tab: tiles for turns, tool calls, failed, tokens and span, the tools used, and the newest turn open with each step as a bar on the turn's own time axis

Search, the Failed and Subagents filters, and Expand all narrow a long session. Search and filters run on the server: a search matches a tool's name or id (and a subagent's name), and a turn with nothing matching is left out while the rest keep their numbers. The record is windowed: when a session holds more turns or calls than the tab loads, a line above the turns says exactly what was left out.

A Flow session also has a Run tab. Expand a run, select a step, and the inspector shows the step's resolved input, its output, and one card per tool attempt.

Across sessions: an integration's usage​

To see what agents did through one integration regardless of session, open the integration under Integrations and select Usage. It is scoped to a domain's connection, and reads for the domain's owners.

An integration's usage page: calls, reads, writes and errors over 30 days, calls per day, the by-tool table, and the latest 50 actions each linking to its sessionAn integration's usage page: calls, reads, writes and errors over 30 days, calls per day, the by-tool table, and the latest 50 actions each linking to its session
  • Calls, Read calls, Write calls and Errors over the last 30 days, and a calls-per-day chart.
  • By tool - calls, writes, errors and last called, per tool.
  • Recent actions - the latest fifty calls with status, duration, time and a link to the session or run they ran in; a Test chip marks a step test.

Every call here is also on the session it ran in; this page is the cross-section, not a second record.

What survives, and for how long​

Action records are pruned after 90 days by default; transcripts are never pruned. Open a conversation older than that and you will read every message, attachment and error, but the actions line under each reply will be gone, and the Activity tab will count zero tool calls and show turns without their steps.

What outlives the prune: the per-turn census behind an agent's Health page (tool names, counts, tokens, durations - facts, never bodies), the daily cost rollups behind Cost, and the audit trail of approvals, which is permanent. A golden eval case keeps its own copy of a recording at the moment it is saved, for the same reason.