AI workflow or agent: choose the right design for the task

Describe the path from request to result

Write one ordinary example from start to finish. Identify the input, the information needed, the output and the point where a person must review it. Then list several exceptions rather than treating the happy path as the whole job.

For an illustrative service inquiry, the steps may be: identify the request type, retrieve the relevant policy, draft a response and route it for review. If those steps stay consistent, a fixed workflow may offer a clear starting point.

Decide where the next step is predictable

Anthropic’s architectural guidance distinguishes predefined workflows from agents that dynamically choose their process and tools. That distinction helps a business team ask where flexibility is useful rather than assuming more autonomy makes every implementation better.

If the same steps solve most requests, implement and evaluate that path first. If the next action depends on information discovered during the task, a bounded agent may be worth testing. Treat this as an architectural decision, not a claim about any provider’s current feature set.

Reference: Anthropic: Building effective agents, architectural guidance

Separate reasoning from authority

A system may be allowed to gather information and recommend a change while lacking permission to apply it. Define each tool’s scope around the action it performs. Reading a record and updating that record should not inherit identical permissions by convenience.

For the service example, drafting a response can be evaluated separately from sending it. A later phase might allow sending certain approved categories. Keep the decision explicit, with a clear record of what was authorized and what actually happened.

Design the failure path alongside the happy path

A missing record, unavailable service or ambiguous request should lead to a known outcome. Define when to retry, ask for clarification or route to a person. Do not let a failed lookup become a confident answer built from an assumption.

Check that retries cannot duplicate an action such as creating a record or submitting a request. Use the source system’s supported mechanisms where available and verify outcomes before marking the task complete. A partial result needs an honest status.

Compare the options on the same work

Choose representative tasks and judge whether each design completes them correctly. Record completion, required human corrections, elapsed time and operating cost using observed data. Include difficult and failed cases rather than evaluating only polished demonstrations.

A flexible design may solve a wider range of tasks while adding review overhead. A fixed path may be easier to inspect but need explicit handling for exceptions. The relevant tradeoff depends on the work and the organization’s tolerance for unresolved cases.

Expand only the part that earns its complexity

Begin with a small operational boundary and a named owner. When a recurring exception emerges, decide whether a rule, a better input or an agent decision is the appropriate repair. Not every new requirement needs a larger system.

Keep the evaluation set as the workflow changes. That makes it possible to see whether an improvement helps the new cases while preserving existing behavior. The pilot should produce evidence for the next decision, rather than only a demonstration that a tool can be called.

Common questions