Services Dressed Up as Software: How to Tell Real AI Embedding From Theater

In June 2025, Gartner published a prediction that should give any buyer of embedded AI pause: more than 40% of agentic AI projects will be canceled by the end of 2027, undone by escalating costs, unclear business value, or inadequate risk controls. In the same analysis, Gartner estimated that of the thousands of vendors claiming to sell agentic AI, only around 130 are the real thing. The rest are doing what it called “agent washing” — rebranding chatbots, robotic process automation, and assistants as autonomous agents.

That is the market a buyer now walks into. The first two pieces in this series covered what the forward-deployed model is and why its economics keep it at the enterprise tier. This one is about the problem that shows up once you are actually in a sales conversation. By 2026 almost every AI vendor will offer to “embed” with you, and the word has stopped meaning much. The hard part is no longer finding someone willing to sit inside your operation. It is telling real embedding, where engineers build software you can run, from a services contract wearing a software logo.

What real embedding is, and what the theater looks like

The genuine article has a specific shape, which the first piece described: a forward deployed engineer learns your problem in place and writes production code against it, and what’s left behind is a system that generalizes — something your next process, or the vendor’s next customer, can build on. The value lives in the running software, not in the person who installed it.

The theater looks nearly identical from the outside and is structurally the opposite. The engagement produces bespoke configuration that works only for you, needs a vendor employee to touch it every time anything changes, and never hardens into a product. Pull the vendor out and the capability leaves with them. This is the critique that has trailed the model since Palantir’s early days: that it is glorified consulting, a services business dressed up as software. Writing for Constellation Research, the analyst Larry Dignan names the failure mode “consulting disguise” — embedding that blurs the boundary between software and services precisely because the software underneath isn’t finished. First Round Review’s diagnostic for founders frames the same line from the buyer’s side: if an engagement is endless custom iterations with no generalizable product on the other end, what you have is a labor arrangement, not a capability.

Both kinds of vendor will say “we embed.” Telling them apart comes down to asking the right questions and listening for the answers a theater vendor can’t give.

The seven questions

The first piece sketched four of these. Here is the fuller version, with what a strong answer sounds like and what should worry you. The most useful ones are not about the technology. They are about what you are left holding when the engagement ends.

1. What is the explicit endpoint? Real embedding is time-bounded and points at a defined state where you operate on your own. A vendor who can describe that state has thought about your independence. The red flag, which Constellation Research lists first, is an engagement with no exit criteria — one engineer per use case, indefinitely. That is a staffing contract, not an implementation.

2. What stays when the team leaves? Ask to see the documentation, runbooks, and knowledge-transfer plan. The due-diligence firm Trustible puts it sharply: a vendor that cannot produce structured documentation of what it built, on demand, is a governance risk by definition. If the only record of how your system works is in a contractor’s head, you do not own the system.

3. How do we run this without you? A real vendor can articulate the path to you operating independently. A theater vendor gets vague here, because indefinite dependence is the business model. The question is not hostile; a confident embedding partner answers it readily.

4. Are you redesigning the workflow or patching it? Constellation Research draws the distinction between engineers who redesign a process around what AI can now do and “glorified integrators” who bolt AI onto the process you already have. Patching is faster to demo and far less durable. Redesign is the harder, more valuable work, and it is what you are supposedly paying an embedded team to do.

5. What proves our team is gaining capability, not dependency? Ask what they measure. A vendor invested in your independence tracks skill transfer: your people taking over tasks, your team shipping changes without them. A vendor that measures only its own ticket volume is building a dependency and calling it a relationship.

6. What are the failure modes, and what happens when the model is wrong? Every honest AI vendor can name the limits of its system and describe what happens at the edge cases. Be especially wary of outputs that arrive with no source references and no confidence signals. An answer you cannot trace is an answer you cannot trust, and a vendor who treats that as a non-issue has not thought about your liability.

7. Who is accountable when the AI is wrong? Pin down where responsibility sits when an agent makes a costly mistake in production. This is no longer just an ethics preference. The insurer Aon notes that regulators and courts now weigh the adequacy of governance and oversight at the time of deployment, which makes “who is accountable” an underwriting question as much as a moral one. (The regulatory side of this gets its own piece later in the series.)

The one test that cuts through everything

If you ask only one thing, ask this: if the vendor walked out tomorrow, what would you still have? A real embedding leaves you a documented, operable system. Theater leaves you a phone number. Constellation Research frames the danger as vendor lock-in, where embedded teams “create dependency relationships that increase switching costs,” and hidden costs that “become permanent liabilities rather than temporary implementation resources.”

The clearest cautionary tale doesn’t come from AI yet. It comes from the previous generation of embedded enterprise work. In September 2025, Zimmer Biomet sued Deloitte for $172 million over a botched SAP S/4HANA implementation, alleging Deloitte misrepresented its capabilities, assigned underqualified personnel, and concealed system defects, leaving the company barely able to operate. Deloitte disputes the allegations and the matter is unresolved, and it is an ERP dispute, not an AI one. But the failure pattern is the embedded-vendor dependency risk in miniature: personnel quality the buyer couldn’t verify, defects it couldn’t see, and a system it couldn’t run without the vendor. Swap the ERP rollout for an agentic workflow and the shape is identical.

The red flags, in brief

Most of the warning signs are the inverse of a good answer above. Collected in one place, the ones worth memorizing:

• No exit criteria. The engagement is described as permanent or open-ended, with no point at which you operate alone.
• No documentation on demand. The vendor can’t show you, in writing, what it built and how it works.
• Headcount that grows in a straight line. One embedded person per use case, with no sign that the work is hardening into reusable tooling.
• A demo that doesn’t survive contact. Polished in the sales meeting, brittle on edge cases, ambiguous inputs, or repeated queries.
• Answers with no provenance. AI outputs that carry no sources and no confidence indicators.
• “The model handles it.” Any time review, accountability, or failure handling is waved away as the model’s job, the risk hasn’t been managed. It has been hidden.

Two honest caveats

First, there is no published study that measures how often embedded-AI vendors turn out to be real versus theater. The criteria above are heuristics drawn from named analysts and vendor due-diligence frameworks, not empirical findings about vendor quality. Use them as a way to structure the conversation, not as a score.

Second, none of this is an argument against embedding. Done properly, putting people who understand the technology inside your actual workflow is the most effective way to get AI into real work, which is the whole point of the first piece in this series. And even a real embedded team does not make adoption painless: the organizational work of changing how people operate doesn’t disappear, it shifts onto the team you brought in. The goal of the diligence is not to avoid embedding. It is to make sure you are buying the real thing, with the artifacts and the independence that distinguish a capability you own from a dependency you rent.