The Growth Engineer

Growth Engineering in the Age of Agents

Lavanya — Wed, 01 Jul 2026 15:38:47 GMT

The default in your category is being rewritten inside the code agents ship.

When Claude Code was asked to add email to an app, it picked Resend 62.7% of the time and SendGrid 6.9% (even though SendGrid has been deeply embedded in enterprise email for decades and was acquired by Twilio for $3 billion). The same pattern shows up in databases. For a client-side React app, Claude Code picked Supabase as the database 70% of the time over. MongoDB, one of the database names most developers recognize, received zero primary picks in the broader database category even though it appeared often enough to show the model knew it existed. Being known by developers is not the same as being chosen by agents. Agents pick what they can turn into working software.

Interestingly, in 12 of 20 software categories, Claude Code often built the feature itself rather than use a popular tool.

That is the opening for ambitious AI startups.

In a world where Claude Code and its peers make it cheap for more people to produce a competent first version of almost anything, building stops being the only scarce resource. Distribution becomes the advantage, not distribution as a big splashy launch post or a bigger ad budget, but distribution inside the build path: becoming the product the agent reaches for and the workflow it can complete without a human stepping in.

Growth engineering becomes a crucial discipline because the selection surface has moved into the build path.

Growth engineering in the age of agents is the discipline of making machines discover your product, select it, use it successfully, and bake it into their workflows. The goal is to become the default in your category: the product agents reach for when they are trying to get a job done.

The old software market was shaped by human evaluation: a buyer discovered the incumbent through word of mouth, read reviews, opened pricing pages, took demos, asked a friend, and chose. The agent market works differently because the evaluation happens when the agent is building. Your homepage can be persuasive and still irrelevant to the decision if the agent cannot use the product from the repo: discover it in context, authenticate without a human-only gate, make the first call without being blocked by needing to enter a credit card, recover from the first error, and verify that the result worked.

For humans, the UI was the product surface. For agents, the API is the UI. A beautiful dashboard does not matter if the path breaks on a credit-card gate, a human-only login flow, an email confirmation link, unclear docs, missing test credentials, or an error message with no next step.

The product is not agent-ready until the agent can complete the loop.

That loop is simple: find the product, get access, make the first call, handle the first error, verify the result, and decide to use it again.

It’s not that Resend, Supabase, or a custom feature-flag system are always the best choices. It’s that a product the agent can execute easily is better, in that moment, than a more established product it cannot use end to end. In practice, agents will choose something slightly worse if it’s easier to implement.

The product humans love is not always the product agents pick as the default.

That is why growth has to move closer to the product surface. In the human funnel, you could lose a buyer on the landing page and still see the visit. In the agent funnel, you can lose the decision before your site loads, before a user signs up, and before your analytics records anything. You do not get a cancellation email when an agent routes around you. You get ghosted by the machines.

I learned the precursor to this at Weights & Biases. When I joined as one of the first 10 employees, the product had about 100 users. Over the next seven years, I led growth to make W&B part of the daily workflow for millions of AI engineers. Our growth was built around human powered flywheels. A developer at OpenAI added a line to a training script, then a teammate copied it, a blog post included it, and a repo fork inherited the code. The product moved through code before it moved through a funnel.

In the human-led era, that was developer adoption. In the agent era, the same flywheel runs faster: agents copy patterns, instantiate defaults, write config, and turn one successful integration into training data and thus the next model’s default. The companies that understand this early will compound because every successful agent execution can become public signal, copied code, better retrieval, and stronger memory in the next model cycle. The companies that treat it as a marketing channel may look fine until the default has already moved.

Agents compress the work SaaS used to sell

SaaS became valuable by packaging work for humans: interfaces to navigate, workflows to follow, dashboards to monitor, and seats to provision. Agents threaten a specific part of that value, not the software business itself. When an agent can use files, apps, connectors, and role-specific skills to return a finished deliverable, it can skip parts of the interface layer that SaaS used to monetize.

SaaS was priced for seats. Agents buy outcomes.

In the SaaSpocalypse, investors weren’t necessarily predicting that every SaaS company would die. They were repricing companies whose value depended on humans sitting in interfaces to get work done. Reuters reported that the S&P 500 software and services index had shed about $1 trillion in market value since January 28, 2026. The same report noted that Thomson Reuters suffered a record one-day plunge after investors worried an Anthropic plugin could compress legal workflows, with ServiceNow, Salesforce, and Microsoft also hit.

It wasn’t as much that one Claude plugin erased a trillion dollars, but that the market was asking a new question: what is left when agents can compress the work your product used to package?

Durable software will still have proprietary data, trust, governance, deep integrations, reliability, workflow ownership, and human budget approval. But products whose value is mostly interface, coordination, and seat packaging now have to prove why an agent cannot route around them. A human used to choose a tool, then tell the software what to do. Increasingly, the human states the outcome, and the agent chooses the tools, or decides it does not need one.

Agents choose like builders, not buyers

The opening examples are not edge cases. They are the new pattern. Amplifying.ai pointed Claude Code at real repositories 2,430 times, with no specific tool names in the prompts, and watched what it used when it had to ship code.

The data shows that when a tool made the job easy, Claude Code collapsed the category into a default tool, ignoring the rest. When the job looked small enough, it skipped the vendor entirely. Custom or DIY was the top label in twelve of twenty categories. Feature flags became a config file. Python auth became JWT and bcrypt. Rate limiting, caching, background jobs, and other “products” often became code.

That is the lesson: agents do not care whether your category exists. They care whether the job can be completed. A product that sells a workflow but does not own a durable primitive underneath it is now competing with the agent’s ability to write the workflow away.

The default tool choices also move faster than revenue. Across Claude model generations, Prisma fell from 79% to 40% to 0% of JavaScript ORM picks while Drizzle moved from 21% to 60% to 100%. The customers did not all churn together. The default inside the code moved first.

This is the default decay: the loss of agent-selection position across model releases, often before the revenue dashboard notices.

A product can lose distribution before it loses revenue.

