AI Gateway

Runs

Reconstruct a full agent turn — model calls and tool calls correlated into one run.

Overview

A run groups everything an agent did in a single working session into one view: the model calls it made (the conversation) alongside the tool calls it ran (the actions). Rather than reading model traffic and tool activity in two separate places, Runs lets you reconstruct a whole agent turn in order.

You'll find it at AI Gateway > Agent Control > Runs.

How runs are correlated

Model calls and tool calls are tied together by a shared run id (agent_run_id). For the two halves of a turn to appear under the same run, the agent must use the same id on both:

  • Tool calls: The native tool-call hook uses the agent session id it already sends as the run id automatically.
  • Model calls: The agent sends the run id on its model requests via the x-vw-agent-run-id header. The aliases x-session-id and helicone-session-id are also accepted, so agents already instrumented for other tools can correlate with little or no change.
Use the same id on every call
Correlation only works when the agent sends the same run id on every call of a turn: both its model calls and its tool calls, including any sub-calls. If the model calls don't carry the header, they'll be captured and governed as normal but won't appear inside the run.

A call with no run id is still fully logged and governed exactly as before; it just won't be grouped into a correlated run. No capture or enforcement is lost.

The runs list

The Runs page lists one row per run, most recent first. Each row shows:

ColumnDescription
RunA short form of the run id.
AgentThe agent key associated with the run's tool calls.
StartedWhen the run began (the earliest call in it).
Model callsHow many model (conversation) calls the run made.
Tool callsHow many tool (action) calls the run made.
DeniedHow many tool calls were blocked by a guardrail. Shows a dash when none were denied.

Click any row to open the run detail.

Run detail

The detail drawer shows every entry in the run, model calls and tool calls interleaved in the order they happened. Each entry is tagged so you can tell the two apart:

  • Model call: Shows the prompt sent and the response received, plus the model used and timing.
  • Tool call: Shows the tool name, its arguments and a summary of the result.

Conversation capture

Prompt and response content is only stored when body logging is turned on for your organization, via the guardrail settings flags Log request body and Log response body. Both default to off.

  • When the flags are on, the prompt and response shown are the post-guardrail (scanned and masked) versions, never the raw unmasked text.
  • When the flags are off, model entries show "(body logging disabled)" instead of content. The run, its counts, timing and tool activity are still recorded.
Privacy first
Because stored prompts and responses can contain sensitive data, body logging is opt-in and stored content is always passed through your guardrails first, so masked entities stay masked in the run view.

Empty state

If no runs exist yet, the page explains how they appear: runs show up once an agent sends the same run id on its calls (the x-vw-agent-run-id header on model calls, or the session id on tool calls).

Backend API

EndpointDescription
GET /mcp/runsList runs, one row per run with model and tool call counts, denied count, token and cost totals. Paginated.
GET /mcp/runs/{run_id}Get a single run's entries (model and tool calls) interleaved in chronological order.

Using runs for compliance

Runs support record-keeping and human-oversight requirements by making a complete agent turn reconstructable end to end: what the agent was asked, what it answered and what actions it took, with every action still passing through allow, deny or approval before it ran.

PreviousMCP audit log
NextMCP approvals
Runs - AI Gateway - VerifyWise User Guide