Most agents are a cron job with better marketing

Somewhere in the last two years, "agent" stopped meaning anything specific. A scheduled script that pulls data and formats a report gets called an agent. A retrieval call wrapped in a system prompt gets called an agent. A Zapier chain with an LLM node in the middle gets called an agent. None of these are wrong to build. They're just not agents, and calling them agents doesn't make them work better. It makes them cost more to build and harder to debug when they break.

Here's the test we actually use: does the task have a fixed, known sequence of steps? If yes, you don't need an agent. You need a queue, a schedule, and someone who's mapped the steps once. An agent is for when the system has to decide, per input, what to do next — which tool to call, which path to take, when to stop. If you already know the path, you're paying for a decision-making architecture to make a decision that was never in doubt.

We saw this directly with KREPL, an agri-inputs company whose field reps were spending close to an hour a day on reporting. The tempting version of this project is a "field agent" that reasons about what to report and how. The actual problem was: reps fill in the same categories of information every day, that information needs to reach the right systems, and nobody had built the plumbing. The fix was workflow automation and data integration — not reasoning, just structure. No step in that process needed a model deciding what to do next. It needed the manual, repetitive part removed. Reporting time dropped from about an hour to under 10 minutes per rep, which works out to roughly 420 selling hours a day back across 500 reps. That number came from moving data correctly, not from anything resembling autonomy.

Compare that to StudyBuddy, an edtech product where the job is tutoring across every subject and every kind of question a student throws at it. There is no fixed sequence here. A geometry proof and a chemistry balancing problem and an essay outline don't share a pipeline. The system has to figure out, per question, what kind of reasoning applies and how to get there. That's not a queue with extra steps — it's a genuinely open-ended problem, and it's why we built a multi-agent system with hybrid reasoning instead of a fixed workflow. The architecture matched the actual shape of the problem. It wasn't a stylistic choice.

The difference between those two projects is the whole argument. KREPL's problem was solved once you knew the steps. StudyBuddy's problem doesn't have steps you can know in advance — the "step" is itself a judgment call the system has to make fresh each time. Building StudyBuddy as a scheduled pipeline would have failed outright. Building KREPL as an autonomous agent would have worked, eventually, at higher cost, with more failure modes, and with a client paying for reasoning they never needed.

A few signs you're looking at a queue-and-schedule problem wearing an agent costume:

• You can write the steps down in order, today, without needing to see live data first.
• The variation between runs is in the data, not in what actions get taken.
• A wrong output is annoying but not expensive — there's no moment where the system has to weigh options with real cost attached to guessing wrong.
• Someone already does this job manually, the same way, every time.
• "Agent" is being used in the pitch before anyone has described what decision the system actually needs to make.

None of this is an argument against agents. It's an argument against reaching for one by default because the word is in the air. An agent is the right call when the task genuinely requires judgment that changes shape per input and the cost of a bad autonomous decision is real — that's StudyBuddy. It's the wrong call when the task is stable and repetitive and the only thing missing is someone willing to automate it properly — that's KREPL, and it's most of what gets pitched to us as "agentic."

We start every engagement by figuring out which one we're looking at, before we talk about architecture. If the honest answer is a scheduled job and an integration, that's what we scope and what we bill for. If there is no measurable delta in building you an agent instead, we will say so, because the more complex system is also the more fragile one, and fragility is not a feature we get to bill twice for fixing.