by Advik Jain, Founder, Optivus Technologies
The most expensive moment in any enterprise AI program is the one where the CTO realizes the pilot won't ship. It rarely happens in a steering committee. It happens quietly, in a 1:1, when the CTO realizes that the architecture they greenlit nine months ago has no path to production, that the consulting partner who sold "AI transformation" has produced sixty slides and a demo notebook, and that the budget they spent could have funded an actual engineering team to build the actual thing.
I have watched this moment happen, in different rooms, in different industries, across the last three years. The pattern is consistent enough now that I think it deserves a name. What most of the AI consulting industry has been selling, and what most enterprises have been buying, is theater. The strategy decks, the capability matrices, the centers of excellence, the use-case prioritization workshops, the pilot programs that win internal innovation awards and never go to production: all of it. Theater.
This piece is about the difference between theater and the work that actually ships.
The shape of strategy theater
There is legitimate strategy work. Market sizing, opportunity assessment, technical due diligence, regulatory review. What I am calling theater is strategy that produces no shipped artifact, not strategy as a category.
Strategy theater has a recognizable shape. Anyone who has been in the room will see five patterns repeat.
The eight-week capability assessment. A consulting partner is engaged to "assess AI readiness." Eight weeks later, they deliver a deck. The deck contains a maturity matrix, a benchmark against unnamed peers, a list of use cases ranked by perceived business value, and a recommended next phase. The next phase is another engagement. The artifact produced is the deck. No system has been built. No code has been written. The clock and the budget have moved.
The Center of Excellence with no shipped product. A line is added to the org chart. A director is hired. A quarterly all-hands is scheduled. The CoE produces a strategy document, a vendor evaluation framework, and a quarterly newsletter. Eighteen months in, the question of what the CoE has actually shipped is met with a slide showing "enablement initiatives" and "cross-functional alignment." The CoE is real. The shipping is not.
The pilot that wins an award and dies in Q2. A pilot is built. It works in the demo. It is presented at the company's innovation showcase. It wins a budget for "scale-up." Six months later, the scale-up is quietly descoped. The pilot's data was synthetic, the integrations were mocked, and the production environment looks nothing like the demo environment. Nobody is fired. The pilot remains a case study on the consultant's website.
The capability matrix that ranks the wrong axes. Enterprises evaluate AI partners against a list of capabilities that look rigorous. Model accuracy on a public benchmark. Number of certified consultants. Vendor partnerships. The matrix never asks the questions that determine whether the system will survive production. Operational maturity. Runbook discipline. Production tenure of shipped systems. Postmortem culture. The wrong axes get scored. The right partners lose to the wrong ones.
The roadmap with no engineering input. A list of forty AI use cases is generated in a workshop with business stakeholders. The use cases are ranked by business value. The list becomes the roadmap. Engineering is brought in afterward, told to implement, and informed that timelines are non-negotiable because the board has already seen the slide. Use cases that should have been killed in week one survive for nine months because nobody with a CS degree was in the prioritization meeting.
Each of these patterns has a cause. Consultants are paid by the hour, so producing a system that requires ten hours of consulting is worse for them than producing a strategy that requires a thousand. Boards have AI FOMO and fund anything labeled AI, so the incentive to actually ship is dulled. The press ecosystem covers announcements rather than running systems, so the marketing return on theater is high and the marketing return on shipping is low.
The cost is real. The strategy theater dollar is the most expensive dollar in an enterprise AI budget, because it produces no shipped artifact and consumes the budget that would have funded the team that could have built one. The opportunity cost is twelve to eighteen months of inaction during the most consequential platform shift in a generation. The reputational cost is a CTO who has to explain to their board why the company is two years into AI and still cannot point at a system in production.
What shipping AI to production actually looks like
The work that actually ships AI to production looks nothing like the work that produces strategy decks. AI work is software work. The discipline that puts a model into production at scale is the same discipline that puts any production system into production at scale: queues that don't lose messages, retries that handle transient failures, observability that lets you debug at 3 AM, audit trails that survive an external auditor's questions, runbooks that an on-call engineer can follow without paging the architect.
The model is twenty percent of the work. The eighty percent is everything around the model. Most of the AI-native consultancies minted in the 2023 to 2025 hype cycle have never shipped production software at meaningful scale, so they don't see the eighty percent. They write strategy decks because they have nothing else to sell.
I call the alternative production discipline. It is the operating doctrine that makes the eighty percent visible, plannable, and shippable. Here is what it contains, in language drawn from systems we run.
Architecture and reliability
A worker pool that isolates long-running jobs from the fast path. Some vendor invoices parse fast. Others, the image-heavy PDFs, the scanned receipts, the multi-page bills with unusual templates, take an order of magnitude longer. If both run on the same worker pool, the slow ones throttle the fast ones, daily throughput collapses, and the controller's morning report arrives late. Our Flowfin queue isolates long-running parse jobs on a separate worker pool, so the fast path stays fast and the slow path cannot block it. This is unglamorous infrastructure work. It is also the difference between an AP automation that scales and one that quietly buckles the first month a client adds a vendor with a difficult invoice format.
Confidence routing that knows the difference between "the model is sure" and "the model has never seen this case." Production AI systems do not output a single number labeled "accuracy." They output a confidence distribution. The job of the system is to route the high-confidence cases through automation and the low-confidence cases to a human who can resolve them. The threshold is not a constant. It depends on the cost of a false positive in the specific domain, which means the threshold is a product decision, not an engineering one.
Failure modes that degrade gracefully. When a downstream API is down, the system shouldn't crash. When a model returns garbage, the system shouldn't ship the garbage. When a user submits an edge case, the system should know it's an edge case. Graceful degradation is engineering work, not strategy work. It cannot be designed in a workshop.
Data integrity
Reconciliation that catches what the model cannot see. The model's job is to extract the data from the invoice. Reconciliation is the layer that catches the problems the data alone will not show.
Take three-way matching as the canonical case. A vendor invoices for a quantity at a unit price. The PO authorized a different quantity, or the goods receipt logged a different number delivered. The model extracts all three documents accurately. The reconciliation pass surfaces that the invoice quantity does not match what was actually received, and the system holds the invoice for human review before it reaches AP's payable queue. The model did its job; the reconciliation layer did the work that mattered.
Duplicate detection is the other half. Vendors regularly submit the same invoice through more than one channel: an email to AP, a portal upload, a paper copy that gets scanned the next morning. Each copy parses as a valid invoice. The model has no way to know the other two exist. The reconciliation pass matches on vendor, invoice number, amount, and date, surfaces the duplicate, and flags it before AP cuts a duplicate payment.
Audit trails that survive an external auditor. In a regulated content environment, every output the system generates has to be defensible against a single question: why did the system cite this source for this claim? The answer cannot be "the model decided." That answer does not pass an audit.
Veritas is built so that every piece of generated content is traceable. Every claim has a citation. Every run is logged with the graph traversal, the source ranking, and any human review that touched the output. When a controller, an editor, or a compliance officer asks why a specific piece of content cited a specific source, the answer is in the logs, not in the model.
Most AI content systems can show you the prompt and the output. They cannot show you why.
Operations
Observability you can debug at 3 AM. When a controller asks why your AI system made a specific decision on a specific invoice three weeks ago, you need to answer in minutes, not days. That requires logging at every step of the pipeline, structured well enough that an engineer who didn't build the system can reconstruct the decision. Most AI systems shipped by AI-native consultancies don't have this. The first time the controller asks the question, the consultancy answers with a meeting.
Cost monitoring that catches a runaway loop before it bills tens of thousands in tokens. Production AI systems can fail expensively. A retry loop that doesn't terminate, a recursive agent that doesn't bound its calls, a prompt that includes the entire production database. The systems we ship have budget alerts wired in at the inference layer, not the billing layer, because by the time the bill arrives it is too late.
This is what shipping AI to production actually means. The wall is real for everyone who tries to scale it. Cohere and Scale hit it on the AI-native side. McKinsey QuantumBlack hits it on the consulting side. We hit it on the systems-shop side. The wall is the reason production AI is hard. It is also where the value lives. It is also the reason the people who can clear it are scarce.
Seven questions to ask any AI consulting partner
If you are an enterprise CTO evaluating AI partners, the questions you ask in the first sales conversation determine the quality of the engagement that follows. Most of the questions in capability evaluations are wrong. They reward strategy theater and penalize production discipline. Here are seven questions that filter for production discipline. Any partner worth signing can answer them in detail. Any partner not worth signing will pivot, deflect, or talk about case studies they read in someone else's blog.
1. Walk me through what broke in the first 90 days of a system you've shipped, and how you handled it.
This is the question that separates partners who have shipped from partners who have demoed. Real production systems break in the first 90 days. The model encounters edge cases the training data didn't cover, the integrations behave differently in production than in staging, the volume is higher or the latency is tighter than the demo accounted for. A partner who has shipped can tell you exactly what broke and exactly how they fixed it. A partner who hasn't will give you a generic answer about "iterative improvement."
2. When your model's confidence drops below threshold, what happens? Who sees it, how fast, and what's the resolution SLA?
Confidence routing is the single most important architectural decision in any production AI system. The answer should include a specific threshold, a specific escalation path, a specific human in the loop, and a specific resolution time. If the answer is "the model handles it," the partner is selling autonomy in a context where you needed handoff design.
3. Walk me through your retry logic when the destination API rate-limits or returns 5xx for an extended window.
This is the production-readiness question. The answer should include a queue strategy, a backoff strategy, a poison-message handling strategy, and a guarantee about no records being dropped. If the answer is hand-wavy, the system will lose data the first time the destination has a bad afternoon.
4. Show me a runbook for a system you've shipped. Who owns it when something breaks at 3 AM, and what does the on-call rotation look like?
Production systems have runbooks. The runbook is a real artifact. If the partner can't show one, the system they ship will not have one, and the on-call burden will fall on your team the moment the partner's engagement ends.
5. Can your client's controller defend the output of your system in front of an external auditor without your help?
This is the auditability test. In any regulated environment, the partner's involvement is not a permanent state. The controller has to be able to defend the system's behavior independently. If the partner has not designed for that, the system creates compliance debt that the controller will eventually have to clean up.
6. What does the handoff to my team look like in month 12? What documentation, what training, and what does ongoing maintenance cost when you're no longer the primary builder?
This is the lock-in test. The right answer involves comprehensive documentation, knowledge transfer, and a defined ramp-down where your team takes over. The wrong answer involves a perpetual managed-service contract that your team can never escape.
7. What does total cost of ownership look like in year two and year three? Walk me through the maintenance burden, the model retraining cycle, and the cost predictability of running this in production for the long haul.
This is the long-term cost question. Most AI engagements price the build but not the run. The cost of operating an AI system in year three is typically dominated by maintenance, retraining, and the inference bill, not the original engineering. A partner who can walk you through their TCO model in detail has thought about it. A partner who pivots to "we'll figure that out together" hasn't.
These seven questions are the framework. Lift them, copy them into your next vendor evaluation, ask them in the first conversation. They will tell you in thirty minutes what a six-week RFP would not.
Why I am writing this
I started Optivus because of a pattern I kept seeing in my last role. I spent 2022 to 2024 on the intelligent automation team at a Big 4 firm, working on AI implementations for enterprise clients during the period when generative AI was reshaping every conversation in every boardroom in India. The work taught me a lot about how enterprise AI actually gets built and what determines whether it survives production.
It also taught me that the model where a consulting firm builds a system, hands it to the client, and walks away does not produce systems that last. The handoff is where most of these systems die. By 2024, when the generative AI wave was clearly the platform shift of the decade, I wanted to build a firm that did the opposite: stay close to the systems we ship, run our own products on the same discipline we sell, and treat the handoff as the beginning of the work rather than the end. That is Optivus.
We run four products, all live with customers in their production environments. Flowfin runs end-to-end Procure-to-Pay and Order-to-Cash for enterprises processing thousands of transactions a month. Veritas powers knowledge graph-based content generation in regulated environments where citations have to survive audit. Janus runs in recruitment workflows where a wrong match costs more than a missed match. Canary is an AI chatbot for websites that customers set up in under five minutes, with a knowledge base we manage end-to-end.
Each product is itself the proof: we don't theorize about shipping AI to production, we ship it, in our own products, every quarter.
Two kinds of firms will come out of this decade. The ones that shipped systems that survived their first ninety days, their first audit, their first 3 AM page. And the ones that produced the most polished decks. There is no third category.
If you are an enterprise CTO reading this, the question I want you to ask in your next vendor meeting is simple: show me the system. Not the strategy. Not the slide. The system.