When Trust Splits, the Blast Radius Should Split Too

This article asks one builder question: How should an agent system divide responsibility so that a mistaken recommendation does not automatically become a mistaken booking, purchase, or public action?

The community is converging on a practical distinction

Agent builders often describe trust as if it were a property attached to an agent: trusted or untrusted, safe or unsafe. In practice, communities are finding a more useful unit of discussion: the effect an agent is about to cause.

Reading a public source and extracting options has a small blast radius. Ranking those options has a larger one because the ranking shapes a decision. Sending money, changing a reservation, or publishing a message has a larger blast radius still. Treating all of those steps as one continuous “agent task” hides the point where a recoverable mistake becomes an external commitment.

The emerging pattern is not to make every step require a human. It is to split the workflow so each stage has the smallest authority it needs.

A trust split is more than a permissions list

A permissions list says what a component may technically do. A trust split says what evidence and approval are required before it does it.

Consider a travel workflow. A research worker may collect flight options, identify constraints, and attach source links. A planning worker may turn those findings into an itinerary, clearly labeling assumptions and unresolved conflicts. A booking worker may prepare the final transaction, but should not silently inherit authority from the research step. The person reviewing the booking needs to see the relevant evidence—not merely a green status from an earlier worker.

This separation creates useful friction. If a fare changed, a source expired, or a traveler’s constraint was misunderstood, the system can stop at the boundary where the discrepancy matters. Without the split, the same error can flow from search to recommendation to purchase before anyone has a meaningful chance to intervene.

The key is that each handoff carries a compact evidence package: what was observed, when it was observed, which assumptions were made, and what the next worker is actually authorized to do.

The hard design question is where to put the boundary

There is no universal number of stages. Too few boundaries create excessive blast radius; too many create an approval maze that users route around.

A good boundary usually appears when one of three things changes:

• The data changes status. An unverified observation becomes a recommendation.
• The action changes reversibility. A draft becomes a reservation, payment, deletion, or publication.
• The audience changes. Internal work becomes an external message or customer-visible result.

These transitions are more durable than organizational labels such as “research agent” or “executor agent.” A single implementation can perform several roles if the runtime still records the transition and applies the appropriate gate.

Community feedback is especially valuable here because builders see different failure modes. One team may discover that source freshness is the real boundary. Another may find that the dangerous step is not payment but sending an itinerary with incorrect names. The lesson is not to copy someone else’s exact topology; it is to compare where their irreversible effects begin.

Evidence should travel with the commitment

A trust split fails if the final reviewer receives only a polished answer. The reviewer needs enough context to challenge the answer without replaying the whole workflow.

That does not mean attaching every trace. A useful receipt can be small:

1. 1. Claim: what the system believes is true.
2. 2. Evidence: the source, artifact, or observation supporting it.
3. 3. Scope: which user, account, date, or transaction the evidence applies to.
4. 4. Uncertainty: missing data, stale values, or unresolved alternatives.
5. 5. Proposed effect: exactly what will happen if approved.

This structure also improves collaboration between agents. A downstream worker can reject an input that lacks scope or freshness instead of treating vague confidence as permission. Operators can compare competing proposals on evidence and consequence rather than on prose quality.

The most important field may be the proposed effect. “Ready” is ambiguous; “send this message to these recipients” is reviewable. “Book the selected itinerary for this traveler at this price, subject to these cancellation terms” makes the commitment visible.

Splitting trust changes product behavior

The user experience should reflect the split without forcing users to understand the internal architecture. Show progress as stages with different meanings: researched, proposed, ready for approval, and committed. Keep drafts editable. Make approvals specific and time-bounded when the underlying facts can change.

This also changes what the system should do when it cannot continue. Instead of producing ambient warnings or repeatedly asking for permission, it should leave one clear blocker: the evidence is stale, a constraint conflicts, or an external effect needs approval. The queue remains drainable because each unresolved item has a reason and a next action.

For builders, the operational benefit is as important as the safety benefit. Narrow commitments are easier to retry, audit, and reverse. A failed booking attempt need not invalidate the research. A corrected source need not erase the entire itinerary. The system can resume from the last trustworthy boundary rather than restarting from scratch.

A question for builders comparing approaches

When you review your own agent workflow, identify the first action that would surprise the user if it happened automatically. Then work backward: what evidence must be present immediately before that action, and which earlier steps can safely remain autonomous?

Share the boundary you found—and the failure mode that led you there. The useful community conversation is not whether agents should be trusted in the abstract. It is which commitments deserve their own evidence, authority, and pause.

Concrete next steps

• List each external or irreversible effect in one workflow.
• Mark the earliest step where an error would become costly or embarrassing.
• Give that step an explicit proposal-and-approval boundary.
• Pass a compact evidence receipt across the boundary.
• Test recovery by changing one upstream fact after research but before execution.

A trustworthy agent system is not one that claims uniform confidence. It is one that keeps mistakes local, makes commitments legible, and gives the right person a meaningful chance to stop the next effect.