Why Most Enterprise AI Failures Are Integration Problems, Not Model Problems

A model demo is one of the most persuasive artifacts in software. Someone types a messy request, the model returns a clean, competent answer, and a room full of people conclude the problem is solved. What they've actually seen is the model running against nothing — no identity system, no third-party API with its own opinions, no system of record that will reject the write, no operational rule that lives in a supervisor's head instead of the prompt. The gap between that demo and a production system is almost never a gap in model capability. It's a gap in integration.

I've spent most of my career on both sides of this line. Before I was building AI systems, I was integrating European rail booking into an airline's loyalty platform — Okta identity, multiple third-party rail providers with inconsistent schemas, distributed booking state, and hybrid card-plus-miles payments, all under enterprise review and a hard deadline. Now I build AI agents that write into live CRM and dispatch systems. The surface changed. The failure modes did not. Enterprise AI dies in exactly the same places enterprise integration has always died — and it's rescued by exactly the same discipline.

The reason the demo is so misleading is that it isolates the one component that has improved the fastest. Frontier models are genuinely good now. If your only variable is "can the model produce a reasonable response to this input," you will almost always win, and you'll win in a meeting, in front of the people who approve budgets. But a production system is not a function from prompt to text. It's a participant in an existing operation, and the operation has preconditions the demo quietly satisfied for free.

In the demo, the user is already authenticated — no token refresh, no SSO handshake, no per-tenant scoping. The data is clean and local — no third-party API that times out, rate-limits, or returns a field its documentation swears doesn't exist. Nothing is written anywhere — no double-booking, no idempotency key, no reconciliation when the CRM accepts the appointment but the dispatch system doesn't. And the business rules are whatever the presenter typed. Strip those four assumptions away and the model is still fine. It's everything around the model that isn't built yet.

When an enterprise AI project stalls between a convincing prototype and something running in production, the cause is usually one of a small set of integration problems that have nothing to do with the model's intelligence:

Notice that none of these are solved by a better model. A larger context window doesn't reconcile a booking that half-committed. A lower hallucination rate doesn't refresh an expired token or make a rate-limited provider respond faster. These are systems problems, and they're the same systems problems I was solving in enterprise integration years before the model was the interesting part of the stack.

The travel booking work is the clearest example I have, because it had no AI in it at all and yet every hard problem was one I now hit again in AI systems. We were streaming train offers across several rail providers whose APIs disagreed with each other and, frequently, with themselves. Bookings had to stay consistent across distributed services when any single downstream provider could fail mid-transaction. Payments combined credit cards and loyalty miles in one flow. It shipped on time for one reason: we prototyped the riskiest integrations first, and we designed the booking lifecycle around failure states instead of happy paths.

That sentence — design around failure states instead of happy paths — is the whole transferable lesson. The happy path is what the demo shows. The failure states are what the production system spends most of its code on. When I started deploying AI into live operations, I didn't change the discipline; I pointed the same discipline at a component that happens to be probabilistic. If anything, the AI raises the stakes, because now the thing initiating the write can also be wrong about whether it should write at all.

The single largest jump in difficulty in any AI integration is the transition from reading to writing. A retrieval assistant that answers a rep's question during a call is valuable and comparatively safe: if it's wrong, a human is in the loop and catches it. An agent that books the appointment directly into the CRM and dispatch workflow is a different risk class entirely, because now a mistake is a real job on a real schedule, and the system it wrote into is the source of truth for the rest of the business.

My rule for this is simple and predates AI: every action must end in an explicit, recorded state — booked, escalated, or failed-with-context — never "it just ended." A model-initiated write is not complete when the model decides to make it. It's complete when the target system has confirmed it, the outcome is persisted somewhere you own, and the path for a failed or ambiguous write leads to a human with enough context to resolve it. That invariant is what makes a probabilistic system auditable and safe to widen over time.

async def book_appointment(intent: BookingIntent) -> Outcome:
    # The model proposed a booking. That is a proposal, not a fact.
    if not passes_business_rules(intent):
        return Outcome.escalate(intent, reason="failed rule check")

    # Idempotency so a retry after a timeout can't double-book.
    key = idempotency_key(intent)
    try:
        confirmation = await crm.create_appointment(intent, idempotency_key=key)
    except (Timeout, ProviderError) as err:
        # The write may or may not have landed. Never assume.
        return Outcome.escalate(intent, reason=f"unconfirmed write: {err}")

    # Only now is it real — persist the recorded state we own.
    await outcomes.record(intent, confirmation, state="booked")
    return Outcome.booked(confirmation)

There is no clever prompt in that snippet, and that's the point. The reliability lives in the idempotency key, the rule check that gates the write, the refusal to assume a timed-out write failed, and the recorded outcome. This is ordinary distributed-systems hygiene. The novelty is only that the caller is a model — which is exactly why the hygiene matters more, not less.

The last category is the one teams underestimate most, because it doesn't look like engineering. In the retrieval copilot work, the model was never the hard part. The hard part was that the rules governing a good booking decision — urgency tiers, membership handling, pricing boundaries, what counts as a same-day job — weren't written down anywhere. They lived in supervisors' judgment and disagreed across the website, the reps, and the people who actually made the calls. Similar calls produced different outcomes depending on who answered.

You cannot prompt your way out of that. Extracting those rules is stakeholder work: interviews, shadowing, reconciling sources that contradict each other, and turning tribal knowledge into something a system can retrieve and enforce. Then it's engineering: structuring that knowledge for retrieval, forcing the model to ground answers in it for the categories where a wrong answer is expensive, and building a feedback path so frontline corrections flow back into the knowledge instead of evaporating. The model is a consumer of that work. It is not a substitute for it.

Because the risk lives in the integration layer, that's where I front-load the work. The sequence I use looks almost nothing like "pick a model and start prompting":

1. 01Map what it touches before writing any prompts. Every system, every identity boundary, every write. The integration diagram is the real spec; the model is one box on it.
2. 02Prototype the riskiest integration first, not the model. If the write into the system of record is the scary part, build a thin end-to-end path through it in week one — before investing in the parts that were never in doubt.
3. 03Design every action around its failure state. For each thing the system can do, define what happens when it half-succeeds, times out, or is refused. If the answer is "we'll handle it later," it isn't designed.
4. 04Keep the model on a short leash where mistakes are expensive. Enforce retrieval for sensitive categories, gate writes behind rule checks, and start with conservative authority — read and recommend before it acts unattended.
5. 05Make every outcome observable and recorded. Booked, escalated, failed-with-context. You cannot improve, debug, or earn trust in a system whose actions you can't see after the fact.

The order is the argument. Teams that lead with the model spend their credibility on the part that was always going to work and discover the integration reality late, under deadline. Teams that lead with the integration surface find the real constraints while there's still time to design around them. This isn't AI-specific wisdom. It's what shipping enterprise integrations teaches you, applied to a new kind of caller.

If you're evaluating whether an AI project will make it to production, stop asking whether the model can do the task. It almost certainly can. Ask instead what the system touches, who it acts as, what it writes into, and what happens at each seam when something fails — and ask whether the rules it's supposed to follow even exist in a form a machine can use. Those questions predict production outcomes far better than any benchmark, because that's where the projects actually succeed or die.

It also reframes what kind of engineer you need. The person who can take one of these from a demo to production isn't primarily a prompt specialist. They're someone who is comfortable in ambiguous operations, fluent in identity and distributed state, disciplined about failure modes, and willing to do the unglamorous work of encoding rules nobody wrote down. That's the same person who could ship the enterprise integration before there was a model involved at all. The model didn't change the job. It just made the integration matter more.