Runtime — Idempotency

Retry anything.
Execute once.

Pass an idempotency_key and every write is fenced at the database constraint level. If your agent retries, times out, or fires a duplicate — the fence catches it. The provider API is never called twice. The cached result is returned instantly.

Not application-level deduplication.
Enforced at the infrastructure layer.
Across all 2,800+ providers.

API Docs → Get API Access

The fence

Caught at the constraint.
Before the provider sees it.

The idempotency fence is a database-level unique constraint on every write operation. When a duplicate arrives — from a retry, a timeout recovery, or a concurrent duplicate request — the constraint catches it before any provider API is called. The cached response is returned. The provider is never hit twice.

idempotent execution

# First call — executes normally

POST /v1/runtime/actions/run

{

"verb": "stripe:create_refund",

"args": { "amount": 50 },

"idempotency_key": "refund-order-1234-v1"

}

# Response

{ "success": true, "refund_id": "re_abc" }

# Retry with same key — fenced

POST /v1/runtime/actions/run

{

"verb": "stripe:create_refund",

"args": { "amount": 50 },

"idempotency_key": "refund-order-1234-v1"

}

# Response — cached, not re-executed

{ "success": true,

"refund_id": "re_abc",

"idempotent": true,

"cached_from": "exec_9xk2p" }

Database constraint — not application logic

The fence is enforced at the database constraint level on every write. No race condition, no timing window. The second call is caught before it leaves the runtime.

Works across all 2,800+ providers

Most APIs don't natively support idempotency keys. The Cerebral fence enforces deduplication regardless of whether the underlying provider supports it. You get safe retries on every verb.

Cached response returned instantly

Duplicate calls don't just fail gracefully — they return the exact cached response from the original execution. Your agent sees success, gets the original result, and moves on.

Works in dry run too

Pass an idempotency key in dry run to test retry behavior before going live. The fence checks even when writes are intercepted — so you can validate deduplication logic safely.

Why it matters

Agents retry.
Production doesn't forgive duplicates.

LLM-based agents are non-deterministic. Networks time out. Events fire twice. Without idempotency enforcement at the infrastructure level, every retry is a potential duplicate refund, double-send, or duplicate order. The fence makes retry logic trivial to build and safe to run.

Network timeouts

Your agent fires an action, the network times out, and it retries. Without idempotency, the action executes twice. With the fence, the retry returns the cached result from the first execution.

Concurrent duplicate requests

Two instances of your agent fire the same action at the same time. The database constraint catches the collision. One executes. One gets the cached result. Neither fires twice.

LLM non-determinism

The model decides to call the same action twice in the same conversation. The fence catches it before the provider sees either call. Your agent's indecision doesn't become a billing event.

Retry anything.Execute once.

Caught at the constraint.Before the provider sees it.

Agents retry.Production doesn't forgive duplicates.

Retries are safe.Always.

Retry anything.
Execute once.

Caught at the constraint.
Before the provider sees it.

Agents retry.
Production doesn't forgive duplicates.

Retries are safe.
Always.