In the agent era, that metric changes. If your product is being used by agents at scale, autonomously, then you don’t have users in the traditional sense. You have workflows. And that leads to a different north star entirely.

In the agent era, I propose WAW (Weekly Active Workflows) is that metric. Here’s why the alignment matters: when your north star is the workflow and your pricing unit is the workflow (no longer “seats”), every growth experiment moves revenue, and every revenue decision improves the growth motion. You’re optimizing two separate machines instead of one.

A “workflow” is an agent-driven sequence of calls that accomplishes a defined task. It’s not just any API call, but a connected sequence starting with a goal and ending with a verifiable outcome. WAW counts distinct workflows invoking your product at least once in a given week, above a minimum success threshold (>80% completion rate).

Why WAW captures what other metrics miss:

• Agents don’t have active days. A workflow might run 50 times in 10 minutes Tuesday, then not again until Thursday. DAU/MAU cannot capture this.

• Raw API call counts can be dominated by one broken agent hammering your API. WAW requires successful, goal-directed sequences.

• “Weekly” filters out stale configs. “Active” filters out broken workflows generating errors. Together: you’re embedded in something being actively built.

WAW vs. Other Options

Track both WAW and WRSEA. WAW for external reporting and pricing alignment. WRSEA as your internal reliability signal, it catches quality degradation before WAW does. When WRSEA starts declining while WAW holds steady, you have a reliability problem that’s about to become a retention problem.

From the W&B playbook: When the WREU dipped, we knew within 48 hours which cohort, which channel, which part of the funnel. Get one person on your team obsessed with growing WAW, and give them the influence to act on it. A single metric gives you a chance to be genuinely creative, because every creative decision has to answer one question. At W&B, I looked at the growth of that one metric each week like my life depended on it – for years, and I had full reign to pull in product, engineering, GTM resources to make that metric grow. This focus is what led to our market domination.

Token-to-Value

Time-to-value was the central PLG metric: how quickly does a user reach their aha moment? Dropbox optimized to minutes. Slack to a first message.

Token-to-value is its agent-era counterpart: how many tokens does it take an agent to confidently pick your product, and how many more to implement it correctly?

Agents make tool selections under implicit token budget pressure. Every ambiguity is a cost. Every missing example forces a guess. The agent picks the thing it can implement in the fewest tokens.

Resend vs. SendGrid: Same Outcome, Completely Different Token Cost

SendGrid is not bad infrastructure, especially for enterprise email with dedicated IPs, its deliverability track record is genuinely valuable. But for an agent writing email code in a single pass, Resend’s token-to-value is dramatically lower. The agent picks what it can implement without iteration.

The four drivers:

• Description clarity: MCP tool descriptions should state when to invoke you vs. alternatives. Agents fail at tool selection when 30+ descriptions overlap. Under 8 tools per server. “Sends a transactional email and returns delivery status” not “Calls POST /v1/emails.”

• Error message specificity: every 4xx is a branching decision. e.g. “Unauthorized” = 0/3. “API key missing, set RESEND_API_KEY, should start with re_” = 3/3.

• API surface predictability: schema changes cost trust. Parameter names that don’t mean what they imply cost tokens.

• Autonomous completability: any required human action is a hard blocker. Agents cannot click. Agents cannot check email. Agents cannot enter a credit card.

Cloudflare’s architectural solution: 2,500 endpoints would consume 1M+ tokens as individual MCP tools. Code Mode: two tools, search() and execute(), agent writes TypeScript against a typed API representation. ~1,000 tokens total. A 1,000x improvement by treating it as an architecture problem, not a documentation problem.

It’s 2026. Build. For. Agents.

The current moment is 2012 in PLG. Dropbox and Slack moved early. They built distribution advantages that compounded for a decade. Most companies were still optimizing human onboarding flows while the Dropbox referral program was already running. The winners from that era look obvious now. They didn’t at the time.

The same window is open now. Most developer tools have no llms.txt, no MCP server, no Agent Skills, no free tier accessible to autonomous agents, and no metrics that distinguish agent-driven from human-driven usage. They’re optimizing human onboarding flows while the default stacks of 2027 are being determined.

The flywheel is already spinning for some companies. Supabase didn’t win a marketing contest, it won a training data and distribution architecture competition that started years before anyone called it that. Resend didn’t out-sell SendGrid, it out-documented and out-simplified it, until a machine could implement it correctly in a single pass, and confidently recommend it to the next machine that asked.

Every successful agent execution is a vote in the next round of training. Every public repo is a permanent signal. Every community config template is an H2A conversion waiting to be cloned. The referral loop closes automatically. The flywheel spins on its own.

The rules of this competition are now clear. The window to enter it is still open.

“It’s 2026. Build. For. Agents.” – Andrej Karpathy

Thank you to Lukas Biewald, James Cham, Amy Tam and Phil Gurbacki for early feedback on this draft.

Part 4 – The Agent Flywheel Checklist is the implementation guide companion to this piece, with specific examples from the companies doing it well.

Improbability

Part 4: Build your Agent Growth Loop

In Part 1, 2 and 3 we talked about how the rules of growth have changed: AARRR remapped for the agent era, three loops that turn a funnel into a flywheel, and why the gap between Supabase and its competitors is widening every time a model retrains. This part is the implementation guide…

Read more

3 months ago · Lavanya

_________________________

