Give an AI Assistant Clear Approval Boundaries
An instruction such as “help me handle this” sounds clear until the work reaches a decision. May the assistant send the message? Change the deadline? Purchase the service? Share a file? Promise the customer a result?
If those boundaries live only in your head, the assistant must either interrupt you constantly or guess. A clear approval boundary tells it what may proceed, what may only be prepared, and what must stop for your decision.
Define authority by consequence
Do not begin with a long list of tools. Begin with consequences. Work deserves a stronger approval boundary when it can:
- Commit or transfer money.
- Create, change, or cancel a promise to another person.
- Publish or communicate in your name.
- Grant access to private or sensitive information.
- Accept legal terms or change a policy.
- Delete, overwrite, or irreversibly move important work.
The same tool can support low- and high-consequence actions. Drafting an email and sending it use the same surface, but they are not the same authority.
Use three simple permission levels
A practical boundary can use three levels:
- Prepare: gather context, analyze options, and draft a proposed result.
- Execute within bounds: perform an exact, reversible, low-consequence action inside a defined scope.
- Return for approval: stop before any action that crosses the stated consequence boundary.
For example: “Draft the renewal response and identify any changed terms. Do not send, accept, or reject the renewal. Return the draft, source terms, and unresolved questions for my review.”
Make the scope exact
Name the account, project, customer, file, date range, or other boundary that defines the assignment. Also name protected items that must remain untouched.
“Organize the project folder” is ambiguous. “Move the five approved image exports into the existing Campaign Assets folder; preserve source files and report any name collision” gives the assistant a target, a safe action, and a stop condition.
State when silence means nothing
An assistant should never treat your delayed response as approval for consequential action. Say so directly: “If I do not reply, leave the proposal pending.”
This prevents urgency, schedules, or repeated reminders from turning absence into permission. Approval should be an observable decision, not an inference.
Require evidence on return
Define what the assistant must show when it returns: sources, assumptions, a before-and-after view, saved output, persisted setting, delivery receipt, or a list of untouched protected items.
The evidence should match the claim. A screenshot may show how a page looked; it does not prove an email was delivered. A save notification may show an attempted update; a reload is stronger evidence that the setting persisted.
Write the boundary into the assignment
Use this five-line pattern:
- Outcome: what should be prepared or changed?
- Scope: what exact systems and records are included?
- Authority: what may be executed without another approval?
- Stop conditions: which exceptions must return to you?
- Evidence: what proves the result and preservation?
This is a core practice of human-controlled AI executive assistance: giving the assistant enough room to be useful without making it the hidden authority for the company.
What we are exploring with Orabuena
Orabuena is in private research and product discovery. We are exploring how approval boundaries, stop conditions, and evidence can travel with delegated work across tools. This is an operating practice and product direction, not a generally available capability.
If your AI assistant either interrupts constantly or acts too freely, show us one boundary that is hard to express. Research participation is separate from product-update emails, a Founding 20 application, and any future purchase.