You probably don't need an agent

The most useful question in applied AI right now is unfashionable: does this workflow actually need the model to make decisions about its own control flow, or do we just want it to?

An agent, stripped of the mystique, is a loop in which a model examines a situation, chooses an action from a set of tools, observes the result, and repeats until it declares itself done. The control flow lives inside the model. That is the entire, precise difference from a pipeline, where the control flow lives in your code and the model is called at fixed points to do bounded work: extract, classify, draft, summarize.

That difference has a price. When the model owns control flow, you inherit non-determinism in the execution path itself. The same input can take different routes on different days. Testing stops being "assert output equals expected" and becomes trajectory evaluation. Debugging becomes archaeology through reasoning traces. Costs become unpredictable because path length is unpredictable. Latency likewise. Error compounding is the quiet killer: a step that is 95% reliable is a fine component in a supervised pipeline and a coin flip after fourteen chained decisions.

Sometimes that price is worth paying. The honest criterion: the space of possible situations is too large or too irregular to enumerate in code. Open-ended research across sources you cannot predict. Debugging, where each observation legitimately reshapes the next step. Long-tail customer operations where writing rules for every case would take longer than the heat death of the roadmap. In these, the model's judgment about what to do next is the product, and there is no pipeline to write because you cannot list the branches.

But look honestly at the workflows most businesses want to automate: process the invoice, triage the ticket, generate the report, sync the systems, draft the follow-up. These have known shapes. The steps are enumerable. The branches are countable. Which means you can write them as pipelines, with the model doing what models are superb at inside each step, and your code doing what code has always been superb at: running the same way twice.

The pipeline version is cheaper to run, dramatically easier to test, debuggable with ordinary logs, and explainable to an auditor. Its failure modes are local to a step instead of emergent from a trajectory. And, the part that surprises people: it usually produces better results on structured work, because constraint is a quality tool. The model asked to do one bounded thing with the right context beats the model asked to freestyle through ten decisions.

So the decision rule we actually use: write down the workflow as steps and branches. If you can, build the pipeline; add an agent later only where a specific step genuinely resists enumeration. If you truly cannot write it down, you may have an agent problem, in which case budget for evals, tracing, spending caps, and human checkpoints from day one, because you are now operating a system with real autonomy.

The market is currently selling agents the way it once sold microservices and blockchains: as identity rather than as tools with fit. Same advice as ever. Buy the boring thing that solves your problem. Save the exciting thing for the problems that are genuinely shaped for it.