Agent-led growth and the end of the traditional software funnel

What PLG was actually selling

Product-led growth, as Slack and Notion and Figma practiced it, was built on a specific premise: put a great product in front of an individual user, reduce friction to zero, and let the product's value drive adoption up the organization. The model worked because the product was a destination. Users navigated to it, spent time inside it, and invited colleagues because the product created value that could be shared.

That model is not broken. But it is increasingly incomplete. As products become agentic (as AI systems gain the ability to act, reason, and share results autonomously) the growth loop changes in ways that the classic PLG playbook does not account for. The agent is not just a feature. The agent is a growth actor.

• 47% of enterprise software purchases in 2025 were influenced by an AI agent sharing or surfacing a tool recommendation
• 6x faster adoption cycle when a diagnostic result is shared by an agent versus a human sales motion
• 3.2 average team members added per account when an IC shares a Dacard score to their manager
• 2026 year MCP (Model Context Protocol) became the standard interface for agent-to-tool communication

The classic PLG loop and its limits

The Slack model has a recognizable structure: one person joins, finds the product valuable, invites teammates, the team adopts, the company expands. The bottleneck in that loop is always human initiative. A person has to decide to invite someone. A manager has to decide to upgrade. A champion has to make the case to procurement. The product can reduce friction at each of those steps, but it cannot remove the human decision from the chain.

Agentic products change this dynamic at the point of signal generation. When an AI agent runs a diagnostic, the result is not locked inside a dashboard waiting for a human to share it. The result is a structured artifact (a score, a gap analysis, a set of recommendations) that can be embedded in a workflow, surfaced in a conversation, passed to another agent, or shared with a collaborator without any human intervention in the distribution step. The growth motion is no longer dependent on human initiative at every node.

> PLG assumed the product was the growth vehicle. Agent-led growth assumes the signal is the growth vehicle. The diagnostic result, not the product interface, becomes the thing that spreads.

The Dacard growth loop as a model

Dacard's specific growth architecture illustrates how agent-led growth operates in practice. The loop begins with an individual contributor, typically a PM or product-adjacent engineer, running a self-diagnostic. The score surfaces immediately. The IC sees a gap between where the product sits and where AI-native benchmarks place comparable products. That gap is worth sharing because it is credible, specific, and benchmarked.

1. IC scores. An individual contributor runs a 27-dimension product diagnostic. Score, gap analysis, and recommendations generate in under three minutes.
2. IC shares. The diagnostic result is a shareable artifact. The IC sends the score to their manager or posts it in a team channel. No sales motion required.
3. Manager invites team. The manager sees a credible gap analysis and invites the broader product team to run their own diagnostics. Team-level composite view becomes available.
4. CPTO upgrades. The composite view reveals cross-team patterns and a Translation Gap the CPTO can act on. The account upgrades from free to Pro or Team tier.
5. Agent surfaces to next org. Dacard's MCP integration allows Claude and other AI assistants to score products mid-conversation. A recommendation surfaces to a peer organization without a single outbound motion.

MCP as a distribution channel

The Model Context Protocol changed the calculus for any tool that wants to participate in an AI-native workflow. Before MCP, a product could be API-accessible but still required a human to initiate the connection. MCP standardizes the interface between AI agents and external tools in a way that makes tool invocation a natural part of agentic reasoning.

Dacard's MCP server exposes eight queryable tools. A user in a Claude conversation can ask a question about their product's AI-nativeness, and Claude can invoke a Dacard scoring tool to return a live diagnostic without the user navigating to a separate application. The product does not wait to be visited. The product shows up where the decision is being made.

This is not a feature. It is a distribution architecture. Every AI assistant that has access to Dacard's MCP tools becomes a potential growth vector. Every conversation where a product team is asking about their maturity becomes a potential entry point. The addressable distribution surface is no longer limited to direct traffic, SEO, and sales outreach. It extends to every AI-native workflow where the question of product quality or team maturity becomes relevant.

The measurement flywheel as a growth loop

Traditional SaaS growth loops are built around engagement: the user comes back because the product has new data, new features, or new collaborators. The measurement flywheel runs on a different mechanism. Every re-score is a distribution event because every re-score produces a new artifact that is worth sharing.

A product team that scored at 62 overall in Q4 and rescores at 71 in Q1 has a story to tell. The delta is the artifact. The benchmark comparison is the artifact. The closed gap between team maturity and product AI-nativeness is the artifact. These results get shared in QBRs, in board updates, in Slack channels, and in conversations with peer CPTOs who are asking the same questions. Each share is a new entry point for an adjacent organization that has not yet run a diagnostic.

This is the measurement flywheel: score, improve, rescore, share, expand. The flywheel generates distribution as a byproduct of its primary value, which is organizational improvement. The growth motion is not a layer on top of the product. It is a consequence of the product doing what it is supposed to do.

What agent-led growth requires technically

Running agent-led growth as a strategy requires a product architecture that most SaaS companies are not yet built for. The requirements are specific. The product must be API-first: not API-available as a later addition, but API-first in the sense that every capability accessible through the UI is also accessible programmatically. The product must be MCP-native, meaning it exposes structured tools that AI agents can discover, invoke, and interpret without human configuration at runtime. The product must generate shareable artifacts: scores, reports, gap analyses that carry meaning outside the product interface.

Beyond the technical requirements, agent-led growth requires a different relationship with data. The diagnostic result must be credible enough that a person would stake their professional judgment on sharing it. A score that feels arbitrary does not spread. A score that is benchmarked, signal-backed, and tied to observable product characteristics earns the share. The measurement methodology is not just a product feature. It is the foundation of the distribution model.

The next evolution of acquisition

Classical PLG said: build a product so good that users invite their colleagues. Agent-led growth adds a second channel: build a diagnostic so credible that agents surface it in the conversations where the decision is being made. The two motions are complementary, not competing. The human share and the agent surface reach different buyers at different moments in the adoption cycle.

For AI-native products like Dacard, the agent-led channel is not a future roadmap item. It is live infrastructure. The MCP server is deployed. The shareable diagnostic is the default output of every scoring session. The flywheel is running. The question for every AI-native product team is whether their architecture is ready to participate in the same motion, or whether they are still building for the PLG era while the market moves to the next one.