What is an AI agent, and how does it differ from a workflow?
An AI agent can choose tools and subsequent steps based on information discovered while pursuing a goal. A fixed workflow is a process whose steps and permitted branches are defined in code. Including a language model does not automatically make a workflow autonomous. A system can classify a request, read an order, draft a response and send it for review while code controls every transition. An agent has discretion to decide which record to investigate first or which question to ask after seeing a result.
Anthropic's agent architecture guidance distinguishes predefined workflows from agents that dynamically direct tool use. The practical design question is how much control the model needs over the process. Natural-language output and API calls do not settle that question. A fixed workflow can contain probabilistic model outputs: what remains fixed is the boundary of permitted steps, rather than every answer being identical. Make that boundary visible through records, failure handling and approval rules. Where autonomy introduces new choices, measure whether those choices improve the authorised outcome enough to justify their cost.
Agent or workflow: an autonomy decision tree
Answer the questions below in order. Choosing a fixed path at the first row does not prevent you from adding an agent later; it provides a working baseline for comparison. If you cannot economically enumerate the steps, continue to the second question. Define success and safe stopping conditions before expanding autonomy. Risk and budget also do not select an architecture by themselves: they identify where an agent needs constraints. A consequential task may still benefit from flexible research, while execution remains under fixed controls.
| Decision question | If yes | If no |
|---|---|---|
| Can manageable rules select the steps? | Build a fixed workflow | Continue to the next question |
| Are success and stopping conditions clear? | Assess the evidence requirements | Define criteria and human handoff first |
| Does intermediate evidence determine the next step? | A bounded agent step is a candidate | Simplify the workflow |
| Are external effects constrained by fixed gates? | Pilot reading and proposals | Build permissions and approval first |
| Does extra success justify cost and latency? | Use an agent within the evaluated scope | Improve the fixed baseline |
In this decision tree, an agent step does not mean giving the entire system unrestricted control. You can place bounded investigation inside fixed intake and return to a fixed approval stage. Tie the decision to examples where the baseline fails. Calling a task complex does not explain which particular freedom the model needs or where it should end.
Build the fixed baseline first
Describe the trigger, required information and expected final state. For a support request, these might be the incoming message, order record and an evidence-backed reply draft. Separate authentication, record selection, retrieval, drafting, approval and execution. Define known branches in code: order-status queries go to the order system, invoice queries to the invoice system. If classification is uncertain, ask for clarification or hand over to a person. That uncertainty alone does not establish a need for an agent to invent a new route.
The LangGraph workflow and agent documentation provides examples of routing, sequential steps and dynamic tool use. Choosing a framework does not define process ownership or security boundaries. Specify each step's inputs, outputs and failure behaviour yourself. Validate model output before passing it to the next system. A missing order identifier and an identifier belonging to a different customer require different responses: clarification for the first and access denial for the second. Returning the same generic error for both obscures what the process should do.
Run realistic cases through the baseline and classify its failures. Do not combine missing data, inadequate sources and integration faults under a label saying an agent is needed. An agent may be unable to retrieve the same missing record. If the fixed path fails because a tool description is unclear, improve that description. Flexible model selection becomes a separate candidate where deterministic routing repeatedly blocks a useful information path. Preserve those examples so the proposed agent can be evaluated against the actual problem rather than a more impressive demonstration.
How to bound the agent's discretion
Give the agent a clear objective, accessible sources and permitted tools. Separate reading, proposing and executing. Evidence gathering can be flexible while record changes, outbound messages and payments pass through fixed server controls. Where approval is required, bind it to the exact target and immutable parameters. Neither a user message nor a tool result should let the model expand its own authority. Reversibility helps define recovery; it does not remove the need to verify that the action is permitted and appropriate.
Set task-level time, call-count and cost limits. Repeated calls with identical arguments and no progress, an ambiguous target or contradictory sources should trigger stopping rules. A handoff should carry found records, missing information, attempted routes and a proposed next step, rather than merely saying that the agent failed. Inspect tool calls, arguments, status results and timestamps rather than guessing the model's internal reasoning. After a downstream write times out, determine whether it completed before attempting another operation.
Version the autonomy scope. Adding a tool, raising a budget or changing a stop condition changes behaviour and requires evaluation. If several safe routes can complete the same task, do not reward only one prescribed call sequence. The goal is more reliable completion of the authorised task, rather than more steps. Multiple agents are a separate design decision: uncertainty about the next step does not automatically justify building a team of agents. Each additional role needs a reason, a contract and a way to assess the combined result.
Hypothetical example: a hybrid design for 200 support requests
Suppose a hypothetical test set contains 200 support requests: 160 routine order, invoice or account questions and 40 cases requiring comparison across records. A message such as “The shipment arrived damaged, the invoice has the old address, and my colleague already opened a ticket” requires evidence from the order, shipment and ticket systems. Imagine the fixed path completes 152 routine requests and 18 complex requests correctly. That is 170 out of 200, or 85% overall, with the failures retained for diagnosis.
Keep the same fixed intake but invoke bounded agent investigation only for the 40 complex cases. Suppose routine success remains 152 and complex success rises to 30: 182 correct cases, or 91%. The difference is twelve extra requests and six percentage points. These are hypothetical results. If average processing cost is €0.04 for a routine request and €0.16 for the agent route, the hybrid test costs €12.80. Routing all 200 requests through the same assumed agent cost would cost €32. The fixed workflow alone would cost €8 for all 200; the hybrid spends €4.80 more to get 12 more requests right, about €0.40 per additional correct request. This arithmetic compares two routing choices under constant unit-cost assumptions; it is not a measured price or performance benchmark.
Completion rate must not be the only acceptance criterion. The agent must refrain from executing refunds itself, select the correct customer and hand over when records remain ambiguous. Measure employee review time and corrections as well. If those criteria pass, enable the agent only for the complex scope tested. Moving routine cases onto the agent route requires another comparison, because a benefit on complex investigation does not establish a benefit for simple queries.
A comparative test plan
- Use identical cases. Run routine, ambiguous and multi-record requests through the fixed path and agent candidate. Keep data, permissions and expected final states equivalent so the comparison measures architecture rather than different inputs.
- Separate outcome from trace. Assess the correct draft, target and human handoff. Anthropic's agent evaluation guidance distinguishes the execution transcript from the final state produced in the environment.
- Count consequential failures separately. Unapproved execution, another customer's record, duplicated writes and missed handoffs must not disappear into an overall completion percentage. Examine the failure class before deciding to expand the pilot.
- Measure time and budget. Record the median and slower cases, tool calls, token usage and human review workload. Verify that the system actually stops when a limit is exhausted instead of simply recording the overrun afterwards.
- Check variability. Repeat difficult cases across several trials. Re-run a held-out set when models or tools change, and avoid treating one successful attempt as evidence of consistent success.
Common mistakes
- Calling every automation using a language model or API an agent and obscuring its control boundaries.
- Assuming extra autonomy is useful without measuring a working fixed baseline.
- Trying to solve unavailable sources or broken integrations by adding an agent.
- Overlooking unauthorised actions and human review workload when completion rates improve.
- Leaving unsuccessful loops open without time, call-count and stopping limits.
How Hatson Tech builds this
We start with real tasks and the existing fixed process. Through AI agent development, we identify uncertain decisions, tool permissions and acceptance criteria, then compare the agent candidate on the same cases. For the core concept, see our AI agents guide; for dividing work, see multi-agent systems. The pilot produces an implementation plan showing where the model chooses, where it stops and which external effects remain behind approval. That makes the architecture reviewable before broader deployment.