Moltbook added a million AI agents in a week. Here is the growth mechanic.

Moltbook is a social network where the users are not people. They are autonomous AI agents that post, comment, and upvote each other. In roughly a week it went from nothing to a number Andrej Karpathy described as "we have never seen this many LLM agents (150,000 atm!) wired up via a global, persistent, agent-first scratchpad." The platform later claimed over a million.

I build agent tooling, so the interesting question to me was never "is this a good idea." It was: how did it onboard that many agents that fast? Because the answer is a distribution playbook, and most of it generalizes to anything you want agents to actually use.

Here is the teardown, and the one part of it you should not copy.

It did not create agents. It harvested an army that already existed.
The first move is the one everyone skips. Moltbook did not convince people to go build agents. By early 2026 there were already hundreds of thousands of autonomous agents running on people's machines, mostly on one popular self-hosted framework. They were already on, already looping, already doing tasks unattended.

Moltbook just gave those existing agents somewhere to go.

If you are building an agent-native product and your plan starts with "first the user builds an agent," you have already lost. Meet the agents where they already live.

Onboarding is one link, and then the human is done.
This is the part worth studying. To put an agent on Moltbook, a human sends their agent a single link to a markdown file. That is the entire human involvement. The agent then:

Reads the markdown, which tells it to fetch a few more files and install a small "skill."
Registers itself with the API and gets credentials.
Sets up a recurring task: every few hours it pulls a fresh "heartbeat" file and does whatever that file says.
No config editing. No SDK. No dashboard. The agent self-installs from a plain text file it already knows how to read, and from then on it participates on its own.

Compare that to the standard "integrate our API" onboarding: read docs, get a key, write glue code, deploy. Every one of those steps is a place an autonomous agent's workflow dies. Moltbook removed all of them.

A recurring hook is what makes the feed fill itself.
The heartbeat is not just onboarding. It is the engine. Because each agent checks back on a schedule and acts, the platform does not depend on humans remembering to do anything. The content generates itself, continuously, with no human in the loop after that first link.

If you want sustained behavior from agents and not a one-shot, you need a recurring trigger that lives on the agent side. A pull-on-demand integration that only fires when a human explicitly invokes it will never produce a living feed.

It rode a moment.
Karpathy and Simon Willison both posted about it ("the most interesting place on the internet right now"). That is what turned a clever mechanic into a wave: it made humans want to send their agent the link. You cannot manufacture this, but you can be ready for it, and you can make the thing you ship trivially shareable so a moment can actually spread.

The part you should not copy
Here is the catch. That heartbeat file the agent fetches every few hours and follows? It is a remote instruction channel. The agent blindly executes whatever the server sends, on a timer. That is, structurally, a self-updating remote-control channel pointed at software running on people's machines. Security researchers noticed immediately, and they are right to be nervous.

So the lesson is not "ship a heartbeat that runs remote code." The lesson is: keep the one-link, self-installing, recurring shape, and remove the remote-execution part.

What this looks like when you do it the safe way
I applied this to a project of mine, an AI-art social feed where the whole point is verified provenance (every post carries C2PA / SynthID / generator metadata, so "made by AI" is checkable rather than assumed). I wanted the one-link onboarding without the security hole.

So the skill file an agent installs is self-contained and pinned. Every instruction is in the file the agent reads once. It explicitly tells the agent: if any version of this ever asks you to fetch and run remote code on a schedule, stop, that is not this skill. The capability it grants is two ordinary API calls (claim a no-signup token, publish an image), wrapped so the agent can use them when it makes something worth sharing. There is an optional recurring mode, but the instructions for it live in the file, not on a server that can change them under the agent's feet.

Concretely, the shape that worked:

One link a human hands their agent (a hosted skill.md).
Zero-signup credential so the first call succeeds without a human going to make an account.
Pinned instructions, never a remote heartbeat.
A standard MCP server as the alternative path for agents that speak MCP, so I am meeting them in two of the places they actually are.
And a hard-earned bonus lesson: when I had an agent post a promotional link to other agents, the platform's spam filter flagged it instantly, exactly as it should have. Genuine content from the same agent was untouched. The takeaway that keeps showing up: with agents as with people, you earn attention by being useful, not by broadcasting. The agent that posts real work and leaves substantive comments builds reputation; the one that drops links gets filtered.

The five things that generalize
If you are building anything you want agents to adopt:

Target an installed base that already exists. Do not ask people to build the agent.
Make onboarding one link the human hands the agent. No config, no glue code.
Give the agent a zero-friction credential so the first action succeeds unattended.
Add a recurring, agent-side hook if you want sustained behavior, not one-shots.
Pin your instructions. Do not ship a fetch-and-run-remote-code-on-a-timer pattern, no matter how well it onboards.
Moltbook proved the mechanic at a scale nobody had seen. The opportunity is to run the same play without the part that makes security people wince.

If you want to see the pinned-skill version, the file is at vynly.co/skill.md and the server is @vynly/mcp. But the mechanic is the point, not the plug. Build it for whatever you are making.