Stork Delivery
An agent needs a stop button
Before an AI system can take action, define its limits, approval points, and the way a person can interrupt it.
The problem: an AI agent can act beyond a useful boundary
An assistant that drafts a response and an agent that sends it have different responsibilities. The second system can create a business consequence before someone has reviewed the result.
If you want an AI workflow to act on behalf of the business, design its limits alongside its capabilities.
A practical approach
Start with a narrow authority
Describe exactly what the system may read and change. A service agent might summarize a case and propose a response while being unable to issue a refund or alter account access.
Use application permissions and constrained tools to enforce those boundaries. Instructions in a prompt can describe the intended behavior, but they should not be the only barrier protecting a consequential action.
For each tool, make the available operation understandable. “Update customer” is broad. “Add an internal note to this case” is easier to limit and inspect.
Put approval at the decision point
If a person must approve an action, show the actual proposed change and the relevant source information. A generic permission to “continue” gives the reviewer too little to judge.
Recheck authorization when the action is executed. An approval based on an older record may no longer apply if the underlying facts have changed.
Keep the approval separate from successful completion. A permitted action can still fail, and the user needs to know whether it happened.
Bound the run
Set limits on elapsed time, tool calls, retries, and spending as appropriate to the task. Decide what happens when the system cannot make progress.
Provide a cancellation mechanism that prevents new work from starting and accounts for work already in flight. Stopping the conversation does not necessarily cancel a request that has already reached another system.
Some effects cannot be undone automatically. The operator should be able to see those effects and the available recovery steps.
Keep a useful record
Record the request, relevant approvals, tool calls, and confirmed outcomes at an appropriate level of detail. Avoid treating a model's private reasoning as the audit record; record observable decisions and actions the application can verify.
Before wider use, test interruption, repeated actions, denied permissions, and unexpected tool responses.
A useful agent has enough authority to complete a bounded task and enough controls for the business to remain responsible for the outcome. Those controls are part of the product, not cleanup work after the demonstration.
The result: an agent whose actions can be limited and interrupted
Start with one permitted action and demonstrate approval, denial, cancellation, and a failure after execution begins. The operator should see which effects completed, which remain uncertain, and what recovery is available. Confirm that stopping the run prevents further work from starting. Use this evidence to decide whether the agent is ready for a wider task or needs a narrower scope.