Relay

An AI agent makes a change. The API times out. What actually happened?

Did it fail, succeed without returning a response, or leave us unable to tell?

Relay sits between that failure and the retry.

It checks what actually happened before deciding what should happen next.

That prevents blind retries from duplicating, overwriting, or repeating actions.

See how Relay handles failuresExplore all scenarios

How Relay works

An agent tries to update a claim reserve from $5,000 to $8,400. The timeout is real, but it is not enough to know whether the business change happened.

Agent intentReserve $5,000 -> $8,400
Enterprise callAPI timeout

No success response comes back.

The uncertainty gapDid the change happen?

The response cannot tell us.

RelayChecks what actually happened
Actual systemReserve = $8,400
Safe decisionDo not retry

The effect already exists.

The request looked like it failed. The business action actually succeeded. Relay caught the difference before another write could run.

The same pattern lets Relay handle partial completion, stale state, duplicate requests, and outcomes that cannot be safely proven.

See the proof

Run the failure, inspect an execution trace, or check the reliability evals.

Inspect a traceOpen Execution Traces to see the attempted action, read-back, reconciliation, and recovery decision.View the evalsOpen Reliability Evals to inspect the deterministic regression suite covering the failure semantics.

Under the hood

The planner proposes intent. Deterministic software owns execution safety.

Failure injection

Reproduces timeout-before-write, timeout-after-write, partial completion, stale state, and other failure conditions deterministically.

See scenarios

Reconciliation + recovery

Compares intended effects with the resulting system state before deciding whether to leave an action alone, retry selectively, replan, or stop.

Inspect a trace

Execution safety

Uses idempotency, expected-version checks, retry limits, selective retry, and human review to prevent unsafe repeated mutations.

See failure cases

Verification

Persists execution evidence in Postgres and exercises the reliability semantics through replayable traces, integration tests, browser workflows, and deterministic evals.

View evals

Try the failure modes

Timeout after write

The change succeeds, but the response is lost.

Partial completion

One action succeeds and the next fails.

Ambiguous outcome

Relay cannot prove whether the action happened.

Explore all scenarios

Synthetic claims workflow. No real insurer or Guidewire integration.