ForjioHuudisIdentityPlugipayPaymentsCatentioAgentsStorlaunchE-commerceFulkrumaFulfilmentRiplloMarketingLinkSnapShort URLsPawpadoGPU streaming
Catentio Docs
⌘K

Runs

The Runs page at Dashboard → Runs is the record of every agent invocation — one shot at one agent, whatever the transport (Discord, REST, CLI, chat bubble, or a pipeline step). A run is reconstructed from its event stream: everything the page shows is aggregated from the events table by run_id.

Runs vs. pipeline attempts

They're related but not the same thing:

  • A run is one agent session — prompt in, events out.
  • A pipeline subtask attempt is one execution of a project step. When the step is kind: agent, the attempt spawns a run and records it as child_run_id — that run shows up here like any other, tagged with its project.
  • Retry/redo mechanics live at the project layer (attempts, retrigger, revert); the run itself is just the session record.

For pipeline-driven multi-step work, start at Projects.

The runs list

The list shows the last 7 days of runs (up to 500), sortable and filterable by agent, transport, model, and status. Columns: Started, Agent, Transport (with a project link when the run came from a pipeline step), Status, Model, Events, Cost, and Run ID.

Statuses are derived from the run's terminal event: running, completed, failed, cancelled.

Click any row for the run detail page.

The run detail page

Agent slug, run ID, the model the run resolved to (with tier, routing rule, and effective reasoning level when the model-dial recorded them), and the status pill.

Stat strip

Transport, started time, duration, event count, cost (USD, summed from the run's cost events), and peak context (tokens and approximate % of the window).

Prompt

The message the run responded to, with its author when known. Long prompts are stored truncated.

Actions

  • Cancel — while the run is running. Cancellation is recorded as a run_cancelled event; everything up to the interrupt is kept.
  • Retry — re-invokes the same agent with the same prompt as a new run with a new ID; the original is immutable.
  • Artifact — when the run produced a run artifact, this jumps straight to its recap/comments/share page.

Score

When the scoring system evaluated the run, the process score (and, on evidence-bearing runs, the LLM result score) with its breakdown.

Context

What went into the session: context-load events, per-step context growth, and the content breakdown when the session transcript is available.

Timeline

The full event stream, ordered: run_started, tool calls and results, model resolution, cost events, through to run_completed / run_failed / run_cancelled. This is the ground truth everything else on the page is derived from — use it when "the agent said it did X" doesn't match what happened.

Artifacts and recaps

Runs that produce reviewable output get a run artifact: a structured recap (summary, per-file changes, commands, outputs, media), a comment thread where the agent replies asynchronously, and PIN-protected public sharing. They live at Dashboard → Artifacts — see Portal → Artifacts.

Querying via API

const runs = await catentio.runs.list({ agent: 'hachimi', limit: 50 });
await catentio.runs.cancel('<run-id>');

runs.get(id) doesn't work. It calls GET /v1/runs/{id}, which doesn't exist on the control plane. For a single run's detail, call GET /v1/runs/{id}/detail directly over REST (404s once the run has aged out of the runtime's in-memory registry) — there's no SDK wrapper for it yet.

The REST surface adds GET /v1/runs/{id}/events, GET /v1/runs/{id}/detail, GET /v1/runs/{id}/context, GET /v1/runs/{id}/context/content, POST /v1/runs/{id}/retry, and GET /v1/runs/{id}/artifact (404 when the run produced none). GET /v1/runs/{id}/status exists as a route but is currently broken (it proxies to a runtime endpoint that doesn't exist) — don't rely on it.

Next