The Case Against Embedded AI

I believe revenue teams should keep their customer data under their own control and bring the intelligence they choose to it, rather than renting a separate slice of AI inside every product they already pay for. My claim is that most teams have the default backwards. I believe it enough that I built a company on it: Actioner, a desktop app that builds a customer graph on your own machine from your email, calendar, and meetings, and puts it to work inside Claude. So you are reading a partisan. What I can offer is a fair map of the decision: the best case I can make for the path I didn’t take, and the weak points of the one I did.

The spend nobody decided on

Go through your renewal notices from the past year. The CRM added an assistant, priced per seat or, increasingly, per credit. So did the marketing platform, the meeting recorder, the outreach tool, the support desk. Salesforce sells Agentforce, HubSpot sells Breeze, and AI-native products like Clarify are rebuilding the CRM around intelligence from the ground up. Every vendor in the revenue stack is now also selling AI.

Add it up and you are buying what is substantially one capability (frontier-model intelligence, differently wrapped) four or five times over, at a markup each time.

The duplicated spend is the visible cost. The quieter one is what you get for it: five intelligences, each seeing a slice. The CRM’s assistant knows what reps typed into fields. The meeting recorder’s knows what was said on calls. The support desk’s knows the tickets. None of them sees the customer whole. And the customer is the one thing a revenue team most needs seen whole. As the money multiplies, the picture fragments, and your process fragments with it, hopping between five assistants that each hold a piece.

What should give you pause is that almost nobody decided any of this. There was no meeting where the options were weighed. Embedded AI arrives inside tools you already own; procurement is incremental; each add-on looks small next to the contract it rides on; and in most organizations nobody owns “AI” as a question of its own, so the question never gets asked. This is not carelessness: the incentives push every team down this path. Which is why it’s worth stopping to notice that a real choice exists.

Feature or layer

Strip away the product names and there are two postures a team can take.

In the first, AI is a feature. Each vendor bakes intelligence into its own product. You pay for it per product, per seat. The vendor picks the model, decides what it can see, and defines what it can do. Your data, and the context that accumulates around your work, live inside that vendor’s walls.

In the second, AI is a layer. You buy intelligence once, from a model provider (Anthropic, OpenAI, whoever you judge best), but you don’t wire it straight into your tools. Between your systems and the model sits a layer you own: your customer graph, your playbooks, the connections into each system. Your systems feed it, the intelligence works through it, and the data stays where it is. A century ago factories ran their own generators until the grid made power something you buy once and run everything on; this is that question, asked about intelligence.

This is not an either/or choice, and I won’t pretend otherwise. Every team will end up with some of both; increasingly, vendors bundle AI in whether you asked or not. The question is directional: which posture is your center of gravity, and what does the other side have to prove before you pay for it?

What embedded gets right

Inside its own walls, an embedded assistant is hard to beat. It works the day the feature ships, with nothing to assemble. The vendor’s product team studied the job and designed the workflow (the prompts, the affordances, the moments where intelligence should surface), so your reps inherit structure that nobody on your side had to build. It acts with the product’s own permissions and audit trail, so what it writes back is governed by rules your admins already set. And it meets people exactly where the task happens, with no window-switching and nothing new to learn.

Plenty of revenue work really does live inside one product’s walls: scoring and routing leads in the CRM, triaging and drafting replies in the support desk, live coaching inside the call. For tasks like these, embedded is the shortest path to value, and a team whose pain sits squarely inside one product may be right to buy the feature and move on.

The limit is not quality. It is the boundary.

Revenue work, more than most work, runs across products: a deal is emails plus meetings plus tickets plus product usage plus whatever made it into the CRM. The moment a task needs the whole picture, an embedded assistant cannot follow it past the walls of the product it lives in. No vendor roadmap fixes that; it is what being embedded means.

The case for the layer

Four things pull toward the layer, and I think they pull harder than most teams realize.

The whole picture

A customer is one entity, and only a layer that spans your systems can hold one view of it. This is where the fragmentation from those renewal notices comes due: five sliced views of a customer are not worth more than one complete view, no matter how well each slice is dressed.

The economics

There is more to it than paying five times. Look at how embedded AI is actually priced: rarely a number you can forecast. One vendor meters by conversation, another by credits, a third by actions or agent runs. Each is an invented currency, converting to real money at an exchange rate the vendor sets and can revise. The quote looks reasonable at pilot volume; then adoption grows, agents run more often, and the meter compounds across five products at once, each spiking on its own schedule.

