Decide when a workflow should become agentic
Use an agent where choosing the next step adds value. Keep stable rules explicit, and evaluate the complete path to a useful outcome.
The decision to build an AI agent should follow an understanding of the work. Some tasks require interpretation and a changing sequence of actions. Others follow stable rules that the organisation already understands. Giving both the same agent-based solution adds complexity without establishing a business advantage.
Anthropic’s distinction is useful: a workflow follows predefined paths, while an agent directs its process and tool use. I would apply that distinction to the decision structure of the task. The question is whether choosing the next step is itself an important part of the work, and whether the system can make that choice within acceptable limits. (Anthropic source)
Examine the path, not the demonstration
Consider a request for an order-status update. If the order number is valid and the answer comes from one authoritative record, a defined lookup and response template may do the job. Adding open-ended planning creates more opportunities for unnecessary tool use and uncertain interpretation. A language model could still help explain the result without controlling the entire process.
Now consider investigating why an order is at risk. The path may depend on what is discovered: a material shortage, a capacity constraint, an unresolved quality issue, or conflicting records. An agent could potentially decide which authorised source to inspect next and assemble evidence for a planner. Its usefulness would depend on the quality of those sources and the reliability of its investigation.
These are different problems even though both begin with an order number. The second needs a stopping condition: enough evidence to support a defined recommendation, an unresolved ambiguity requiring a person, or a limit on time and tool use. An investigation that keeps collecting information without improving the decision consumes capacity without delivering an outcome.
Preserve the parts that should remain predictable
A sensible design can combine a fixed workflow with bounded agentic work. Identity checks, access permissions, record validation, and approval requirements can remain explicit. The agent can investigate within that boundary. This allows flexibility where interpretation is useful while keeping the organisation’s commitments under dependable control.
The same principle applies to outputs. A free-form explanation may help a person understand an issue, but a downstream system may require a validated record with specific fields. The design needs a deliberate transition between those forms. Fluent language should not be treated as evidence that an action request is complete or authorised.
Business owners also need an alternative when the agent cannot finish. That alternative might be an existing manual queue or a narrower workflow. It should preserve the information already collected and make the unresolved question clear. Otherwise, every difficult case restarts from the beginning and the apparent time saving disappears at the handoff.
Compare complete operating alternatives
I would evaluate a candidate agent against the current process and a simpler automated option. Use representative cases, including difficult exceptions. Compare acceptable completion, review effort, elapsed time, running cost, and recoverability. The evaluation should include the work performed by people after the system produces an answer.
The decision to expand should be specific. An agent may be useful for investigation but unsuitable for making customer commitments. It may work well within one product family while struggling with inconsistent records elsewhere. Those limits are valuable findings because they tell the organisation where its operating conditions support delegated work.
Agentic design should be a response to a real need for flexible action. When leaders can explain that need and demonstrate its value against a simpler approach, they have a sound basis for investment.
Developed from my EA 878 capstone on the Cognitive Enterprise Architecture Framework (CEAF); BA 809 individual analysis of capability modelling. These recommendations extend the coursework; examples are illustrative and do not report an employer assessment or measured results.