Name the outcome before the technology
A team wants to turn incoming requests into useful answers. Before choosing an agent, it should define useful: a complete response, an identifiable source, missing information flagged and a clear next step. This is a hypothetical example, not a project result. If the task cannot be described and evaluated, calling the system an agent will not make it clearer. It may simply hide the misunderstanding behind a convincing interface.
When the path is known
Anthropic distinguishes predefined workflows from agents that choose their steps and tools dynamically. In our example, classifying the request, searching a designated source and drafting a response could form an easy-to-follow workflow. A person could check the draft before it is sent. The practical question is whether an important situation falls outside that sequence, not whether the workflow looks sufficiently advanced.
When the next step must be discovered
Suppose requests vary considerably, and the information required only becomes clear after an initial check. An agent might choose which source to consult next or which question to return to the user. Its proposed value is adapting the path. To assess that value, the team should observe when dynamic choices produce a better answer than the fixed route and when they merely introduce unnecessary detours.
Make boundaries part of the product
Microsoft recommends the level of complexity that meets requirements, with cost and time taken into account. In an experiment, these become concrete questions: how many checks are acceptable, what may the system consult, and when should it ask for help? Separate preparing an answer from permission to send it. Record why the system stopped and what information was missing. These choices make its behaviour understandable to the person using the product, as well as to the technical team.
Compare alternatives on the same task
A useful evaluation could give a simple model call, a workflow and an agent the same examples. Proposed criteria include a correct and complete answer, invented information, human interventions, cost and time to outcome. Include unclear requests and tasks that cannot be completed with the available data. Without that comparison, more steps may look like progress simply because they are visible. The architecture deserves to grow when an observed improvement justifies the operational and maintenance effort. Repeating the comparison after changes also shows whether a new version retains the advantage the team originally observed.