Lavanya Shukla is the Managing Partner of Improbability.vc, an early-stage fund backed by Sequoia, Coatue, Village Global, Bloomberg Beta, Lukas Biewald, Adrien Treuille, and AI leaders at OpenAI, DeepMind, Turing et all.

She spent seven years running Growth and AI at Weights & Biases, scaling it from 100 users to millions, every AI engineer at every major lab, through product-led growth.

Improbability Engine’s thesis: invest in the 1–2 AI companies that matter every year. If you’re building one of them, reach out: lavanya@improbability.vc

Improbability

Part 1: The Agent Flywheel

A developer opens Cursor and types: “add email to this app…

Read more

3 months ago · Lavanya

Improbability

Part 2: The Four Distribution Paths

If the agent flywheel is the engine, distribution is how it spins. In the human era, growth followed a few familiar paths—word of mouth, SEO, sales. In the agent era, those paths still exist, but they’ve been reshaped and multiplied…

Read more

3 months ago · Lavanya

Improbability

Part 3: The North Star: Weekly Active Workflows (WAW)

In every era of growth, there’s one metric that actually matters. At Weights & Biases, it was Weekly Returning Engaged Users. Everything we did flowed through that one number…

Read more

3 months ago · Lavanya

Improbability

Part 4: Build your Agent Growth Loop

In Part 1, 2 and 3 we talked about how the rules of growth have changed: AARRR remapped for the agent era, three loops that turn a funnel into a flywheel, and why the gap between Supabase and its competitors is widening every time a model retrains. This part is the implementation guide…

Read more

3 months ago · Lavanya

If the agent flywheel is the engine, distribution is how it spins. In the human era, growth followed a few familiar paths: word of mouth, SEO, sales. In the agent era, those paths still exist, but they’ve been reshaped and multiplied.

Today, your product spreads through four distinct channels. And they don’t all compound the same way.

Human → Human (the original): Classic word of mouth, has a blast radius of one.

Human → Agent (H2A): A human configures their agent once, “use Vercel for deploys,” “auth through Clerk,” and that instruction executes across every relevant task the agent runs. One human preference becomes thousands of agent invocations.

From the W&B playbook: H2A is the 2025 equivalent of what we did with repo integrations at W&B. When a developer added wandb.init() to their HuggingFace training script, every developer who cloned that repo encountered W&B. One human decision led to thousands of downstream users. H2A has the same mechanic but at 100x the scale, an agent doesn’t just clone a repo, it applies the tool across every relevant task it runs, indefinitely.

Agent → Human (A2H and GEO): An agent recommends your product to a human who has never heard of it. Someone asks Claude what to use for transactional email. Claude says Resend. Your position here is determined by training data density, retrieval confidence, and execution success history. All three are engineerable.

Agent → Agent (A2A) – the frontier: Orchestrators delegate to sub-agents, sub-agents select tools, tools call APIs. There’s no human in the loop, and the blast radius is massive. In a fully A2A world, product selection happens entirely between machines.

The compounding flywheel math: in H2H, one recommendation → one new user. In H2A, one human configuration → thousands of agent invocations. In A2A, one default selection propagates across every workflow that orchestrator runs. These are not the same growth curve.

And most teams are still building just for Human → Human.

Let’s walk through what each step of the Agent flywheel looks like today.

A – Acquisition: Training Time and Inference Time

Agents don’t really evaluate products in the way we think about it. They’re not weighing pros and cons or comparing feature sets. They’re pattern-matching against what they’ve seen before: training data, examples, code that worked.

That’s the core thing to understand. If your product shows up clearly and consistently in that data, it gets picked. If it doesn’t, it doesn’t.

When a developer opens Claude Code and types “add auth,” the agent doesn’t search for options. It draws on what it learned during training (for the most part), every GitHub repo using your SDK, every Stack Overflow answer, every tutorial published before the training cutoff. These are your acquisition channels, running 24/7 across every model deployment worldwide. Models heavily weight data from before their training cutoff, distribution advantages you build now are baked into the models developers will use for years.

Vercel’s CEO Guillermo Rauch emphasized this when Neon was acquired by Databricks: “Agents favor infrastructure well represented in training. Postgres: check. Not reinventing the wheel and bringing new query languages to market was rewarded.” He was explaining why Supabase’s training data saturation mattered more than Neon’s arguably superior serverless architecture.

From the W&B playbook: At W&B, we were obsessed with how many public repositories were building on top of our SDK. We looked at this number obsessively every week. Every new repo felt like a win, not just because it was a user, but because it was a distribution node node. The more popular, the repo got the more people used W&B. At the time, we didn’t look at it as training data, but that’s exactly what it was. Those repos fed everything else. Developers would build in public, publish tutorials, and share their work. That content drove word of mouth across labs, conferences, and teams. Each piece reinforced the next, and over time, the system started to compound. In the early days, a lot of this was manual. I spent time reaching out to maintainers of popular ML repos, asking them to integrate W&B. It was slow and expensive, but it worked. Today, that same dynamic is happening automatically, agents are effectively doing that distribution for you.

The ROI of open source is now measurable. Track public repos using your SDK. Cross-reference with AI citation share 12–18 months later. They move together with a lag roughly equal to one model training cycle.

At inference time, agents also actively retrieve information mid-task. Win this with three things:

• a plain text file at

  yourdomain.com/llms.txt

  listing every major doc page with its URL, title, and one task-oriented sentence (Cloudflare goes furthest, their doc pages open with “STOP! If you are an AI agent or LLM, read this before continuing. HTML wastes context”),

