Delegating to AI means deciding what it may decide
Define what AI may do, what needs approval and when work must stop. A practical delegation table and testing checklist for founders.
Delegating to AI means deciding which actions it may take, which require approval and which conditions must stop the work. Define those boundaries before connecting tools or expanding the task. Clear instructions help, but actual permissions and review controls must support them.
A goal tells the system what you want. It does not automatically grant authority to do everything that might help achieve it. “Improve customer retention” could involve research, draft responses, pricing changes or customer contact. Those are different actions with different consequences.
Separate preparation from commitment
Begin by listing the actions the workflow could take. Then ask which ones are reversible, who is affected and what evidence is needed before they happen. Preparing a suggested response is different from sending it. Flagging a disputed invoice is different from issuing a refund.
The NIST AI Risk Management Framework emphasises documented responsibilities and accountability. The table below is a practical workflow tool, not a certification exercise or a claim of compliance with that framework.
A worked boundary table
This customer-service scenario is illustrative. It describes a proposed operating design, not a live Walter feature or a measured customer outcome.
A service manager wants AI to help organise incoming requests. The initial scope is to read the authorised queue, prepare a proposed category and draft a response from approved guidance. A person remains responsible for customer commitments.
| Boundary | Example action | Required behaviour |
|---|---|---|
| Within delegated scope | Prepare an internal draft and identify the guidance used. | Keep it labelled draft and attach the supporting source. |
| Approval required | Send a response, offer an exception or change a customer record. | Show the exact proposed action and affected record to the authorised reviewer. |
| Stop and escalate | Guidance conflicts, identity is uncertain or the request is outside the agreed policy. | Do not improvise a commitment; explain the missing decision and route it to the owner. |
This table only becomes effective when the implementation matches it. If the workflow is supposed to draft only, avoid granting an unnecessary send capability. If approval is required, check that the approved action and the executed action are the same.
Make approval concrete
“May I proceed?” is difficult to assess without context. A useful approval request names the recipient or record, the exact action, the proposed wording or change, the supporting evidence and any unresolved uncertainty.
After approval, record what actually happened. Approval is permission, not proof of execution. If an action fails or the circumstances change before it runs, report that state instead of treating the earlier approval as a successful outcome.
Also define the scope of repeat permission. Approval for one specific reply does not necessarily authorise future replies to different people. Make any standing authority explicit and narrow enough to review.
Define stops that mean something
A stopping condition should identify an observable trigger and the next owner. “Use common sense” is not a reliable operational boundary. “Stop if the proposed refund is outside the supplied policy and ask the service manager” is clearer.
Other useful triggers can include missing source access, conflicting instructions, repeated failed attempts or a request to act on the wrong account. Choose them for the actual task. Do not copy a generic list and assume the important cases are covered.
Try the boundaries before expanding permission
Test a permitted action, an approval-required action and a stop case with synthetic or properly authorised inputs. Check both the visible request and what the system actually does. If it asks for approval but can still execute without it, the boundary has not been demonstrated.
Keep the first trial small enough for a person to inspect every result. Record unexpected behaviour and narrow the task where needed. Broader autonomy should follow evidence about this workflow, rather than enthusiasm about what the model can do in a demonstration.
A delegation brief to reuse
Goal: [observable outcome]. You may: [bounded actions]. Ask before: [specific commitments]. Stop when: [observable triggers]. Evidence required: [sources and checks]. Decision owner: [person]. Review date: [time]. Execution record: [where actual outcomes are kept].
The point is to make authority understandable to the people who remain accountable. An agent can carry out work within a boundary. The founder still decides what that boundary should be.
Explore Always Running: visit AlwaysRunning.ai to learn more.
