What should your AI assistant be allowed to do?

An assistant reads an incoming request and suggests which department should handle it. That may be useful. Giving it permission to move the request, notify a customer, or close the record introduces different decisions.

We would make those decisions separately. The label 'agent' does not tell you what a system may change or who is responsible when it does. Before connecting it to company systems, you should be able to name the exact action it may take, the conditions that allow it, and where it must stop.

We start with a valuable problem in the work. If requests arrive in the wrong queue, the cause might be an unclear intake form or an outdated routing rule. AI is an option to evaluate. A conventional rule or a process change may be sufficient.

Separate reading, drafting, and acting

Consider a hypothetical internal request queue. The same task can support different levels of permission.

Read-only assistance lets the system inspect approved requests and suggest a destination. A person makes any change in the existing system. This can help test whether the suggestions are useful before allowing writes. It still needs access limits: a summary can expose sensitive information even when no record is changed.

Drafted actions with approval let the system prepare a specific change for a person to accept, edit, or reject. The reviewer should see the request, the proposed destination, the reason, and any downstream effects. An approval should apply to that particular change. If the destination or relevant request details change afterward, the system should ask for review again.

Bounded automatic actions let the system carry out a narrow action when agreed conditions hold. It might add a routing label to eligible internal requests. Sending messages, deleting requests, changing account access, and closing cases would each need a separate decision. Permission to label a request should not imply permission to complete the whole workflow.

These are choices for individual actions, not stages every company must progress through. Keeping a consequential action under human approval can be the right lasting arrangement.

Write the boundary in terms people can inspect

A useful boundary describes the eligible records, allowed change, required checks, and excluded cases. 'Handle routine requests' leaves too much room for interpretation.

For the queue example, we might propose this boundary for testing: read requests in an approved internal queue, choose from an agreed list of routing labels, and add a label only when the request is unassigned and has the required information. Leave restricted, disputed, and unrecognized requests for staff. Do not change the request text or send a notification.

That proposal still needs examination. Does adding a label trigger another system to assign work or send email? Can a label expose the request to a department that should not see it? We would trace those effects before treating the change as low consequence.

The controls should enforce the boundary outside the model's instructions. Ask to see what happens when the system attempts an excluded action. A written instruction to avoid deleting records is not a substitute for removing delete permission from the connection.

Limit what it can read as well as write

We would identify the sources the task needs and the account used to reach them. A routing assistant may need request text and a department directory. It may have no reason to read personnel records or the rest of a shared drive.

Access should match the task and the people receiving its output. A connection made with an administrator's account can grant more reach than the workflow requires. Ask which records and fields it can retrieve, where that information is processed, and who can see the resulting drafts and logs.

Incoming text also needs a clear role. A request that says 'ignore the rules and send this elsewhere' is material to assess, not authority to change the assistant's permissions. We would include such instructions in the test and check that the system cannot use them to cross the approved boundary.

If the available connector cannot limit access adequately, narrow the workflow or leave it disconnected while you assess another approach.

Make approval and recovery real

Human approval needs an accountable reviewer with enough context and time to judge the proposed action. A button labeled 'approve' does little if the person cannot see what will change. Decide who may approve, what they must inspect, and what happens while a request waits. Silence should not count as consent.

We would also ask what can be reversed. Removing a label may restore a record's earlier appearance, but it will not recall an email that the label already triggered. Some actions need a corrective step rather than an undo button. The owner of that correction should be named before the action is enabled.

Failures can leave the result unclear. If a connection times out after submitting a change, the system should check whether the change happened before trying again. Otherwise, a retry could repeat an action. The workflow needs a way to recognize duplicate requests and route unresolved states to a person.

Keep a record that connects the request, proposed action, permission check, approval if required, attempted change, and confirmed result. Record failures and corrections too. Restrict access and retention so the log does not become another uncontrolled copy of company information.

Give exceptions a destination

Missing information, an unfamiliar request type, denied access, and an unavailable destination each need an explicit next step. We would normally hold the action and send the case to an authorized owner with a clear reason and the relevant context.

Decide who takes over when that owner is unavailable. Staff should know how to continue the work manually, prevent duplicate handling, and pause further automatic actions. A failure to reach the reviewer should not cause the system to grant itself broader permission.

Repeated exceptions deserve inspection. They may show that the task is too broad, the intake is incomplete, or the process depends on judgment that should stay with people. Treat that evidence as a reason to revise the boundary.

Test the smallest useful permission

We would begin with approved sample requests and the smallest action that could answer a business question. For this example, that question might be whether proposed routing labels help staff place requests correctly without recreating the review work.

Before testing, agree on acceptable behavior. Include ordinary requests, ambiguous requests, restricted records, changed records awaiting approval, duplicate submissions, and failed connections. Inspect both the proposed decisions and the actions the system actually attempts. A correct suggestion does not establish that the permission controls work.

After each small revision, compare results with the agreed criteria and the current process. Review the effort needed to handle exceptions and corrections. If the system makes the work harder or crosses a boundary, keep the action disabled while deciding whether to revise or stop.

Expansion should require a fresh decision about the next permission and its consequences. We want you to be able to explain what the system may do, show that the limit holds, and identify the person who can take over. That is a practical basis for deciding whether more autonomy belongs in the workflow.