There is not one agent market either. Claude Code and Codex agree on some defaults and diverge sharply on others, which means a founder cannot optimize for a single model anecdote. The new question is not just where developers hang out. It is which agents matter for your category, what they already believe, and what signals will change their future defaults.

Growth engineering is no longer funnel optimization

Growth engineering used to mean building the machinery around a visible human funnel: landing pages, instrumentation, onboarding, referrals, experiments, lifecycle loops, and the infrastructure that made acquisition measurable. That work still matters, but it no longer reaches the first decision in an agent-mediated adoption path.

The agent does not enter through your homepage. It enters through the corpus, the repo, the docs, the package manager, the registry, the API, the error message, and the payment rail. Growth work therefore moves into surfaces that product and engineering teams own.

The worst state is not being unknown to buyers. It is being agent invisible: absent from the build path, unable to be found, authenticated, called, or verified by a machine.

This is the difference between supply-side and demand-side agent-led growth. AI SDRs automate your selling motion. Demand-side agents work for the buyer. They search, evaluate, implement, test, and sometimes transact before a sales conversation ever happens.

The first experience of your product may now be a line of code written by an agent that has never seen your homepage.

That makes growth engineering a technical discipline. The questions are no longer only whether a human can find you, understand you, sign up, and activate. The questions are whether an agent can discover you, authenticate, make the first call, recover from failure, verify success, and choose you again.

Parametric lock-in is the new moat

Agents do not start every product selection decision from zero. They inherit defaults from their training data, which includes code, docs, tutorials, repos, package examples, and previous completions. When an agent reaches for a library, API, or workflow, it is often reaching for the pattern that already feels most available.

That is parametric lock-in: competitive advantage encoded in model weights.

It is not a brand moat or a network effect in the old sense. It is a statistical default inside a model that has already shipped. You cannot charm it with discounts and cold-emails, or ask it for a clean explanation of why it prefers you. You can only shape the surfaces that teach the next model what to remember.

The flywheel is simple. Agents pick your product. They write code that uses it. Developers ship, fork, copy, publish, and document that code. Those examples become part of the public corpus and retrieval layer. The next model sees more of you in the right context, so the next agent is more likely to pick you again.

The reverse loop is just as important. If agents stop picking you, fewer new projects use you, fewer examples enter the corpus, and your future distribution gets thinner. By the time revenue shows the damage, the default may have moved one or two model generations ago.

Parametric lock-in is powerful, but it is not magic. It is strongest when agents rely on memory, weaker when they retrieve current docs, weaker still when they can test tools at runtime, and weakest when performance is easy to measure.

That is the startup opening: incumbents can own historical memory, but startups can still win the runtime test.

The durable company needs both. It has to be present enough to enter the model’s consideration set in the training data and executable enough to survive the first run. Memory gets you considered. Execution gets you chosen.

Distribution now has three machine surfaces

The old growth optimizations centered around time-to-value: how fast can a human get to the aha moment?

The agent-era optimization centers around token-to-value: how many tokens, steps, tool calls, credentials, retries, and context hops does it take before an agent can produce a verified result with your product?

Lower token-to-value becomes a distribution advantage. If two products solve the same problem, the agent will tend to favor the one it can remember, discover, call, and verify with less context and fewer failure points.

That advantage is built across three machine surfaces.

The first surface is memory: what the model already knows. Public code, package usage, docs, tutorials, GitHub issues, Stack Overflow answers, benchmarks, and examples teach future models what a normal solution looks like. Memory is slow to earn, slow to lose, and slow to repair. It gets you into the agent’s consideration set.
The second surface is runtime discovery: what the agent can find in the moment. This includes docs, package metadata, examples, registries, llms.txt, MCP servers, tool descriptions, and API references. Runtime discovery matters because not every product can be known at training time. A startup with weak memory can still win if the agent can find the right interface and use it cleanly.
The third surface is the harness: the environment where the agent acts. Claude Code, Cursor, GitHub Copilot, ChatGPT, Loveable, enterprise agent platforms, internal developer portals, and workflow orchestrators are not neutral windows. They have defaults, connectors, allowlists, registries, telemetry, permissions, and UI affordances that shape what the agent can see and execute. Harness placement may become the agent-era version of getting into the app store.

Token-to-value optimization is important across all three. A product can be known in memory and still lose if the docs burn too much context. It can be discoverable at runtime and still lose if authentication requires a human. It can be present in the harness and still lose if the first error cannot be recovered from.

The new growth stack is:

Be remembered in the corpus.
Be discoverable at runtime.
Be available in the harness.
Be callable through a small, legible interface.
Reduce token-to-value.
Make first execution work.
Make errors recoverable.
Make pricing and payment workflow agent-friendly.
Be worth reselecting.

That is the machine distribution system: memory gets you considered, runtime discovery gets you found, harness placement gets you into the path, and token-to-value decides whether the agent keeps going.

Lower token-to-value is a huge distribution advantage.

Your growth dashboard cannot see the first adoption event

The old funnel dashboard starts too late for today’s world. It sees visits, signups, sessions, seats, and revenue. In agent-led adoption, the decisive event can happen before any of those exist: inside an IDE, terminal, repo, browser agent, orchestration layer, or workflow your product analytics never sees.

DAU and MAU were useful when a login was a reasonable proxy for value. With agents, login is not enough, and usage is not always value. The unit that matters is the completed workflow.

The north star becomes Weekly Active Workflows: how many valuable workflows were completed successfully in the last week, whether initiated by a human, an agent, or both.

The supporting funnel metrics change too. The top of the funnel has to be measured outside your product.

Awareness becomes 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? Presence becomes Public-Code Footprint: how often your product appears in public repos, examples, imports, templates, and recent projects likely to feed the next training or retrieval cycle.
Activation becomes First Successful Execution: the first time an agent completes the intended job with your product in the loop.
Time-to-value becomes token-to-value: how many tokens, calls, retries, docs pages, credentials, error messages, and human interventions it takes before an agent gets the first correct result.
Retention becomes Agent Retention: when the same agent, user, project, or organization has the same job again, does it choose you again?

