AI in production doesn't die at the model. It dies in week two.

Every AI project has a demo that works.

The model answers well, the flow makes sense, the room approves. That is almost never where the problem is. It shows up when the pilot meets the company's real system — and that rarely happens on day one. It happens in week two.

The four places it dies

The legacy code

The demo runs on a clean case. The real operation runs on years of accumulated decisions: business rules that exist only inside an 800-line function, exceptions nobody remembers creating, a field that means three different things depending on the flow.

No model understands that on its own. It needs context that isn't in the code — it's in the code's history.

The integration nobody documented

Every production system has at least one. The endpoint that only works if you send the headers in a particular order. The job that runs at 3am assuming the table was already populated. The queue that chokes on a payload above a certain size.

The pilot never touches it. The real implementation does — and that's where the timeline doubles.

The cost nobody measured

In the demo, each call costs a fraction of a cent and nobody looks. In production — real volume, retries, large context, and an agent that decides to call the expensive model because the task "seemed hard" — the bill changes order of magnitude.

AI cost isn't a budget line. It's an architecture decision: who can call what, under which ceiling, and what happens when that ceiling is hit.

The context that gets lost

Between one conversation and the next, the system forgets. What was decided yesterday doesn't shape what it proposes today. Every interaction starts from zero — and the person on the other side pays the cost of explaining it all again.

That is tolerable in a five-minute demo. It is unworkable in an operation that runs every day.

What has to exist before the model

The right question isn't "which model should we use". It's what has to be standing for any model to be useful:

• Architecture — where AI enters the flow, what it may and may not decide alone, and what happens when it gets it wrong.
• Context — a way for the system to know what has already been decided, not just what is on screen right now.
• Cost governance — a ceiling per call, per task and per agent, measured before it becomes an invoice.
• Determinism where it matters — not every step can be model improvisation. Some need to be a flow, with explicit control.

None of it is glamorous. It is what separates a pilot from a system.

Day 200

The question we ask on every project isn't "does this work in the demo?". It's: will this still be working on day 200?

Because by day 200 the team that built it has moved on, volume has tripled, three edge cases nobody predicted have shown up, and somebody needs to understand why the system made the decision it made.

That is exactly where we come in. We don't build demos — we build systems that keep working after the novelty wears off.