Before You Build an Agent, Try a Cron Job
I lead development of an agentic AI platform. That is exactly why I spend so much of my time talking people out of building one.
A version of this meeting happens every few weeks. Someone walks me through a workflow they want to automate. It is usually a good workflow to automate — genuinely repetitive, genuinely expensive in human hours. Then they say the sentence: "so we were thinking an agent."
I have learned to ask one question in response, and it is not a technical one: what varies between one run and the next?
Sometimes the answer is rich and immediate — the number of steps depends on what the first lookup returns, the tools needed differ per case, there is no way to know in advance when the task is finished. Those are agent problems and I am happy to build them.
More often there is a pause, and then: "well, the content is different each time." The content. Not the steps. The same six operations run in the same order, every time, and the only thing that changes is the text flowing through them. That is not an agent. That is a pipeline with a language model in the middle of it, and the difference in what it costs to build, run and operate is not small.
The ladder nobody draws
"Should we use an agent" gets treated as a yes or no question when it is really a question about where you sit on a ladder. There are four rungs, and each one buys you flexibility in exchange for something real.
| Rung | What decides the control flow | What it costs you |
|---|---|---|
| Plain code | You do, at author time | Nothing. It is testable, cheap and instant. |
| One model call in a fixed pipeline | You do — the model only fills in a value | Latency and per-call cost. One place to evaluate. |
| A fixed workflow with several model steps | You do — the graph is written down | Several evaluation surfaces, and errors that compound between steps. |
| An agent | The model does, at run time | Unbounded worst case, non-deterministic control flow, and the whole apparatus from my previous article. |
The rungs are ordered by one property: who decides what happens next. On the first three, that is you, in code you can read, diff and test. On the fourth you have handed control flow itself to a probabilistic system, and everything that makes agents hard follows from that single transfer.
Which means the decision is not "is this problem AI-shaped." It is narrower and much easier to answer: does the sequence of steps need to vary per input? If you can draw the flowchart in advance and it does not change, you do not need an agent. You need one of the rungs below it, and you will be happier there.
What the boring version actually gets you
I want to be specific about this, because "keep it simple" is easy to say and easy to ignore. Staying on a lower rung is not an aesthetic preference. It buys concrete things:
- A bounded worst case. A pipeline costs what it costs. An agent loop has a worst case measured by whatever ceiling you remembered to set.
- Failures that point at a line of code. When step four of a fixed workflow breaks, you know it was step four. When an agent produces a bad outcome, the first job is reconstructing what it even decided to do.
- One evaluation surface per model call instead of a combinatorial space of paths through your tools.
- Latency you can quote. "Under two seconds" is a sentence you can say about a pipeline and cannot honestly say about an agent.
- Anyone on the team can maintain it. This one gets undersold. A scheduled job with a model call in it is legible to every engineer you have. An agent loop is legible to the two people who built it.
None of that is an argument against agents. It is a list of what you are spending when you reach for one, so that you can check you are getting something worth the price.
Where an agent genuinely earns it
Since I have spent several paragraphs on restraint, let me be equally concrete about when I do reach for the top rung. There are four signals, and in my experience you want at least two of them before it is worth the cost.
- The number of steps is unknown until run time. An investigation that might resolve after one lookup or might take nine, depending on what it finds.
- Tool composition cannot be enumerated. Not "which of these three tools," but genuinely open combinations you cannot write down as a graph without the graph becoming absurd.
- The stopping condition is semantic. The task is done when the answer is good enough, and "good enough" is a judgment rather than a predicate.
- A human is in the loop, steering. Conversational, iterative work where the next step depends on what the person says after seeing the last one. This is the strongest signal of the four, and it is why coding assistants are genuinely agentic while most back-office automation is not.
Notice what is not on that list: the task being difficult, the text being unstructured, the output needing to sound natural, the domain being complex. Those all argue for a language model somewhere in your system. None of them argue for handing it control flow.
Why teams reach too high anyway
I do not think this is a competence problem, and it is worth being honest about the forces involved, because they are not all irrational.
The demo is easy. An agent that does something impressive on a well-chosen example can be assembled in an afternoon, and it is genuinely thrilling the first time you watch one chain three tools together and land the answer. The gap between that and something you can put on an on-call rotation is enormous, but it is invisible from the demo, so it is invisible in the meeting where the decision gets made.
The work is more interesting. I am not above this. Given a choice between building an agent loop and building a scheduled job that calls one model, I know which one I would rather spend a quarter on, and so does everyone on your team.
And "we built an agentic platform" is easier to fund than "we added a classifier to an existing job." That one is a real organisational pressure and I would not pretend otherwise. But it produces a specific and recognisable failure: a system that is architecturally ambitious, demos beautifully, and gets quietly switched off eight months later because nobody could make it reliable enough to trust unattended.
Build the boring version first — it is not wasted work
The objection to all of this is that you will just have to rebuild it as an agent later, so why not start there. I think that gets the economics backwards, because the simple version keeps paying for itself even if you do climb.
Build the deterministic pipeline. Instrument it the way I would instrument anything — trace every run, capture the inputs and outputs, log the cases it handles badly. Then let it run against real traffic for a few weeks and read the failures.
What you get is a list of the specific decisions your rigid flow got wrong. That list is the most valuable artefact in the whole project. It tells you exactly which decision needs judgment, which is precisely where a model call belongs — and it is a far better specification than anything anyone could have written up front.
Then, if it turns out the control flow really does need to vary, you climb. But now you are climbing with three things you would not otherwise have: an eval set built from real failures, a baseline you can measure the agent against, and a fallback path for when the agent misbehaves at three in the morning. I have never regretted having those. I have repeatedly regretted not having them.
The actual point
Agentic is a control-flow decision, not a product decision. It is the choice to let a probabilistic system decide what your software does next, and it should be made on those terms, deliberately, with a one-sentence reason you can say out loud.
If you can say that sentence — the number of steps genuinely depends on what we find, and here is a case where that matters — then build the agent, and build it properly. If the honest answer is that the steps are always the same and only the content changes, you have been handed a much easier problem than you thought. Take the win.
The best-engineered AI system I have worked on was mostly ordinary software with a language model doing one hard thing in the middle. That is not a compromise. That is what it looks like when someone was disciplined about where the uncertainty was allowed to live.
I'm Tihomir Tomašević, a software architect with 17+ years in enterprise systems, currently leading development of an agentic AI platform. If you did decide you need the top rung, I have written about how to structure the loop and about how to debug it in production. Through T2 Software I take on selected consulting work on exactly these problems — including the engagements that end with me telling you to build something simpler. Get in touch or find me on LinkedIn.