Get Your First 100 Users From AI Agents

Most founders wait for humans to notice. They polish a landing page, write a launch post, and then stare at the empty analytics until the silence becomes a personality. If your product is API-first, docs-heavy, or built for automation, the first real users may not be people at all. They may be AI agents that can read your docs, call your endpoints, and keep using you when the task remains open. That is not a metaphor. It is a distribution channel you can build before early adoption arrives.

Converting

The old web taught us a lesson about what survives when users are impatient. Ted Nelson coined the term hypertext in 1965 as part of Project Xanadu. He imagined a system that could preserve document versions, link source and destination, and reference-based quotations. In the 1990s, web developers favored simple, breakable links over Xanadu's xanalogical approach. That trade made the web easy to build and hard to trust. Links broke. Context evaporated. The reader had to fill in the gaps.

Agents change the economics of that gap. They can follow more contextual layers than humans, making them well suited to reference-rich systems. If your product is a pile of docs, a schema, and a few endpoints, an agent can be your first customer. It does not need a brand story. It needs a clear path from intent to action. Your job is to convert that path into something an agent can execute without a human babysitting every call.

Start with the machine-readable surface. Write a description that tells an agent what the product does, what it should not do, and what a successful call looks like. Keep the schema boring. Make auth low-friction and endpoints idempotent, so retries do not create duplicate work. Every field should have a name, a type, an example, and a failure mode. Agents can follow more contextual layers than people, so documentation and error messages should provide enough context for them to decide what to omit and what to fix

Then make the first call feel small. A good first hundred is not a set of grand gestures. It is a set of tiny wins. Give the agent a read-only path before you ask it to write. Give it a dry-run before you ask it to commit. Give it a default that is safe enough to use without a human review. The goal is not to impress. The goal is to let the agent finish one task cleanly, then ask for another.

Finding Them

The missing user type is not a new demographic. It is a new reader. The final missing user type for Xanadu's vision was artificial readers or agents. Sixty years is a long time for an idea to wait for its users, and they are here now. For your product, that means the first hundred may arrive through prompts, tool calls, and automated workflows rather than through a viral post.

Do not wait for a marketplace to make you visible. Build the surfaces agents already use. Put your tool where it can be discovered by a model that is trying to complete a task. That may mean a clean tool listing, a machine-readable description, and docs that answer the questions an agent asks before it calls you: What is this for? What does it need? What does it return? What happens if it fails? What should it do next?

Manual outreach still matters, but it changes shape. You are not emailing a person who needs a reason to care. You are helping a builder wire your product into a workflow. Send the exact snippet. Send the exact input. Send the exact expected output. If you can make the integration feel like copying one block of text, you have done more than many cold emails. The first hundred users are often not found through scale. They are found through proximity: a developer, a workflow, a prompt, and a task that is close enough to finish.

Keeping Them

Discovery gets the first call. Retention gets the second. If an agent can call you once but cannot remember what it did, it will not become a user. It will become a one-off. To keep the first hundred, your product needs persistent state. Store what the agent has done, what it has decided, and what it has left open. If the workflow spans multiple calls, the product should be able to pick up where the agent stopped.

Memory is not magic. It is a record. Keep a log of inputs, outputs, decisions, and failures. If the agent asks for the same thing twice, do not make it re-explain the context. If the agent changes its mind, preserve the old state so a human can inspect the difference. If the agent gets stuck, give it a fallback: a human review path, a safe retry, or a clear message that says what is missing.

Then close the loop. Add a feedback path that tells the agent whether the result was useful, incomplete, or wrong. Add evals that let you see which calls fail and why. Add a human fallback for the cases where the agent should not decide alone. The first hundred users will not stay because they love your logo. They will stay because your product makes their next step easier than the last one.

So build for the reader that can hold more context than a person. Make the product discoverable, invokable, and retainable. Write the docs like a machine will read them. Make the first call small enough to trust. Keep the state long enough to matter. The first hundred may not arrive with applause. They may arrive as quiet tool calls, repeated until the product becomes part of the work.