Execution control for autonomous agents

Your agent retried.
Do you know what it already did?

Ratchet is how you let an agent do things it cannot take back — charge a card, ship a deploy, publish a package, send the email — and know what it already did, what that cost, and what it may still spend.

• Never twice. A retry, a restart and two workers racing all get the same answer.
• Never a guess. When nobody can know whether it happened, we say so instead of assuming.
• It remembers for you. An agent that lost its context asks what it already did — one call, not a re-derivation.
• It cannot overspend. Give a task a budget and the gate refuses the step that would cross it.

Works with anything that makes an HTTPS request · 1,000 effects a month, free · No card · Two HTTP calls

curl -X POST https://ratchetgate.com/v1/effects/begin \
  -H 'content-type: application/json' \
  -d '{"effect_type":"email.send","idempotency_key":"demo-1","payload":{}}'

The problem is not that agents fail. It's that they retry.

An LLM's control flow is non-deterministic. Network calls fail ambiguously. Processes die mid-action. So the same logical action gets attempted zero, one, or several times — and nothing in your stack knows which.

Vendor idempotency keys help for the handful of vendors that offer them. They do nothing for SMTP, Slack, git, internal APIs, or the other twenty tools your agent touches — and nothing at all across separate processes.

What a repeat actually costs

Not knowing is the expensive part

An agent that cannot tell whether it already charged the card has three options, and all three cost you.

The gate replaces all three with one lookup. A repeat is answered from the recorded outcome in 2.3ms, a new effect in 5.1ms, and a capped runaway loop let 20 of 100 attempts through — measured with the scripts in the repository, in process and excluding the network time to you. The transcripts.

Ratchet never sees your model calls and does not make inference cheaper. What it removes is the work you would do to find out what already happened. Your console adds up the refusals in dollars not spent at vendors, and reports it as at least that, because effects without a declared cost are not counted.

New

A run gets a memory, and a wallet

An agent's memory of what it has done lives in its context window — lossy under compaction, paid for again every turn, and impossible to check. It can sincerely believe it sent the email and be wrong.

GET /v1/runs/trip-8812

{ "done":    [ { "what": "flight.book", "outcome": "succeeded" } ],
  "unknown": [],
  "budget":  { "remaining_micros": 140000 },
  "next":    "Everything under this run is settled." }

PUT /v1/runs/trip-8812/budget
{ "limit_micros": 50000000 }

The half that matters is not the ceiling — budgets could always refuse. It is that the agent can read its own balance, and one that sees what is left takes the cheaper path or stops cleanly, instead of learning the limit exists at the moment it spends. It cannot raise that ceiling: reading needs the scope agents carry, setting needs one they do not.

A twelve-step task listed in full is 10.1KB of context. The digest is 0.6KB — about seventeen times smaller, because a memory that costs more than re-deriving the answer does not get used.

Ask before you act

One call before the action, one call after. Ratchet holds the durable record.

The part that makes it worth paying for

When we don't know, we say so.

If your process dies between “go” and “done”, most systems quietly let the next caller retry. Ratchet won't. The lease expires and the effect becomes indeterminate — a known unknown, surfaced instead of buried.

Exactly-once delivery is not achievable in a distributed system, and we won't claim it. What Ratchet guarantees is at-most-once initiation, a recorded outcome that later callers replay, and an explicit state for the case nobody else admits exists.

The agent's door

The first call needs no key

An agent that finds this service shouldn't have to wait for a human to go and register. Send the first request with no credential at all: you get a real decision, and a workspace and API key come back with it.

curl -X POST https://ratchetgate.com/v1/effects/begin \
  -H 'content-type: application/json' \
  -d '{"effect_type":"email.send","idempotency_key":"welcome:user_123","payload":{}}'

→ { "decision": "execute",
    "workspace": { "api_key": "rk_live_…", "quota": 100 } }

Store the key — it is returned once. The workspace is a real gate, not a demo that always says yes, and it is capped at 100 gated effects until you claim it with an email. Claiming lifts it to the free plan.

It provisions a new workspace and can never reach an existing one, so this is the only unauthenticated write in the service. Everything that touches data you already have still needs a key.

The rest of it, in one place

Each of these is a real control with a real page behind it. None of them is something you need on day one.

• A loop that never fails Every call succeeds, so nothing alerts — and the bill arrives anyway. Set a ceiling per effect type, or a multiple of your own normal, and the breaker trips.
• Agents that never ask The gate only stops the code that calls it. Where a vendor honours idempotency keys, Ratchet derives the one they deduplicate on, so the refusal happens at their end whether or not your agent cooperated.
• Step five of five fails Declare the steps as one unit and how to undo each. Ratchet returns the rollback plan in reverse order — and each undo is itself gated, so a retried refund cannot double.
• Approvals, webhooks, audit Effects above a threshold can wait for a human. Every decision fans out to your webhooks, signed. Everything lands in an audit trail you can read.

Works with whatever you're building on

Plain HTTP, or MCP over stdio and streamable HTTP. No SDK required.

Verified against Claude Code / Claude Desktop, Cursor, and any MCP client that speaks stdio or streamable HTTP. The REST API is provider-neutral — nothing about it assumes a model vendor.