Industry perspective · Agent orchestration
Automation or AI Agent? Start with the Decision, Not the Tool
A practical way to decide whether a business task needs a fixed workflow, an AI drafting step, or an agent with room to choose its next action.
A new inquiry arrives, somebody reads it, and a follow-up task gets created. It is tempting to call the whole process an AI agent. But the useful question is smaller: which decision actually needs judgment? Answering that question can save you from building a complicated system around work that already follows a clear rule.
Write the ordinary path first
Describe the job using one recent example. A form collects the customer's service area, requested work, and preferred contact method. The system checks whether the area is supported, assigns an owner, and creates a task. None of those steps necessarily needs a language model. A rule can compare a postcode with a list.
Now identify the uncertain part. Perhaps the customer describes an unusual repair in a paragraph, and someone must decide which team should read it. That is a candidate for an AI classification step, with an explicit option for uncertainty. It does not automatically make the remaining workflow autonomous.
Choose how much freedom the task needs
Anthropic distinguishes predefined workflows from agents that choose their own process and tools. Use that distinction as a design question: do you already know the next steps, or must the system discover them as it works?
In a hypothetical service business, routing a standard inquiry might use rules plus one classification call. Investigating an unfamiliar technical issue could need several searches, with each result influencing the next step. The second task may justify an agent. The first probably needs a reliable workflow and a readable exception queue.
Put the uncertain decision on a short leash
For the inquiry example, define the allowed categories and the fallback. A useful result might include the recommended team, the supporting phrase from the inquiry, and whether human review is needed. A confident-sounding explanation is not evidence that the choice is correct.
Keep consequential actions separate. Suggesting a destination is different from promising a service, quoting a price, or changing a customer's account. Start with a recommendation people can check. Expand the action scope only when the relevant decisions have been tested against realistic cases.
Compare complete outcomes
Run the simple approach and the more flexible approach on the same sample. Compare correct routing, unresolved cases, review time, and the effort required to understand a failure. Include requests with missing information and messages that belong outside your service.
A more elaborate design earns its place when it handles a meaningful problem better after review and recovery costs are included. If both approaches reach the same result, the one your team can explain and maintain is usually the stronger starting point.
Try this on one workflow
Draw three boxes: known rules, judgment needed, and action taken. Put each step in one box, then ask whether the judgment box really needs freedom to choose new steps. Build the smallest version that answers that question. You can add autonomy later; first make the decision and its boundaries visible.