When not to build an AI agent
Build an agent only when the sequence of steps genuinely cannot be known before the task starts. If the steps are knowable, write a workflow - it is cheaper, faster, debuggable, and correct every time. Most workloads sold as agentic are fixed pipelines with a classification step in the middle.
The test
Before the task begins, can you write down the steps it will take?
If yes, it is a workflow. Write it as ordinary code with a model called at the steps that need judgement. If no - if step four genuinely depends on what step three discovered, and the branching is not enumerable - you have an agent-shaped problem.
Most workloads described as agentic fail this test. 'Read the email, classify it, extract the fields, look up the customer, draft a reply' is a pipeline with two model calls in it. Wrapping it in an agent framework adds non-determinism, latency, and cost while removing your ability to reason about what it will do.
What an agent actually costs
Every autonomous decision point multiplies the state space you have to test. A five-step fixed pipeline has five things that can go wrong in known ways. A five-step agent loop has an unbounded number of paths, and the failure you see in production is frequently one you cannot reproduce.
There is a cost in money too - agent loops re-read context on every turn, so token spend grows quadratically with trajectory length. And there is a cost in trust: an operator who cannot predict what the system will do stops relying on it, which is how automation projects quietly die.
Where agents genuinely earn their place
Research and investigation, where the next query depends on what the last one returned. Triage across systems, where the path through is genuinely data-dependent. Reconciliation, where the discrepancy determines what to check next.
The common thread is that the branching factor is real and unknowable in advance. That is a narrow category, and it is worth being honest about how narrow.
If you do build one, build it as software
The orchestration layer should be ordinary durable execution: a state machine on a queue with retries, idempotency keys, and full replay. If a run fails at step seven, it resumes at step seven with the same inputs.
The supervisor pattern - one coordinating model delegating to narrow, single-purpose tools - is more debuggable than a swarm of peer agents negotiating, and in our engagements it performs at least as well.
- Hard step limits and a wall-clock budget on every run
- Typed tool contracts validated by the runtime, not trusted from the model
- Full trajectory logging: every call, argument, and result, replayable
- A human escalation path that is a first-class feature, not an exception handler
The honest version of the pitch
'We will build you an agent' sells better than 'we will build you a state machine that calls a model twice'. The second one is usually the correct answer, ships faster, and still gets the outcome the client asked for.
We say the second one. It occasionally costs us the project, and it has never cost us a client.
Questions this raises
Is a multi-agent system better than a single model with tools?
Rarely, in our experience. Multiple agents add coordination overhead and failure modes; a single model with well-designed tools and a state machine around it covers most workloads with far less operational surface. Reach for multiple agents when the sub-tasks genuinely need different context windows or different privileges.
How do you stop an agent from looping forever?
Hard step limits, a wall-clock budget, and a repetition detector that halts when the same tool is called with the same arguments twice. All three, because each one catches a different failure.
What framework do you use for agents?
For orchestration we use durable execution - Temporal or an equivalent state machine on queues - rather than an agent framework, because retries, idempotency, and replay are the hard parts and those frameworks are built for them.
Related
Retrieval recall is the RAG metric that actually decides quality
Most RAG systems fail at retrieval, not generation. How to measure recall@k on your own corpus, what a passing number looks like, and why prompt engineering cannot fix a retrieval problem.
Idempotency is the whole job
Automation that cannot safely run twice is a liability. Idempotency keys, durable execution, and decline-code-aware retries - the patterns that keep automated money movement correct.
Production AI Systems
We design and ship production AI systems: retrieval-augmented generation on pgvector, deterministic multi-agent supervisors, evaluation harnesses, and guardrails. Built in Kolkata, deployed for teams across India, the US, the UK and the UAE.
Intelligent Workflow Automation
We replace repetitive operational toil with idempotent, event-driven automation: durable workflows, system integrations, exception dashboards, and alerting your operators can trust. Software engineering studio based in Kolkata, working with teams worldwide.
Published 22 August 2026 · Last reviewed 22 August 2026 · Written by Manish Meena in Kolkata, India.