If an Agent Has Never Heard of You, You Don't Exist
How software spreads when humans configure agents, agents recommend tools, and defaults compound.
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.
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.
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.
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.
