Most AI Products Have Zero Network Effects
Here's How to Actually Build One.
I keep hearing the same pitch. "Our agent gets smarter with every user." It's the new "we have a data moat," and most of the time it's wishful thinking dressed up as strategy.
If you're building agents, here's the uncomfortable reality: you're a consumer of foundation models, not a creator of them. Your "AI" is rented. Anyone with a credit card and a weekend can clone your demo. The only thing that matters long-term is what compounds in your favor while competitors copy your features.
First, kill the comfortable lie
Martin Casado and Peter Lauten at a16z took the data-moat story apart years ago in The Empty Promise of Data Moats, and the argument has aged well. Most of what founders call "data network effects" are actually data scale effects. No interaction between users. Your product just has more training signal than a smaller competitor's. The value of incremental data falls as you scale, while the cost of the edge-case data that actually differentiates you climbs. The flywheel decelerates exactly when you need it to accelerate.
Doubly true in the agent era, because the foundation model providers are eating the generic intelligence layer for you and your competitors at the same rate. Whatever your agent learned from 10,000 users last year, GPT-next or Claude-next probably ships out of the box.
So the bar is higher than "we collect data." The real question: does user A joining make the product better for user B in a way B can feel? That's a network effect. Everything else is a feature.
What actually compounds
Five mechanisms genuinely compound, ranked weakest to strongest.
1. Memory and accumulated context
Memory is a switching cost, not a network effect. When your agent knows the preferences, codebase, voice, approval thresholds, leaving means retraining from zero. NFX calls memory one of the most common emerging defensibilities in AI, and Satya Nadella supported it here. But it's per-user: six months of context doesn't make the product better for you. Memory protects retention, not acquisition. It's the foundation you build on, not the moat itself.
Practical move: make accumulated context visible, so users feel what they'd lose by churning. And don't bet everything here. Memory portability is coming, and "we hold your data hostage" is a moat with an expiration date.
2. Cross-customer learning loops
The narrow version of data network effects that actually works: learnings from customer A transfer to customer B in a way B can perceive and attribute. Fraud detection is the canonical case. Every merchant on a fraud network makes every other merchant measurably safer. It generalizes to any agent handling negotiation, pricing, compliance, or security, where customers pool adversarial knowledge. The key word is adversarial. This compounds best where the environment fights back, because the edge cases never stop arriving and freshness beats volume.
Practical move: instrument the transfer. "Merchants catch 31% more fraud in week one from patterns learned across the network" is a network effect you can sell. "Our models improve over time" is not.
3. Ecosystem and marketplace effects
The oldest playbook in software, and it works better in AI than people realize. When third parties build on your platform, every integration, skill, or workflow makes the product more valuable for everyone, and the builders lock themselves in. MCP went from a spec Anthropic published in late 2024 to the de facto standard for agent-to-tool connectivity, with over 18,000 community-indexed servers. Every server published makes every compatible agent more capable, instantly. Most startups are watching that happen instead of positioning inside it.
The move isn't to invent your own protocol. You'll lose. It's to become where the ecosystem's value concentrates for your vertical: the curated registry, the trust layer, the marketplace where the best skills in your domain live. Shopify didn't invent e-commerce protocols; it became the place where the ecosystem made every merchant more powerful.
Practical move: find what your power users already build for themselves (prompts, workflows, configs) and make it shareable, discoverable, attributable. The day a user adopts another user's workflow, you have your first real network edge.
4. Multiplayer and collaboration effects
Most agent products are single-player by design, which leaves the most proven network effect in B2B software on the table. Figma didn't win on better vector tools. It won because design became multiplayer and the file lived where the team was. The agent version: shared configs, team-level memory, human-agent handoffs in one system. When my teammate's approvals and context shape how the agent behaves for me, the product gets harder to leave with every person who joins.
The NFX test is brutal and useful. Ask users: "What happens if you stop?" If it's "I'll switch to a similar tool," you have nothing. If it's "I'd lose months of team context and shared workflows," you have something.
Practical move: find the first moment two users would naturally touch the same artifact and make it first-class. Don't bolt on "teams" pricing. Build one genuinely shared object.
5. Agent-to-agent network effects
The speculative one, and the one I'd watch closest starting today. As agents begin transacting with other agents, with A2A maturing alongside MCP, a new network forms where the nodes aren't humans. More agents means better matching, price discovery, and task routing. The marketplaces of the next decade may have agents on both sides.
The honest caveat: almost nobody has shown this at scale, and the security story is still messy. Which, if you think like a builder rather than a doomer, is the opportunity. In agent-to-agent networks, trust is the scarce asset. Whoever becomes the trust layer for transactions in a vertical inherits the network effect of the whole vertical. Liquidity follows trust, not the reverse.
Practical move: if agents will transact in your space, design so every successful interaction produces a verifiable record. Reputation systems are network effects with a balance sheet.
How to actually build one: the Cold Start playbook
Andrew Chen's The Cold Start Problem is the best manual ever written on this, and almost nobody in AI has applied it. He frames the journey in five stages. Most founders screw it up by building stage-five features (marketplaces, "agent platforms") while still living in stage one.
Cold start: be ruthlessly useful to one user. No network, no platform. One user, one painful job, done dramatically better. This is Chen's "come for the tool" move. Instagram was a filters app before a social network; Dropbox was a folder before shared folders. The tool delivers value at user one, and the network layers on later. Build a vertical agent that's excellent at one job, not a general agent that's passable at everything. Then accumulate context, so the product compounds for the individual before any network exists. Build the switching cost first. A leaky bucket can't fill.
Tipping point: ignite one atomic network. Don't build "the network." Build the smallest network that's stable on its own, then replicate it. Slack's wasn't "companies," it was three people on one team messaging. Uber's wasn't "San Francisco," it was 5pm at the Caltrain station. For an agent product it's probably one team, one workflow, dense enough that the loop closes without you pushing it. If you can't describe your atomic network in one sentence, you have a distribution wish, not a strategy. Igniting it means doing things that don't scale: white-glove the first ten teams, seed the marketplace with skills you wrote yourself. Tinder seeded sorority parties; PayPal wrote bots to buy on eBay.
Solve the hard side, always. Every network has a hard side: the minority who do disproportionate work and are disproportionately hard to recruit. Drivers, not riders. In agent products it's whoever builds the reusable stuff: power users writing skills, developers publishing MCP servers, domain experts encoding judgment into configs. Maybe 2% of your users, 90% of your value. Court them the way Uber courted drivers, with attribution, status, and eventually money. A skills marketplace with no incentivized creators is a parking lot with no cars.
The moat: open the edges. APIs, marketplace, protocol participation. Let others build on what you've made dense. Now the network defends itself, because the hard side has income and status tied to your platform, and any competitor faces their cold start problem against your density. That asymmetry, Chen argues, is the real moat. Not the technology. The accumulated network a challenger has to rebuild from zero.
Most AI startups die in the cold start while pitching the moat to investors.
The test I'd run on my own product
Strip away the pitch deck and ask three questions, cold.
One. If a competitor cloned my product tonight, feature for feature, what would my users lose by switching tomorrow? If the answer is "nothing," you have a feature, not a company. Fine at the start. Not fine in year three.
Two. Does my hundredth customer make my first customer's experience measurably better, and can the first customer tell? If you can't name the mechanism, you don't have one.
Three. What does my product accumulate that the foundation model providers structurally can't? They'll have better models than you forever. They won't have your vertical's trust relationships, your cross-customer learnings in a narrow domain, or your ecosystem of builders. Those are the only games worth playing.
The application layer won't be won by whoever uses AI best. The models are everyone's. It'll be won by whoever builds the thing that gets harder to compete with every day it exists, and harder to leave with every user who joins. It's just strategy, and the founders who remember that will take the category.