The Flywheel Part 1: What Actually Compounds in the Insights Industry

Editor's Note:  This article first ran on the Insight Innovation Ventures Substack and appears here with permission. It was written for investors sizing up AI-era companies, and the questions it asks land differently depending on which side of the table you sit on.

The piece sorts out three kinds of flywheel the industry constantly mixes up, and only one of them compounds. If you're buying research or technology, that distinction becomes a ten-question audit you can run against any supplier pitch, starting with whether new usage actually improves the product or just adds volume.

If you're the supplier, the question is harder. If a well-funded competitor had your model and your public data tomorrow, what would still be yours? The author's verdict when the answer is nothing: you have a feature, and features get copied.

This is Part 1 of a new three-part series extending the Decision-as-a-Service framework: why the flywheel is the clearest route to a durable moat in this industry, why the word gets abused constantly, and the framework for telling a real one from a slide.

Every insights company competing on “better AI” is competing for a fleeting advantage — models commoditize in months. The companies that win the next decade are the ones building a flywheel: a self-reinforcing loop where proprietary human signal trains better judgment, better judgment produces better decisions, better decisions generate more usage, and more usage produces more proprietary signal. Data is necessary for that loop. It is not sufficient. Most companies invoking “flywheel” this year have the data and not the loop.

The Mechanism, Precisely

A flywheel is a self-improving loop in which output generates data, that data refines the system, the refined system produces better output, and the better output generates more data. Usage generates data. Data improves the model or the method. The improved system generates more usage and better outcomes. Better outcomes generate more data. Break the chain anywhere — no feedback capture, no retraining cadence, no reason for usage to increase — and what remains is a data asset, a useful product, or a well-run service business. Not a flywheel.

“Flywheel” has become the industry’s favorite unearned metaphor. A panel is not automatically a flywheel. A dashboard is not automatically a flywheel. An AI feature bolted onto a legacy platform is not automatically a flywheel. Naming something a flywheel does not make the wheel turn.

Why the Claim Needs to Be Narrower Than It Sounds

The flywheel is not the only moat left in insights. Distribution, workflow switching costs, earned trust, regulatory credibility, and deeply embedded expert judgment can all be durable advantages without ever closing into a self-improving loop.

A genuine, compounding advantage sits at the intersection of four things, and if any one of them approaches zero, there is no flywheel:

Unique signal without rights clarity is a lawsuit waiting to happen. Rights clarity without workflow embedding is a well-governed product nobody depends on. Workflow embedding without outcome learning is a sticky tool that never gets smarter. Outcome learning without the first three is a research question, not a business. All four, multiplying rather than adding, is what a real flywheel requires — which is why they are rare.

Three Loops Get Confused as One

The most common error in this space is treating “flywheel” as one thing. It is at least three distinct loops.

The data flywheel. More activity generates more human signal. Easiest to build, easiest to overstate — a panel that recruits more respondents has more data, but more data does not make the next output better unless something downstream is actually learning from it.

The product or workflow flywheel. Better performance drives more usage, and that usage generates correction signal and query patterns that make the product better. A real step up, because the loop closes inside the product experience.

The decision-outcome flywheel. Recommendations get implemented, outcomes get measured, causal performance gets attributed, and the decision engine improves because it now knows which past recommendations actually worked. This is the rarest loop, because it requires something almost no insights company has today: reliable access to what happened after the recommendation was delivered.

A panel company can collect a million new observations a month without becoming better at making client decisions. A dashboard can add seats without producing new ground truth. A consultancy can deliver an excellent recommendation and never learn whether the client acted on it. Calling all three of these a “flywheel” is the biggest source of confusion in how this industry talks about AI-era moats.

Outcome Capture Is the Real Bottleneck

The most valuable feedback a decision-intelligence provider can receive is not “the client liked the deck.” It is: did the client act on the recommendation, what did they do instead, what result followed, and — hardest of all — was the recommendation the cause of that result, or would it have happened anyway?

Answering that requires data-sharing rights into the client’s own systems, an operating relationship deep enough to be invited into the outcome layer, and enough experimental discipline to separate correlation from causation. The research industry has spent decades delivering evidence without a reliable view of what happened after the recommendation left the building. The rarest asset in this category is not raw proprietary data — it is validated decision-outcome data, linked back to a governed decision context.

