Most writing about AI agent workflow automation stops at what agents can do. Building one into a production system is a different problem, and almost none of it is about prompting. It is about tools, state, idempotency and how you test something that does not give the same answer twice.
The tools are the product, not the model
An agent is only as good as what it is allowed to call. In practice most of the engineering effort goes into the tool layer, and that is where quality is won or lost.
Tools need to be narrow. A single updateRecord tool that accepts any field is an invitation to unpredictable writes. Several specific tools — assignOwner, setDueDate, closeTicket — are easier for the model to select correctly and far easier for you to reason about when something goes wrong.
They also need to fail informatively. When a tool returns error, the agent has nothing to work with and will usually retry the same call. Returning this ticket is already closed, no action needed lets it recover on its own.
Every tool must be idempotent
Agents retry. They retry on timeout, on ambiguous responses, and sometimes because the model decided the first attempt was unclear. If calling a tool twice does the thing twice, you will eventually send two emails, raise two tickets or charge twice.
The standard fix applies: accept a caller-supplied idempotency key, store it with the result, and return the stored result on a repeat. This is ordinary distributed-systems hygiene, and it matters more here because the caller is non-deterministic.
State has to survive a restart
A conversation held in memory disappears when the process recycles. For a chat that is annoying; for a multi-step workflow holding a half-finished task, it is a data problem.
Persist the run: which step it is on, what each tool returned, and what remains. The useful test is whether you can kill the process mid-run and have it resume correctly. If you cannot, the system works only while nothing goes wrong, which is not a property you can rely on in production.
Bound the loop
Agents get stuck. They call a tool, dislike the result, call it again with a small variation, and continue until something stops them. Without limits this is a billing incident.
Hard caps worth setting from day one:
- Maximum steps per run.
- Maximum calls to any single tool.
- A wall-clock timeout on the whole run.
- A token budget, enforced rather than monitored.
When a cap is hit, escalate to a human with the trace attached. Do not fail silently, and do not retry the run from the start.
Testing something non-deterministic
You cannot assert on exact output, so assert on everything else.
The tool layer is deterministic and should be unit tested normally. What the agent does with it needs a different approach: a held-out set of real cases with known correct outcomes, run repeatedly, scored on whether the right tools were called with the right arguments rather than on the wording of the response.
Run it several times per case. A system that is right once and wrong twice on identical input has a variance problem you need to know about before your users find it.
Log the trace, not the answer
When an agent does something wrong, the output tells you almost nothing about why. What you need is the sequence: which tools were called, in what order, with what arguments, and what came back.
Store that trace against every run and keep it long enough to investigate a complaint that arrives a fortnight later. This is also what makes the system auditable, which matters for any regulated context.
Where the human belongs
Put the approval immediately before the irreversible action, not at the end of the run. By the end, the reviewer has to reconstruct a sequence of decisions; immediately before, they only have to check one thing.
Most of the time saved is in the gathering and drafting anyway, so keeping the final click costs very little and removes the failure mode that actually hurts — a plausible, confident, wrong action that nothing downstream catches.
Our Call Center Agent is built on this pattern. See our AI workflow automation service, or read what AI agent workflow automation actually is for the conceptual version.
Common questions
What makes building an AI agent different from normal development?
The caller is non-deterministic. That makes tool design, idempotency and persisted state far more important than prompting, and it means you cannot assert on exact output when testing.
Why must agent tools be idempotent?
Because agents retry — on timeout, on ambiguous responses, sometimes because the model judged the first attempt unclear. Without idempotency keys you will eventually send two emails, raise two tickets or charge twice.
How do you test a non-deterministic system?
Unit test the deterministic tool layer normally, then score the agent against a held-out set of real cases on whether the right tools were called with the right arguments. Run each case several times to detect variance.
