In this article
One support request, two kinds of work
Consider an illustrative message: “My parcel arrived damaged; can you help?” The application can deterministically authenticate the customer, fetch eligible orders and enforce the return policy. Interpreting an unclear description or finding the relevant passage in several documents may benefit from a model. Issuing a refund is a separate action with its own authority and business rules.
A good design can combine these approaches. Use code for the stable sequence and a model for a bounded interpretation step. Introduce an agent only if the next useful action genuinely depends on what was learned: request a photograph, inspect tracking or consult a product-specific policy. If every request follows the same three calls, a fixed workflow is usually easier to explain and test.
Match autonomy to the work
The useful distinction is who chooses the next step.
Deterministic workflow
Known states and explicit rules. The application defines the sequence.
Model-assisted step
Interpret variable input inside a controlled sequence.
Agent
Choose tools and plan steps within an authorised scope.
Classify the work before choosing an agent
Deterministic workflows suit known states, stable rules and effects that must be repeatable. Models help with ambiguous language, classification, extraction or option generation where rules become brittle.
An agent adds planning and tool choice. That is useful only when the task cannot be bounded as a simpler sequence and when the additional failure surface can be observed and controlled.
Build an autonomy ladder
Start with model assistance that proposes while a person decides. Then allow constrained actions with allow-listed tools, validated arguments, budgets and approval for high-consequence steps. Full autonomous execution should be the last promotion, not the prototype default.
Each level needs promotion criteria based on evaluation quality, exception rate, reversibility and operating capacity. A polished conversation is not evidence that a workflow can own business consequences.
An autonomy ladder
Move to the next level only when evaluation and recovery support it.
Suggest
The assistant prepares. A person decides.
Act within limits
Allowed tools, validated inputs and approval when needed.
Delegate a bounded task
Observe execution and retain an explicit stopping path.
Control tools, state and fallback
Treat model output and tool arguments as untrusted input. Enforce authorization outside the model, isolate tenant context, cap loops and spend, and record decisions without logging unnecessary personal content.
Define what happens when the model, tool or provider is unavailable. A safe fallback may queue work for a person, switch to a deterministic rule or stop before an irreversible effect.
Make the stopping conditions part of the design
Give the process an explicit state: received, gathering evidence, awaiting clarification, ready for review, completed or handed over. Set limits on tool calls, elapsed time and repeated attempts. When evidence conflicts or a tool keeps failing, the next step should be a defined handover rather than another improvised call.
The model’s self-reported confidence is not an access check or a release criterion. Verify required fields, policy evidence and operation permissions in the application. When approval is required, bind it to the exact proposed action and re-check the current record before execution. Otherwise a reviewer may approve one amount while a later model step executes a different one. The diagram below describes this application-level control path, not a promise that a prompt enforces it.
From a request to a controlled action
Proposed support workflow. Business checks run in application code; an agent cannot approve its own action.
Request → identity → evidence → proposed action
Evidence complete and action permitted?
Yes
- Obtain approval if required
- Revalidate → execute once → record outcome
No / limit reached
- Do not execute the proposed action
- Clarify or hand over with the collected evidence
Evaluate completed work, not an impressive conversation
Compare a fixed workflow and an agent on the same cases. Record whether the task was completed correctly, how often a person intervened, which tools were used and whether any unauthorised action was attempted. Separate a justified handover from a failure: asking for a missing order number may be the correct result.
Inspect traces for unnecessary loops and tools called without useful new information. A more capable model may improve interpretation without changing the best process structure. Keep the simplest design that satisfies the workload, and expand autonomy only for cases whose success and failure are understood. An assistant that reliably prepares a reviewable decision can be more valuable than one that tries to finish everything without supervision.
FAQ / DECISIONS
Frequently asked questions
Is an agent more capable than a workflow?+
It is more flexible, not automatically more reliable or valuable. Capability matters only when the use case needs it and the organisation can govern the added uncertainty.