Start with the customer’s request
A fixed menu can handle a predictable routing question. A document assistant can help with questions whose wording varies. A system that changes an order or prepares a workflow action needs additional permissions and controls. Name the task first; calling something an “agent” does not establish what it can reliably do.
One refund request, three system boundaries
A customer asks to cancel a class and return the credit. The product label tells you little about the risk: what matters is which records the system can change and whether a person must approve the change.
| Capability | Example behaviour and control |
|---|---|
| Informational chatbot | Explains the cancellation policy from approved material; hands off an account-specific decision |
| Read-only assistant | After identity checks, retrieves the booking status but cannot cancel it |
| Action-taking agent | Proposes a cancellation; a bounded tool validates ownership, policy and duplicate requests |
Separate answering from acting
Reading a policy and issuing a refund have different consequences. Define which sources the system can access, which actions are available and when a person must approve. Use limited permissions for each connection and keep enough history to understand why an action was attempted or refused.
Test the boundaries
Evaluate realistic requests, missing information and attempts to ask for unauthorised actions. A useful test checks whether the system asks for clarification, cites the right material or hands over to staff when it cannot proceed. Measure complete task quality and operating cost rather than the fluency of one impressive answer.
Before you proceed
- Choose the narrowest capability that completes the task.
- Define allowed sources, actions and human handoffs.
- Test failures and uncertainty as well as successful answers.