Behind those meters sits an awkward cost structure. Embedded vendors buy their intelligence the expensive way (metered, per token, from the model providers) while your team can buy it the cheap way, through the flat subscriptions those same providers price aggressively to win the direct relationship. The same follow-up email costs the vendor more to generate than it would cost you. That leaves each vendor a choice: pass the difference through with margin on top, or eat it to keep the credits looking affordable. Many are eating it, for now. That makes today’s embedded pricing an introductory offer whether the vendor frames it that way or not, with the repricing due to arrive once your workflows depend on the feature. There is also a quieter way to protect the margin: route your requests to a smaller, cheaper model and hope nobody notices. On the layer, you chose the model. Behind a credit meter, you will never know.

To be fair, intelligence costs money everywhere: model providers meter usage too, and heavy use of the layer is not free. The difference is legibility. The layer runs on one meter, denominated in a public unit that a competitive market keeps visible and comparable. Embedded runs on five proprietary meters designed never to be compared, either with each other or with the underlying cost.

You cannot control a cost you cannot see; the layer at least lets you see it.

What compounds

Everything your team invests in making AI useful (the prompts that work, the playbooks, the workflow definitions, the connections into your systems) has to live somewhere. On the layer, it accumulates in one place that belongs to you and moves with you. Spread across embedded products, the same investment is locked to each vendor’s walls and evaporates the day you churn.

Trajectory

The best argument for embedded, that it can see and do things inside the product an outsider can’t, describes the present, and the present is moving. Open connector standards now let a general-purpose model read and act on the same systems the embedded assistant sits inside, and that surface grows monthly. A directional bet should follow the direction of travel.

One workflow, both ways

Take the most ordinary workflow a revenue team has. Customer communications: follow-ups, reach-outs, the daily correspondence that moves deals. Every embedded tool demos this, which is what makes it the right test. The embedded version drafts your follow-up from what lives inside that product. The layer drafts it from the call that just ended, the full history of the relationship, the whole email thread, and what the customer has actually been doing in your product, then writes it in your voice, following a playbook your team encoded once and owns. On the surface, the same email. Underneath, one is a feature exercising its silo, the other is your intelligence working with everything you know about the customer.

Where my side is weakest

Two counterarguments come up in nearly every conversation I have about this, and both deserve a real answer.

The first: doesn’t the layer concentrate everything on one model provider? It does. Dependence in this market is not something you avoid; you choose its shape. Embedded gives you dependence that is deep and plural: data, workflow, and context sunk into each of several vendors, on each vendor’s contract terms. The layer gives you dependence that is single but shallow, if you do the work to keep it shallow: keep your data in systems you control, so the provider connects to it rather than holding it; connect through open protocols rather than proprietary formats, so the integration work is portable; keep your playbooks in plain files you own, not inside anyone’s interface; keep contract terms short, and every so often run your real workflows against a competing model so that switching remains a measured cost instead of a theory. Frontier models are converging enough that, for most revenue-team work, they are substitutable. Done well, this makes the model provider the most replaceable component in your stack, while embedded AI makes intelligence the least replaceable part of every product you rent.

The second is the one I hear most from people who have tried: teams get handed Claude or ChatGPT seats and don’t know what to do with them. Usage plateaus at drafting the odd email, the seats go quiet, and six months later someone calls the pilot a failure. Embedded tools come with the workflows already designed; a general assistant arrives as an empty box.

Everything in that account is true. But notice the comparison it smuggles in: a finished product against a bare chat window. That was never the real comparison. The layer is a foundation, and structure gets built on it, cheaply now. The platforms have grown the primitives that turn an open-ended assistant into a set of buttons: skills, projects, agent definitions, shared playbooks. Describe a workflow in plain language and the model will draft its own structure for it; what once needed a vendor’s product team now takes an afternoon. And ready-made structure is becoming a category of its own: packaged skills, MCP connectors, and products built on top of general assistants that supply the spine while your data stays yours. Closing that gap is the reason my own product exists, so discount me accordingly; but the direction is not subtle. The practical rule for any team starting out: begin from workflows, not seats. Codify your handful of highest-frequency plays before anyone gets a login, and the empty-box problem never appears.

A year in, this objection turns inside out. The structure you built encodes your team’s motion, not a vendor’s generic one, and it is the part of your AI investment that compounds, because it lives in one place and belongs to you.

Embedded tools spare you the empty box by making the structure theirs.

Make it a decision

None of this says embedded AI is bad. It says the default is backwards. Today embedded adoption happens without a decision, and the layer has to fight for consideration; given the economics, the fragmentation, and the direction of travel, the burden of proof belongs on the other side.

Nothing needs ripping out. At the next renewal that arrives with an AI SKU attached, ask one question: what does this feature see, or do, that our own layer structurally cannot, and will that still be true in a year? When there is a real answer, pay for the feature without guilt. When there isn’t, you have just found the budget for the layer, and the first workflow to build on it.