Money, messages and deletions

Sort every tool into three bins

Reversible and cheap. Reads, drafts, records you can edit. Let the agent do these freely; gating them costs more than the mistakes.

Reversible but public. A message you can delete after fourteen people have read it. A comment on a customer’s issue. Technically undoable, practically not. Treat these as irreversible. This is the bin teams get wrong, because “we can delete the post” sounds like a plan until you have watched a screenshot travel.

Irreversible. Payments, refunds, deletions, sends, publishes, submissions, anything with a legal counterparty.

The sorting is the design. Do it in a document, out loud, before you write the tools.

Four controls, cheapest first

1. Dry run by default. Every destructive tool takes a commit flag defaulting to false, and returns a rendered description of what would happen. The agent’s normal mode is therefore producing a plan. Execution is a separate, non-model step over that plan.

This one change removes most of the fear from the rest of the design, and it gives you the diff you will need for approval.

2. Numeric limits in the harness. Maximum refund amount. Maximum recipients per run. Maximum rows a single delete may touch. Maximum total spend per day. Numbers in code, not sentences in a prompt: you already know why.

One worth stealing outright: refuse any bulk operation touching more than a handful of records without approval. Most catastrophes are a single operation with a missing condition on it.

3. A delay with an undo window. Queue the send for sixty seconds with a cancel link in the team channel. Far cheaper than an approval step, requires nobody to be at their desk, and catches most of what approval would catch, because the errors people catch are the obvious ones, and sixty seconds is enough to notice an obvious one.

4. Approval on the specific action, showing the exact diff.

Deletion is a status change

In an automated system, delete means setting a deleted_at timestamp, with the real purge done later on a schedule a person controls. Two reasons: an agent’s deletion is precisely the operation you are most likely to want back, and a hard delete can orphan everything that referenced it. Give the agent the soft delete and nobody the hard one.

Roll it out in stages

Shadow mode first. The agent produces the action; a person does the work as usual; you compare the two. Two weeks of that gives you a real error rate against real inputs, before anything can go wrong. It is the most underused technique in this whole subject, because it feels like not shipping.

Then five per cent automatic, then fifty, then the rest, with the error rate watched at each stage rather than assumed.

A kill switch you have tested

One flag, in one place, that stops all runs without a deploy. A row in a table, an environment variable the runner re-reads each cycle, a feature flag.

Then test it, and time it. If you cannot stop your automation within thirty seconds, at 3am, from a phone, it is not ready to run unattended. That is not a metaphor. Try it once and write the number down.