Earlier this year a report out of MIT became the most-screenshotted slide in enterprise software: of the generative-AI pilots companies had funded, roughly 95% showed no measurable return on the P&L. Gartner had already forecast that at least 30% of generative-AI projects would be abandoned after the proof-of-concept by the end of 2025. Read those two numbers next to each other and a pattern falls out. The money is not being lost on AI that does not work. It is being lost on AI that works fine in a demo and never makes it into a system anyone actually uses.
This is the context in which a whole category was invented: the AI implementation company. The pitch is clean. You have a business. AI is happening to your business whether you like it or not. You are not an AI expert. Therefore you should hire the people who are — a dedicated AI implementation company — and they will assess, strategize, pilot, and transform. It sounds like the responsible thing to do. It is mostly how you join the 95%.
The category is a marketing wrapper, not a discipline
Here is the thing the brochures get backwards. "AI implementation" is not a new discipline that requires a new kind of firm. The hard part of putting a large language model into production is not the model. The model is a hosted API you can call in an afternoon. The hard part is everything around it: the data pipeline that feeds it, the retrieval layer that grounds it, the evaluation harness that tells you when a change made it worse, the monitoring that catches it drifting, the guardrails that stop it from confidently saying something wrong to a customer, and the maintenance commitment to keep all of that alive after the launch press release. That is not AI work. That is software engineering. It has been software engineering the whole time.
Which is why the firms that spun up an "AI practice" in 2023 and rebranded as an AI implementation company tend to stall at exactly the same place: the proof-of-concept. A PoC is the part of the job that looks like AI and feels like magic. It demos well to a steering committee. It is also the cheap 10% of the work. The expensive 90% — wiring it into real data, surviving real load, passing real security review, and not degrading the week after a model provider silently ships a new version — is the part that requires people who have shipped and operated production software for years. A strategy deck does not survive contact with a vector database that is returning garbage at 2 a.m.
Pilots don't die from a lack of AI. They die from a lack of engineering.
Walk back through any stalled AI initiative and the autopsy almost never reads "the model wasn't smart enough." It reads: the data was never cleaned, so retrieval was noise; nobody built evaluations, so no one could prove the thing was good enough to trust; there was no monitoring, so the first sign of failure was an angry customer; the proof-of-concept was built by people who had no intention of operating it, so handover was a cliff. These are the failure modes of teams that can prototype but cannot productionize. They are endemic to the AI-implementation-company model precisely because that model optimizes for the demo, which is what gets the next contract signed.
I run a boutique software engineering studio, and I will tell you what production AI actually looks like, because we have been shipping it for the past couple of years and we run our own company on it. We built an internal assistant on Claude that answers two to three hundred questions a week from the team. Early on it helpfully surfaced the company-wide vacation schedule before HR had published it. That is the moment that matters — not the demo, the failure. We added guardrails. That unglamorous loop — ship, watch it fail in a small way, instrument it, constrain it, ship again — is the entire job. A firm whose deliverable is a PoC never reaches the loop, because the loop starts after the part they get paid for ends.
What "implementation" actually means once you're honest about it
Strip the word of its consulting gloss and implementation means: this thing runs, in production, against real data, and someone is on the hook when it breaks. For a retrieval-augmented system that is a real data pipeline, a vector store you have actually tuned — Pinecone, Qdrant, pgvector, whatever the data demands — and an evaluation layer using something like Langfuse or LangSmith so that "it seems better" becomes a number you can defend. It means the DevOps is owned by the people who wrote the application code, not thrown over a wall to a separate department who learned about the project at launch. None of that is exotic AI knowledge. All of it is the ordinary competence of a team that ships software for a living.
We built a generative-AI application for an entertainment client that reads screenplays and generates visual scene compositions — work that used to take a sketch artist months, compressed into minutes. The interesting part of that engagement was never the model selection. It was the document processing, the structuring of messy script input, the prompt and retrieval scaffolding, and the plumbing that made it reliable enough to put in front of a paying user. The AI was one layer. The other layers were the reason it shipped instead of sitting in a slide titled "Phase 2."
How to tell a builder from a deck-merchant
There is a fast diagnostic when a vendor calls itself an AI implementation company. Ask what they were doing before 2023. If the honest answer is "we were a software engineering team and we added AI to the stack," good — they know how to operate the 90%. If the answer is some version of "we were founded to do AI transformation," be careful: you may be buying a team whose oldest production system is younger than the problem you are trying to solve. Then ask the unsexy questions. Who reviews the code? What does your evaluation setup look like? How do you catch a model regression? Who is on call when it breaks? Watch how fast the conversation retreats from these toward roadmaps and value frameworks.
Ask, too, how they decide what AI tools to use, because the deck-merchants adopt everything that trends and the builders are ruthless. We run a quarterly review of new tooling and reject somewhere between 60% and 80% of what we evaluate — either the adoption cost is too high or it does not beat what we already run. AI coding tools like Claude Code and Cursor are reviewed accelerators in our shop, not crutches, and every pull request is still reviewed by at least one other senior engineer before it merges. A vendor who treats AI as a magic input rather than a tool that has to earn its place will build you something that demos beautifully and rots quietly.
Production AI is a maintenance problem, which is a people problem
Here is the part the implementation pitch never mentions: the launch is the cheap day. The model you integrate this quarter will be deprecated, repriced, or quietly changed. Your retrieval quality will drift as your data grows. Your guardrails will meet an input nobody imagined. An AI system is not a deliverable you accept and walk away from; it is a living thing that needs the same team watching it month after month. Which makes the staffing model the whole game. If your AI implementation company staffs your project with rotating contractors who churn out and take the context with them, you do not have an implementation partner. You have a body shop with a better noun.
This is where I will plant a flag from experience rather than theory. Our engineer turnover runs under 5% a year against an industry norm well north of 20%, average engineer tenure is around eight years, and our average client engagement is about four. That is not a recruiting brag — it is the only structural reason a production AI system stays healthy. The person who tuned the retrieval in March is the person debugging the regression in November. Continuity is not a nice-to-have for AI work; it is the difference between a system that compounds and one that quietly degrades until someone proposes a rewrite. The category called "AI implementation company" is largely silent on this, because churn is its operating model.
For the category-level version of this argument, what AI consulting really is is the place to start. Our AI engineering services cover the engineering side we actually sell.
What to actually buy
So commit to the position: do not go shopping for an AI implementation company. Go shopping for an engineering team that ships and operates production software, has added AI to its stack deliberately, and will still be the same team in two years. The AI competence you need — RAG, agents, evaluations, the model landscape — is real and learnable, and a serious engineering team has already learned it, the same way it learned databases and cloud infrastructure. What you cannot fake or contract around is the boring half: the discipline to put a thing in production, instrument it, maintain it, and own it when it breaks. That is the half the 95% skipped, and it is the half that decides whether your project becomes a line item or a capability.
The label is not the danger. Plenty of competent engineering shops, mine included, will happily put "AI implementation" on the proposal because that is the phrase you typed into the search bar. The danger is buying the label as if it were a discipline — paying for a team that exists to demo AI rather than one that exists to ship software. AI is not the hard part anymore. Shipping never stopped being the hard part. Hire for the hard part.