Why AI Agents Keep Failing on Long Multi-Step TasksStart nowStart Now
Your agent has a half-life<br>Ankush · Author<br>Writes about Construct, AI agents, and developer tools.<br>Published August 11, 2026 · @ankushKun_
ai-agent<br>reliability<br>workflow-automation<br>product
Valve named a game Half-Life after the physics joke hiding in plain sight: how long something lasts before half of it is gone. Your agent has one of those. It just does not get a hazmat suit or a crowbar out of the deal.
Take an agent that gets 95% of its individual steps right. That is a good agent. Now give it a ten-step job.
It finishes six times out of ten. The other four times, it fails halfway. Literally. A half-life.
Nothing broke. No step regressed. 0.95 to the tenth power is 0.60, and that is the whole story. Reliability that looks excellent per step is mediocre per job, and it gets worse in a way most people do not feel until they schedule something and walk away.
If you have been asking why your agent keeps failing halfway through a multi-step job, this is usually the answer, and it is not the one people go looking for.
Meet Construct→
Why your agent keeps failing on long tasks
The tempting explanation is that long tasks are harder tasks. Longer means more ambiguity, more chances to misread the goal, more compounding confusion.
That explanation is wrong, and there is a clean piece of work showing why. In "Is there a half-life for the success rates of AI agents?", Toby Ord shows that agent performance across task lengths is explained by an extremely simple model: a constant rate of failing during each minute a human would take to do the task (Ord, arXiv:2505.05115). Not accumulating confusion. A flat hazard rate, ticking the entire time the job runs.
Physicists already have a letter for that rate. It is λ, the decay constant in N(t) = N₀·e^(−λt), and the half-life is just t½ = ln(2) / λ. Valve put the same λ on Gordon Freeman's suit and in the Half-Life logo for the same reason: it is the constant that decides how long something lasts before it is gone. Ord's result is that your agent has one too.
That gives every agent a half-life: the task duration at which its success probability hits 50%. Longer tasks fail, in Ord's framing, because they contain increasingly large sets of subtasks where failing any one fails the whole thing. Raise λ (worse per-minute reliability) or raise exposure (longer jobs), and the surviving fraction falls the same way a sample of isotope does. You do not need a crowbar for this. You need less exposure.
This reframes the problem usefully. If failure were about difficulty, you would fix it with a smarter model. If failure is a rate per unit of exposure, you fix it by reducing exposure. Those are very different engineering programs, and almost everyone is running the first one.
Why multi-step agent workflows fail: 48 steps, 8.5% success
Ten steps is a toy. Real recurring business work is worse, because it loops.
Here is a job we hear about constantly from small agencies: monthly client reporting. Eight clients. For each one, pull analytics, pull ad spend, pull the CRM's deal movement, write the summary, render it into the client's template, email it. Six steps, eight times. Forty-eight steps.
Article tablePer-step reliabilityOne 48-step run finishes99%62%95%8.5%90%0.6%
A 95% agent, which is a genuinely capable agent, completes that job start to finish about one time in twelve. And the failure mode is the ugly one: it dies at client six, having already emailed five reports, and you cannot tell what state anything is in without reading the whole transcript. One continuous experiment, cascading into a mess you did not budget for. Black Mesa energy, spreadsheet edition.
So people conclude agents do not work for real operations. What actually does not work is running forty-eight steps as one uninterrupted bet.
Will a better model fix agent reliability?
There is a genuine counterargument: models are getting better at long tasks fast. METR measures the 50% time horizon, the task duration at which an agent is predicted to succeed half the time, using how long human experts need for the same work. That horizon has been doubling roughly every seven months for six years, with recent data suggesting faster (METR, measuring AI ability to complete long tasks; METR, time horizons).
That is real progress and it is not slowing. It is also a terrible thing to plan a business process around. The horizon is defined at 50% reliability, which is a coin flip, and the doubling curve tells you nothing about next Tuesday's client reports. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls (Gartner, June 2025). A large share of those projects will die from exactly this: a demo that worked once, scheduled weekly, quietly failing most weeks. Unforeseen consequences, delivered on a cron.
Waiting for the model...