Designing AI workflows that survive contact with real work

Four principles we hold to: scoped roles, visible state, controlled actions, and recovery from checkpoint. Each exists because of a specific way autonomous systems fail.

Agent demos usually work. Agent deployments usually do not, and the gap between the two is not model capability. It is that a demo runs once, on a chosen task, with someone watching. A deployment runs continuously, on tasks nobody anticipated, while everyone is busy.

These are the four principles we design against. Each one exists because of a specific failure we would otherwise keep hitting.

1. Scoped roles

A general-purpose agent with every tool available will, given a broad enough brief, eventually use the wrong one. Not through malice or even error, but because a large action space with a vague objective makes some bad action reachable.

So specialists get a defined remit and only the tools that remit requires. A content specialist cannot issue refunds. A data analyst cannot publish externally. This is not a trust judgement about the model; it is the same reason production systems use scoped credentials rather than root everywhere.

The secondary benefit is quality. A role with a narrow remit and an explicit standard produces more consistent output than a generalist asked to be good at everything.

2. Visible state

The single most common complaint about autonomous systems is not that they fail. It is that nobody can tell whether they are working. A progress bar that only moves at the end is indistinguishable from a hang.

• Every task exposes what stage it is at and which specialist holds it.
• Spend is visible while it accrues, not summarised afterwards.
• Blocked work says what it is blocked on, in terms of the decision needed rather than the internal error.
• Anything waiting on a human sits in one queue rather than being discoverable only by looking.

The design rule we use: if a person had to walk away for two hours, could they tell on return what happened and what needs them? If not, the state is not visible enough.

3. Controlled actions

There is a hard line between work that is reversible and work that is not. Drafting a message is reversible. Sending it is not. Modelling a price change is reversible. Applying it is not.

Everything on the irreversible side is held for approval by default, and the approval shows exactly what would happen — the actual message, the actual amount, the actual recipient. Approving a summary of an action is not approval, because the summary is generated by the same system asking for permission.

Ask what the worst plausible action is, then ask whether a person sees it before it happens. If not, the gate is in the wrong place.

4. Recovery from checkpoint

Long-running work fails partway. An API rate-limits, a source goes down, a step times out. The naive response is to restart the task, which discards every completed step and repeats the cost.

Instead each step commits its result before the next begins, so a failure resumes from the last good state. On a task with an hour of completed research and a failure in the writing step, recovery costs the writing step, not the hour.

This has a design consequence worth stating: steps have to be individually meaningful. If a step's output is only interpretable in the context of the whole run, it cannot be a checkpoint. Designing for recovery pushes you toward a cleaner decomposition than you would otherwise write.

What these have in common

Every one of them costs capability in the short term. Scoped roles mean a specialist sometimes cannot do something adjacent that it could have handled. Approval gates add latency. Checkpointing constrains how work is decomposed.

That trade is deliberate. A system that is slightly less capable and substantially more predictable is the one you can actually delegate to, and delegation is the point. Capability you cannot leave unattended is a demo.