• an MCP server in a discoverable registry so an agent can invoke you without training data;

• and Q&A-structured documentation that matches how agents decompose queries.

Measure AI Citation Share: ask Claude, ChatGPT, and Perplexity “what should I use for [your category]?” weekly. Tools like Profound (enterprise),

Otterly.AI

, and OpenLens (free) automate this. Public repos using your SDK over time was the leading indicator we tracked most obsessively at W&B, cross-reference it with AI citation share 12–18 months later.

A – Activation: First Successful Execution

In the human era, activation is an emotional experience. You could watch it in session recordings, the moment someone got it. You optimized onboarding to accelerate it.

For agents, there is no aha moment. Activation is the first successful autonomous task completion, the agent calls your API with correct parameters, gets a success response, uses the returned data correctly in the next step, and the overall task completes without any user intervention. You only know it happened if you instrument for it.

Instrument it in your logs: flag any new account that records 3+ consecutive successful API calls within a single 60-minute session window. That connected sequence, not isolated calls, is your activation event proxy.

Before activation, the agent needs to pass the Autonomous Loop Test: can it provision, authenticate, configure, write code, deploy, and verify, with zero human intervention? Your product needs to be simple to use end-to-end without human intervention. And simple to buy without human intervention.

Without this autonomous loop, growth is a non starter.

The four hard blockers that kill activation before it starts:

• Auth requires clicking a confirmation email, agents cannot check email

• API key creation requires a dashboard click, agents cannot navigate web UIs

• Free tier requires a credit card, agents cannot enter payment info

• Rate limits fire before a real task completes, looks like a product error, not a throttle

Supabase’s Management API lets an agent spin up Postgres, create tables, configure RLS, and retrieve connection strings, all programmatically. Lovable provisions databases without showing users a dashboard. Resend takes this further: npm install resend, set RESEND_API_KEY, call resend.emails.send(). One doc page, one env var, no dashboard.

pg.new

gives you a Postgres URL in one second from the terminal. These products pass. Most enterprise tools with sales-gated trials don’t.

After the loop test, activation fails most often on one thing: error messages that don’t tell the agent what to do. “Unauthorized” provides zero signal. “API key missing, set RESEND_API_KEY in your environment, it should start with re_” provides three actionable signals: what’s wrong, where to look, what to fix. Grade every error response on those three questions. Rewrite anything that scores below 2/3.

R – Reliability: The New Retention

Retention in the human era was about habit, DAU/WAU/MAU, cohort curves, re-engagement emails. For agents, there are no habits. They keep selecting you because you consistently work. They stop selecting you, silently, gradually, because you stopped being reliable.

This is the most invisible failure mode in agent-era growth. Agents don’t churn dramatically, they gradually stop invoking you across more task types until you’re only a fallback. You won’t see a spike in cancellations, you’ll see a slow decline in Tool Reselection Rate.

Schema stability is a retention strategy. Every breaking change, every undocumented behavior shift, these are silent retention losses happening in agent memory. The agent encounters an unexpected result, records the failure, and starts routing around you.

Expansion in the agent era is Workflow Spread: one developer adds your MCP server → their agent uses you for all relevant tasks → their team inherits that config → usage compounds with no additional human decision. One committed agent can generate 100x the API calls of an occasional human user, continuously, without needing an internal champion.

R – Referral: The Three Loops That Close the Flywheel

In the human era, referral was human → human. Dropbox gave away storage. Slack spread through viral invites.

From the W&B playbook: At W&B, referral ran through three loops: repo integrations (one repo adding W&B → thousands of cloners encountering it), a content loop (users published publicly → ranked in Google → new developers arrived pre-sold), and community word of mouth at labs and conferences. Each loop fed the others. The SEO content loop is now partially obsolete, AI is eating traditional search. But the training signal those tutorials created is permanent. The flywheel didn’t die, it just transformed.

Loop 1 – The Model Loop

When agents successfully complete tasks using your product, those trajectories can become training signals for the next model generation. More completions → stronger parametric memory → higher default selection at Acquisition. Each model generation amplifies the previous.

A competitor cannot outspend you to undo training data. They can only wait for the next training cycle and try to accumulate more signal. This is the most durable competitive moat in the agent era, and it’s built by the same motion that built W&B: make something developers love, get it into public repos, let the tutorials write themselves.

Loop 2 – The Community Loop

Developers who successfully use your product share their configs. “My Cursor setup for Next.js + Supabase + Vercel” gets published, gets cloned. Every developer who clones it is an H2A conversion for every tool in that config. A popular config template can drive more H2A conversions than any product launch, and it compounds every time someone else clones from the people who cloned it.

Loop 3 – Agent-Generated Content

In the human PLG era, user-generated content was a core growth mechanic with Yelp reviews, Airbnb photos, W&B community reports. In the agent era when Lovable scaffolds a new app, it writes code that includes Supabase, Resend, and Stripe. That project gets committed to GitHub. It joins the pool of public code that future models learn from. The agent generated the content, the content feeds the flywheel. This loop is newer, faster, and almost no one is deliberately seeding it yet.

Agent Skills Are The New npm Packages

Agent Skills are SKILL.md files that developers install with a single command (npx skills add your-org/your-product), injecting your institutional knowledge into the agent’s context before it writes a single line of code. Not documentation. The patterns that only come from running your product at scale: database index choices you only know after running millions of queries, auth anti-patterns you only discover after handling millions of users.

