Skip to content
Brihat InfotechBrihat Infotech

AI Engineering

Why enterprise agent projects get cancelled

Not because the model was not good enough. Because nobody built the evaluation set, the cost ceiling, the action allowlist or the human lane — and the security review found out.

Animesh Pathak25 Jul 20263 min read

The post-mortems blame the model. Rewind an agent project that was quietly stopped and the fatal decisions are almost always engineering omissions made in the first fortnight, before anyone wrote a prompt.

Analyst commentary through 2026 has repeatedly warned that a large share of agentic AI projects will be cancelled — and consistently attributes it to cost, unclear value and inadequate risk controls rather than to capability. That matches what we see.

The five omissions

1. No evaluation set

Without a fixed set of real cases with known-good answers, every prompt or model change is an unmeasured bet. Quality drifts, nobody notices until a user complains, and by then there is no way to tell which change caused it.

The set has to be collected from the people who will use the system, during discovery, before the system exists. A hundred real questions with verified answers is enough to start. Teams that skip it are tuning blind.

2. No cost ceiling

Agentic loops retry, re-plan and re-read context. An unbounded loop means cost scales with the difficulty of a case rather than with its value — and the hardest cases are usually the least valuable.

The controls are unglamorous: a bounded loop, a per-run ceiling, caching for stable context, and routing easy cases to a smaller model. Without them the finance conversation arrives in month three and the project loses it.

3. No action allowlist

An agent with a general-purpose API key and a prompt asking it to be careful is not a control, and no security review will accept it as one.

The boundary has to be explicit: these operations, with these parameters, as this identity. That allowlist is the security model, and it is what makes the system reviewable. Retrofitting it after a working pilot means redesigning the tool layer.

4. No human lane

The framing that survives a risk committee is that the agent clears the roughly eighty per cent that never needed judgment and assembles context for the rest. Systems built without a human lane either answer the hard twenty per cent confidently and wrongly, or block the queue entirely.

The threshold should be a business parameter someone can tune, not a constant buried in code.

5. Integration underestimated

The agent is a fortnight. The connections to the ERP, the case system and the document store are the quarter. Enterprise surveys consistently put system integration at the top of the barrier list, ahead of model quality.

Scoping this backwards produces the classic pattern: an impressive demo in week three, then two quarters discovering that the core system has no usable write interface and its vendor will not add one.

The use case that gets cancelled

Predictable from the start. It looks impressive in a demo, touches something visible to leadership, and has no measurable baseline.

The one that survives is duller: a queue with a real backlog, an owner who already resents it, and a quality bar you can measure against today. Loan origination checks. Invoice-to-PO matching. Claims intake. Service-ticket triage.

If you cannot state today's number, you will not be able to prove the agent worked — and an unprovable win does not get funded twice.

What to measure

  • Straight-through rate — the share handled without a human. This is the value.
  • Accuracy against the evaluation set, per release rather than per demo.
  • Escalation quality — when the agent hands off, does the human get useful context or a raw dump?
  • Cost per completed task against the baseline it replaced.

Straight-through rate alone is a trap: an agent raises it by being confidently wrong more often. It only means something read next to accuracy.

The order that works

  1. Pick a queue with a measurable baseline. Write the number down.
  2. Collect the evaluation set from real users.
  3. Establish the data boundary and the action allowlist before building.
  4. Ship with a human lane and a replayable log.
  5. Run alongside the existing process rather than instead of it.
  6. Compare against the baseline from step one.

None of that is about the model, which is the point. Models will change several times over the life of the system. The skeleton is what you actually own.

  • delivery
  • ai
  • agents
Questions this raises

Almost never for model reasons. The recurring causes are engineering omissions: no evaluation set so quality drift goes unnoticed, no bounded cost so spend scales with enthusiasm, no action allowlist so the security review stops it, no human lane for cases needing judgment, and integration effort underestimated. Surveys of enterprise programmes consistently rank integration and compliance above model quality as barriers.

AP

Written by

Animesh Pathak

Founder

Founded Brihat Infotech in 2022 and has led delivery on every engagement since. Works problem-first: map how the organisation actually runs before proposing a system, then stay on the engagement long enough to be accountable for whether it gets used.

Next step

Bring us the problem. We will bring the architecture.

A discovery call takes forty-five minutes. You leave with our read on the problem, the shape of the system we would propose, and a straight answer on whether we are the right team for it.

  • No sales deck
  • An engineer on the call, not an account manager
  • NDA before you share anything