Choose between AI agents and workflow automation by asking who decides the next action. In a predefined workflow, the application follows routes designed by the team. An agentic design lets a model choose some steps and tools used to pursue a goal. Both can include AI, business rules and human review.
The practical question is how much discretion a task needs and what evidence justifies granting it. Flexibility does not establish that a business rule is followed correctly. Predictable sequencing does not establish that information produced by a model is accurate.
Distinguish rules, model assistance and agentic control
Anthropic's architecture discussion distinguishes predefined workflows from model-directed processes and tool use. That distinction is more useful than a product's “agent” label. Its older tooling examples are not a current implementation-stack recommendation.
| Approach | Who chooses the route? | Question to investigate |
|---|---|---|
| Rule-based workflow | Application rules | Are inputs and permitted outcomes defined? |
| Model-assisted workflow | Rules around a bounded model task | Does interpretation help within a known sequence? |
| Agentic process | Model selects permitted actions | Does the task require a variable route? |
These are design categories, not a ladder on which the last option is always best. One service may use all three in different places. Keep business authority separate from orchestration choice.
Trace one request through three designs
Imagine a fictional distributor receiving an email asking where an order is. In the rule-based route, the customer enters a reference in a form; the application checks access, retrieves status and displays it. Unmatched references go to support.
In a model-assisted route, a model proposes the reference and category from an email. The application validates the output, checks identity through an appropriate process and follows the lookup sequence. An uncertain match is not permission to expose someone else's order.
In an agentic route, a model may choose permitted order, shipment or support tools before drafting a response. That creates additional paths to evaluate. The tools still need enforced access and action limits rather than relying on the model to remember them.
Decide which uncertainty belongs in the model
Separate interpretation from policy. Recognising that “my delivery has not arrived” concerns a shipment can be a candidate for model assistance. Deciding whether an unauthorised person may receive account information should remain an enforced access decision.
List cases requiring refusal or escalation: conflicting references, an account mismatch or missing evidence. Investigate whether a narrow classifier or retrieval step resolves the problem before selecting an open-ended route. Choose the simplest design that can be evaluated against the task.
Specify tools and approval boundaries
Give each tool clear inputs, permitted record scope and expected results. Separate status lookup from changing an address, issuing a refund or sending a message. These actions have different consequences and may need different controls.
The distributor's first pilot could allow read-only lookup and drafting while a staff member sends replies. Record what that reviewer checks. Plausible tool output does not establish that the correct account was selected or that an action was authorised.
Build an evaluation set before comparing demos
Create controlled ordinary, ambiguous and adversarial cases. Keep expected outcomes and permitted actions with each. Include two order numbers, an unavailable shipment service, a stale record and input that instructs the system to ignore its task.
Measure task completion, record selection, unauthorised action attempts, appropriate escalation, tool calls, elapsed time and cost per completed case. Define pass conditions with the business owner. A polished answer is insufficient if the wrong account was queried or an approval skipped.
Compare cost at the workflow level
Record model usage, tool charges, hosting and review effort. Compare cost per useful completed task rather than only per model call. A cheaper response requiring extensive correction can make the whole process more expensive.
Limit repeated tool calls and total execution. Decide what customers and support see when a limit is reached. Test investigation of a partial attempt without automatically repeating actions that might already have succeeded.
Design recovery and a stop route
Keep an appropriate trace of requests, selected tools, record identifiers, decisions and approvals under the system's data-handling rules. Operators need enough context to distinguish a model error from stale source data or a failed connection.
Define how to suspend model-directed actions while preserving a manual or deterministic route. Prompt, model, tool and data-source changes should trigger relevant reevaluation. Passing a test set is evidence for those cases and configuration, not every future request.
Choose a bounded first implementation
The AI automation overview covers the broader capability discussion. Use the AI integration strategy guide for source-system planning. Identify one task, its limits and the evidence required to move beyond a pilot.
For an AI development brief, bring sample cases, permitted data, existing process costs and an operational owner. Explain why the chosen route fits without promising unmeasured autonomy, savings or accuracy.