npm hit 350K packages in eight years. The Agent Skills ecosystem hit 350K in two months. Supabase’s launch: 1,405 likes, 108K views on day one, packaging things like “use BRIN indexes for timestamp ranges, not B-tree.” Knowledge that only comes from running millions of Postgres databases. Microsoft shipped 98 skills and has 1.7M installs. The distribution logic is identical to npm: be in the developer’s environment before they visit your website.

R – Revenue: Seats to Workflows

In the human era, revenue occurred when someone hit a feature gate, felt the friction, and chose to upgrade. PLG was built around engineering those moments.

When the buyer is a machine, the mechanic breaks in three places: agents don’t have seats (one agent can generate more usage than 50 human users), agents don’t feel friction (the upgrade prompt never appears if a feature is blocked, the agent fails silently), and agents scale usage in ways no buyer can forecast at contract signing. You need pricing that captures expansion automatically.

The natural unit of agent value is the workflow, a complete, goal-directed task. Three models that work: usage-based (safe default, charge per API call, per email sent, Supabase, Resend, and Stripe all use this), outcome/workflow-based (frontier, Intercom Fin at $0.99/resolved ticket, $10M+ revenue in year one), and hybrid flat base plus usage overage (where mature tools are converging, enterprise buyers get budget predictability, usage captures agent-scale expansion).

Workflows are the bedrock of both your growth motion and your revenue model. If your north star is WAW and your pricing unit is the workflow, you’re measuring and monetizing the same thing. Every growth experiment and every pricing decision is aligned.

Free tier best practices are non-negotiable for agents:

• No credit card required before getting an API key

• No email verification before the first API call

• Programmatic provisioning available at the free tier

• Rate limits generous enough for a real task to complete

Any failure = inaccessible to fully autonomous agent workflows.

From the W&B playbook: W&B’s free tier, unlimited for individuals and academic researchers, required no credit card, and was core to community adoption. Researchers became evangelists, wrote tutorials, joined labs that became enterprise customers. In the agent era, the payoff is the same but faster: an agent that completes a real task at the free tier generates training signal, config templates, and AGC that feeds all three loops.

All of this creates a system that compounds faster than anything we’ve seen before. Distribution feeds usage, usage feeds training data, training data feeds future selection.

But there’s a problem: most teams are still measuring the wrong thing.

If agents are the ones using your product, and they behave nothing like humans, then the metrics we’ve relied on for the past decade start to break down.

So what should you measure instead? Find out in Part 3!

Thank you to Lukas Biewald, James Cham, Amy Tam and Phil Gurbacki for early feedback on this draft.

_________________________

Lavanya Shukla is the Managing Partner of Improbability.vc, an early-stage fund backed by Sequoia, Coatue, Village Global, Bloomberg Beta, Lukas Biewald, Adrien Treuille, and AI leaders at OpenAI, DeepMind, Turing et all.

She spent seven years running Growth and AI at Weights & Biases, scaling it from 100 users to millions, every AI engineer at every major lab, through product-led growth.

Improbability Engine’s thesis: invest in the 1–2 AI companies that matter every year. If you’re building one of them, reach out: lavanya@improbability.vc

Improbability

Part 1: The Agent Flywheel

A developer opens Cursor and types: “add email to this app…

Read more

3 months ago · Lavanya

Improbability

Part 2: The Four Distribution Paths

If the agent flywheel is the engine, distribution is how it spins. In the human era, growth followed a few familiar paths—word of mouth, SEO, sales. In the agent era, those paths still exist, but they’ve been reshaped and multiplied…

Read more

3 months ago · Lavanya

Improbability

Part 3: The North Star: Weekly Active Workflows (WAW)

In every era of growth, there’s one metric that actually matters. At Weights & Biases, it was Weekly Returning Engaged Users. Everything we did flowed through that one number…

Read more

3 months ago · Lavanya

Improbability

Part 4: Build your Agent Growth Loop

In Part 1, 2 and 3 we talked about how the rules of growth have changed: AARRR remapped for the agent era, three loops that turn a funnel into a flywheel, and why the gap between Supabase and its competitors is widening every time a model retrains. This part is the implementation guide…

Read more

3 months ago · Lavanya

The checklist below is ordered by leverage and time-to-impact. Tier 1 takes hours and the payoff is immediate: you go from invisible to agents to discoverable. Tier 2 compounds over months. Tier 3 builds the structural advantages that are hardest to replicate. Work through them in order.

Tier 1 – Table Stakes

1. Publish llms.txt

Most developers have encountered robots.txt (tells crawlers what not to index) and sitemap.xml (lists your pages for search engines). llms.txt is the third file in that lineage; except instead of controlling access or listing pages, it tells agents what your documentation is actually for.

It’s a plain text file at yourdomain.com/llms.txt. Every major doc page listed with its URL, title, and one task-oriented sentence. Not “Authentication Overview”; “How to add email/password login to a Next.js app.” The difference matters because agents decompose queries into tasks, not topics. A task-oriented description gets matched; a topic heading doesn’t.

Build it grouped by what developers are trying to accomplish, not by product area. “Add authentication” before “Authentication overview.” Format each entry as [Title](URL); one sentence focused on the task. Plain text only; no HTML, no nav structure, no auth, no redirects. If you want to go further, add llms-full.txt: your entire documentation in one file, bulk-ingestible in a single request.

