Many enterprise technology teams are currently being pitched agentic solutions — autonomous, tireless, about to transform everything. The pitches share a property: they describe what agents might become, not what makes them work. Meanwhile the practical question sits unanswered: for this process, in this organisation, is an agent the right tool?
What an agent actually is
Having built and operated agentic workflows in our own daily delivery, our position is specific: agents earn their place on bounded tasks with defined tools, permissions, observability and approval points — and a deterministic script is the better answer more often than the market admits.
Underneath the pitch, an agent is a loop: a model that reads context, chooses among the tools it has been given, acts, observes the result, and continues until a stopping condition. That definition contains everything that matters. The agent is exactly as capable as its tools, as safe as its permissions, as trustworthy as its stopping conditions, and as debuggable as its traces.
It is not a digital employee. An employee can be asked what happened; an agent without execution traces cannot. An employee learns the organisation's boundaries; an agent has precisely the boundaries someone configured, and no others. Calling it an employee invites the organisation to skip the engineering that makes it safe.
The fit test
Four questions predict whether a process suits agentic execution:
- Is the task bounded? A defined job with a recognisable end state — triage this ticket, prepare this draft, reconcile these records. Open-ended mandates ("improve our documentation") produce open-ended behaviour.
- Is the tool surface explicit? The actions the agent needs should be enumerable: read these systems, write to this one, call these APIs. If the honest tool list is "whatever it turns out to need", the process is not understood well enough to automate — by any method.
- Are the actions reversible — or gated? Drafts, suggestions and staging changes are cheap to undo. Payments, deletions, customer-facing sends are not; they need a human approval step designed into the workflow, not appended to it.
- Is verification cheaper than execution? Agents are valuable when checking the output takes minutes and producing it took hours. When verification costs as much as doing the work — nuanced judgement calls, high-stakes correctness — the agent saves nothing and adds a failure mode.
A process that passes all four is a candidate. If several criteria fail, a deterministic workflow or manual process is usually the safer starting point.
Where they help
The patterns that pass the test in practice are consistent: triage and routing — reading incoming tickets, classifying, enriching with context from internal systems, routing with a recommendation; drafting for review — documents, responses, analyses prepared for a human who approves; multi-system lookups — answering questions whose evidence lives across repositories, wikis and trackers; and engineering workflows — review support, test scaffolding, documentation upkeep, where the output is verified by CI and reviewers as a matter of course.
The shared shape: the agent does the traversal and assembly work that consumes human hours, and a human — or an automated check — owns the consequential decision.
Where they do not
The same test rules out the showcase use-cases: irreversible actions without gates — anything touching money, production data or customers where an approval step "slows the demo"; thin verification — outputs nobody can efficiently check, which convert automation into deferred risk; compliance-critical paths — where "the model chose differently today" is an audit finding, determinism is the requirement, not a limitation; and processes nobody can specify — an agent is not a substitute for understanding the workflow. Automating a process you cannot describe produces automated behaviour you cannot predict.
The deterministic alternative
For a surprising share of pitched use-cases, the honest architecture review ends with: this is a workflow engine and two integrations. If the steps are known, the branches are enumerable and the inputs are structured, a deterministic pipeline is cheaper to build, generally more predictable to operate, and behaves identically every time — which auditors, operators and downstream systems all prefer.
The practical pattern is hybrid: deterministic pipeline for the known path, an agent for the step that genuinely requires reading and judgement — classification of messy input, assembling context from unstructured sources — and approval gates where the two meet. Use the model where the input is messy; use the pipeline where the process is known.
Governance is the architecture
In enterprise use, the governance concerns are not compliance overhead added to the agent — they are the agent architecture: its own identity with least-privilege access, never a borrowed personal credential; an explicit, revocable tool contract; traces of every step — what was read, what was invoked, what came back; approval points placed where actions become consequential; and an owner who reviews what the agent actually does and answers for it.
An agent with these properties is infrastructure. Without them it is an unaudited process with production access — which is not a new risk category, just an old one wearing a new name.
Failure and recovery
Multi-step workflows fail mid-flight: a tool times out on step seven of twelve, a model returns something unusable, an external system changes shape. Production agentic systems treat this as normal operations — checkpoint state so workflows resume rather than restart, make steps idempotent so a retry is safe, define escalation so a stuck workflow lands with a human, and watch failure patterns, because a rising retry rate is an early warning that something upstream changed.
The demo never shows step-seven failures. Production is made of them.
Agent fit test
- Is the task bounded, with a recognisable end state?
- Is the tool surface explicit and enumerable?
- Are the actions reversible — or gated with human approval?
- Is verification cheaper than execution?