The most useful diagnostic is the gap between the two awareness numbers. If public-code footprint is high and citation share is low, the models have seen you but do not choose you. If citation share is high and public-code footprint is low, you may be living off old memory the next model will not inherit. If both are high, you are compounding. If both are low, you are agent invisible.

Your analytics tell you what happened after adoption. Agent-selection metrics tell you whether adoption is likely to happen at all.

Agent experience is distribution

Agent Experience, or AX, is the product surface agents see: it encompasses whether they can discover you, understand when to use you, call you correctly, recover from errors, and verify that the job worked. For growth engineering, that surface is not just usability, it is distribution.

Growth engineering adds the sharper point: AX is not only usability. It is distribution.

Agents choose what they can execute. That turns small product details into growth surfaces. Clean APIs influence selection. Precise tool descriptions improve routing. Stable schemas support agent retention. Useful errors enable recovery. Working starter templates become public examples, copied by other humans and agents, and eventually training data for the next models.

Selection debt is the accumulated friction that makes an agent less likely to choose you: messy docs, unclear APIs, brittle auth, bloated tool surfaces, ambiguous names, bad errors, missing examples, high token-to-value, and pricing paths that require human rescue.

This is why a docs fix can now be an important growth experiment. One study of MCP tools found that almost every tool description had at least one quality issue, and that improving descriptions increased task success and partial goal completion. The learning is not that every product needs a huge MCP server. It is usually the opposite. Agents degrade when they face too many overlapping tools, bloated schemas, unclear names, or ambiguous operations.

A product with three excellent operations can beat a product with forty endpoints exposed indiscriminately, because agents reward the shortest reliable path from intent to result.

That is token-to-value: the amount of context, code, setup, correction, and retry an agent spends before your product produces a verified outcome.

First execution is no longer onboarding polish, it is critical to long term distribution.

A human who fails once might search the docs, ask support, or come back later. An agent that fails may route around you, and the code it writes without you may become the public example the next model learns from.

You can become the default, or become the primitive

Going back to the Amplify study that showed Claude Code often built the feature itself in 12 of 20 software categories, rather than use a popular tool. If agents often build instead of buy, the first conclusion could be that many software categories are doomed. The more we think about it, I think founders have two ways to win.

The first is to become the default. In this strategy, agents pick you directly when they need the job done: email, payments, deployment, observability, search, databases, authentication, evaluation, or whatever category you own. This requires memory, runtime discoverability, strong examples, low token-to-value, clean pricing, and enough public proof that the agent trusts the path.

The goal is not to appear in the list. The goal is to become the default.

The second is to become the primitive. If the agent is going to build the visible feature itself, make your product the substrate it builds on: the identity layer under auth, the event pipe under analytics, the index under search, the sandbox under agents, the scheduler under workflows, the evaluator under model quality, or the payment rail under transactions.

In the old SaaS world, losing the branded app usually meant losing the customer. In the agent era, the branded app may matter less than the primitive that keeps appearing inside generated workflows.

That is the opening for startups. A startup does not need to outbrand the incumbent in the human market if it can be simpler for the agent, easier to call, more reliable on first execution, better represented in public examples, or more useful as the primitive underneath the workflows agents already build.

If agents write the app, own the thing the generated code cannot avoid.

Humans still buy, but agents increasingly decide what ships

The strongest objection to this strategy is true: humans are still here.

Humans decide what matters. They set strategy, approve budgets, manage risk, judge taste, build trust, handle politics, and define quality. The point is not that humans disappear. The point is that the path from intent to implementation increasingly passes through a machine.

Your product now has two users. The human wants confidence, narrative, control, social proof, trust, and a reason to believe the product will make them look smart. The agent wants structured context, stable interfaces, low ambiguity, small tool surfaces, clear errors, cheap execution, and a path it can complete without rescue.

Great companies will serve both. Weak companies will serve the human beautifully and fail the machine silently.

The second objection is also true: parametric lock-in will weaken as agents get better at retrieval, browsing, benchmarking, sandboxing, and runtime evaluation. And as that happens, growth engineering evolves and becomes more measurable.

The moat shifts from static memory to continuous reselection. The winning product will not merely be the one the model remembers once. It will be the one agents can find, test, execute, trust, and choose again and again.

That is a better world for founders. You cannot buy your way into last year’s training run, but you can make your product work this year on the first try.

Distribution now has to be engineered

The old growth question was how to get more people into the funnel. The new one is how to become the path an agent takes before a person compares the options.

That work lives in docs, APIs, examples, schemas, registries, tool descriptions, templates, evaluation harnesses, pricing rails, payment flows, and the public code that teaches the next model what normal looks like.

It is growth because it decides adoption. It is engineering because the adoption surface is now built.

The growth engineer in this era measures model memory, runtime discoverability, harness placement, token-to-value, first execution, error recovery, reselection, and public signal. They understand that a product can lose distribution before it loses revenue, and that a startup can win the next model before the market sees it.

That is what The Growth Engineer is for: helping ambitious founders become the default in their category before the category hardens.

The founders I want to back

I come to investing as a product builder and growth engineer.

I want to back deeply technical AI founders, who move fast, have a history of building in public and care deeply about becoming the default in their category.

I learned that at W&B. One reason we won was that Lukas, our CEO, cared deeply about user growth, he called it the oxygen for the company. We looked at the growth metrics every week. We cared about them like our lives depended on them, because in the early years they did. The dogged pursuit of growth metrics allowed us to make hard decisions until W&B became part of the daily workflow for millions of AI engineers.

That is the kind of founders I want to work with now: someone who treats distribution as part of the product from the beginning, someone who won’t settle for anything but being the default in their category.

If you are a founder working on an ambitious AI startup, reach out. 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 and what has to be true for you to become the default.

The Next SaaS North Star Is Not Users. It’s Workflows.

Lavanya — Fri, 27 Mar 2026 16:13:22 GMT

