Rensei docs
A2A

A2A Dispatches

Dispatch history and outcomes.

The Dispatches page is the chronological audit log for every task the platform has handed to a registered external A2A agent. It covers both kinds of dispatch: explicit dispatches authored intentionally in a workflow via the agent.dispatch node, and transparent dispatches that the routing layer performed automatically during skill resolution.

Navigate to it from the Factory section of your project:

/<org>/<project>/factory/a2a/dispatches

Dispatch kinds

Every row in the a2a_task_instances table carries a workType prefix that encodes how the dispatch was initiated:

KindPrefixDescription
explicitexplicit:<workType>A workflow node directly named the agent and skill. The operator chose the target.
transparenttransparent:<workType> or bare stringThe routing layer selected the agent automatically via skill matching and Thompson Sampling. The caller specified work requirements; the platform chose the agent.

The Dispatches page decodes this prefix and lets you filter by kind.

Reading the dispatch log

Each row in the table shows:

ColumnNotes
AgentName and URL of the target agent (joined from agent_cards)
Skill / work typeThe skill invoked and the work-type label (decoded, prefix stripped)
Kindexplicit or transparent
Statusactive, completed, or failed
Session IDCorrelation key - links to the session that initiated the dispatch
StartedWall-clock dispatch time
LatencyDuration for completed/failed rows; blank for active rows

Click any row to view the session that initiated it, or navigate to agent detail to see all dispatches for a specific agent.

Filtering and pagination

Use the controls at the top of the page to:

  • Filter by kind - show all, explicit only, or transparent only
  • Filter by status - all, active, completed, or failed
  • Filter by agent - narrow to a specific registered agent

The log is paginated using a cursor-based scheme: the page returns up to 50 rows (max 200) ordered newest-first. A Next page button appears when more rows exist. The cursor is a started_at timestamp - bookmark the URL to return to the same position.

Back-compat note for pre-prefix rows

Rows written before the explicit: / transparent: prefix convention (W5-FU-9) are treated as transparent for display purposes. The filter and query logic matches both the prefixed form and legacy bare-string workTypes so older records remain visible without re-migration.

Interpreting outcomes

Active dispatches

active means the session has been claimed by a worker but has not yet posted a completion. An active row that is older than your expected session timeout may indicate a stuck agent. Use the session inspector on the linked session to diagnose.

Failed dispatches

failed rows record sessions that terminated with an error. Common causes:

  • The remote agent returned a JSON-RPC error envelope (task status.state = 'failed')
  • The dispatch timed out (default 30-second wall-clock timeout from the MCP bridge)
  • Cedar policy denied the invocation before the wire call

Click the session ID to inspect the full activity stream.

Cost and latency patterns

The latency column lets you spot slow agents. For cost-related breakdowns, visit the Routing Intelligence panel, which shows per-agent Thompson Sampling posteriors and cost-efficiency scores derived from dispatch outcomes.

How dispatch records are created

Every time the platform routes work to an A2A agent, recordTaskStart in task-instance-store.ts writes a row to a2a_task_instances with status='active'. When the session completes, recordTaskComplete updates the row to completed or failed and stamps completed_at. The dispatch log reads this table directly.

The MCP bridge emits pre-verb and post-verb events on the Layer-6 hook bus, which trigger the task-instance-store subscriber to write and update rows without any coupling between the bridge and the persistence layer.

On this page