Run status and steps

AMC's status sync calls GET /runs/{id}/status on every live run, every 60 seconds by default. It is the record of the run. AMC also calls it whenever someone opens the run, to draw the step list, so keep finished runs readable.

{
  "orchestratorRunId": "run_5f2c0e8a41b94c55",
  "status": "running",
  "currentStep": 2,
  "totalSteps": 3,
  "steps": [
    {
      "stepId": "fetch",
      "name": "Fetch invoice",
      "status": "completed",
      "agentId": null,
      "agentName": "Fetcher",
      "startedAt": "2026-10-17T09:30:00.300000+00:00",
      "completedAt": "2026-10-17T09:30:04.900000+00:00",
      "tokenCount": 0
    },
    {
      "stepId": "summarize",
      "name": "Summarize",
      "status": "running",
      "agentId": null,
      "agentName": "Summarizer",
      "startedAt": "2026-10-17T09:30:05.000000+00:00",
      "completedAt": null,
      "tokenCount": 4810,
      "inputTokens": 4200,
      "outputTokens": 610,
      "cachedInputTokens": 3000,
      "model": "<model-id>"
    },
    { "stepId": "approve", "name": "Approve summary", "status": "pending", "tokenCount": 0 }
  ],
  "runName": "invoice-INV-1042"
}

Run fields

For runName, assigneeRef and failureReason, an absent or null value means "no statement". It never clears what AMC already recorded.

Run status values

Once AMC records completed, failed or cancelled, the run is final: it stops polling, and later reports don't change it.

Completed with issues

When a run produced a usable result but part of the work wasn't done, report completed with outcome: "partial" and a run-level failureReason that says what wasn't done. The run's status stays completed; its outcome is partial instead of success.

{
  "orchestratorRunId": "run_5f2c0e8a41b94c55",
  "status": "completed",
  "currentStep": 2,
  "totalSteps": 2,
  "outcome": "partial",
  "failureReason": "Slack post failed; the report was saved but nobody was notified.",
  "steps": [
    { "stepId": "report", "name": "Save report", "status": "completed", "tokenCount": 0 },
    { "stepId": "notify", "name": "Notify channel", "status": "failed", "tokenCount": 0,
      "failureReason": "Slack returned 503" }
  ]
}

• •partial is the only value AMC reads. It matches after trimming, without regard to case. Any other value, or no outcome, is no statement, and the run is a clean success.
• •AMC honors it only with status: "completed". On a failed or cancelled run it is ignored.
• •Send it on the same report as completed. Once the run is final, later reports don't change it.
• •AMC never derives a partial outcome from failed steps. A completed run with a failed step and no outcome is a clean success. Whether a failed step matters is your agent's call.
• •AMC stores up to 2000 characters of failureReason. Without a run-level reason, it uses the first failed step's failureReason.
• •People see Completed with issues with the reason, and the completion email's subject starts with Completed with issues. The run counts as neither a pass nor a failure. An admin can mark it complete or failed.

Step fields

Declared steps

If you registered declared steps, AMC shows the full plan as pending from the start of the run. It matches each declared step to a reported one by key equal to stepId (then by name, ignoring case). Reported steps that match nothing stay in the order they ran, alongside the matched ones. When the run ends, declared steps that never ran are dropped.

Step content

When someone opens a step, AMC calls GET /runs/{id}/steps/{stepId}/content. AMC doesn't store it, so serve it for as long as people may look at the run.

{
  "stepId": "summarize",
  "action": null,
  "delivered": "Invoice INV-1042: 14 line items, three cost centers, total within limit.",
  "reasoning": null,
  "activityLog": [
    { "time": "2026-10-17T09:30:05.200000+00:00", "type": "thinking", "tool": null,
      "text": "Grouping line items by cost center", "result": null },
    { "time": "2026-10-17T09:30:06.800000+00:00", "type": "tool", "tool": "get_invoice",
      "text": "{\"id\": \"INV-1042\"}", "result": "{\"total\": 1200}" }
  ]
}

delivered is the step's headline output. Each activityLog row is one detail line under it: type is thinking, tool or result. AMC also accepts a bare string as a row and shows it as a tool line.

Live events

GET /runs/{id}/events returns text/event-stream. Replay the run's events from the start, then follow new ones, and close the stream when the run ends. Each event is one data: line holding a JSON object.

data: {"eventType": "step.status", "orchestratorRunId": "run_5f2c0e8a41b94c55", "stepId": "fetch", "payloadFragment": "{\"status\": \"running\"}", "at": "2026-10-17T09:30:00.300000+00:00"}

data: {"eventType": "step.status", "orchestratorRunId": "run_5f2c0e8a41b94c55", "stepId": "fetch", "payloadFragment": "{\"status\": \"completed\"}", "at": "2026-10-17T09:30:04.900000+00:00"}

data: {"eventType": "run.completed", "orchestratorRunId": "run_5f2c0e8a41b94c55", "stepId": null, "payloadFragment": "{\"summary\": \"...\"}", "at": "2026-10-17T09:31:10.000000+00:00"}

payloadFragment is a string that itself holds JSON. AMC parses it by event type and drops events it can't read:

Events are display only. Anything you send on the stream must also appear in /status, because the poll is what AMC records.