AI agents for business: where they work, and where a workflow wins

An agent built where a workflow would do is a standing source of cost, latency, and surprise.

A workflow is the right pattern when the steps are known in advance: do this, then call that, then format the result. Most business tasks are like this. Classify a ticket and route it. Extract fields from a document and write them to a system. Retrieve some context and draft a reply. These can use a model at one or two steps, but the orchestration is fixed, which means it is testable, debuggable, and cheap.

An agent earns its place only when the task genuinely cannot be expressed as a fixed sequence: when it has to decide which steps to take based on what it finds, use tools in an order that is not known ahead of time, and recover from dead ends over multiple turns. Open-ended research across systems, multi-step troubleshooting, and tasks where the path branches unpredictably are real agent territory. The test is simple: if you can draw the flowchart, build the workflow.

Getting this call right is most of the value we add, and it usually means talking a client out of an agent. An agent introduces non-determinism, higher cost, harder testing, and new failure modes; you take those on only when the task pays for them.

The clearest case is open-ended work over many tools where the next step depends on the last result. An agent investigating a production incident might query logs, then, based on what it sees, pull a related dashboard, then check a recent deploy, then form a hypothesis, a path no fixed workflow could enumerate in advance. A research agent gathering and reconciling information across several systems is similar: the value is in adapting the plan as it learns.

Even then, the strongest designs keep the agent on a short leash: a bounded set of tools, a limited number of steps, and a human in the loop wherever an action is consequential or hard to reverse. The most reliable production agents are narrow and supervised, not open-world and autonomous. Breadth of capability is usually a liability, not a feature.

And the question is rarely all-or-nothing. Many good systems are mostly workflow with a small agentic core: a deterministic pipeline that hands off to a constrained agent only for the one genuinely open-ended step, then takes back control. That keeps most of the system testable while reserving autonomy for where it is actually needed.

An agent that can take actions needs guardrails on which actions it can take, and on which ones require a human to approve. The blast radius of a mistake is defined by the tools you give it; a read-only agent is a very different risk from one that can send emails, move money, or change records. Scope the tools to the minimum the task needs.

It also needs an eval harness: a graded set of scenarios that tells you, on every change, whether the agent is getting better or worse, because agent behavior is emergent and a prompt tweak can quietly break a path that used to work. And it needs hard cost and step ceilings, so a reasoning loop that goes wrong is capped by design rather than discovered on an invoice. An agent without a budget limit is a financial liability waiting for a bad day.

These are not optional extras for production. The gap between an impressive agent demo and an agent you can actually depend on is almost entirely guardrails, evals, monitoring, and the discipline to keep the thing narrow.

A year in, either you are running a narrow, supervised agent that reliably does work no workflow could, or you saved the money and shipped the workflow that was the right answer all along.

The mark of a mature AI program is not how many agents it runs; it is that every agent in production is there for a reason that survives scrutiny, and every task that did not need one is a clean, cheap, testable workflow. The hype rewards the opposite, agents everywhere, which is how teams end up with systems they cannot test, cannot predict, and cannot afford.

The agents that last are narrow and supervised, with guardrails and evals that were there from the start. The ones that get quietly switched off were broad, autonomous, and impressive in the demo. The difference is engineering discipline, not model capability.

Whichever side the task lands on, you should own the result: the code in your repositories, the evals, and a team that understands why it is an agent or a workflow. That understanding is what lets you build the next one well.