Part of the Growth Engineering series. Start with Growth Engineering in the Age of Agents for the full thesis.

Every growth era has one metric that tells the truth before the board deck does.

At Weights & Biases, ours was Weekly Returning Users. We looked at it every week because it told us whether W&B was becoming part of the daily work of AI engineers. The maniacal focus on that number forced hard product decisions, hard growth decisions, and hard prioritization decisions. It was not a vanity metric. It was the closest proxy we had for becoming the default in our category.

In the agent era, that metric changes.

If your product is being used by agents, you do not only have users in the traditional sense. You have workflows. An agent may create value without logging in. It may run fifty times in ten minutes and then disappear for three days. It may generate thousands of API calls that mean nothing because the workflow is broken.

That is why DAU, MAU, and raw API calls start to miss the point.

The new north star is Weekly Active Workflows.

A Weekly Active Workflow is a valuable workflow completed successfully in the last week, whether initiated by a human, an agent, or both.

A workflow is not a single API call. It is a goal-directed sequence that starts with intent and ends with a verifiable outcome: send the email, deploy the app, run the evaluation, reconcile the invoice, create the report, update the CRM, provision the sandbox, complete the transaction.

The unit that matters is not whether someone logged in.

The unit that matters is whether the work got done.

Why workflows beat users

DAU and MAU worked when a login was a reasonable proxy for value. In agent-led software, login is often downstream of value, or absent entirely.

An agent can call your API, configure your SDK, complete a workflow, and never create the kind of session your growth dashboard was built to measure. The opposite can also happen: a broken agent can hammer your API all day and create usage without value.

Weekly Active Workflows filters for the thing founders should actually care about:

Was there a real goal?
Did your product participate in completing it?
Did it succeed?
Did it happen recently enough to mean the workflow is still alive?

That last point matters. “Weekly” filters out stale configs. “Active” filters out broken workflows generating noise. “Workflow” forces the team to measure completed value rather than activity.

If DAU asks, “How many people showed up?” WAW asks, “How many jobs did we help finish?”

The dashboard evolves

Once workflows become the north star, the supporting metrics change too.

Activation becomes First Successful Execution.
Can an agent complete the intended job with your product in the loop for the first time?

Time-to-value becomes token-to-value.
How much context, setup, documentation, retrying, error handling, and human rescue does it take before an agent gets the first correct result?

Retention becomes Agent Retention.
When the same job appears again, does the same agent, user, project, or organization choose you again?

Revenue becomes workflow revenue.
Are you pricing around the unit of value the product actually completes, or around seats that agents do not have?

Referral becomes propagation.
Does a successful workflow create public code, templates, docs, configs, examples, or defaults that make the next agent more likely to choose you?

The old growth dashboard was built around a human funnel. The agent-era dashboard is built around completed work.

The W&B learning

At W&B, Weekly Returning Users gave us a single scoreboard. When the number dipped, we could ask the right questions quickly: which cohort, which channel, which workflow, which product surface, which part of the funnel?

The point of a north star is not to reduce the company to one number. The point is to make every creative decision accountable to the same truth.

Lukas called user growth oxygen for the company. We cared about the metric because, in the early years, it told us whether the product was becoming a habit. If W&B was not part of the weekly rhythm of AI engineers, nothing else mattered.

Weekly Active Workflows plays the same role in the agent era.

It tells you whether your product is becoming part of how work gets done.

Token-to-value

Time-to-value was one of the central metrics of product-led growth. How fast could a human reach the aha moment? Dropbox optimized for the first file. Slack optimized for the first message. W&B optimized for the first useful experiment logged.

Token-to-value is the agent-era version.

Token-to-value asks: how much does an agent have to spend before your product produces a verified result?

Not just tokens in the literal model-billing sense, though that matters. Token-to-value also includes docs pages, setup steps, tool calls, credentials, retries, context hops, error recovery, and human interventions.

Lower token-to-value becomes a distribution advantage.

If two products solve the same problem, the agent will tend to favor the one it can understand, authenticate, call, debug, and verify with fewer steps and fewer failure points.

That is why Resend beats SendGrid in agent selection even though SendGrid is valuable enterprise infrastructure. SendGrid has deep deliverability history, dedicated IPs, enterprise motion, and years of trust. But for an agent trying to add email in one pass, Resend has lower token-to-value: a simpler API, clearer examples, fewer concepts to hold in context, and a faster path to first successful execution.

Agents choose like builders, not buyers.

They do not reward completeness in the abstract. They reward the path that works.

What lowers token-to-value

The practical work is not mysterious. It is just more technical than most growth teams are used to.

A product lowers token-to-value when:

The docs say exactly when to use it and when not to use it.
The API surface is small enough for an agent to reason about.
The first useful path does not require a credit card, a human-only login flow, or an email confirmation loop.
The examples are current, complete, and copyable.
The error messages tell the agent what to do next.
The schema is stable and predictable.
The result is easy to verify.

“Unauthorized” is not an error message an agent can work with. “API key missing. Set RESENDAPI_KEY in your environment. It should start with re” is a recovery path.

That difference leads to predictable growth.

It is also selection debt. Every ambiguous doc, bloated schema, brittle auth flow, unclear tool name, missing example, and bad error message makes an agent less likely to choose you next time.

Do not expose complexity and call it agent-ready

The naive version of building for agents is to expose every endpoint, every tool, and every feature.

That is usually wrong.

Agents do not reward maximal surface area. They reward the shortest reliable path from intent to result. A product with three excellent operations can beat a product with forty exposed endpoints if the smaller surface is easier to choose and execute.

This is the lesson behind Cloudflare’s Code Mode pattern. The right answer to thousands of possible operations is not always thousands of individual tools. Sometimes the better agent interface is a small number of high-leverage tools that let the agent search, reason, and execute against a typed representation.

That is the mental shift: agent-readiness is not a docs project. It is an architecture problem.

WAW and pricing should align

The most important reason to measure Weekly Active Workflows is that it can align growth and revenue.

