We get the same call twice a month. The innovation team ran a beautiful POC. The demo landed. The CEO asked what's next. Six months later, the system still isn't live, everyone has a theory, and nobody can point to the single thing that's blocking production. Here's what we actually find when we go in.

1. Latency was never a POC metric

POCs get judged on one question: "does the model produce the right answer?" Production gets judged on a much harder one: "does it produce the right answer in under 800 ms, 99.9% of the time, while 10,000 other users are also asking, at a cost per call that doesn't eat the margin?"

If nobody measured latency under representative load from week one, go-live will be latency's coming-out party. You'll discover it on the worst possible day - in front of the business stakeholder who approved the program. We require latency instrumentation in every POC we scope, even the ones we don't intend to ship, because it's cheaper to discover a p99 problem with a synthetic load test than with a real CEO on the phone.

Practical rule: any POC that doesn't answer the question "how does this behave at 10× current load" isn't a POC. It's a puppet show.

2. The compliance review was the last step, not the first

We've seen six-month POCs thrown out in a one-hour compliance review. A system without 5568 accessibility, WCAG 2.1 AA, HIPAA-class controls, pen-testing, and auditable decisions will be rejected by the first regulator who looks at it - and you'll rebuild half of it to catch up.

On the Apollo platform now running in 30+ Israeli government hospitals, we built compliance into the earliest architecture sketches. Landing Zone wasn't an afterthought; it was a constraint we designed around. The hospital network onboarding took days, not months, because the compliance review found what it was supposed to find: nothing new.

The lesson: for any customer operating under a regulator, the compliance posture is the architecture. If your POC wasn't designed to pass its first audit, it isn't a candidate for production - it's a candidate for a rewrite.

3. There was no observability - just logs

When an agent does something unexpected in production, you need to answer five questions within five minutes: which model handled the request, which prompt template, which tool calls were made, what was the user's context, and what did this specific request cost. If your "observability" is a text log of prompts and responses, you're flying blind.

Production agent observability we consider non-negotiable:

• Per-agent, per-model, per-latency-percentile dashboards. CloudWatch + Prometheus + Grafana. You want to see tail latency on the Claude Sonnet path separately from the Haiku path.
• Audit trails on every critical decision. Replayable. Attributable. Regulator-friendly. On Sensei's clinical orchestrator, every agent decision is reconstructable three months after the fact.
• Cost attribution per tenant and per intent. An agent that starts burning $2,000 a day on a single user's query is a bug - you want to see it the first hour, not on the next invoice.
• Prompt regression tests in CI. When someone changes a prompt, you want to see the eval diff before it merges, not after the customer complains.

4. Nobody owned production ownership

The POC was owned by innovation. Production needs owners in engineering, security, ops, and the business unit - and it needs them assigned before the handoff. The fatal moment in most programs is the meeting where innovation says "it's ready for you" and four different people in the room think someone else is going to run it.

When we deliver, we don't leave the room until there's a named owner for: the model fallback policy, the prompt registry, the cost budget, the on-call rotation, the compliance audit cadence, and the eval regression set. If those owners aren't named, we keep running it - and bill for it - until they are.

5. The integration was "left as an exercise"

Many POCs cheat on integration. They use a sandbox account, mock data, or a bolt-on API that looks real enough for the demo. Real integration is where budget and timeline evaporate: TMS integrations require carrier credentials; EMR integrations require HL7/FHIR adapters and clinical sign-off; government integrations require Landing Zone, national identity, and a three-month security review.

At Atlantic Logistics, the agent that processes >70% of inbound documents today passed through four separate integration layers that were never touched in the POC: the carrier email gateway, the OCR preprocessing pipeline, the TMS write-back, and the human-review queue. Each one added weeks; collectively, they defined the production timeline. The POC was done in six weeks. The integration work that made it actually run took four months.

If your POC's integration story is "assume an API exists," the real timeline is whatever your engineering team estimates for that integration, plus the security review, plus the staging rollout. Triple the POC timeline and call it production.

6. Adoption was assumed, not engineered

Six months after go-live, the CFO asks where the ROI is. Answer: it never arrived. The tool shipped, but nobody changed how they work. Dispatchers still pick up the phone first because the agent routing was "too new." Clinicians still document on paper because the new SOP wasn't on their laminated badge reference.

Adoption is not a launch email. It's a program: role-based enablement, rewritten SOPs (the post-AI version of every critical process), champion networks, 30/60/90-day KPIs tied to business outcomes, and a feedback loop back into the product. The budget for this is almost never in the original POC scope - which is why it's almost never done - which is why the ROI slide at year-end shows a flat line.

Our rule: if the engagement doesn't include 12–16 weeks of enablement alongside the build, we won't take it. Without the culture change, the tool we just built becomes a very expensive shelf ornament.

7. The exit criteria were never written down

"When is this POC done?" is a question most POCs never answer in writing. Without exit criteria, the program becomes a trailing cursor: always close, never crossing. The engineering team keeps polishing; the business team keeps asking "is it ready yet?"; and the calendar keeps slipping.

Write the exit criteria on day one. For a POC, that might be: "p99 latency under 1 s at 500 concurrent users; eval accuracy above 92% on the reference dataset; compliance review passed; one named integration endpoint in staging." If you can't name the criteria, you're not running a POC. You're running a research project with a delivery date.

What actually makes the crossing

Here's what we see in the programs that do cross from POC to production:

• Production-first architecture. Observability, fallback, cost controls, compliance - in the earliest diagrams, not in phase 2.
• The same senior engineers from scoping through ship. No relay race between strategy consultants and offshore delivery. The person who scoped the architecture is the person standing up the CI pipeline.
• Measured adoption, not hoped-for adoption. 30/60/90 KPIs tied to business metrics. If the numbers don't move, the program changes.
• Owned production. Named humans for every operational concern before go-live. No handoff without a receiver.
• Written exit criteria. "Done" is a specification, not a vibe.

That's how Brinks's predictive maintenance ended up running across thousands of ATMs. It's how Atlantic Logistics crossed 70% document automation under production SLAs. It's how Apollo ships in 30+ Israeli government hospitals with accessibility, pen-testing, and Landing Zone all green.

If you have a POC that won't cross the finish line, the fix usually isn't more model quality. It's the five things above. Book a discovery call - we'll walk your program through a structured diagnostic, and tell you honestly whether the gap is closable in a sprint or a rebuild.