Observability
Failed step diagnostics and human-in-the-loop corrective actions
A failed station does not quietly try again. It stops with the state it actually produced and surfaces for evaluation, which is what makes the next decision a person's rather than a retry loop's.
Open Orchestration dashboard in the consoleA failed station does not retry itself
A station that cannot proceed stops and surfaces, carrying the state it actually produced rather than the state it was supposed to produce. It does not quietly try again with stale context.
The failure most first runs hit
Reading the failure
Start from the recorded state rather than the error at the end. The first station whose output stopped matching what the next one needed is usually the real problem; the station that eventually failed is often just the first one that could not continue.
- Open the run's traceRead from the top, in station order.
- Find the first surprising outputNot the first error — the first output that is not what the next station was going to need.
- Check whether a tool call was involvedA refused tool call is recorded with its reason, which is frequently the whole explanation.
Correcting and re-running
Because nothing retried itself and nothing was overwritten, correcting means changing the thing that was actually wrong — a rule file, a grant, a connection — and starting a new run. The failed run stays as the record of what happened.
Put it into practice
Run a fleet with these guardrails on from day one.
Hard cost caps, one audited gateway in front of every tool call, and versioned rule files — the defaults, not an enterprise add-on.