Build Your Agent Flywheel

The practical checklist for becoming the default in your category.

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:

1. Add authentication.

2. Send transactional email.

3. Create a database.

4. Deploy an app.

5. Set up billing.

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

1. Find the product.

2. Get access.

3. Authenticate.

4. Configure.

5. Write code.

6. Run the first call.

7. Handle the first error.

8. Verify success.

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

1. A credit card is required before the first API key.

2. Email verification gates the first API call.

3. API key creation requires dashboard clicking.

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

1. What failed?

2. What should I check?

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

1. The answer in the first 100 words.

2. Exact install command.

3. Exact imports.

4. Exact environment variable names.

5. Complete working example.

6. Error handling inside the example.

7. Expected success state.

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

1. No credit card before getting an API key.

2. No email verification before the first API call.

3. Programmatic provisioning available at the free tier.

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

1. What should agents do first?

2. What anti-patterns should they avoid?

3. Which defaults work best?

4. Which integrations fail most often?

5. What should they check before shipping?

6. What should they never generate?

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

1. App framework.

2. Your SDK.

3. Adjacent tools.

4. Environment variable examples.

5. MCP configuration.

6. Agent instructions.

7. Tests or verification steps.

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

1. Weekly Active Workflows.

2. First Successful Execution.

3. Token-to-value.

4. Agent Retention.

5. Error Recovery Rate.

6. Agent versus human API call ratio.

7. Public-Code Footprint.

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

1. Technical posts with complete working code.

2. Public examples integrating your product with common adjacent tools.

3. Starter templates that developers actually clone.

4. High-quality answers to common questions in your category.

5. Community tutorials where your product is the natural default.

6. Debugging guides with exact error messages and fixes.

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

1. First Successful Execution Rate.

2. Token-to-value versus alternatives.

3. Error Recovery Rate.

4. Agent Retention.

5. Time from first call to verified outcome.

6. Support burden compared with alternatives.

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

1. A free path that lets the first real workflow complete.

2. Usage or workflow-based expansion when value scales.

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

1. Run the Autonomous Loop Test.

2. Audit the free tier.

3. Rewrite the top ten error messages.

4. Publish llms.txt.

5. Start separating agent-initiated usage from human-initiated usage.

This quarter:

1. Ship a small MCP server.

2. Restructure docs into self-contained task pages.

3. Instrument Weekly Active Workflows.

4. Publish starter templates with agent configuration.

5. Start testing workflow-based pricing.

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

Part 1: The Agent Flywheel

Part 2: The Four Distribution Paths

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

Part 4: Build your Agent Growth Loop