The benchmark is Cloudflare. Their doc pages open with: “STOP! If you are an AI agent or LLM, read this before continuing. This is the HTML version. Always request the Markdown version instead; HTML wastes context.” They link directly to the Markdown version, the llms.txt index, and the full bulk file. Supabase was one of the first major developer platforms to ship llms.txt and keeps it current. Vercel has one. Most of their competitors don’t.

Time: a few hours. Read supabase.com/llms.txt and developers.cloudflare.com/llms.txt before you build yours. The pattern is obvious once you see two good examples.

2. Ship an MCP Server

MCP (Model Context Protocol) is the standard that lets AI agents invoke tools at runtime; think of it as a USB-C port that works across every agent and every tool. An MCP server means an agent can discover and use your product without you being in their training data at all. Discovery converts to usage in one step, no human required.

Also important: your API itself needs to be legible to an agent. Function names should clearly suggest what each function does, and naming should stay consistent so it’s easy to guess. An agent should be able to infer how to use your API without needing to read every line of documentation.

The most common mistake is shipping too many tools. Agents fail at tool selection when more than 30 descriptions overlap; accuracy approaches chance at 100+. Start with 3–5 operations, validate each one works reliably, then add. Keep servers under 8 tools. Every description should answer “when should I use this?” not “what endpoint does this call?”

Write short descriptions around outcomes: “Sends a transactional email and returns the message ID and delivery status. Use for password resets, receipts, and notification emails.” Not: “Calls POST /v1/emails.” The first tells an agent when to invoke you. The second just describes an HTTP method.

Two more requirements that ship teams routinely skip: auth must be device flow or API key only; agents cannot complete browser-based OAuth flows; and every error response must include what failed, what to check, and what to do. That’s three things. Always.

Stripe’s MCP server is the reference implementation. It gives agents “wallets”; create payment links, check subscriptions, process refunds, all without a human touching the Stripe dashboard. An agent building a SaaS product can wire up payments end-to-end. Supabase exposes its Management API the same way: an agent can provision a database, create tables, configure row-level security, and retrieve connection strings without showing a user a dashboard. Cloudflare took the architectural approach: instead of 2,500 endpoints consuming a million tokens, Code Mode exposes two tools; search() and execute(). The agent writes TypeScript against a typed representation. About 1,000 tokens total. A 1,000x token efficiency improvement.

Test it: open Claude Code, ask it to use your tool with only your MCP server available and no other context. Watch where it fails. Every failure is a growth leak in your activation stage.

3. Run the Autonomous Loop Test

This is the most important 30 minutes you’ll spend this week. It surfaces every hard blocker in your trial flow before you invest in anything else.

Open Claude Code. Say: “Integrate [your product] from scratch. I haven’t set anything up.”

Grade each step: provision → authenticate → configure → write code → deploy → verify. Every point where it asks for help is a hard blocker. Not a rough edge; a wall agents cannot pass.

The four failures that appear most often:

• Credit card required to get an API key; agents cannot enter payment info

• Email verification gates the first API call; agents don’t check email

• API key creation requires a dashboard click; agents cannot navigate web UIs

• Rate limits fire before the first real task completes; looks like a product error, not a throttle

Fix these before investing in anything else in this list. A polished MCP server doesn’t help if an agent can’t get an API key without clicking a button. The Autonomous Loop Test tells you exactly what’s broken.

4. Rewrite Your Top 10 Error Messages

Error messages are the most underestimated growth lever in developer infrastructure. When an agent hits a 4xx and can’t recover, it doesn’t retry; it routes around you. That routing decision is often permanent.

Rewrite anything scoring below 2/3. This is usually a two-hour task. The impact on Error Recovery Rate is immediate and measurable.

5. Restructure Docs as Self-Contained Pages

Most developer documentation is written for humans who skim. Agents don’t skim. They extract. When an agent loads a documentation page, it’s looking for a complete, actionable answer; not an overview that references four other pages.

The rule that changes the most: every page must be self-contained. No “as we covered earlier.” No “you’ll need to complete the setup in the previous guide first.” An agent reads one page. If that page assumes the reader has read another, it will fail any agent that arrives at it directly; which is most of them.

Concretely, every doc page should open with the answer. The first 100 words should directly address the question the page’s title implies. Not “In this guide, we’ll explore...”; just the answer. The code example needs the exact import statement (package name and specific export, not “import the SDK”), all required environment variables named exactly as they appear in .env (RESEND_API_KEY, not “your API key”), error handling inline in the code block, and the expected success state so the agent can verify completion.

Rewrite every H2 and H3 as the question the section answers. “Row-Level Security” is a topic. “How do I set up Row-Level Security for a multi-tenant app?” is a question an agent can match to. The distinction matters for runtime retrieval; Q&A structure is how agents decompose and search.

Specificity also matters for AI citation. “Supabase is fast” won’t appear in any agent recommendation. “Supabase serves 4.5M active developers across 16 AWS regions with 99.99% uptime” might. Quantified, verifiable claims are what agents extract and repeat.

Clerk and Resend are the benchmarks. Every Clerk framework integration guide; Next.js, React, Remix, Astro; gets its own complete page: exact npm install, exact env vars, exact imports, working component, expected behavior. One page, everything the agent needs. Resend does the same for each language integration. No cross-references required.

6. Audit Your Free Tier

For humans, the free tier is a try-before-you-buy mechanism. For agents, it’s something more fundamental: the only path to selection in fully autonomous workflows. Agents cannot enter a credit card. They cannot approve a subscription dialog. If your free tier requires any human action to access, autonomous agents can’t trial your product at all.

Four checkboxes:

• No credit card required before getting an API key

