The approval is the product
Why the approval card, and not the agent builder, is the center of a delegation product. Blast radius, not capability, decides what people hand over.
14 July 2026 · 5 min read · Delagents
When we started sketching Delagents, the screen everyone expected us to design first was the agent builder: the place where you name an agent, give it instructions and pick its tools. We designed the approval card first instead, and we still spend more design time on it than on anything else in the product. This essay is about why.
Capability is not what stops people
The models are already good enough for most of the work our roster does. They can draft a refund reply in the house tone, categorize a month of receipts, rank twenty-five companies against a profile and write a two-line intro for each. If capability were the constraint, people would have handed their Gmail to an agent a year ago.
They have not, and the reason is not doubt about whether the agent can do the work. It is the question of what happens when the agent does the wrong thing with a real account. A wrong draft costs a minute. A wrong send costs a customer. A wrong refund costs money that has already left. The account is real, so the mistake is real.
Blast radius versus capability
Blast radius is the set of things that change in the world when an action runs, as opposed to the set of things that change on the screen. It is a different axis from capability, and it is the axis people are actually weighing when they hesitate.
| Action | Capability needed | Blast radius | What it needs |
|---|---|---|---|
| Draft a reply to a ticket | High: tone, context, policy | None; the draft stays in the workspace | Nothing |
| Send that reply | The same draft | A customer reads it | A sign-off |
| Issue the refund it mentions | Trivial: one API call | Money moves | A sign-off, always |
| Archive a thread | Trivial | Low; it can be undone | Depends on the agent's policy |
| Delete a record the agent did not create | Trivial | The previous state is gone | A sign-off, always |
Read the table by columns and the pattern is plain: the actions with the largest blast radius are usually the least demanding to perform. The hard part of a refund is not the refund. It is being sure it should happen. A delegation product has to be built around the third and fourth columns, not the second.
What a checkpoint changes
A checkpoint turns 'hope it does the right thing' into 'I saw it before it happened.' A budget cap turns an open-ended bill into a known one. Neither makes the agent more capable. Both make the hand-off possible, and the hand-off is the product.
So the approval card carries everything a person needs in order to decide in one look: the exact action, in the words the tool will receive rather than the agent's description of it; a preview of the payload, the email as it will read or the entry as it will post; the cost so far and the cost of this step; the rule that stopped it; and who else can decide. We store a fingerprint of exactly what the approver saw next to their decision, so the record can later show not only that someone approved, but what they were looking at when they did.
Why the builder is the wrong center
A builder is where you configure an agent. The card is where the agent's work turns into something that happened. If the builder sits at the center, the product optimizes for configurability: more settings, more branches, more ways to describe cases in advance. That is a reasonable center for an automation builder. It is the wrong center for delegation, because you visit the builder once per agent and the approval card twenty times a day. Design attention belongs on the repeated moment.
The best-designed screen in the app is the approval card, not the agent builder.
This is also where we differ from most of what we see around us, with the caveat that these products change monthly and we can only read their public pages. Relay.app is the nearest neighbor: human steps are native there, which we respect. Zapier Agents, as far as we can tell, treats approvals as one feature among many rather than the object the product is organized around. Products built to run unattended, Manus among them, put their effort into finishing the task without you, which is a different bet from ours.
What this decides for us
- When anything is waiting on you, the Inbox is the first thing you see. 'Waiting on you: 3' is the most important number in the product.
- A card can be decided from the Inbox, from the delegation page, from an email or from Slack, and every path shows the same preview.
- On a repeat action, the card shows only what changed since the last one you approved.
- Silence never means yes. A checkpoint left past its SLA escalates to the next approver, then pauses the run.
- Every decision, what was shown, who decided and when, lands in an append-only log the workspace can export.
The objection: approval fatigue
The honest objection is that after the twentieth card people stop reading and start rubber-stamping, and a card nobody reads protects nobody. We take this seriously, and the answer is not to remove the card. It is to make each one cheaper to read: show the diff, not the whole payload; let a workspace set decide-on-behalf rules once an agent has a track record; sample rather than review every repeat of a proven action. The floor, the eight actions that always stop for a person, does not move whatever the rules say.
When we demo Delagents, the screen on show is the approval card, with a real action behind it. If the card is good, everything upstream of it, the brief, the plan, the run, can be trusted a little more. If the card is bad, nothing upstream matters.
