Break the chain. Then make it dependable.

Model a multi-step AI automation, inject real failure modes, and inspect which safeguards improve reliability, latency, cost, and human workload.

Simulation only. This lab never connects to an inbox or external app. “Save to drafts” is an inspectable local state, not a real side effect.

Worked example

Failure injection

Email draft chain

Draft only · six steps · human approval required

ReadyRunningPassedFailedRecovered

Failure scenarios

Select one, then run or step through the chain

Execution trace

Ready to simulate

No run yet
Pick a failure mode and run the chain.

Reliability report

Transparent estimates from the current safeguards

Reliability61%end-to-end success

P95 latency18.4sincludes retries

Expected cost$0.08per attempted run

Manual review42%runs needing a person

Before

61%

Hardened

91%

Reliability = product(step success) + recovered failures − duplicate side effects

Retry amplification1.18×attempts per run

Dedupe protection100%duplicate suppression

Recovery coverage83%failures with a route

P50 latency7.2stypical successful run

Typed contracts

Schema validation catches malformed model output before it reaches a downstream action.

Idempotency

A stable event key makes retries safe and prevents duplicate drafts or notifications.

Recovery routes

Checkpoints, dead-letter queues, and compensation turn silent loss into inspectable work.

Human judgment

Risk-based approval targets ambiguous cases instead of forcing every run through review.

Automation reliability: safeguard scores and simulated failures

Your browser does not support video.

Read the explanation

The reliability lab initializes a six-node email-draft chain. Five nodes contribute ten safeguard points each and the approval node eight, totaling fifty eight. Baseline is forty nine plus twice node count, sixty one. Adding rounded average safeguard coverage times three point seven gives ninety seven, capped at ninety eight. Bars compare sixty one and ninety seven at three pixels per score. These captions are heuristics, not measured production uptime or evidence that ninety seven percent of real requests succeed. An enabled flag affects metric sums but the execution step routine still iterates through every node. Model prompts, approvals, schemas and compensation labels are configuration strings; no actual model, mail service or external action is invoked. Configured costs are five non-AI nodes at point zero zero two dollars and one AI node at point zero two four, total point zero three four. Ten configured retries across six nodes produce amplification one plus ten over one hundred eight, about one point zero nine two six, giving point zero three seven one five dollars rounded four cents. Bars encode node and retry counts at five pixels per count. The displayed median latency sums clipped timeouts times point eighteen plus one point two, giving ten point two seconds. Multiplying by an authored percentile factor yields twenty two point four seconds. This is not a sampled percentile. Changing cost or timeout changes estimates, while displayed execution trace cost and latency are independently constructed captions. The default tone scenario fails at zero-based index three, so four native step clicks append four trace rows and stop the simulated chain safely. A rate-limited scenario at index one with positive retries advances to the next node after a Retried caption, without replaying the failed action or waiting exponential backoff. Six clicks then produce six trace rows. Bars encode those row counts at forty pixels per row. Duplicate-event mode stops after its first suppressed row and can still show a completed outcome because no node is marked failed. Approval rejection is scenario-driven, not a real reviewer decision. Native steps and actual JSON and CSV exports preserve the original simulation, configuration IDs are normalized only in paired headless comparison, and no public or exhaustive real-service reliability proof is claimed.