Most “AI features” don't fail in the demo. They fail in the second week of real usage — when the questions get messier, the bill arrives, and the one engineer who understood the prompt chain is on holiday.

We've shipped AI in our own products and in client products across fintech, edtech, and emergency response. The pattern is consistent: the feature isn't the hard part. The system underneath the feature is the hard part. Six disciplines decide whether it survives.

1. Retrieval & grounding

A demo can get away with stuffing documents into context. Production can't. You need a real retrieval layer: hybrid search, a deliberate chunking strategy, freshness signals, and tenancy-aware embeddings so one customer's data never leaks into another's answers. And answers should cite sources — always. Users forgive a wrong answer with a citation faster than a confident hallucination.

2. Agents & orchestration

The difference between an agent and a jumble of chained prompts is structure: task decomposition with typed tools, deterministic fallbacks when a step fails, and clean state you can inspect afterwards. If you can't replay a failed run and see exactly which step went wrong, you don't have an agent — you have a liability.

3. Guardrails & UX

Guardrails are a UX problem as much as a safety problem. Structured outputs, refusal handling, latency budgets, and graceful degrade paths need to be written into the interface — what does the user see when the model times out, refuses, or returns garbage? If the answer is “a spinner forever,” the feature isn't done.

4. Evals & regression

This is the discipline that separates teams who ship AI once from teams who keep shipping it:

* A golden set of real inputs with expected outputs

* Offline evals in CI, so a prompt change is tested like a code change

* Prompt versioning, so you can roll back

* Human review loops for the cases automation can't judge

Without this, model drift ships silently. With it, your AI feature gets better every week instead of quietly rotting.

5. Cost & routing

The feature that delights users at $0.002 per request can die at $0.04. Model tiers, caching layers, and per-tenant budgets aren't optimizations to do later — they decide whether the feature survives its first finance review. We ship with a per-request unit-cost dashboard from week one, because the CFO will eventually read the bill.

6. Trust & compliance

PII redaction, audit trails, SOC 2-aligned logging, and red-team playbooks — built in from the start, not bolted on for the enterprise deal. Retrofitting trust is far more expensive than designing for it.

The honest test

Ask your team three questions about your AI feature:

1. If the model provider changed behavior tomorrow, would CI catch it?

2. Do you know your cost per request, per tenant, today?

3. Can you show a regulator exactly what the model saw and said last Tuesday?

If the answer to any of these is no, you have a demo in production — not a production feature. That's the gap we close in our AI Engineering practice: working AI features in production, an evaluation harness, guardrails, monitoring, and cost controls. It's how a fintech client's reconciliation agent went from a stalled prototype to production in eight weeks, with hallucinations down from ~7% to under 0.4% on the golden set.

"Everyone has an AI page. Few can put AI into production and keep it reliable, safe, and cost-controlled."