Before designing an agent, I write down the decisions the system is supposed to make. “Handle incoming requests” is a goal, but it does not tell me whether the next step is predictable, whether missing information can be recovered, or what authority the system needs.
Those details determine the architecture. A fixed workflow follows an explicit sequence or set of branches. An agent can choose its next action from observations. Both can use a language model; the useful distinction is who controls the path through the work.
Separate uncertainty from ordinary business rules
Consider a request to update a delivery address. Reading a loosely written message may require language understanding. Checking that the order belongs to the customer is an ordinary access decision. Determining whether dispatch has already started is a current-state lookup. Applying the change is a business operation.
There is little value in asking a model to improvise all four steps. I would let it identify the request and extract a proposed address, then use explicit rules for ownership, eligibility and the actual update. If the address is incomplete, the workflow can ask a focused clarification question.
A different task, such as investigating conflicting descriptions across several sources, may need a less predictable sequence. An agent could decide which source to inspect next, provided its research scope and completion criteria are clear.
Draw the decision boundary before the tool list
I start with three questions: what can the system observe, what can it decide, and what can it change? These questions expose more useful boundaries than a long list of available integrations. A system that can read every account record still may have permission to change only one field on one verified account.
For each proposed autonomous step, I ask what new information could change the next action. If the answer is always the same, a fixed step is usually easier to inspect. If the answer depends on evidence that cannot be predicted in advance, limited agent choice may be useful.
The engineering work I do through Wizutech gives me a practical reason to make this distinction: operational software has to connect ambiguous human requests to precise system behavior. The architecture should make that transition understandable.
Give the flexible section a small interface
A useful hybrid design has an explicit entry condition, a bounded agent task and a checked result. For a research task, the result might contain candidate records, supporting sources and unresolved questions. It should not be an unconstrained paragraph that the next step has to reinterpret.
That boundary also makes replacement easier. A model can change while the surrounding application still expects the same result structure. The important contract is the meaning of the output, including what an incomplete result looks like.
My companion note on tool contracts for ambiguous requests develops that interface in more detail. A smaller decision space is useful only if the tools inside it have clear semantics.
Compare the complete task
I would compare a workflow and an agent on representative requests, including the cases that require clarification or cannot be completed. The useful measures include accepted outcomes, incorrect actions, operator effort and total execution cost. Counting model calls alone says little about whether the system solved the problem.
Failures should be grouped by their cause. A missing business rule needs a rule. An unclear request needs clarification. A genuinely open-ended investigation may benefit from adaptive planning. Expanding autonomy is a poor substitute for identifying which problem occurred.
Before expanding the design, I check whether delegating to multiple agents would produce independent deliverables. A bounded agent inside a predictable workflow can be a strong starting point: enough flexibility to investigate uncertainty, with the surrounding application still responsible for the task’s limits and outcome.
Updated 30 September 2026.