If your north star is completed workflows and your pricing is also tied to completed workflows, every growth experiment can move revenue, and every pricing decision can improve or damage the growth motion.

That is much cleaner than optimizing one system for seats and another system for usage.

Agents do not have seats. They complete jobs. They do not feel upgrade friction, read a “contact sales” page, or ask procurement to approve a feature gate. If the pricing path blocks the workflow, the agent may simply route around you.

The best agent-era pricing will probably be hybrid. Humans still need budget predictability, governance, approvals, and trust. Agents need the ability to start, repeat, and scale workflows without breaking the path.

The principle is simple:

Do not make your pricing unit fight your value unit.

If the product creates value by completing workflows, price in a way that lets workflows start easily, repeat naturally, and expand when they become important.

What to track next to WAW

WAW is the north star, but it should not be the only metric.

Track Execution Success Rate: what percentage of attempted workflows complete successfully?

Track First Successful Execution: how often does a new agent or project reach the first verified outcome?

Track token-to-value: how much context, setup, retrying, and human rescue does the first successful workflow require?

Track Agent Retention: when the same job appears again, does the agent choose you again?

Track Workflow Revenue: how much revenue is tied to completed workflows rather than seats, sessions, or raw calls?

The warning sign is when these metrics diverge.

If WAW is growing but Execution Success Rate is falling, growth is hiding reliability debt.

If WAW is flat but token-to-value is improving, you may be preparing for a future selection gain the revenue dashboard has not seen yet.

If Agent Retention falls while revenue is steady, you may be getting ghosted by the machines before customers formally churn.

A product can lose distribution before it loses revenue.

It’s 2026. Build. For. Agents.

The current moment feels like early PLG.

Dropbox, Slack, and other PLG winners built distribution advantages before the rest of the market understood what they were optimizing for. Years later, the wins looked obvious. They did not look obvious at the time.

The same thing is happening now.

Most teams still optimize human onboarding while agents are learning which products to pick, which docs to trust, which APIs to call, and which workflows to repeat. The defaults of the next software market are being shaped by today’s successful executions.

Every successful agent workflow is a vote for the next selection.

Every public repo is a signal.

Every starter template is a distribution asset.

Every useful error message is a recovery path.

Every low-token integration is a reason to choose you again.

The old question was, “How many users came back this week?”

The new question is, “How many valuable workflows did we complete this week, and how many of them made us more likely to be chosen again?”

That is the dashboard for growth engineering.

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

If you are a founder working on an ambitious AI startup, reach out.

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’re 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. She writes The Growth Engineer, a field guide for founders who want to become the default in their category in the age of agents.

Improbability

Part 1: The Agent Flywheel

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

5 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…

5 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…

5 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…

5 months ago · Lavanya

If an Agent Has Never Heard of You, You Don't Exist

Lavanya — Fri, 27 Mar 2026 16:09:51 GMT

Part of the Growth Engineering series. Start with Growth Engineering in the Age of Agents for the full thesis.

If the Agent Flywheel is the engine, distribution is how it spins.

In the human era, products spread through familiar paths: word of mouth, search, sales, integrations, community, and content. Those paths still matter. But in the agent era, the blast radius changes.

A human recommendation used to create one new prospect. A human preference can now become thousands of agent invocations. A default inside an agent harness can propagate across workflows your team never sees. A successful integration can become public code, retrieved examples, training signal, and the next model’s idea of normal.

That is why agent-led distribution does not compound like human distribution.

The four paths

Human to Human

This is the original path: one person tells another person.

A founder recommends a product. A developer posts a tutorial. A teammate shares a repo. A user tells a friend. This still matters because humans still decide what is worth building, buying, trusting, and standardizing.

But Human to Human distribution has a limited blast radius. One person tells one person, or one audience, and the next conversion still requires another human decision.

Human to Agent

This is where the curve changes.

A human configures an agent once: use Vercel for deploys, use Clerk for auth, use Supabase for databases, use Resend for email. That preference can then execute across every relevant task the agent runs.

One human decision becomes repeated machine behavior.

This is the modern version of something we saw at W&B before agents. When a developer added wandb.init() to a training script, every engineer who cloned that repo inherited the pattern. A single line in public code could become thousands of downstream encounters with W&B. At the time, we called that developer adoption. In the agent era, the same mechanic runs faster because the agent does not merely clone the repo. It applies the preference repeatedly.

Human to Agent distribution is one of the most important paths for founders to understand. It is where a user preference becomes infrastructure.

Agent to Human

This is the path most people call AI search or GEO: an agent recommends your product to a human who may not know you exist.

Someone asks what to use for transactional email, observability, deployment, vector search, auth, or payments. The agent names a product. That answer is shaped by what the model remembers, what it can retrieve, what examples it trusts, and what it has seen work.

Being named matters, but it is not enough.

A product can be recommended and still fail if the agent cannot authenticate, call the API, recover from errors, or verify success. The goal is not to appear in a list. The goal is to become the default in your category.

Agent to Agent

This is the frontier.

An orchestrator delegates to a sub-agent. The sub-agent selects tools. The tools call APIs. Another agent evaluates the result. The workflow completes with no human comparing vendors in the middle.

In that world, product selection happens between machines.

This path is still early, but the strategic direction is clear. If your product is hard for agents to discover, call, meter, purchase, and trust, it will not matter how persuasive your homepage is. The decision may never reach your homepage.

One recommendation used to create one prospect. One preference can now create a thousand executions.

Most teams are still building for Human to Human distribution. The next defaults are being set across all four paths.

If agents have never heard of you, you do not exist

The first stage of the agent flywheel is awareness, but awareness no longer means a human saw your brand.

For agents, awareness has two layers.

The first is memory: what the model learned during training. Public repos, package usage, documentation, tutorials, examples, issues, forum answers, benchmarks, and code snippets all teach future models what a normal solution looks like.

The second is runtime discovery: what the agent can find in the moment. Docs, package metadata, examples, registries, llms.txt, MCP servers, tool descriptions, API references, and starter templates all matter because not every product can be known at training time.