• No email verification before the first API call

• Programmatic provisioning available at the free tier

• Rate limits generous enough for a real task to complete

Any “no” means you’re inaccessible to fully autonomous agent workflows.

From the W&B playbook

SendGrid eliminated its permanent free tier in May 2025, replacing it with a 60-day trial. Within months of that change, Resend’s selection rate in Claude Code testing climbed further. The free tier is the trial stage of the Autonomous Loop Test. A credit card requirement is a wall agents cannot pass. Resend’s free tier; 3,000 emails/month, no credit card; isn’t just generous. It’s a distribution strategy.

Tier 2 – Compounding Advantages

Tier 1 makes you visible. Tier 2 builds momentum. These items take weeks of sustained work, but each one compounds; the value accumulates across model training cycles, not just across user cohorts.

7. Publish Agent Skills

Here’s the asymmetry at the heart of agent-era growth: generic training data contains what’s in tutorials. Agent Skills contain what you’ve learned from running your product at production scale that never made it into a tutorial.

Agent Skills are SKILL.md files developers install with a single command (npx skills add your-org/your-product). The developer installs once; their agent gets your institutional knowledge injected into its context before writing a single line of code. Not documentation; the patterns that only emerge after running your product at scale: the database index choices you only know after running millions of queries, the auth anti-patterns you only discover after handling millions of users.

The npm analogy is intentional. npm hit 350K packages in eight years. The Agent Skills ecosystem hit 350K in two months. Vercel, Supabase, Stripe, Prisma, Coinbase, and Microsoft all shipped official skills before Q1 2026 ended. Microsoft: 1.7M installs from 98 skills. The distribution logic is the same as npm: be in the developer’s environment before they visit your website.

Supabase’s Agent Skills launch tells you exactly what to aim for: 1,405 likes, 108K views on day one. They packaged things like “use BRIN indexes for timestamp ranges, not B-tree” and “avoid subqueries in RLS policies.” Knowledge that only comes from running millions of Postgres databases. That’s the moat; not what the docs say, but what you know from experience that the docs don’t say.

8. Ship Starter Templates with Full Agent Configuration

A starter template with your product embedded is an H2A conversion for every developer who clones it; and for every tool in the stack. Not just yours.

The template should be a complete working stack: Next.js + Supabase + Resend + Vercel + Stripe (or your relevant combination), with AGENTS.md pre-configured with the right tool choices, Agent Skills installed for each tool, and MCP servers specified. A developer who clones it isn’t just getting your product; they’re getting a configured agent environment where your tool is already the default.

The AGC loop runs through this too. Every project that Lovable or Bolt scaffolds using your tool gets committed to GitHub by the developer who built it. That code enters the pool of public repositories that future models train on. The agent generated the code; the developer committed it; the training signal is permanent.

From the W&B playbook

At W&B, complementary repo integrations were the highest-leverage growth motion we ran. One integration with a popular ML repo; YOLOv5, HuggingFace Transformers, Stable Diffusion; put W&B in front of every developer who cloned that repo. Starter templates are the agent-era equivalent: one template, potentially thousands of agent deployments, all using your tool by default.

9. Instrument for WAW and the Supporting Metrics

You can’t optimize what you can’t see. Most analytics stacks treat all API calls the same way; they have no concept of whether a call was agent-initiated or human-initiated, and no concept of a “workflow” as a unit of measurement. Fix this before you need it.

Separate agent-initiated API calls from human-initiated ones using user-agent strings or session metadata. Then define a “workflow” event in your instrumentation: three or more consecutive successful API calls within a single 60-minute session window. That pattern; a connected sequence with a goal; is your activation event proxy and your WAW building block.

Build a weekly dashboard tracking WAW, First Successful Execution Rate, Tool Reselection Rate, Autonomous Completion Rate, and the Agent/Human API call ratio. Run weekly AI citation testing; 10 prompts across Claude, Perplexity, and ChatGPT; and log the results. Set an alert for declining Tool Reselection Rate: that’s your earliest warning signal, appearing weeks before problems show up in WAW.

From the W&B playbook

At W&B, we built a growth dashboard on day one and maintained it religiously. Every channel, every cohort, every experiment tracked. The discipline of having one north star metric with a supporting dashboard is what let us debug growth problems in 48 hours instead of weeks; we knew which cohort, which channel, which funnel stage within a day of a number moving. Assign one person to own WAW. Build the dashboard before you need it.

10. Seed the Next Training Cycle

The model generation that will set the defaults in 2027 is being trained on content published in 2025 and 2026. The companies seeding it now are building structural advantages that are almost impossible to catch up to later; because you can’t go back and create 2025 training data in 2027.

Technical blog posts with complete, working code. Not marketing copy. Working code that a developer could paste and run, with your tool embedded naturally. Every piece gets indexed. Every indexed piece is training signal.

Stack Overflow answers in your category. The most-upvoted answers for the most common questions are disproportionately represented in training data. Answer 10–20 questions per quarter. Answer them better than anyone else.

Open-source integration examples. A public repository showing your product integrated with the 5–10 most common adjacent tools. Accumulates stars, forks, derivatives; all training signal.

Sponsored community tutorials. Pay developers who write tutorials to use your product as the natural choice. At W&B, we did this at scale and it was one of our highest-ROI growth investments. Those tutorials drove human adoption and built training signal simultaneously. The human growth has plateaued; the training signal is permanent.

