Guides · Building with AI
Guides · Building with AI
An AI agent that works in a demo but fails in production almost never fails because of the model. It fails on the layer around the model: integrations that break, auth tokens that expire, permissions it never really had, actions it repeats because nothing made them safe to retry, and spend with no ceiling. A demo is one happy path, run once, by one friendly person. Production is every other path, run by strangers, with real money and real data behind it.
This is the reliability chapter of our guide to building an app with AI in 2026. If you wired an agent to automate your posting, a marketing workflow or an internal task rather than a classic app, the same thing applies: a demo that runs is not a system you can walk away from. The failure modes below are the ones we keep finding when a working agent meets real use.
Because a demo tests the one path you built it for, and production tests every path you did not. You click through with a valid token, your own account, and inputs you already know work. Then a stranger arrives whose account has different permissions, the token expires halfway through a task, an upstream API returns a shape you never saw, and two requests land at the same instant. The model handled every one of those fine. The system around it did not.
The industry is finding this out at scale. 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. Notice what is missing from that list: the model. Agent projects rarely die because the AI could not do the task. They die on the parts around it.
A handful of failure modes account for most agents that die after launch. Each one is invisible in a demo, because a demo runs once, fast, under supervision. Here is what each looks like live, and the fix in a line.
| Failure mode | What it looks like live | The fix |
|---|---|---|
| Broken integration | An upstream API changes a field or rate-limits you, and the agent acts on a response it misread | Validate every response, fail loud, degrade on purpose |
| Expired auth token | The token that worked in the demo expires, and the agent quietly loses access mid-task | Refresh tokens server-side, treat lost auth as a real error, not a shrug |
| Missing permissions | The agent reaches data or actions it should not, or cannot reach what it should | Enforce permissions on the server, per request, never in the prompt |
| No spend cap | Nothing limits how many calls or jobs run, so cost climbs with no ceiling | Hard spend and rate limits, plus a stop switch you can actually hit |
| Repeated action | A retry or a double-click makes the agent charge, post or email the same thing twice | Idempotency keys, so the same action runs once no matter how often it fires |
| Lost state | The agent forgets where it was after a crash or restart, and resumes in the wrong place | Persist state outside the agent, make every step resumable |
Because success multiplies, it does not average. If each step in a workflow succeeds 95% of the time, a 20-step run succeeds about 36% of the time, not 95%. That is 0.95 raised to the power of 20. The more steps an agent chains, the faster the odds fall, and agents chain a lot of steps.
The pattern holds at every reliability level. Ten steps at 99% each land around 90%. Twenty steps at 95% land around 36%. Fifty steps at 99% land around 60%. This is why a workflow that ran perfectly once in a demo tells you almost nothing about the hundredth run in production. The fix is not a better model. It is fewer steps, a check between them, and a way to retry the one that failed without redoing the whole chain.
The fixes are boring, and that is the point. None of them are about the model. They are the same controls any production system needs, applied to something that can now act on its own. Work through this list before an agent touches real users.
The most expensive failure we have seen was not a crash. It was an automated app with no cap on how many jobs ran at once, no spending limit, and no real stop switch. The owners ran it unsupervised for a single day and got an AI bill of over $1,000 before they reached us.
The demo worked perfectly. Nobody prompts an AI builder for a spending limit, so it never wrote one. That is the shape of almost every production failure: the thing that breaks is the thing nobody asked the model to build.
A spend cap is one line of defence. The deeper pattern, permissions handled in the browser with no server-side control, is the one we find most often across AI-built apps, and it is documented with the fixes in security holes we keep finding in AI-generated apps.
Run the same self-check we use before anything ships. The six domains in is your app production-ready apply to an agent as squarely as to an app: server-side security, data rules, limits, backups, monitoring, and the edge cases nobody prompted. If you cannot answer yes across all six, that gap is the work.
We build and check agents this way as a habit. We grill the plan before an agent runs, and we verify it actually finished the task instead of trusting the receipt it hands back. Across 15 shipped apps we have wired several model providers together with full data separation, and hardened agents that worked in a demo but leaked, over-spent or silently dropped tasks the moment real use started.
If you have an agent that nails a demo but you are not sure it survives real users, real money and real data, get a written quote to harden it before launch. You get an honest read on where it breaks first, before anyone talks money.
Founder and main developer at Zyntari. Building apps and AI solutions since 2024; before that, 12 years in sales and client-portfolio management and co-founder of two companies. More about the team · LinkedIn