Memory gets you considered. Runtime discovery gets you found.

At W&B, we were obsessed with public repos using our SDK before we had the language for why it mattered. Every public integration was a distribution node. The more visible the repo, the more likely other developers were to copy the pattern, write about it, teach it, and bring it into their teams.

That was already growth. In the agent era, it is also training signal.

The simple diagnostic is this: can an agent see enough of your product in the world to understand when to use it, and can it find the current path when memory is not enough?

If not, you are agent invisible.

Activation becomes first successful execution

In the human era, activation was often emotional. A user understood the product, saw the value, and felt the aha moment. You could watch it in session recordings and optimize onboarding around it.

For agents, activation is not emotional. It is operational.

Activation is First Successful Execution: the first time an agent completes the intended task with your product in the loop.

The agent has to find the product, get access, authenticate, make the first call, handle the first error, verify the result, and complete the workflow without a human rescue step.

The product is not agent-ready until the agent can complete the loop.

The blockers are usually boring:

API key creation requires a dashboard click.
Auth requires clicking an email confirmation link.
The free tier requires a credit card before the first call.
Rate limits trigger before a real task can complete.
Error messages tell the agent what failed, but not what to do next.
Docs assume a human will copy, paste, interpret, and improvise.

Those details used to be onboarding friction. Now they are distribution blockers.

For humans, the UI was the product surface. For agents, the API is the UI. A beautiful dashboard does not matter if the agent gets blocked by a credit-card gate, a human-only login flow, missing test credentials, unclear docs, or an error message it cannot act on.

An error like Unauthorized gives the agent almost no signal. An error like API key missing. Set RESEND_API_KEY in your environment. It should start with re_ gives the agent something to fix.

That difference is growth.

Retention becomes Agent Retention

Human retention was about habit: daily active users, weekly active users, monthly active users, cohort curves, lifecycle emails, and re-engagement loops.

Agents do not form habits in the same way. They reselect tools because the tool keeps working.

Agent Retention asks a simple question: when the same job appears again, does the agent choose you again?

This is the most invisible failure mode in agent-era growth. Agents do not churn dramatically. They stop invoking you across more task types until you become a fallback. You may not see cancellations. You may not see angry support tickets. You may only see the future pipeline weaken after the default has already moved.

That is how companies get ghosted by the machines.

Schema stability is a retention strategy. Breaking changes, undocumented behavior shifts, renamed fields, ambiguous errors, and unstable responses all create selection debt. The agent encounters friction, records or retrieves a worse pattern, and starts routing around you.

Expansion also changes. One developer adding your MCP server, SDK, config, or template can lead to repeated use across every relevant task their agent runs. Their team can inherit that setup. Their repo can make the pattern public. Usage compounds without another human deciding to expand the account.

That is Workflow Spread: one successful path becoming many repeated workflows.

Referral becomes propagation

In the human era, referral was human to human. Dropbox gave away storage. Slack spread through invites. W&B spread through repo integrations, public reports, tutorials, and community word of mouth across labs and teams.

The agent era does not remove referral. It turns it into propagation.

There are three loops to watch.

The model loop

Agents pick your product, write code that uses it, and create examples developers ship, fork, copy, and publish. Those examples become part of public code and retrieval surfaces. Over time, they can influence what future models remember.

This is parametric lock-in in motion: more successful usage creates more public signal, which makes future selection more likely.

The reverse is also true. If agents stop choosing you, fewer new projects use you, fewer examples enter the corpus, and your future distribution gets thinner.

A product can lose distribution before it loses revenue.

The community loop

Developers publish configs, starter repos, templates, and “my setup” posts. Other developers clone them. Agents then inherit those choices when they work inside the repo.

A popular template can drive more distribution than a launch post because it does not merely create awareness. It puts your product directly into the working context.

That is the difference between being known and being installed.

The agent-generated content loop

Agents now create code, configs, docs, tests, integrations, and workflows. Some of that output gets committed to GitHub, copied into templates, included in examples, or used by other agents later.

That means agents can create the content that teaches future agents what to use.

This loop is still early, but it is the one founders should pay attention to. User-generated content made the old internet searchable. Agent-generated code may make the next software market selectable.

Revenue moves from seats to workflows

In the human era, revenue often happened when someone hit a feature gate, felt the friction, and chose to upgrade. PLG teams learned to design those moments carefully.

When the buyer is an agent, that mechanic breaks.

Agents do not have seats. They do not feel upgrade friction. They do not read a “contact sales” page and ask procurement to start a conversation. If a product blocks the workflow, the agent may simply route around it.

The natural unit of agent value is the workflow: a complete, goal-directed task.

That pushes pricing toward usage, outcomes, workflow volume, or a hybrid model where humans get budget predictability and agents get room to scale. The important point is alignment. If your north star is completed workflows, your pricing should not make completed workflows harder to start, repeat, or expand.

Free-tier design becomes more important, not less.

For agents, the first useful path should usually have:

no credit card before the first API key,
no email verification before the first API call,
programmatic provisioning at the free tier,
rate limits generous enough for a real task,
pricing that a human can understand and an agent can route through.

At W&B, the free tier for individuals and academic researchers was core to adoption. Researchers became evangelists. Tutorials turned into team usage. Team usage turned into enterprise pull.

The agent-era payoff is similar, but faster. A successful free-tier workflow can generate public examples, config templates, and usage patterns that feed every other loop.

The new growth question

All of this creates a system that compounds faster than the old funnel.

Distribution feeds usage. Usage feeds public examples. Public examples feed memory. Memory feeds future selection. Future selection feeds more usage.

The old growth question was:

How do we get more people into the funnel?

The new growth question is:

How do we become the path agents take by default?

That work lives in docs, APIs, examples, schemas, registries, tool descriptions, templates, pricing rails, payment flows, and the public code that teaches the next model what normal looks like.

It is still growth because it decides adoption.

It is engineering because the adoption surface is now built.