The Model Layer Is the Wrong Place to Look for the Moat

Frontier-model access commoditizes fast; renting state-of-the-art intelligence is table stakes. Domain performance, governance, integration depth, and evaluation discipline do not commoditize nearly as quickly.

A fine-tuned domain model makes sense for tasks that are stable, repetitive, and high-volume. But for most insights work, the underlying knowledge changes faster than model weights should, and buyers increasingly care whether an answer is current and auditable — qualities that favor retrieval and disciplined evaluation over static fine-tuning. A flywheel is model-agnostic. It needs a learning architecture — a defined mechanism for capturing feedback and improving on a cadence — not necessarily a proprietary model. Conflating “we built a domain model” with “we built a flywheel” is one of the more common category errors in how this shift gets pitched right now.

The same caution applies to retrieval architectures and agent-facing distribution protocols. A generic retrieval layer on a standard corpus is among the most portable, easily replicated pieces of enterprise AI architecture that exists. It becomes hard to displace only when the corpus is unique and continuously refreshed, retrieval is coupled to proprietary structure rather than a generic index, every result carries traceable provenance, and the whole thing is embedded in a workflow that feeds outcome measurement. Distribution protocols that let agents query a system directly are a channel, not a moat — they make a company easier to find, but they do nothing on their own to make the underlying loop harder to copy.

Don’t Give the Flywheel Away

None of the above matters if a company gives its compounding asset away in the first contract it signs. A supplier with genuinely unique data can destroy its own flywheel by bundling training rights in with basic access, converting a compounding asset into a one-time payment that gets permanently baked into someone else’s model weights.Separating inference access, analysis rights, fine-tuning rights, foundation-model training rights, and persistent-derivative rights into distinct, deliberately priced categories is the right default. It shouldn’t become dogma — a supplier may lack the capital to operationalize its own corpus, or a buyer may pay a price that genuinely reflects exclusivity. The discipline is narrower than “never sell training rights”: never sell irrecoverable rights cheaply, blindly, or bundled into a contract built for a different economic era.

The Flywheel Audit

A company should answer “yes” to most of the following before anyone — an investor, an acquirer, a client, or its own leadership — accepts that a flywheel exists rather than a story about one:

1. Unique input — Does new usage generate proprietary data a competitor cannot simply go buy?

2. Legal control — Are consent, reuse, training, and deletion rights known at the level of the individual record?

3. Signal quality — Does new data measurably improve accuracy or calibration, or does it just add volume?

4. Feedback capture — Are corrections and outcomes systematically collected, or do they evaporate once the deliverable ships?

5. Causal evidence — Can the company distinguish an improved recommendation from a coincidence?

6. Learning cadence — Does the system update on a defined, disclosed schedule, or is “model refresh” an annual event?

7. Workflow dependency — Would replacing this supplier require a client to change business rules, or just log into a different dashboard?

8. Economic reinforcement — Does each turn of the loop improve retention, pricing power, or margin?

9. Governance and traceability — Can every high-stakes output be traced back to its evidence and a stated confidence level?

10. The counterfactual test — If a well-funded competitor had the same model and the same public data tomorrow, would this company still be improving faster? If not, there is no flywheel yet. There is a feature, and features get copied.

The Correction That Matters Most

Static data is not a moat.
A domain-specific language model is not a moat.
RAG is not a moat.
MCP is not a moat.
RSL is not a moat.

A flywheel is not a moat unless it is genuinely closed.

The future of insights is not a single data flywheel. It is a competition to own the feedback loop that competitors cannot see, buy, or reproduce. For some companies that loop is participant engagement. For others it is identity-linked behavioral signal, embedded workflow usage, governed model evaluation, or measured decision outcomes. The winners will be the companies that know which loop they can uniquely close—and that stop mistaking an archive, an API, a model, or a dashboard for the loop itself.

This piece names the mechanism and gives a working test. The next two posts in the series take the same foundation from opposite directions: how the demand side is restructuring discovery and buying, and a full diligence checklist for evaluating any specific flywheel claim before you buy it, invest behind it, or build your own roadmap on the assumption that it is real.

The industry has stopped rewarding companies simply for having data. It has started pricing, in real dollars, whether that data is turning.