AI IN PRODUCTION

Why 40% of AI Projects Fail (and How Not to Join Them)

Four in ten agentic AI projects will be canceled by 2027, according to Gartner. The model is not the problem. The 7 rules we use to get an agent into production alive.

PUBLISHED August 31, 2026 · 7 min read

By ACME
Editorial

One of our agents reported the same file as saved two weeks in a row. The file did not exist. We found out by auditing the pipeline, not by reading the report: the report said everything was fine.

That is the short version of why AI projects fail. They do not fail because of the model, but because of the engineering nobody built around it.

Why do 40% of AI projects fail?

According to Gartner, over 40% of agentic AI projects will be canceled by the end of 2027. The causes it lists do not include the model: escalating costs, unclear business value and inadequate risk controls. At the same time, 74% of companies plan to deploy agents within the next two years. Almost everyone will try. Four out of ten will crash, and not because of the idea.

The gap is between the demo and production. In the demo the agent runs once, on hand-picked data, in front of people who want it to work. In production it runs a thousand times, on dirty data, with nobody watching. Everything that separates one from the other is engineering. We already wrote about how to spot a fake AI demo. This is the follow-up: what has to exist behind the demo for it to become a system.

The model is not the problem

The model is the best-performing part of the stack and the easiest to swap. Claude, GPT or Gemini get better every month without you doing anything. What does not improve on its own is everything around them: the tests, the limits, the verification, the spending brake.

You do not have to take our word for it. In August, OpenAI paused training on its next models for two weeks and hardened its monitoring with automated investigators that review its models' actions and reasoning and raise an alert within 30 minutes of any concerning signal. If the lab training the biggest models in the world halts its own training to put controls around it, your internal pilot needs them too.

Teams already running agents in production repeat the same idea. Linear's team, walking through how they built their internal agent, listed five rules and three of them have nothing to do with the model: map the real workflow before writing code, give the agent tools to find context instead of stuffing context into the prompt, and measure every output with evals. As Jacob Shumway put it: "Give it the tools to load context. Don't give it context." None of that is the model. All of it is engineering.

The 7 rules that cost us money

We run our own agents every day: they produce video, watch SEO, read trends, open pull requests. These seven rules did not come from a paper. Each one has an invoice or a scar behind it.

  1. "It worked when we tried it" is not a test. One successful run is an anecdote. Our video pipeline generates three candidates per scene and an automated judge picks one: with a single candidate we rejected 4 out of 6 scenes; with three, we approved 4 out of 4. Same model, same prompt. The difference was giving quality control options to choose from.
  2. No logs, no production. If you cannot reconstruct what the agent did and why, you do not have a system: you have faith. Our agent wrote this line this morning, verbatim (it logs in Spanish):
    Posts nuevos: 0
    PRs abiertos (draft): ninguno
    Saltados (ya procesados): 1
    It means: zero new posts, no draft PRs opened, one item skipped as already processed. Eleven runs in two weeks and almost all of them end like that. An agent that knows how to do nothing, and leaves a record of it, is worth more than one that invents work to justify itself.
  3. An agent that says "saved" is not an agent that saved. The confession at the top: two out of three weekly files were lost after being reported as saved. The rule that came out of it is simple. Every claim an agent makes gets verified from the outside, against the disk, against the system, against anything that does not depend on its own word.
  4. Running twice cannot break anything. If the process dies halfway and you relaunch it, it cannot duplicate or overwrite what was already done. In our pipeline, state lives in a manifest, and a test reads the code of every stage and rejects any that tries to write without going through the lock. The lock had existed for months. Nothing called it. The test was born from finding that out.
  5. Spending starts blocked. Our video API client is born with spending disabled by default. That rule cost 26 credits: probing an endpoint with real requests generated videos that could not even be canceled. Today spending requires explicit authorization and every piece has a budget brake.
  6. No agent merges alone.Everything that touches production goes through human approval. In our case it is literally an emoji on Slack: the agent proposes, prepares the change and waits. The day a mistake gets expensive, we want the last hand on it to have been a person's.
  7. The agent knows how to shut itself down. If a prerequisite fails, it ends and reports in one line. No infinite retries, no zombie processes. One Monday the data source for our trends engine went down and the cycle aborted cleanly in five minutes. The version without a fail-safe would have hung there burning CPU all morning.

How do you know if your pilot will reach production?

Ask your team or your vendor three questions: where are last week's logs, what happens if the process runs twice, and where is the spending brake. All three need a concrete, showable answer. If any of them does not have one, you do not have a system yet, just a demo with good press.

What we do

We install agents inside other operations with these same rules, because we already paid the price of learning them in ours. The format is a 30-day pilot on one of your real processes, with logs, a spending brake and human approval from day one. And when it ends, you keep root and the manual: the code is yours, the logs are yours, the brake is yours.

If you have an AI pilot dead in a drawer, that is exactly the one we want to see.

Frequently asked questions

Why do AI projects fail?

According to Gartner, over 40% of agentic AI projects will be canceled by the end of 2027, driven by escalating costs, unclear business value and inadequate risk controls. Implementation fails before the idea does.

Is the AI model the problem?

No. Models like Claude, GPT or Gemini are the best-performing part and the easiest to swap. Projects die from what is missing around them: tests, logs, spending limits, external verification and a human approving anything expensive.

What does an AI agent need to work in production?

At least seven things: tests with multiple candidates, logs for every action, external verification of its claims, idempotency so it can run twice without breaking, a spending brake, human approval for expensive actions and a fail-safe to shut itself down.

How do I know if my AI pilot is for real?

Ask for last week's logs, ask what happens if the process runs twice and where the spending brake is. If all three questions have concrete answers, it is for real. If not, it is still a demo.

~/subscribe

Get the next posts

1-2 emails per month with notes on AI velocity, MVPs, and B2B operations. Unsubscribe anytime.

~/start-project
30-DAY PILOT ON YOUR CASE
BRING A PROCESS. WE BREAK IT LIVE