Timeline: A few months to payoff. Entirely real. Budget this as infrastructure investment, not marketing spend. The companies that planted these seeds in 2024 are seeing the returns now.

Tier 3 – The Structural Changes

These take months and require sustained organizational commitment. They’re also the hardest to replicate once a competitor has established them.

11. Pursue Orchestrator Partnerships

Cursor, Claude Code, Lovable, Bolt, and Replit collectively set defaults for millions of projects. A product that gets included in a vibe-coding platform’s default stack is in every project that platform creates; at no marginal cost, indefinitely. This is the highest-leverage distribution play in the agent era.

Supabase’s growth from 1M to 4.5M developers was driven primarily by Bolt, Lovable, and Cursor choosing it as the default backend. That wasn’t a marketing deal. It was the result of having the lowest token-to-value for backend infrastructure: the Autonomous Loop Test passed cleanly, the MCP tooling was polished, the Agent Skills were published. Platforms choose defaults based on what causes the fewest support issues for their users. The product work comes first.

When you approach these platforms, don’t come with a pitch deck. Come with data: your First Successful Execution Rate, your First-Session Autonomous Completion Rate, a token-to-value comparison against your alternatives. These teams optimize for user success rates. Show them yours.

12. Move to Workflow-Based Pricing

If you’ve built the flywheel, per-seat pricing will actively work against you. Here’s the sequence:

1. Kill per-seat pricing for any tier where agents could plausibly be the primary user.

2. Launch a free tier requiring no credit card that lets an agent complete a real task. Agent-accessible is now a design constraint, not a feature.

3. Move paid tiers to usage-based or workflow-based pricing that captures agent-driven expansion automatically; without requiring renegotiation when an agent fleet doubles usage in a quarter.

4. Add hybrid tiers: flat base + usage overage. Enterprise buyers get budget predictability; usage captures the expansion that seat-based pricing leaves on the table.

Intercom Fin at $0.99 per resolved ticket is the reference case: $10M+ revenue in year one, perfectly aligned incentives. You get paid when the agent succeeds.

The structural reason to do this now: when your pricing unit is the workflow and your north star is Weekly Active Workflows, your growth team and your finance team are optimizing the same thing. Every experiment that moves WAW moves revenue. That alignment is rare and worth engineering for.

Where to Start

The flywheel is already spinning for some companies. It’s not spinning yet for most.

The Tier 1 items; llms.txt, MCP server, the Autonomous Loop Test, error message rewrites, doc restructuring, free tier audit; can all be done this week. Each one removes a specific wall that currently makes you invisible or inaccessible to agents. Do them in order. The Autonomous Loop Test first: it’s 30 minutes and will tell you exactly which of the other items to prioritize.

Tier 2 is the compounding work. Tier 3 is the structural work. Both require sustained commitment, and both are significantly harder if a competitor gets there first.

The window that exists right now; where most developer tools have no llms.txt, no MCP server, no Agent Skills, and no agent-accessible free tier; won’t stay open. Build the flywheel while the defaults are still being set.

“It’s 2026. Build. For. Agents.” – Andrej Karpathy

Thank you to Lukas Biewald, James Cham, Amy Tam and Phil Gurbacki for early feedback on this draft.

_________________________

Lavanya Shukla is the Managing Partner of Improbability.vc, an early-stage fund backed by Sequoia, Coatue, Village Global, Bloomberg Beta, Lukas Biewald, Adrien Treuille, and AI leaders at OpenAI, DeepMind, Turing et all.

She spent seven years running Growth and AI at Weights & Biases, scaling it from 100 users to millions, every AI engineer at every major lab, through product-led growth.

Improbability Engine’s thesis: invest in the 1–2 AI companies that matter every year. If you’re building one of them, reach out: lavanya@improbability.vc.

Improbability

Part 1: The Agent Flywheel

A developer opens Cursor and types: “add email to this app…

Read more

3 months ago · Lavanya

Improbability

Part 2: The Four Distribution Paths

If the agent flywheel is the engine, distribution is how it spins. In the human era, growth followed a few familiar paths—word of mouth, SEO, sales. In the agent era, those paths still exist, but they’ve been reshaped and multiplied…

Read more

3 months ago · Lavanya

Improbability

Part 3: The North Star: Weekly Active Workflows (WAW)

In every era of growth, there’s one metric that actually matters. At Weights & Biases, it was Weekly Returning Engaged Users. Everything we did flowed through that one number…

Read more

3 months ago · Lavanya

Improbability

Part 4: Build your Agent Growth Loop

In Part 1, 2 and 3 we talked about how the rules of growth have changed: AARRR remapped for the agent era, three loops that turn a funnel into a flywheel, and why the gap between Supabase and its competitors is widening every time a model retrains. This part is the implementation guide…

Read more

3 months ago · Lavanya

The agent doesn’t Google anything. It doesn’t compare products or check pricing pages. It just picks Resend, sets it up, and the whole thing is done in under a minute.

That happened hundreds of thousands of times last year. It’s why Resend, launched in 2023 with zero users, now has 500K developers. Their competitor, SendGrid, has been around since 2009. Twilio paid $3B for it. They have a full enterprise sales motion, dedicated IPs, and 15 years of deliverability track record.

When Claude Code adds email to a project, it picks SendGrid 7% of the time. It picks Resend 63% of the time. Nobody at Resend made this happen. Nobody at SendGrid stopped it.

I spent 7 years at Weights & Biases leading our growth efforts. We grew from 100 users to millions, every AI engineer at every major AI lab; through product-led growth. It was a product developers loved, and a meticulously optimized growth engine behind it.

