What “AI‑native” actually means in a marketing ops stack

I have lost count of the number of vendor calls this year that opened with the phrase “we are AI‑native.” In most cases the product on the other end of the call was the same product it was eighteen months ago, with a chat box bolted onto the left rail and a new pricing tier on the website. The label is doing more work than the architecture is.

The phrase is worth taking seriously, because there is a real version of it. There are a small number of marketing tools right now that were genuinely designed around the assumption that an LLM would be inside the loop, and they behave differently in production than the retrofits do. The retrofits are not bad - some of them are even useful - but pretending they are the same thing as the ground‑up rebuilds is going to cost teams real money over the next two years.

The retrofit pattern

A retrofit looks like this. The vendor took an existing product - a marketing automation platform, a CRM, a CDP, a reporting tool - and added a feature called something like “Ask” or “Assistant” or “Copilot.” The feature lives in a sidebar. It can answer questions about the data the product already had, generate copy for the templates the product already shipped, and occasionally produce a workflow that the product already supported.

None of this is bad. Some of it is genuinely useful. But notice what the architecture is doing. The data model has not changed. The permissioning has not changed. The audit log, where one exists, was not designed to record actions taken by a model. The workflow engine still treats every step as deterministic and every input as user‑typed. The chat box is a thin layer over the same product, with no plumbing underneath it that knows the difference between something a person did and something the model did on a person’s behalf.

In practice this surfaces in three ways. The first time something goes wrong, nobody can tell whether the model or the marketer changed the field. The second time something goes wrong, the audit log says a user did it, because the model is acting as the user. The third time, the team quietly turns the feature off, because the cleanup is more expensive than the speed.

What an actually AI‑native stack looks like

The handful of tools that were built ground‑up around an LLM behave differently in a few places that matter. The data model has a notion of provenance - every record knows whether a human, a deterministic workflow, or a model produced it, and that label survives downstream syncs. The permissioning model gives the model its own identity, with its own scopes, its own rate limits, and its own off switch that does not also turn off the rest of the product. The audit log records model actions distinctly from user actions, with the prompt or rule that produced them attached.

Workflows in these tools have an explicit “model step” primitive that is not the same as a deterministic step. The step has a defined input contract, a defined output contract, and a fallback path for when the output does not validate. A retrofit, by contrast, will let you drop a free‑text “generate copy here” action into a workflow with no contract on either side and no defined behavior when the model returns something off.

None of this is glamorous. None of it shows up in the demo. It is also the difference between a stack you can run for two years without growing a long tail of unexplained data and a stack that grows that tail in the first quarter.

Why the distinction matters operationally

If you are evaluating a vendor right now, the marketing material is not going to help you tell these apart. Both kinds of products will say “AI‑native” on the homepage. The way to tell, in practice, is to ask three questions on the demo call.

Show me the audit log entry for an action the model just took. If the answer is “it looks like a normal user action,” the model has no identity. The product is a retrofit.

Show me what happens when the model returns something the workflow cannot use. If the answer is “the workflow proceeds with whatever it got,” there is no contract on the model step. If the answer is “the workflow halts and routes to a named fallback,” somebody designed for failure.

Show me how a customer revokes the model’s ability to write to a specific field without revoking the rest of the integration. If the answer involves “that is on the roadmap,” the permissioning model is the old one with a chat box on top.

These three questions take about ten minutes on a demo and they will sort the field faster than any analyst report.

Where this leaves the buyer

Most teams do not need to be on an AI‑native stack today. Most teams need their existing stack run with discipline, with AI applied selectively at the points where it actually compresses meaningful work. (An older post on where AI belongs and where it does not is here.) The stack you already own is almost certainly enough to operate well, and replacing it on the basis of a label is the kind of decision that looks fine at signing and expensive at the eighteen‑month mark.

When the time comes to replace something, do it because the thing you have stopped earning its keep on the actual work, not because a competitor has a better‑looking sidebar. The architecture underneath the sidebar is what you are going to live with.

If you want a read on what your current stack is and is not capable of, we do that work. The conversation is short and starts with what you already own.