AI agents: when one helps and when it does not
An AI agent is a system that decides its own next step instead of following a sequence somebody wrote in advance. Given a goal and a set of tools it can use, it looks at the situation, chooses an action, observes what happened, and chooses again, until it decides it is finished. That single property is both the entire benefit and the entire risk. It is the benefit because it lets a system handle situations nobody anticipated, which is exactly what fixed workflows cannot do. It is the risk because you no longer know in advance what the system will do, which makes it harder to test, harder to debug, more expensive to run and capable of surprising you. Agents earn their complexity when the sequence genuinely cannot be known ahead of time. When it can, a plain script wins on every dimension that matters.
The one distinction that matters
Strip away the vocabulary and there is a single question: is the order of steps decided when the system is written, or while it is running.
A workflow is decided when it is written. It reads the file, extracts the fields, validates them, writes to the database. The same every time. You can test it exhaustively, you know what it costs to run, and when it breaks the stack trace tells you where.
An agent is decided while running. Given the goal of processing this document, it might read it, notice a reference to an attachment, go and find the attachment, discover the attachment is a scan, run extraction on it, notice the totals disagree, and flag the discrepancy. No one wrote that sequence. It emerged from the situation.
The second is obviously more capable and it is also four things worse: slower, more expensive per item, harder to test because the space of behaviours is not enumerable, and capable of doing something nobody considered. Whether that trade is worth making depends entirely on whether the first approach was actually possible.
Where an agent earns its keep
When the inputs vary more than you can enumerate. Incoming requests in arbitrary formats, documents whose structure differs by sender, problems that arrive as prose. A workflow needs a branch for each case and the cases do not stop arriving.
When the work requires looking things up before knowing what to do. If the next step depends on what the previous step found, and the possibilities are wide, an agent expresses that naturally where a workflow expresses it as a tangle of conditionals that nobody can maintain.
When the task is genuinely investigative. Finding why two systems disagree, or assembling the evidence for a decision from several places. The path is different every time by nature, which is the case agents were invented for.
Where a script wins
Whenever you can draw the flowchart. This sounds obvious and is routinely ignored, because agents are more interesting to build and because a proof of concept with an agent demonstrates the technology in a way a script does not.
The test is practical: sit down and try to write the steps. If you can write them, and the branches are countable, build that. It will cost less to develop, run in a fraction of the time, cost a fraction per item, and be debuggable by someone who was not involved in building it. Those are not small advantages and they compound over the years the system will run.
The useful middle ground, and the shape most production systems actually take, is a workflow with an agent in one step. The workflow handles the known sequence and calls the agent for the one part that genuinely varies. This gets most of the capability with most of the predictability, and it is much easier to reason about when something goes wrong.
Controlling what an agent can do
The instinct is to control an agent through instructions: tell it what not to do. This is the weakest available control, because it depends on the system interpreting the instruction correctly in a situation you did not anticipate, which is precisely the situation where it is least reliable.
The controls that work are structural. Restrict the credential: an agent running with read-only access cannot delete anything, whatever it concludes. Cap the steps: a hard limit prevents a loop from running for an hour. Require approval for anything irreversible: sending an external message, moving money, changing a record of record. Log every action with the reasoning, so that when something goes wrong the sequence can be reconstructed.
The distinction underneath all four is reversibility. An agent that can only take actions you can undo is an engineering problem when it misbehaves. An agent that can take irreversible actions is an incident, and no amount of prompt engineering changes which of the two you have built.
What to expect in production
Two things surprise organisations consistently. The first is cost: an agent that takes twelve steps costs roughly twelve times a single call, and at volume this is the difference between a viable system and one that is quietly switched off after the first invoice.
The second is variance. The same input can produce different paths on different runs, which means a system that worked in testing can fail in a way testing could not have found. This is not a defect to be engineered away; it is the property you chose when you chose an agent. The practical response is to bound the blast radius rather than to chase determinism: keep actions reversible, keep a human on anything that is not, and measure the outcome continuously rather than assuming a passing test still holds.
