A team asks for an AI agent to handle customer requests. Before selecting a platform, there is a more useful question: which parts of this work genuinely need the system to choose its next step?
If the process is already clear, a fixed workflow may be easier to test and operate. If the work requires interpreting an unfamiliar situation and deciding which information to gather next, an agent may offer useful flexibility. Many business processes need a combination of both.
The leadership decision is how much discretion to delegate, where to place it and what evidence will justify it. This connects the process-mapping and responsible-use boundaries in my VORTA material with the distinction between automation, assistants and agents in my AI for Business training.
Separate the interface from the way the work runs
A conversational interface does not tell you how much autonomy a system has. A chatbot can collect information for a tightly controlled workflow. A scheduled process can include an agent that chooses among several research tools.
Anthropic’s engineering article makes a useful architectural distinction: workflows follow predefined paths, while agents let a language model direct the process and use of tools dynamically. It also recommends adding complexity only when simpler approaches are insufficient. The terminology varies across products, so examine the actual design rather than relying on the label.
For a business decision, distinguish three options:
- Rules-based automation: defined inputs trigger defined actions. A valid form creates a record and sends an acknowledgement.
- A fixed workflow with AI steps: the sequence remains controlled, but AI interprets or generates information within a step. For example, it classifies a message before established routing rules assign the case.
- A bounded agent: the system can choose intermediate steps or tools to reach a stated goal, within explicit limits on data access, actions and resources.
A workflow containing AI still needs evaluation: its sequence may be predictable while a model’s classification or draft remains unreliable. Conversely, an agent can operate inside strict boundaries. Flexibility and control are design choices that need to be considered together.
Use one process to compare the options
Consider an illustrative customer-support process. These are design examples, not results from a client project.
Request: “Where is my order?”
When identity has been verified, the order identifier is valid and the order system is authoritative, the path is largely known: retrieve the status, apply the approved response format and show the result. AI may help interpret the initial message, but it does not need to invent a plan for checking a delivery date.
The important exceptions are also clear: no matching order, conflicting records or insufficient identity evidence. Define where each exception goes before automating the normal case.
Request: “These updates contradict each other. What happened?”
Now the task may require comparing an order record, a courier update and earlier correspondence. A bounded agent could choose which approved source to inspect next and prepare a sourced explanation. Its permission to investigate does not automatically include permission to change an address, issue compensation or make a delivery commitment.
The final handoff might still be a fixed workflow: the agent submits its findings, an authorized person decides on an exception, and the case-management system records the outcome. This puts flexibility where investigation requires it while keeping consequential actions explicit.
Ask four questions before adding autonomy
1. Is the uncertainty in the route or in the policy?
An agent can help explore an uncertain route to an answer. It should not be used to conceal an unresolved business policy. If managers disagree about who qualifies for a refund, adding an agent will not establish a legitimate refund rule.
Write down what is unknown. “We do not know which source will resolve this discrepancy” is different from “we have not decided what staff are allowed to offer.” Resolve the second issue through accountable management.
2. Can someone verify completion?
Define a useful end state before choosing the implementation. For an investigation, completion could mean a summary that identifies conflicting records, links to the evidence and states what remains unresolved. A polished answer alone is an inadequate acceptance test.
If nobody can assess whether the result is correct, begin with a narrower task or better source information. An open-ended instruction such as “handle the customer” leaves too much room for different interpretations of success.
3. What could the system change?
List permissions as concrete actions: read a record, prepare a draft, update a field, send a message or authorize a transaction. Separate the actions that may run independently from those that require approval. Enforce important limits through the application and its permissions, rather than relying only on wording in a prompt.
When a human decision is required, make the review usable. The reviewer needs relevant evidence and a genuine ability to refuse or intervene, as discussed in human oversight of AI.
4. Does flexibility improve the complete job?
Compare the simplest credible approach with the proposed agent on the same representative tasks. Include ordinary cases, missing information, conflicting records and failed tool calls. Measure correct completion, intervention effort, time and operating cost. Set resource limits appropriate to the task and define what happens when they are reached.
Count the work needed to inspect and repair outputs. A faster first draft may create a slower end-to-end process. The relevant comparison is the cost and quality of a completed job, consistent with measuring AI value beyond time saved.
Record the decision in a short design brief
Before implementation, bring the process owner and the delivery team together to complete these six lines:
- Outcome: the specific result the business needs.
- Fixed steps: the sequence and rules already known.
- Permitted discretion: what the system may decide for itself.
- Action limits: what it may read, change or communicate, and under whose authority.
- Acceptance evidence: how correct completion will be checked.
- Exception owner: who takes over when the system cannot proceed safely or reliably.
This brief does not replace technical testing or a risk assessment. It makes the business decision clear enough for those activities to be meaningful. Revisit it when the purpose, connected tools or permitted actions change.
Start with the part of the process whose outcome and boundaries can be explained clearly. Add autonomy where testing shows that it improves useful performance. A deliberate combination of rules, AI-assisted steps and bounded investigation can be a stronger solution than giving the whole process the same level of freedom.
If you are deciding how to structure a business assistant or automation, schedule a consultation to examine the workflow, decision boundaries and evidence needed for a practical first implementation.