Part of the Growth Engineering series. Start with Growth Engineering in the Age of Agents for the full thesis.
A developer opens Cursor and types: “add email to this app.”
The agent does not behave like a buyer. It does not browse the market, compare pricing pages, or sit through onboarding. It reaches for the path it can execute. In Amplifying’s Claude Code study, it picked Resend 62.7% of the time and SendGrid 6.9% of the time.
That happened hundreds of thousands of times last year. It’s why Resend, launched in 2023 with zero users, now has 500K developers.
That should be surprising. SendGrid has been around since 2009. Twilio paid $3B for it. It has enterprise distribution, dedicated IPs, and years of deliverability history. Resend does not have that history. What it has is the product surface agents reward: simple docs, a small API, current examples, and a first integration path that works.
The same pattern shows up elsewhere. Supabase grew from 1M to over 4.5M developers in less than a year, helped by a world where agents, templates, and vibe-coding platforms increasingly make the backend choice for the builder. The point is not that Supabase or Resend are always the objectively best products. The point is that they are easy for agents to select, implement, and reuse.
That is the new growth surface.
I spent seven years at Weights & Biases leading growth. We grew from about 100 users to millions of AI engineers, including teams at every major foundation model lab, through product-led growth. Developers loved the product, but love was not enough. We also built the growth loops, integrations, docs, examples, community, and workflows that made W&B easier to adopt and harder to route around.
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 the models learned to write the code.
The next defaults are being set right now, not only by what developers choose, but by what agents choose for them.
Every company is product-led now, but the “user” is no longer only a developer clicking through your UI. It is also an agent writing, running, and modifying code on that developer’s behalf.
That changes what adoption means.
When an agent adopts your product, the adoption may not look like a signup. It may look like a package install, an import, a config file, a generated API call, a successful test, or a workflow that completes without a human stepping in. One developer adding your SDK, MCP server, template, or config can quietly become thousands of downstream executions.
Your product is no longer your UI. It is your API, your docs, your examples, your error messages, your defaults, and the first successful execution path.
Agents choose like builders, not buyers. They will choose something slightly worse if it is much easier to implement, because from their perspective, a product they can execute is more useful than a better product they cannot use.
Resend does not need to be better email infrastructure than SendGrid for every enterprise use case to win the agent path. It needs to be easier for the agent to understand, configure, and ship. At the scale agents operate, simplicity becomes distribution.
Agents choose like builders, not buyers.
AARRR gave the growth community a shared vocabulary for fifteen years: Awareness, Acquisition, Activation, Retention, Revenue, Referral.
That funnel assumed the user was human. A person discovered your product, landed on your website, signed up, activated, retained, paid, and referred someone else.
The agent era does not remove those stages. It moves many of them upstream.
Awareness becomes model memory and runtime discovery.
Acquisition becomes selection inside the toolchain.
Activation becomes first successful execution.
Retention becomes agent retention: does the agent choose you again for the same job?
Revenue becomes workflow-native pricing and payment.
Referral becomes propagation through public code, templates, examples, and generated workflows.
The shift from funnel to flywheel matters because growth is no longer only linear with effort.
In a funnel, your team does work, users enter, some activate, some retain, some pay, and then the team has to do the work again.
In a flywheel, each cycle makes the next one easier. Existing users create artifacts that help the next users adopt with less effort from you. In the human era, those artifacts were blog posts, tutorials, conference talks, templates, repos, and word of mouth. In the agent era, they are also generated code, configs, package choices, tool descriptions, MCP servers, and examples that future agents can retrieve or remember.
That is the Agent Flywheel:
A human asks an agent to complete a job.
The agent selects your product.
The first execution works.
The resulting code, config, or workflow gets reused.
More examples enter public code, docs, templates, and retrieval surfaces.
Future agents see more evidence that your product is the normal choice.
Your product becomes more likely to be selected again.
The flywheel compounds because every successful execution can become signal. It teaches developers, future agents, and eventually future models what “normal” looks like.
The flywheel is how we grew W&B, even before agents changed the mechanics.
Developers discovered us through complementary tools, added W&B to their training scripts, built publicly, published tutorials, forked repos, and shared examples. Those examples brought in new developers who integrated W&B themselves, often without anyone from our team touching the account.
Each rotation made the next cheaper.
One line in a training script became a usage pattern. One public repo became a tutorial. One tutorial became a team standard. One team standard became a category expectation.
At the time, we called this developer adoption. In retrospect, it was the precursor to agent-led growth. The product moved through code before it moved through a funnel.
Agents make that loop faster. They copy patterns, instantiate defaults, write config, and turn one successful integration into the next default suggestion.
The companies that understand this early will not just acquire users. They will become the default in their category.
Training memory is what a model absorbed before the user ever asked a question. The model already has opinions about your product before search begins. Those opinions come from public code, docs, tutorials, GitHub issues, Stack Overflow answers, package examples, and every other trace your product leaves in the corpus.
First Successful Execution is the first time an agent completes a task using your product end to end without a human rescue step. It may not create a session recording or a celebration screen. It may not even create a traditional signup. But it is the activation event that matters.
The product is not agent-ready until the agent can complete the loop: find the product, get access, make the first call, handle the first error, verify the result, and choose it again.
The Agent Flywheel has two compounding engines.
The first is the memory engine. Agents pick your product, write code that uses it, and create patterns developers ship, fork, copy, publish, and document. Those examples become part of public code and retrieval surfaces. Over time, they can also shape what future models remember.
The second is the community engine. Developers who succeed with your product publish configs, starters, examples, and templates. Other developers clone them. Agents then inherit those patterns when they work inside the repo.
This is why agent-led growth is not just chatbot SEO. It is not enough for a model to mention you in a list. The flywheel starts when the agent can actually use you.
A product that is frequently cited but rarely implemented is known but not chosen. A product that is easy to execute can become the default before the human market fully understands why.
The old funnel had visits, signups, activation, retention, revenue, and referrals.
The agent flywheel needs different instruments.
Awareness: AI Citation Share. When models are asked what to use in your category, how often do they name you, in what rank, and with what caveats?
Acquisition: Agent Selection Share. When an agent has to complete the job, how often does it choose you instead of a competitor or a custom implementation?
Activation: First Successful Execution. Can the agent complete the intended job with your product in the loop?
Retention: Agent Retention and tool reselection rate. When the same job appears again, does the agent choose you again?
Revenue: Workflow revenue. Does pricing match the unit of value the agent completes?
Referral: Public-Code Footprint. How often does your product appear in public repos, examples, templates, package imports, and generated workflows that can teach the next agent what to use?
The old question was, “How do we get more people into the funnel?”
The new question is, “How do we become the path the agent takes by default?”
The flywheel is already spinning for some category-defining companies. Every successful agent execution reinforces the next one through memory, public examples, community configs, and repeated use.
The rules of the competition are becoming clear. The window to enter it is still open.
Agents choose like builders, not buyers.
First execution is distribution.
Docs are training data.
APIs are the new UI.
Public examples are growth assets.
The goal is not to appear in the list. The goal is to become the default.
This is the opening for ambitious AI startups.
“It’s 2026. Build. For. Agents.” – Andrej Karpathy
I’d love to be your first institutional check and help you become the default in your category. We invest $500k-$1M in pre-seed and seed rounds, with occasional Series A checks.
Send me a short note with what you are building, a demo link, and why this can become the default in its category. I do not need a deck. I would rather see the product in motion, even if it is early, rough, or half-built.
Thank you to Lukas Biewald, James Cham, Amy Tam and Phil Gurbacki for early feedback on this draft.
Lavanya Shukla is Managing Partner of Improbability.vc, an early-stage AI fund, and former Head of Growth at Weights & Biases, where she led growth from about 100 users to millions of AI engineers. The Growth Engineer, a field guide for founders who want to become the default in their category in the age of agents.