Design Sensible Boundaries and Approvals

Would you let an AI agent organise a list of holiday ideas? Probably. Would you let it spend £2,000 on a non-refundable trip without asking? That's a very different proposition.

The same assistant can be useful at both ends of a task, but different actions deserve different permissions. Reading public information, creating a draft and making a payment are not interchangeable.

Suppose your agent is preparing a club event. It could research venues, build a shortlist and draft enquiries. You might approve the outgoing messages one by one, while keeping payments and bookings entirely outside its scope.

Those boundaries aren't there to make AI less interesting. They let you give it more useful work with confidence. A tool that's allowed to create documents but not send them can still save substantial time.

A good design asks where a mistake would be awkward, costly or difficult to reverse. Set approval points there, rather than interrupting every harmless step with another confirmation.

You tell an assistant to organise the household's finances. That could mean categorising spending, generating a budget, moving money or cancelling services. The same broad instruction covers actions with very different consequences. Useful AI systems need boundaries matched to those consequences.

Imagine starting with a much smaller task: analyse a fictional bank-statement export and prepare a summary of recurring expenditure. You might allow the system to read that test file and create a report. It has no reason to access your email, change account settings or contact providers. Restricting its permissions keeps the task understandable and reduces what could go wrong.

Now imagine a connected system that can draft cancellation emails for unused subscriptions. Drafting is valuable and relatively easy to inspect. Sending those emails changes relationships with real organisations. You may reasonably require confirmation before a message goes out, particularly if the system is uncertain about the contract or the intended recipient.

An approval point should occur where it changes the risk. You don't need to confirm every harmless search or every paragraph the assistant writes. You might let it gather options and prepare drafts independently, then ask for review before sending, purchasing, deleting or sharing sensitive material. This preserves useful autonomy while keeping consequential decisions visible.

There's also a difference between permission and intention. An integration may technically allow file deletion, but the task doesn't necessarily require it. A well-scoped agent should know that its job is to prepare a report and not treat all available tool capabilities as invitations to act. If it encounters an ambiguous instruction, asking is better than improvising a destructive action.

Think about failures and retries. Suppose the assistant sends a message but the connection drops before it receives confirmation. If it simply tries again, the recipient might receive duplicates. A robust design needs a way to check what happened before repeating an action. These are ordinary software concerns that become increasingly important when a model decides which tool to call next.

Good boundaries are not restrictions added to spoil an exciting feature. They are what make the feature practical enough to trust. The clearer the permissions, approval points and failure behaviour, the more confidently you can delegate work that would otherwise remain manual.

An approval screen should tell you what action you're approving. 'Continue?' is vague. 'Send this draft email to these four recipients' gives you a meaningful decision. The recipient list, the contents and any attachment should be visible before you confirm the action.

It's also sensible to separate what the agent can *see* from what it can *change*. Read access to a calendar may be enough to identify meeting dates. Creating an event needs additional authority. Deleting an event is another level again. These distinctions let you use connected tools without granting unnecessary powers.

As you test, introduce one small failure: a missing file, an expired connection or an ambiguous recipient. See whether the system stops and explains what it needs. The quality of its response to a problem may tell you more about its readiness than a demonstration in which every step works perfectly.

The aim isn't to interrupt the agent constantly. It's to give it enough room to do useful preparation while making important changes visible and reversible where possible. A simple, clearly designed approval boundary can make the difference between an intriguing demonstration and a tool you'd be comfortable using regularly.