Originally published on robatdasorvi.com
The agent you are about to build should be a for-loop with four if-statements, and the only reason it isn't one is that nobody has ever been given a budget line item for a for-loop.
I know your situation. You have a task that involves a language model somewhere in the middle. You have read that agents are the future. You have a diagram with boxes labeled planner, executor, and critic, and the boxes have arrows that loop back on themselves, and it looks like an architecture. Nobody will tell you to avoid AI agents here, because saying so sounds like saying you don't believe in electricity. So you're going to build it, it's going to work in the demo, and then it's going to spend eight months in the state that Gartner politely calls "pilot."
Let me tell you the thing I wish someone had told me before I spent a quarter learning it by hand.
Should I use an AI agent or just write the code?
Write the code. Use an agent only when you genuinely cannot enumerate the steps in advance — not when enumerating them is tedious, but when it is impossible, because the next step depends on what the previous step found.
That distinction is the entire architecture decision, and it collapses about 80% of the agent projects I've seen into ordinary software. Anthropic's own engineering guidance, published in December 2024, draws the line cleanly: workflows are systems where models and tools are orchestrated through predefined code paths; agents are systems where the model dynamically directs its own process. Their recommendation, from the company selling you the models, is to find the simplest solution possible and only increase complexity when needed.
That is a vendor telling you to buy less of the product. It is worth reading twice.
Here is the honest test. Sit down and try to write the flowchart. If you can draw it — even a big, ugly one with fourteen branches — you do not have an agent-shaped problem. You have a normal program that calls a language model at four or five specific points where natural language needs to become structured data. That program will be debuggable, testable, and cheap. Your agent will be none of those things, and it will do the same work by asking a model to rediscover your flowchart at runtime, from scratch, at three cents a rediscovery.
When should you avoid AI agents entirely?
Avoid AI agents when the task has more than roughly ten sequential steps, when a wrong step is expensive to undo, or when you cannot afford to be wrong the same way twice. The reason is arithmetic, not ideology.
Agent reliability compounds multiplicatively. If each step in your chain succeeds 95% of the time — which is generous, and is roughly where good tool-calling sits — then a twenty-step task completes correctly 36% of the time. Nobody advertises this, because "our agent is 95% accurate" is a true sentence that produces a system which fails two times out of three.
The benchmarks have been saying this out loud for two years and the industry has been extremely good at not hearing it. Carnegie Mellon's TheAgentCompany, released in December 2024, put agents inside a simulated software company with 175 real professional tasks — software development, project management, HR, finance — and the best model of the day completed 24.0% of them autonomously. Eighteen months and several model generations later, the leaderboard has crawled into the low thirties. Salesforce's CRMArena-Pro, published in May 2025 across 4,280 queries and nineteen expert-validated business tasks, found leading agents hit 58% on single-turn tasks and 35% once the task required multiple turns. The paper also notes, in the flat tone of people reporting a fire, that agents display "near-zero" inherent confidentiality awareness.
But the number that should actually change your architecture is from Sierra's τ-bench, June 2024. They introduced a metric called pass^k: not can the agent solve this task, but does it solve the same task on all k attempts. GPT-4o scored about 61% pass@1 on retail customer-service tasks and roughly 25% on pass^8. Read that as a business fact rather than a benchmark fact: for eight customers with the identical problem, there was a one-in-four chance all eight got helped correctly.
An agent that succeeds 61% of the time and is inconsistent about which 61% is not a reliable employee. It is a coin that talks.
Why do most AI agent projects fail?
They fail because the failure is invisible until the bill arrives. Gartner predicted in June 2025 that over 40% of agentic AI projects would be canceled by the end of 2027 — not because the agents didn't run, but because of escalating costs, unclear business value, and inadequate risk controls.
The same press release contains my favorite piece of industry accounting: Gartner estimates that of the thousands of vendors selling agentic AI, roughly 130 are real. The rest are engaged in what the analysts named "agent washing" — rebranding existing chatbots and RPA scripts. So when you benchmark your build against what competitors appear to have shipped, remember that you are, statistically, benchmarking against a rename.
MIT's Project NANDA reached the same place from the buyer's side. Their 2025 report The GenAI Divide, built on 300-plus public deployments, 52 executive interviews and 153 survey responses, found that 95% of enterprise generative AI pilots produced no measurable P&L return despite $30–40 billion in investment. Their diagnosis wasn't model quality or regulation. It was that these systems don't retain feedback or improve, so every run starts from zero — which is, if you look at it directly, a description of an agent loop.
I have my own small version of this. I run a content system that includes a long-form article lane. For weeks it looked like the lane had simply gone quiet. It hadn't. The generation step was failing to produce parseable JSON roughly 40% of the time, and because each attempt consumed a 48-hour scheduling slot, eight of twenty articles evaporated with no error surfaced anywhere a human would look. The model wasn't wrong. The model was occasionally malformed, which in a deterministic pipeline is a caught exception and in an agent loop is a silence.
That's the real cost structure. Deterministic code fails loudly at the line where it broke. Agents fail quietly, three steps downstream, with a confident summary of what they believe they accomplished.
But won't the models get good enough to fix this?
Partly, and it won't help as much as you think, because the gap that kills agents is between capability and consistency, and only one of those two is improving quickly.
This is the honest counterargument and it deserves an honest answer. Yes, models improved enormously between the τ-bench results and today. Yes, pass@1 scores climbed. But pass^k — the reliability metric, the one your customers actually experience — has climbed far more slowly, because it is a product of per-step reliability raised to a power. Getting from 95% to 97% per step is a real engineering achievement that moves a twenty-step task from 36% to 54%. You have doubled your quality and you still lose half the runs.
And there's a nastier wrinkle: better models don't reliably make you faster. METR ran a randomized controlled trial with 16 experienced open-source developers across 246 tasks between February and June 2025. The developers predicted AI would speed them up 24%. Afterwards, they reported feeling 20% faster. They were 19% slower.
Sit with that for a second, because it's the load-bearing finding of this entire essay. These were skilled engineers, using frontier tools, on their own repositories, and they were wrong about the direction of the effect by nearly forty percentage points. If experienced developers cannot correctly perceive whether AI made them faster on their own code, you have no chance of perceiving whether your agent is working by watching it work. The perception channel is broken. Only measurement survives.
So no, waiting for the next model doesn't fix it. Waiting for the next model fixes the demo, which was never the problem.
How do I know if my task is actually agent-shaped?
Three conditions, all of which must hold: the search space is genuinely unenumerable in advance, a wrong step is cheap to detect and cheap to undo, and you have a verifier that isn't another language model.
That third one eliminates most candidates on the spot. Coding agents work — really work, not demo-work — because compilers and test suites exist. The agent can flail through twelve wrong approaches and the ground truth is free and instant. Deep research agents work reasonably well because a bad source is recoverable and a human reads the output anyway. Both are domains with a cheap, external, non-negotiable oracle.
Your refund-processing agent has no oracle. Your outbound-email agent has no oracle. Its verifier is a second model asked "does this look right?", which is how you get a system that is confidently wrong twice and calls it consensus.
If you can't name the oracle, you don't have an agent. You have a very expensive way to generate plausible text and a very cheap way to lose money.
What should I build instead?
Build the pipeline. Named steps, structured output at every boundary, hard schema validation, a real error when the schema fails, and a human gate on anything that leaves your system and touches another person.
Then measure the thing everyone skips: not whether it succeeded, but whether it succeeded the same way across ten identical runs. That's your pass^k. If it's below 90%, you don't have a product, you have a distribution.
You can always add the loop later. Adding autonomy to a system with good instrumentation is a Tuesday. Adding instrumentation to an autonomous system that has been in production for six months is a rewrite, and it will be presented in the postmortem as "scaling challenges."
If I had one minute with you, before your architecture review, this is what I'd say:
Go find the demo you're using to justify this. Run it ten times with the same input. Not one time — ten. Write down how many produce the identical correct outcome.
If the answer is ten, build your agent, and I'll be genuinely happy to be wrong.
If the answer is six, you already have your architecture decision, and you got it for the price of nine extra API calls instead of two quarters and a team. The number you're about to write down is the most valuable thing you'll learn this month, and the entire industry is structured so that nobody will ever ask you for it.
Ask yourself. Then go write the for-loop.
