“Where is my order?” and “You promised delivery yesterday, the carrier says something different, and I need to change the address” might arrive in the same inbox a minute apart. A support team recognises two different jobs. The first may need a single record lookup; the second requires someone to untangle what happened before deciding how to respond.
That everyday distinction deserves more weight in an architecture discussion than enthusiasm for deploying an AI agent. Bring both requests to the design meeting. Which steps can you specify in advance, and where does the work turn into an investigation? Working through those questions makes the choice between a workflow, an agent and a combination of the two much more concrete.
Who decides what happens next?
A deterministic workflow follows a sequence and conditions defined by its designers. It receives data, checks requirements, queries systems and performs actions according to explicit rules. Deterministic refers here to control of the route. An external service or an AI component within that route may still return variable results.
An agent uses a model to decide part of the route: what information to obtain, which tool to consult or when to stop investigating. That flexibility can help when inputs and intermediate steps cannot be fully anticipated. Anthropic's distinction between workflows and agents separates predefined paths from dynamically selected actions. Neither category is inherently more mature. The right architecture meets the business objective at an acceptable level of cost, delay and operational risk.
It helps to distinguish three kinds of uncertainty. Input uncertainty concerns a structured form versus an ambiguous email. Route uncertainty concerns known steps versus an investigation that depends on intermediate findings. Outcome uncertainty concerns an objectively verifiable result versus an answer that requires human judgement.
Free text does not automatically require an agent. A model can extract proposed fields from a message, after which conventional rules validate them and determine the next step. The process retains a predictable route while gaining an interpretation capability. Autonomy becomes more useful when the system must choose between several investigations and revise its approach after each result. Even then, the available decisions should have clearly defined boundaries rather than an unrestricted mandate to solve everything.
One order, two possible routes
Return to the inbox of an imaginary distributor. A customer wants to change the delivery address after a delay. Before interpreting the complaint, the system needs to identify the order and establish whether this person may access it. A workflow can handle those checks using explicit rules; an AI component then interprets the request and proposes the next step.
If the order is still being prepared, consulting the address-change policy may be enough. If warehouse and carrier records disagree, a bounded agent could examine previous messages or ask for missing information. Autonomy enters the process at the point where investigation helps, rather than becoming the default for every step.
The important boundary comes when something must change. Retrieving an order, reading messages and proposing a resolution are different tools from changing an address or granting compensation. Those actions need their own validation and approval. A persuasive customer message does not change the policy, just as a persuasive agent response does not establish permission to act. Keeping that distinction visible also gives operators a practical way to understand what happened when a case goes wrong.
The boundary around each tool
Each tool should describe a recognisable business operation with defined parameters, validation and output. A tool called “update customer” is too broad if it permits changes to every field. “Propose a correction to the contact telephone number” has a more understandable scope. Authorisation belongs in the system performing the action. A prompt telling a model not to change sensitive information cannot replace a technical permission check. Separate reading from writing, record the requesting identity and preserve a case identifier across calls.
Set limits for iterations, elapsed time and spending. When the agent reaches a limit, it should hand over a useful state to a person: what it checked, what it found and what remains unresolved. Continuing to search indefinitely is not evidence of better service.
A convincing answer can still be wrong
Before expanding autonomy, assemble representative test cases. Include complete requests, ambiguous wording, conflicting records and unavailable services. Define what successful completion means before observing the system's answer. Evaluate a conventional workflow, a hybrid alternative and an agent against that same set. Measure correct resolution, mistakes reaching customers, human intervention, response time and cost per completed case. Repeat probabilistic tests to reveal variation rather than relying on a single favourable run.
Plausible language is an insufficient acceptance criterion. A system may write an excellent explanation after retrieving the wrong order. Evaluation must inspect the business result and the actions performed, not merely the quality of the final paragraph. Review serious failures separately from ordinary mistakes. An incorrect greeting and an unauthorised refund should never disappear inside one average quality score.
The ongoing price of flexibility
Model usage is only one cost. Tool calls, storage, monitoring, retries, human review and maintenance also matter. A system using fewer tokens can still be more expensive if its outputs create extensive correction work.
For frequent, stable processes, explicit rules often provide an operationally straightforward foundation. For variable investigations, those rules can generate a growing queue of exceptions. Compare the complete operating cost using the actual frequency of each scenario. Write down the improvement that justifies additional complexity. One useful criterion might be more correctly resolved cases without an increase in unauthorised actions. That is more informative than a general ambition to deploy agents across the organisation.
Include the cost of change in the comparison. If business rules change every week, the team needs an economical way to update them, test them and communicate their consequences to operators.
The architecture will keep changing after launch. A new commercial policy, a replacement integration or an unexpected exception will force another decision. Someone on the business side must own what counts as an acceptable outcome, while a technical owner controls permissions, evaluation and deployment. Without those responsibilities, every incident risks becoming a fresh negotiation about what the system was meant to do.
When the next proposal to “put an agent on it” arrives, ask how it would handle the two requests that opened this article. If a workflow handles the first reliably, extra autonomy needs a reason. If a bounded investigation improves the second, you have something worth testing. Bring that comparison to DigitalCube, along with real exceptions and the outcomes your team needs to protect. It is a more useful starting point than choosing the technology before examining the work.