Service

Agents that stop

change anything that matters.

The interesting question about agents was never whether they can do the work. It is what happens the first time one is confidently wrong while holding your send button, your database, or your payment API.

The answer most teams ship with is “we told it not to in the prompt.” That is not a permission system. It is a request.

We build agents that do the reading, drafting and routing unsupervised — because that is where the leverage is — and stop for a person before anything that cannot be undone.

The rule

Anything irreversible gets a human in front of it. Everything else runs.

01

What gets gated

The map is short and worth making explicit early, because it decides the architecture. Gates are cheap to design in and expensive to add later.

ActionTreatment
Sending email or messagesCannot be unsent. Gate it.
Charging or refundingMoney moves. Gate it, and make it idempotent or you will double-charge.
Deleting or overwritingGate it, and prefer soft deletion so the mistake is recoverable.
Publishing externallyGate it. The internet keeps a copy.
Filing or submittingGate it. Regulators do not accept "the agent did it".
Reading, drafting, summarisingSafe. Let it run — this is where the leverage actually is.
02

The six things that break

01

The approval gate

The agent proposes; a person disposes. The hard part is not the button — it is holding the run's state coherently while it waits, sometimes for days, and resuming correctly when the answer arrives.

02

Idempotency

Every agent runs twice eventually — a retry, a redeploy, a duplicate webhook. Every side effect needs a key so the second run is a no-op rather than a second invoice.

03

Retries that don't compound

Naive retries on a partially-applied action are how one failure becomes five records. Retry belongs around the unit of work, not around the whole run.

04

Cost ceilings

An agent in a loop is a billing incident. Per-run and per-day ceilings, enforced in the runtime, with a defined behaviour on hitting them that is not "crash".

05

Tool boundaries

What the agent may touch, stated explicitly and enforced in code rather than requested in a prompt. A prompt is not a permission system.

06

Legible traces

What it decided, what it called, what came back, what it did next — readable by a person debugging at 2am, not just by a dashboard.

03

On the Claude Agent SDK

We build on the Claude Agent SDK and know its deployment model well enough to have opinions about it — including the one most teams miss: you can spawn the Claude Code binary and have runs bill against a subscription rather than requiring per-token API keys.

That is not a trick, it is a legitimate deployment mode, and for internal tooling it changes the economics substantially. It is the kind of thing you only learn by shipping on the platform rather than reading about it.

We are not religious about the SDK. If your stack is already on something else, the architecture above is the part that matters.

What can your

that you couldn't undo? Let's find out together.