When a model provider ships a feature that was your entire product, the reflex is to ask whether you are a layer or a moat. That is the right instinct and the wrong test, because it is a binary applied to something continuous. The useful framing is a radius: a perimeter inside which a platform can ship your capability in one release cycle. Everything inside gets absorbed. Everything outside gets more valuable, because the platform just made the thing sitting on top of your data cheaper and better. The question is not which category you belong to. It is whether your feedback loop closes, how fast it closes, and whether it closes per customer or globally.
This expands on a post I published on LinkedIn after Anthropic gave Claude its own Slack account.
Key Takeaways
- The platform is not eating products. It is eating thin layers. A wrapper, a connector, and memory implemented as a rolling summary all ship in a single release.
- The same release that destroys a thin layer makes a defensible position worth more. Cheaper, better intelligence sitting on top of proprietary data increases the value of owning that data.
- "Layer or moat" fails as a test because it describes a position rather than a mechanism. Positions get copied. Loops compound.
- The mechanism is loop closure: what fraction of decisions return a measured outcome, how quickly that outcome changes behavior, and whether the improvement is per customer or global. Global improvement is replicable by anyone with the same model.
- Most tools that log outcomes globally and call it learning do not have a flywheel. They have a changelog.
- For buyers, this is a procurement test, not a philosophy. Ask a vendor whether their system gets better for you specifically, and ask them to show the cohort curve that proves it.
What Happened: Claude Got Its Own Slack Account
In June 2026 Anthropic introduced Claude Tag, which gives Claude an identity inside Slack rather than a chat window beside it. Per Anthropic's own product page, you tag @Claude into any thread and it "reads threads, understands full context, and reacts in real time," summarizing discussions, pulling analytics, drafting pull requests. It shipped in beta for Claude Enterprise and Team customers, with Microsoft Teams listed as coming soon.
A few dozen "AI for Slack" startups went on red alert that week, and the reaction was rational. If your product was a thin conversational surface over Slack, a platform just shipped your roadmap as a feature.
But the panic proved too much. Plenty of companies adjacent to that release were made better off by it, and not by luck. The distinction between the two groups is structural and you can work it out in advance.
The Platform Eats Thin Layers. It Boosts Whatever It Cannot Reach.
Only the first half of that sentence gets discussed, and the second half is where the money is.
Inside the radius are the things a platform can implement generically because they require nothing it does not already have. A Slack wrapper is a thin layer. A connector is a thin layer. Memory implemented as a rolling summary is a thin layer. Each of these is a Tuesday release. None of them requires the platform to know anything specific about your customer, so none of them is protected by anything except the platform's attention, and attention is exactly what a release cycle spends.
Outside the radius are proprietary data, domain depth, and system-of-record status. These are not safe because they are hard to build, though they are. They are safe because the platform cannot reach them: it does not have your customer's five years of spend history, their taxonomy, their approval rules, or the record that other systems treat as authoritative.
Here is the part that inverts the panic. When the platform makes reasoning cheaper and better, it raises the value of everything that reasoning gets pointed at. If you own the system of record, a better model is not a competitor. It is a free upgrade to your product, delivered by someone else's research budget. The same release that vaporizes a wrapper makes a data-owning company more valuable on the same day. That is why the reflex to ask "am I about to be killed" is less useful than asking which side of the perimeter your value actually sits on. It is also the argument behind our view that marketing data integrations are the real AI moat: the model is the commodity, the pipes and the governed data underneath are not.
Why "Layer or Moat" Is the Wrong Test
The binary fails for a specific reason: it describes where you are standing rather than what you are doing.
A position can be described in a sentence, and anything that can be described in a sentence can be copied by a well-funded team in a quarter. "We have proprietary data" is a position. So is "we own the workflow." Both are true of companies that got absorbed anyway, because a static advantage is a snapshot and snapshots get matched.
What does not get matched is an advantage that grows as a function of use. If your system improves every time a customer makes a decision with it, then a competitor starting today does not need to match your current state. They need to match your accumulated state, and they need to do it while you keep accumulating. That is the difference between a wall and a flywheel, and it is why the question has to be about mechanism.
This is also why "we have a lot of data" is not the answer people think it is. Data volume without a closed loop is storage. The relevant question is whether outcomes come back and change behavior.
The Real Test: Does Your Feedback Loop Close?
Three properties determine whether a loop is a moat or a changelog, and all three are measurable rather than rhetorical.
Coverage. What fraction of the decisions your system influences come back with a measured outcome attached? Most tools influence far more decisions than they ever learn from. If a recommendation is made ten thousand times and the result is recorded eighty times, the loop is technically closed and practically open.
Latency. How long between an outcome occurring and that outcome changing what the system does? A loop that closes quarterly is a report. A loop that closes in a day is a control system. The gap is where competitors live.
Specificity. This is the one that decides defensibility, and it is the one most often faked. When your system learns, does it get better for this customer, or better for everyone? Global improvement feels like progress and is worth very little strategically, because anyone with the same base model and a similar corpus can reproduce it. Per-customer calibration, tied to that customer's own history and rules, cannot be reproduced by a competitor who does not have that history. Most "agentic" tools log outcomes globally and call it learning. That is not a flywheel. It is a changelog.
There is a fourth property worth naming because teams throw it away: override capture. When a human corrects your system, is that correction logged as signal, or discarded as an exception? Overrides are the highest-value data you will ever receive, because they are labeled failures from the exact distribution you serve. Systems that treat them as noise are throwing away their moat to keep their dashboards clean.
I laid out the full six-axis version of this test, including the cohort proof, in The Kill Radius on my Substack. What follows here is the buyer's side of the same argument.
Talk to an Improvado expert about running marketing AI on data and context your team owns.
The One Honest Proof
Everything above can be asserted by any vendor. Only one thing is hard to fake.
Plot your customers by vintage. Take a cohort that has been live for two years and a cohort live for two months, hold data volume roughly constant, and compare performance on the same task. If the older cohort is meaningfully better, something is compounding that new data alone does not explain, and that something is your loop. If the two cohorts perform the same once you control for volume, then you do not have accumulated calibration. You have a product that works equally well on day one and day seven hundred, which is a fine product and not a moat.
That curve is worth more than the other properties combined, because it is the only one that measures the outcome rather than the intent. A vendor can describe a feedback architecture in a slide. Producing a vintage curve requires the architecture to have actually worked for years.
What This Means If You Are Buying Marketing AI
Most of this discussion is aimed at founders. The buyer's version matters more, because you are the one who absorbs the cost when a vendor turns out to be inside the radius.
When a vendor sits inside the radius, you do not usually get a dramatic failure. You get a slow one. The product stops differentiating from a general assistant, roadmap velocity drops as the team pivots, pricing gets defended rather than justified, and eventually you are paying for a wrapper around a model you could call directly. The switching cost lands on your team, and it lands at the worst time.
Four questions worth asking in an evaluation, all of which have concrete answers:
Does it get better for us specifically, or for everyone? Ask what the system knows about your account that it does not know about any other account, and how it learned it. Vague answers here are the answer.
What happens to our corrections? When your team overrides an output, ask where that goes. If the honest answer is a support ticket, the loop is open.
Show me the vintage curve. Ask whether longer-tenured customers outperform newer ones on the same task at similar data volume. Vendors with real compounding are usually pleased to be asked. Vendors without it will reframe the question.
Who owns the context if we leave? If the taxonomy, metric definitions, and accumulated corrections live only in the vendor's system, you have rented your own institutional memory. Owning that layer is what keeps the choice of model a choice.
That last one connects to a failure mode we have written about repeatedly. Agents that hold no durable organizational context have to be re-briefed constantly, which is a cost you pay three times over, and when several of them each keep a private copy of strategy, you get agent sprawl instead of compounding. The structural answer in both cases is the same: keep the context in a layer you control, so organizational memory persists across sessions, vendors, and model generations.
Improvado is built on that side of the perimeter deliberately. Unified marketing data across your channels, your taxonomy and metric definitions applied consistently, and an agentic layer that reads governed data your team owns. When the underlying models get better, that gets better with them.
Talk to an Improvado expert about owning the data layer under your marketing AI.
Frequently Asked Questions
What is the platform kill radius?
It is the perimeter within which a platform can ship a capability in a single release cycle. Anything inside it is a thin layer: a wrapper, a connector, memory implemented as a rolling summary. These get absorbed because they require nothing the platform does not already have. Anything outside it, such as proprietary data, domain depth, or system-of-record status, is not just safe but actively made more valuable by that same release, because better and cheaper reasoning increases the value of the data it is pointed at.
Why is "am I a layer or a moat" the wrong question?
Because it describes a position rather than a mechanism, and positions get copied. "We own proprietary data" and "we own the workflow" are both statements that a well-funded competitor can work toward in a quarter, and both were true of companies that got absorbed anyway. What cannot be matched is an advantage that grows with use, since a competitor would have to match your accumulated state while you keep accumulating. So the useful question is about the mechanism that compounds, which is loop closure.
What does it mean for a feedback loop to close?
Three things together. Coverage: what fraction of the decisions your system influences come back with a measured outcome. Latency: how long before that outcome changes system behavior. Specificity: whether the resulting improvement is per customer or global. All three matter, but specificity decides defensibility, because global improvement can be reproduced by anyone with the same base model, while calibration tied to one customer's history cannot.
What is the difference between a flywheel and a changelog?
A flywheel means outcomes return and change future behavior in a way that compounds, so the system is measurably better for a customer after two years than after two months. A changelog means outcomes are recorded and improvements are shipped globally on a release schedule. The second one looks like learning in a demo and produces no defensibility, because the improvement accrues to the product generally rather than to any particular customer relationship. Most tools that describe themselves as agentic have the second one.
How can I tell whether a vendor actually has compounding?
Ask for the vintage curve: do longer-tenured customers outperform newer ones on the same task when data volume is held roughly constant? If yes, something is compounding beyond raw data accumulation. If performance is flat across cohorts once you control for volume, the product works the same on day one and day seven hundred, which means there is no accumulated calibration to defend. This is the hardest claim to fabricate, because producing the curve requires the architecture to have worked for years.
What is the risk of buying from a vendor inside the kill radius?
Rarely a dramatic failure, usually a slow one. The product stops differentiating from a general assistant, roadmap velocity drops as the team pivots, pricing gets defended rather than justified, and you end up paying for a wrapper around a model you could call directly. The switching cost lands on your team at the worst possible time. The mitigation is to make sure the context that matters, your taxonomy, metric definitions, and accumulated corrections, lives in a layer you own, so changing vendors does not mean re-teaching your business from scratch.