That was in 2019. We were talking to other ML engineers like us, researchers at labs, practitioners at startups, academics building the next generation of models. Then one of those models learned to write the code.

The two most interesting growth stories of the past year: Supabase 1M → 4.5M developers in 12 months, Resend 0 → 500K users beating a Twilio-backed incumbent, have almost nothing to do with human-facing growth tactics. An AI agent picked both of them. Millions of times. Autonomously.

Most growth teams are still optimizing for humans. The defaults of 2027 are being set right now.

PLG Is More Important Than Ever

Every company is product-led now—but the “user” has changed. It’s no longer just a developer clicking through your UI. It’s an agent writing and running code on their behalf.

When an agent adopts your product, it doesn’t try it once. It uses it every time that task comes up—automatically, at scale, often without the human ever thinking about it again. One developer adding your MCP server to their setup can quietly turn into thousands of executions.

Your product is no longer your UI. It’s your API.

And it changes what matters. Technical superiority isn’t enough if an agent can’t easily understand how to use you. In practice, agents will choose something slightly worse if it’s easier to implement, because from their perspective, a product they can execute is strictly better than one they can’t.

Resend isn’t better email infrastructure than SendGrid for enterprise use. But it’s one command, one environment variable, and one clear doc page an agent can read and execute. At the scale agents operate, that simplicity is everything.

The Agent Flywheel – AARRR, Remapped

AARRR gave the growth community a shared vocabulary for 15 years. Before we walk through how each stage transforms, it’s worth understanding why this becomes a flywheel, not just a remapped funnel. Turning our funnel into a predictable flywheel was the reason we succeeded at growing W&B.

In a funnel, growth is linear with effort. Your team builds growth programs, users come in, some activate, some retain, and the loop starts over at the same effort level.

In a flywheel, each cycle makes the next cycle easier. Existing users create assets that help the next users discover your product with less work from you. The effort compounds down as the flywheel spins up.

From the W&B playbook

The flywheel is how we grew W&B. Developers discovered us through complementary tools, integrated W&B, built publicly, published tutorials. Those tutorials brought new developers who integrated it themselves, without us sending a single email. Each rotation made the next cheaper. By 2021, a meaningful percentage of new signups came through channels we hadn’t actively seeded in months.

The agent flywheel compounds faster and more durably. When agents successfully complete tasks using your product, those trajectories can become training data for the next model generation. More completions → stronger model memory → higher default selection → more completions. And the community loop runs in parallel: developers who succeed with your product publish their configs, other developers clone them, propagating your tool across thousands of agent deployments at once.

This is why the gap between a product like Supabase and its competitors is widening, not narrowing. Not a feature gap. A compounding flywheel.

Two terms worth defining:

• “Training memory” (parametric memory) is what a model absorbed during training, the way a doctor’s clinical knowledge comes from years of medical education, not from Googling before each patient. The model already has opinions about your product before any search begins.

• “First Successful Execution” is the first time an agent completes a task using your product end-to-end without a human intervening. It’s invisible, no session recording, no celebration screen. You have to instrument it.

Two engines, one flywheel.

Metrics by stage

The flywheel is already spinning for some category-defining companies. Every successful agent execution reinforces the next one—through training data, through community configs, through repeated use.

The rules of this competition are now clear. The window to enter it is still open.

“It’s 2026. Build. For. Agents.” – Andrej Karpathy

But that raises a deeper question: how exactly does this growth happen? If agents are the new users, what are the actual paths through which products spread?

That’s what we’ll break down next in Part 2.

Improbability

Part 2: The Four Distribution Paths

If the agent flywheel is the engine, distribution is how it spins. In the human era, growth followed a few familiar paths—word of mouth, SEO, sales. In the agent era, those paths still exist, but they’ve been reshaped and multiplied…

Read more

3 months ago · Lavanya

Thank you to Lukas Biewald, James Cham, Amy Tam and Phil Gurbacki for early feedback on this draft.

_________________________

Lavanya Shukla is the Managing Partner of Improbability.vc, an early-stage fund backed by Sequoia, Coatue, Village Global, Bloomberg Beta, Lukas Biewald, Adrien Treuille, and AI leaders at OpenAI, DeepMind, Turing et all.

She spent seven years running Growth and AI at Weights & Biases, scaling it from 100 users to millions, every AI engineer at every major lab, through product-led growth.

Improbability Engine’s thesis: invest in the 1–2 AI companies that matter every year. If you’re building one of them, reach out: lavanya@improbability.vc

Improbability

Part 2: The Four Distribution Paths

If the agent flywheel is the engine, distribution is how it spins. In the human era, growth followed a few familiar paths—word of mouth, SEO, sales. In the agent era, those paths still exist, but they’ve been reshaped and multiplied…

Read more

3 months ago · Lavanya

Improbability

Part 3: The North Star: Weekly Active Workflows (WAW)

In every era of growth, there’s one metric that actually matters. At Weights & Biases, it was Weekly Returning Engaged Users. Everything we did flowed through that one number…

Read more

3 months ago · Lavanya

Improbability

Part 4: Build your Agent Growth Loop

In Part 1, 2 and 3 we talked about how the rules of growth have changed: AARRR remapped for the agent era, three loops that turn a funnel into a flywheel, and why the gap between Supabase and its competitors is widening every time a model retrains. This part is the implementation guide…

Read more

3 months ago · Lavanya