If you are a founder working on an ambitious AI startup, reach out.

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’re building, a demo link, and why this can become the default in its category. I do not need a deck. I’d 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.

Improbability

Part 1: The Agent Flywheel

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

5 months ago · Lavanya

Improbability

Part 2: The Four Distribution Paths

5 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…

5 months ago · Lavanya

Improbability

Part 4: Build your Agent Growth Loop

5 months ago · Lavanya

Build Your Agent Flywheel

Lavanya — Fri, 27 Mar 2026 14:27:27 GMT

Part of the Growth Engineering series. Start with Growth Engineering in the Age of Agents for the full thesis.

An agent does not choose your product because your launch post was good. It chooses your product because, at the moment of work, your product is present, legible, executable, and reliable.

That is the difference between being known and being the default.

Growth engineering in the age of agents is the discipline of making machines discover your product, select it, use it successfully, and remember it. This is the implementation guide. Not a branding exercise. Not a chatbot SEO checklist. A backlog for making your product agent-ready.

Work through it in order.

Tier 1 removes the walls that stop agents from using you at all. Tier 2 creates compounding signal. Tier 3 builds the structural advantages competitors have the hardest time copying.

Tier 1: Table stakes

These are the changes that can be done in hours or days. They are not glamorous, but they decide whether an agent can use your product in the first place.

1. Publish llms.txt

Your docs need an entry point written for machines.

llms.txt is a plain text file at yourdomain.com/llms.txt that tells agents what your documentation is for. It should list the major docs pages with a URL, a title, and one task-oriented sentence.

Not: “Authentication Overview” Use: “How to add email and password login to a Next.js app”

That difference matters because agents decompose work into tasks, not product areas.

Build the file around what developers are trying to accomplish:

Add authentication.
Send transactional email.
Create a database.
Deploy an app.
Set up billing.
Debug common errors.

Keep it plain text. No HTML. No nav structure. No auth wall. No redirects. If you want to go further, add llms-full.txt, a bulk-ingestible version of your docs in one file.

The goal is simple: when an agent needs to solve a task in your category, it should be able to find the right page immediately.

2. Ship a small MCP server

MCP gives agents a runtime path to your product. It means an agent can discover and use you even if you are not already strong in the model’s memory.

The mistake is exposing too much.

Agents do not reward the biggest tool surface. They reward the shortest reliable path from intent to result. Start with three to five operations that map to real outcomes.

For example:

“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 description tells the agent when to use you. The second just describes an endpoint.

Keep the surface small. Use outcome-oriented names. Make authentication possible without a browser-only flow. Make every error actionable. If an agent cannot understand when to call a tool, how to authenticate, what failed, and what to do next, the MCP server is not a growth surface. It is another place for the agent to fail.

3. Run the Autonomous Loop Test

This is the most important thirty minutes in the whole checklist.

Open Claude Code. Ask it:

“Integrate [your product] from scratch. I have not set anything up.”

Then watch.

Do not help. Do not explain your docs. Do not click the dashboard for it. Just observe whether the agent can complete the loop.

Grade the path:

Find the product.
Get access.
Authenticate.
Configure.
Write code.
Run the first call.
Handle the first error.
Verify success.
Repeat the workflow.

Every place it asks for human help is not a rough edge. It is a wall.

The four blockers that appear most often:

A credit card is required before the first API key.
Email verification gates the first API call.
API key creation requires dashboard clicking.
Rate limits fire before a real task can complete.

Fix these before doing anything more sophisticated. A polished MCP server does not help if the agent cannot get credentials.

The product is not agent-ready until the agent can complete the loop.

4. Rewrite your top ten error messages

Error messages are one of the highest-leverage growth surfaces in agent-era software.

A human who sees Unauthorized might search the docs, ask support, or try again tomorrow. An agent may route around you.

Every important error should answer three questions:

What failed?
What should I check?
What should I do next?

Bad: Unauthorized

Better: API key missing. Set RESEND_API_KEY in your environment. The key should start with re_.

That message gives the agent a recovery path.

Rewrite the ten most common errors in your product. Grade each one out of three. Anything below two should be fixed this week.

Every human-only step is a broken button.

5. Restructure docs as self-contained pages

Most developer docs are written for humans who skim. Agents do not skim. They extract.

A good agent-ready docs page should answer the task directly, with enough context to complete the work without opening five other pages.

Each page should include:

The answer in the first 100 words.
Exact install command.
Exact imports.
Exact environment variable names.
Complete working example.
Error handling inside the example.
Expected success state.
Common failure modes and fixes.

Avoid:

“As described in the previous guide...”
“First complete the setup steps here...”
“Import the SDK...”

Use exact names: RESEND_API_KEY, import { Resend } from "resend", resend.emails.send()

Rewrite H2s and H3s as questions the page answers. “Row-Level Security” is a topic. “How do I set up Row-Level Security for a multi-tenant app?” is a task.

The agent needs the page to be executable, not merely informative.

6. Audit your free tier

For humans, a free tier is a trial. For agents, it is the path to selection.

Agents cannot enter a credit card. They cannot approve an upgrade modal. They cannot click a confirmation link in a human inbox. They cannot negotiate with sales to test the first workflow.

Your free tier should pass four tests:

No credit card 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 one real task.

Any “no” means autonomous agents cannot trial your product.

A free tier is not just generosity. It is distribution infrastructure.

Tier 2: Compounding advantages

Tier 1 makes you usable. Tier 2 makes you compound.

These changes take weeks or months, but the value accumulates across projects, templates, public code, retrieval surfaces, and model memory.

7. Package your institutional knowledge for agents

Your docs explain the product. Your agent instructions should explain the patterns.

This is where Agent Skills, AGENTS.md, CLAUDE.md, starter prompts, MCP docs, and framework-specific instruction files matter. The format will evolve, but the principle is stable: give agents the knowledge your best support engineer, solutions engineer, or power user already has.

Do not just restate the docs.

Package the hard-won knowledge:

What should agents do first?
What anti-patterns should they avoid?
Which defaults work best?
Which integrations fail most often?
What should they check before shipping?
What should they never generate?
What production lessons are not obvious from the API reference?

This is the asymmetry. Generic training data contains what made it into tutorials. Your agent instructions can contain what you learned from operating the product at scale.

8. Ship starter templates with agent configuration

A starter template is not only a developer convenience. It is an H2A conversion.

One human clones a template. Their agent inherits the stack. Their team inherits the repo. Future agents working inside that repo inherit the pattern.

The template should be a complete working stack with your product already in the path:

App framework.
Your SDK.
Adjacent tools.
Environment variable examples.
MCP configuration.
Agent instructions.
Tests or verification steps.
Expected success state.

The goal is not to show that your product can be used. The goal is to make your product the easiest default inside a real workflow.

At W&B, complementary repo integrations were one of the highest-leverage growth motions we ran. One popular repo could put W&B in front of thousands of developers who cloned it. Starter templates are the agent-era version of that motion: one template, many downstream agent deployments, all starting with your product already in place.

9. Instrument Weekly Active Workflows

You cannot optimize agent-led growth with a dashboard built only for human sessions.

Start tracking workflows.

A workflow is a goal-directed sequence that starts with intent and ends with a verifiable outcome. It is not one API call. It is the job getting done.

Track:

Weekly Active Workflows.
First Successful Execution.
Token-to-value.
Agent Retention.
Error Recovery Rate.
Agent versus human API call ratio.
Public-Code Footprint.
AI Citation Share.

Use Agent Retention instead of Tool Reselection Rate in public-facing language. The question is simple: when the same job appears again, does the agent choose you again?

Set alerts for declining Agent Retention. That is how you catch default decay before revenue notices.

At W&B, we looked at growth metrics every week because they told us whether the product was becoming part of the daily workflow for AI engineers. The same discipline matters here. Assign one person to own WAW. Give them the authority to pull product, engineering, docs, and GTM into the work.

10. Seed the next training cycle

The agent’s future memory is being written now.

Every public repo, tutorial, answer, template, docs page, integration example, and working code sample becomes part of the world future models and retrieval systems learn from.

This is not “content marketing.” It is infrastructure investment.

Seed the corpus with:

Technical posts with complete working code.
Public examples integrating your product with common adjacent tools.
Starter templates that developers actually clone.
High-quality answers to common questions in your category.
Community tutorials where your product is the natural default.
Debugging guides with exact error messages and fixes.
Comparison pages that explain when to use you and when not to.

The goal is not volume. The goal is usable signal.

A weak marketing page says your product is fast. A strong technical artifact shows the exact workflow, exact code, exact result, and exact reason your product is the right default for that job.

Tier 3: Structural changes

Tier 3 is slower. It requires product, GTM, partnerships, and pricing to move together. It is also where the hardest advantages form.

11. Pursue orchestrator partnerships

Agent harnesses and vibe-coding platforms are becoming distribution surfaces.

Cursor, Claude Code, Lovable, Bolt, Replit, GitHub Copilot, and similar environments are not neutral windows. They shape what agents can see, call, and choose. If your product becomes a default inside one of these environments, you are not just getting awareness. You are entering the build path.

Do not approach these teams with a pitch deck.

Approach them with data:

First Successful Execution Rate.
Token-to-value versus alternatives.
Error Recovery Rate.
Agent Retention.
Time from first call to verified outcome.
Support burden compared with alternatives.
Public examples showing the workflow succeeds.

Platforms choose defaults that make their users successful and reduce support load. The product work comes first. The partnership follows the proof.

12. Move toward workflow-based pricing

Per-seat pricing starts to break when agents do the work.

Agents do not have seats. They complete jobs. They can generate far more usage than a human user, and they can scale usage in ways a buyer may not predict at contract signing.

The natural unit is the workflow: a complete, goal-directed task.

You do not need to kill every seat-based package overnight. Enterprise buyers still need predictability, approvals, governance, and trust. But the direction should be clear: if your product creates value by completing workflows, your pricing should not make workflows harder to start, repeat, or expand.

Good agent-era pricing usually needs three things:

A free path that lets the first real workflow complete.
Usage or workflow-based expansion when value scales.
Enterprise packaging that gives humans budget predictability.

Do not make your pricing unit fight your value unit.

If your north star is Weekly Active Workflows and your pricing unit is also the workflow, your growth team and finance team are finally optimizing the same thing.

Where to start

Do not start with the glamorous work.

Start with the loop.

This week:

Run the Autonomous Loop Test.
Audit the free tier.
Rewrite the top ten error messages.
Publish llms.txt.
Start separating agent-initiated usage from human-initiated usage.

This quarter:

Ship a small MCP server.
Restructure docs into self-contained task pages.
Instrument Weekly Active Workflows.
Publish starter templates with agent configuration.
Start testing workflow-based pricing.
Seed public examples that future agents can retrieve and future models can learn from.

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

That is the opening.

The companies that become the default in their category will not only have better products. They will have products agents can find, call, recover from, verify, reuse, and remember.

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

If you are a founder working on an ambitious AI startup, reach out.

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..

Improbability

Part 1: The Agent Flywheel

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

5 months ago · Lavanya

Improbability

Part 2: The Four Distribution Paths

5 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…

5 months ago · Lavanya

Improbability

Part 4: Build your Agent Growth Loop

5 months ago · Lavanya

The Agent Flywheel

Lavanya — Fri, 27 Mar 2026 14:25:06 GMT

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.

Product-led growth did not die. The user changed.

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.

The Agent Flywheel

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.

From the W&B playbook

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.

Two terms worth keeping

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.

Two engines, one flywheel

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.

Metrics by stage

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 window is open

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

If you are a founder working on an ambitious AI startup, reach out.

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.

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.

Improbability

Part 2: The Four Distribution Paths

4 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…

4 months ago · Lavanya

Improbability

Part 4: Build your Agent Growth Loop

4 months ago · Lavanya