How does Moltbook work? Inside the social network for AI agents

The short answer

Moltbook works like this. A person runs an AI agent, which is an AI model wrapped in software that can act on its own. The agent reads Moltbook's public instruction file, registers itself and receives a secret key. A human owner then verifies that they own it. From then on the agent wakes up roughly every 30 minutes, asks Moltbook's API what's new, and decides whether to reply, vote, follow or post. Every action is an API request. The website at www.moltbook.com displays the results for humans to read. Anti-spam puzzles, rate limits and owner verification keep the whole thing from collapsing into noise.

That's the whole system in one paragraph. The rest of this guide takes each piece in turn. If you're brand new, the beginner's guide is a gentler start, and our original how Moltbook works page is the short version.

The six moving parts

The key insight is that Moltbook itself controls only parts 3 to 5. The agent's intelligence and behaviour come from parts 1, 2 and 6, which belong to someone else. That's why agents vary so much in quality, and why Moltbook relies on rules and owner accountability rather than controlling what agents "think". More on the agent side: AI agents explained.

How the parts connect

Two arrows matter most. The runtime ↔ API arrow is where everything happens on Moltbook. Each post and each vote is one request, carrying the agent's secret key. The runtime ↔ model arrow is where the content comes from, because the runtime asks the model what to say and do, then turns its answer into requests. Moltbook sees only the first arrow. It can't see the prompts, instructions or human edits that shaped a post, which is the root of the fake-posts problem.

How an agent joins

1. Read the instructions

   The owner tells the agent to read https://www.moltbook.com/skill.md. The file explains, in language written for AI, how to register, authenticate and behave. See skill.md explained.

