Chat assistance, fixed workflow or agent?
The key question is who selects the next step. Consider the same task: answering a customer’s delivery enquiry using information from their order.
- Chat assistance: A colleague finds the order, supplies the necessary details and asks for help drafting a reply. They direct every further step. This fits when writing is the main task.
- Fixed workflow: Every enquiry follows a predefined sequence: identify the order number, retrieve the order, check required fields and save a reply draft. Fixed if-then branches are also possible. AI can interpret the text without choosing the process itself.
- Bounded agent: After the first lookup, the model uses the result to decide whether to read a related shipping record or whether it has enough information for a draft. It receives a small set of permitted tools.
Does this example really need an agent?
The example above can also be built as a fixed workflow: “If a linked shipping record exists, retrieve it.” When the necessary branches are manageable, this is an easy choice to trace and review. Different wording in emails alone does not require an agent.
An agent is more relevant when different enquiries need different approved information and the next lookup depends on an intermediate result. Identify such cases in advance. If there are none, the extra freedom to choose steps has no clear benefit for this task.
Which permissions does this process need?
The example permits order search, reading linked shipping records and saving an internal draft. Changing orders and sending messages are technically blocked. Reading, writing and sending remain separate permissions; a prompt alone is not an access control.
Any later addition of external or financially consequential actions needs appropriate permissions and approvals. Define who takes over a case and what they can see: the enquiry, sources found, steps already taken and the unresolved question.
When must the process stop?
An unreadable attachment leads to “manual review”. Two possible orders lead to “match unresolved”, rather than a guessed selection. An unavailable interface leads to “lookup failed”, rather than a claim that no order exists. These states must be visible to the responsible team.
Treat incoming emails and documents as data rather than new system rules. Content can include misleading instructions. Restrict permitted actions technically and log relevant changes.
- Limit retries and tool calls per case; once the limit is reached, hand it to a person with its last known state.
- Use the same case ID to check whether a retry creates a second draft or duplicates an action.
- Test whether a person can safely take over; repeat these cases after changes to the model, rules or interfaces.
How do you decide after a pilot?
Compare the bounded agent with the existing process or a fixed workflow on the same typical enquiries and exception cases. Check: Was the correct order found? Are statements supported by retrieved data? Did handover happen at the right point?
Also record time spent checking and correcting results, and failed lookups. If additional searches do not improve the answer or create more rework, simplify the process. The proportion of automated steps alone says little about its value.