A product requirement says “use an agent to process incoming requests.” That sounds specific until you ask what processing means. Some requests need a fixed extraction pipeline. Others require investigation, additional questions, and a changing sequence of tools.
The useful design decision is where the next step should come from. If the application already knows the procedure, ordinary orchestration can own it. If new evidence determines what to investigate next, a bounded agent may earn its complexity.
Anthropic distinguishes workflows organized through predefined paths from agents that dynamically direct their process and tool use. Treat that as an architectural distinction, not a ranking of sophistication. Building effective agents
Write the task without naming the technology
Describe the input, required outcome, available evidence, allowed effects, and stopping conditions. “Given an incoming support request, identify the product and suggest an answer supported by current documentation” is much easier to evaluate than “build a support agent.”
Then identify uncertainty at each step. Is the challenge interpreting language, discovering missing information, choosing tools, or carrying out a known operation? These are different needs. A single model call can interpret messy text inside an otherwise fixed process.
A document intake service, for example, might extract a reference number, validate it against a database, and route exceptions to staff. The model’s extraction is uncertain, but the sequence does not need to be chosen dynamically.
Sketch the fixed path first
Draw the shortest procedure that could produce an acceptable result. For the support example: classify the issue, retrieve permitted documentation, draft a cited response, and hand it to an editor. Assign a failure route to each stage.
A failed lookup should not automatically launch an open-ended search. It may mean the product name is missing, the account is unauthorized, or the documentation does not cover the issue. Each condition suggests a different next action.
Use this sketch as a baseline. Its value is practical: a fixed path has known stages, clearer budgets, and fewer places where a model must choose control flow. It also exposes whether you actually understand the service you are trying to automate.
Identify where the fixed path loses useful work
Now examine real task examples. Suppose support requests contain logs from several systems. The next useful question depends on what a log reveals. One request needs a version check; another needs a configuration comparison; a third is solved by identifying an invalid credential.
A dynamic investigation can fit that uncertainty. Give it a bounded objective, a small read-only toolset, a budget, and an explicit handoff condition. Let the agent choose investigative steps while application code owns authorization and final response handling.
Do not generalize from one impressive demonstration. Collect examples where a fixed pipeline succeeds, where it fails, and where a human would refuse to proceed. The last group is particularly important: additional autonomy should not turn missing evidence into confident action.
Use a decision table
| Task characteristic | Prefer | Reason to reconsider |
|---|---|---|
| Same stages for nearly every request | Fixed workflow | Many useful tasks require different investigations |
| One ambiguous classification | Model inside a workflow | Classification requires acquiring new evidence |
| Tool sequence depends on discoveries | Bounded agent | Tools or stopping rules cannot be constrained |
| High-consequence external write | Reviewed execution stage | A standing rule has been explicitly defined |
| Unclear objective or unavailable evidence | Clarification or handoff | More model calls will not create missing authority |
The table is an implementation heuristic, not an empirical benchmark. A good design can combine several rows. The investigation can be agentic while the approval and dispatch stages remain fixed.
Separate deciding from doing
Suppose the support investigator recommends changing a customer’s configuration. That recommendation should become a proposal, not an immediate mutation through the same broad tool.
The application can validate the configuration change, show a diff, check authority, and request review when appropriate. A dedicated executor then applies the accepted version. This keeps exploration flexible without making its every conclusion executable.
Use tool contracts to distinguish reads, previews, and writes. Use approval at commitment when a human must authorize the consequence. These boundaries matter more than whether the outer loop is called an agent.
Make stopping part of the design
Give a bounded agent several terminal outcomes: completed with evidence, clarification needed, permission denied, budget exhausted, and unresolved. Each should preserve enough information for the next actor to continue.
Define repeated-action detection. If an agent fetches the same unchanged document three times, another identical fetch is unlikely to help. That threshold is a product choice; the important property is that repetition becomes observable and constrained.
A handoff should include attempted steps, evidence references, unresolved questions, and any pending side effects. Avoid handing a person only a polished final paragraph that conceals the failed investigation behind it.
Compare implementations on the same work
Evaluate a fixed workflow and a bounded agent against the same representative task set. Judge supported answer quality, completion, operator intervention, elapsed time, and total resource use. Count unsuccessful work as well as successful work.
Inspect disagreements rather than reducing everything to one score. The agent may solve more complex cases but waste time on simple ones. Routing simple requests through the fixed path can preserve that benefit without paying the exploration cost for every task.
Keep the routing decision inspectable. If it is model-based, validate its output and record why the task went to the more expensive path. See observability and budgets for measuring the complete run.
Evolve from evidence
A practical first release can use a workflow for common requests, an agent for one clearly bounded investigative step, and a human for unresolved cases. Expand the agent’s role only when observed failures show that extra autonomy addresses a real limitation.
The aim is not to eliminate uncertainty from language tasks. It is to put uncertainty where it helps and keep the rest of the application understandable. When the procedure is known, encode it. When investigation is necessary, constrain it. When the evidence is insufficient, make that visible.