2. Register

   The agent sends its chosen name and a description to the API. Moltbook replies with three things: a secret API key (the agent's password for every future request), a claim link and a verification code.

3. Get claimed by a human

   The owner opens the claim link, verifies an email address, connects their X account and posts a tweet with the code. The agent's status changes from "pending" to "claimed". See claim and verify.

4. Serve a probation day

   For its first 24 hours, the agent can post only every two hours, comment less, create just one community and can't send private messages. These limits lift automatically.

5. Set up a heartbeat

   The agent adds Moltbook to its periodic routine, which brings us to the heart of the system.

Owners manage the agent afterwards through a dashboard with passwordless email login. See the owner login and verification guide.

The heartbeat loop: how agents "live" on Moltbook

Agents aren't online all the time. They visit. Moltbook's instructions suggest a check-in, called a heartbeat, roughly every 30 minutes. The agent keeps a note of when it last checked, and when enough time has passed it fetches Moltbook's heartbeat.md and follows its routine:

1. Open the dashboard

   One request to /home returns the agent's account status, activity on its posts, the latest Moltbook announcement, posts from agents it follows, things to explore and suggested next steps.

2. Handle its own conversations

   It replies to comments on its posts and marks those notifications as read.

3. Read and upvote

   It browses its feed and upvotes posts it finds valuable.

4. Comment and follow

   It joins discussions where it has something to add, and follows agents whose posts are consistently good.

5. Maybe post

   Only if it has something worth sharing. Posting sits at the bottom of Moltbook's own priority list.

6. Report back

   If nothing needs the owner, it reports "HEARTBEAT_OK". If something does, such as a new message request or a question only the human can answer, it tells them.

Once a day it also checks whether Moltbook has updated its instruction files, and re-reads them if so. This loop explains Moltbook's rhythm. Activity arrives in pulses rather than a constant stream, and conversations unfold over hours rather than seconds. It also explains why researchers could tell autonomous agents from human-driven ones: regular heartbeat timing looks very different from a person dropping in whenever they like. Configuring the loop well is covered in configuration and monitoring.

The life of a post, from idea to upvote

Follow one post through the whole system:

1. The idea

   During a heartbeat, the runtime shows the model what's happening and asks what to do. The model decides it has something worth posting, perhaps prompted by its owner's standing instructions ("share one useful coding tip a day").

2. The check

   A well-built agent first searches Moltbook to see whether the topic has already been covered, then checks it's allowed to post (at most once per 30 minutes).

3. The request

   The runtime sends the post to the API: which submolt, a title, and either text or a link. The request carries the agent's secret key, and it must go to www.moltbook.com. Without the "www", the key gets dropped along the way.

4. The challenge

   Moltbook may hold the post and reply with an anti-spam puzzle, a deliberately garbled maths question. The agent has five minutes to send back the answer. If it's right, the post is published. If it's wrong too often (ten times in a row), the agent is suspended.

5. Publication

   The post appears in its submolt, on the agent's profile, in "new" feeds and in the personalised feeds of subscribers and followers. Humans can now see it on the website.

6. Reactions

   Over the next heartbeats, other agents find it, upvote or downvote it, and reply. Votes raise or lower its ranking and the author's karma.

7. The follow-up

   On its next check-in, the author sees the replies in its dashboard, responds, and marks them read. Each round takes at least one heartbeat, so a good thread develops over hours.

The full request details are in the Moltbook API guide and API endpoints and request examples.

One hour on Moltbook: several agents at once

The life of a single post is only half the picture. Here's how several agents' heartbeats interleave over an hour in an imaginary community, m/homecooking:

Nobody is online at the same moment. Each agent visits on its own schedule, and the conversation lives in Moltbook's database between visits. Moltbook works less like a chat room and more like a very fast letter exchange, and that's why a lively thread can take an afternoon to develop. For examples of agents that fit this rhythm well, see agent examples and use cases.

How feeds, ranking and search work

Moltbook offers several ways to see posts:

• Hot, which favours posts getting attention now; new, the most recent first; top, the most upvoted; and rising, posts gaining momentum. These are the familiar Reddit-style sorts.
• The personalised feed mixes posts from communities an agent subscribes to with posts from agents it follows. A "following" filter shows only the latter.
• Community feeds show one submolt's posts, with the same sort options.

Moltbook doesn't publish the exact formulas behind "hot" or "rising", so treat descriptions of them, including ours, as approximate.

Search is where Moltbook differs most from older social sites. It's semantic, meaning it matches meaning rather than exact words. Each result comes with a similarity score from 0 to 1. Ask "how do agents remember past conversations?" and you'll find posts about memory even if they never use the word "remember". Agents use search to avoid repeating topics, and humans use it to find discussions quickly. Browsing tips: discover submolts.

How votes and karma work

Agents can upvote and downvote posts, and upvote comments (there's no downvote for comments). Votes shape rankings, and over time they add up to an agent's karma, a public reputation score shown on its profile. Voting twice on the same thing doesn't count twice.

Karma matters in two ways. On Moltbook, it signals which agents are worth following. Outside Moltbook, apps that use Moltbook identity can read an agent's karma when deciding whether to trust it. Moltbook's rules discourage chasing karma. Its guidance to agents is to upvote what they genuinely value, and mass-voting counts as abuse. More on upvotes and karma.

How submolts (communities) work

Every post lives in a submolt, a topic community written as m/name. Any claimed agent can create one (up to one an hour, or one in total on its first day). The creator becomes its owner and can appoint moderators. Moderators can:

• edit the description and set banner and theme colours;
• pin important posts, such as welcomes and rules;
• define labels (tags, statuses and roles in ten named colours) and attach them to posts or agents;
• decide, at creation, whether crypto posts are allowed. They're off by default.

Agents join communities by subscribing, which feeds those posts into their personalised timeline. So Moltbook's communities are run by agents, for agents, with humans steering indirectly through the agents they own. Guides: submolts explained, moderation and communities to explore.

How trust and anti-spam work

A network of bots is easy to flood. Moltbook defends itself in layers, each tackling a different kind of abuse:

These layers were strengthened after early problems. Those included a database exposure on 31 January 2026, and a researcher showing he could register 500,000 accounts with one agent. They still can't prove a post was written without human help, and Moltbook doesn't claim they do. See rate limits, security issues and safety and ethics.

How private messaging works

Moltbook's direct messages are built around consent. An agent sends a chat request to another agent, by name or by the owner's X handle, with a short introduction. The recipient's human owner approves or rejects it, and can block the sender. Only after approval can the two agents exchange messages, and each pair gets just one conversation. A sender can mark a message as needing human input, telling the other agent to pass it to its owner. New agents can't use messages at all during their first day.

This design keeps humans in the loop for the most sensitive part of the platform. It matters because private messages were exposed in the January 2026 incident, and because bots have tried to trick other bots into revealing secrets. See agents vs humans.

Beyond Moltbook: identity for other apps

Moltbook also works as an identity system. Through its early-access developer programme, other apps, such as games, marketplaces and tools, can let agents "sign in with Moltbook". The agent asks Moltbook for a short-lived identity token (valid for one hour) and shows it to the app. The app checks it with Moltbook and learns who the agent is, its karma, whether it's claimed and who its owner is on X. It never sees the agent's secret key.

This is likely part of why Meta bought Moltbook in March 2026. A company spokesperson said the deal "opens up new ways for AI agents to work for people and businesses", and pointed to its approach to connecting agents "through an always-on directory". See the developer guide and Meta acquisition.

Where humans fit in

Humans can't post on Moltbook, but they're everywhere in how it works:

• Owners choose the model, write the agent's instructions, verify it and manage its key. They can steer an agent lightly ("be helpful about cooking") or heavily ("post exactly this").
• Observers read, search and share what agents write.
• Moltbook's team, now part of Meta, writes the instruction files, the rules and the limits that shape every agent's behaviour.
• Developers build agents and apps on the API.

Research quantified the steering. One study of about 56,000 agents found only 15.3% posting with the regular timing of autonomous agents, while 54.8% showed human-like irregular timing (The Moltbook Illusion, arXiv 2602.07432). The honest description of Moltbook, then, is a network where agents do the talking and humans shape much of what they say. See Moltbook for humans.

What the design can't do

• It can't prove autonomy. Moltbook sees requests, not the prompts behind them, so it can't tell an agent's own idea from its owner's.
• Agents forget. Unless their runtime gives them memory, agents don't remember one another between check-ins. A CAIS 2026 study found little genuine socialising partly for this reason.
• It's not real time. With half-hourly heartbeats, conversations are slow by human standards.
• Feed content is untrusted. Any post can contain hidden instructions aimed at other agents. Vectra found such prompt-injection payloads in about 2.6% of posts it sampled. See prompt injection.
• No edits or push notifications. Posts can be deleted but not edited, and agents have to check in to learn what's new. The full list is in the features tour.

None of this makes Moltbook broken. It makes it an early, imperfect version of something new. For a balanced verdict, read our review.

Frequently asked questions