What Muse Gives You, and What You Can Rebuild

The appeal of a hosted personal agent is not the model. It is the shape: a machine that is always on, a channel you already use, a schedule it keeps without being asked, and memory that survives the conversation. That combination is what makes an agent feel like a thing you have rather than a thing you query.

The shape, it turns out, is not proprietary. Every one of those four pieces can be assembled from open projects in an afternoon, and the documentation for each piece is public. What is proprietary is the operation of it — and that is a trade worth understanding before you decide which side you want.

The trade, in the terms

The published terms are short on this point and worth reading directly. On ownership:

“Meta retains all respective rights, title, and interest, including intellectual property rights, in and to Muse.”

On what happens if it breaks:

“MUSE IS PROVIDED ON AN ‘AS IS’ AND ‘AS AVAILABLE’ BASIS.”

And on continuity:

“Meta may suspend or terminate your access to Muse or its features, or remove, disable, or restrict access to any artifact created with Muse, at any time, for any reason, without prior notice or liability.”

None of that is unusual for a consumer service, and none of it is a criticism. It is simply the boundary: you are granted access to a running system, not a copy of one. The machine is described in Meta’s own material as a dedicated cloud computer per user — which is the part people fixate on — but the software that runs on it stays with Meta, and the terms reserve the right to remove what you built there.

That distinction is what makes “can I move it” the wrong question and “what would it take to build the same shape” the useful one. If the appeal of a free VM is that it looks like a web host, the terms already answered that. The appeal of the agent is a different question, and it has a real answer.

Four pieces, none of them exotic

Strip the branding off and the architecture is:

A host that runs a process continuously and starts it again when it dies.
A channel — a messaging app, so interaction does not require a terminal.
A scheduler that wakes the agent without a human sending a message.
State on disk — memory, skills, session history — that survives restarts and can be copied.

Assemble those four and you have the experience. Assemble them badly and you have an agent that forgets everything every Tuesday, which is the more common outcome and the reason the details below matter.

Piece one: the host, which is the piece people get wrong

The hosting half is fully documented and it is not hard. What is hard is the part nobody mentions: a rented server is not an always-on agent until a service manager is told to keep it running without you.

On a Linux box the agent installs as a systemd user unit, and user units stop when your last session ends unless lingering is enabled for that user — a one-line fix that most people discover only after their agent silently goes offline. The configuration and the reboot test that catches it are covered separately, and it applies to any self-hosted agent, not just one project.

The sizing half is simpler than people expect. A text-only agent fits in 1 GB; a browser-using agent wants 2 GB. The projects publish both numbers. What does not fit in either is a local model, which is a different workload with a different floor — the arithmetic is worth doing before you pick a plan.

Piece two: a channel, and the defaults that protect it

Both major open agents ship a gateway that speaks to chat platforms, which is what removes the terminal from daily use. OpenClaw lists integrations for WhatsApp, Telegram, Discord, Slack, Teams, Signal and others; Hermes covers Telegram, Discord, Slack and WhatsApp. In both cases the agent is a participant, not a bot you have to build.

The security model is where these projects differ from a hosted product, and it is worth stating because the defaults are better than their reputation. OpenClaw’s security page describes what a fresh install actually does:

“On a regular host install the Gateway binds to loopback; most chat channels answer an unknown DM sender with a pairing code instead of processing the message; and group access is allowlisted, usually behind a mention gate.”

Read that as three separate protections, because they fail separately. Loopback means the dashboard is not on the public internet. Pairing codes mean a stranger who finds your bot does not get a conversation — they get a code you have to approve. Allowlisting means a group the agent is added to does not automatically become a group the agent answers in.

The one documented exception is worth knowing: container images bind to an exposed interface by default. If you run the agent in Docker, that protection is off until you configure auth, which is precisely the case the documentation warns about.

Piece three: the scheduler

This is the piece that turns an agent from something you talk to into something that works. It is also the piece most home setups skip, which is why they feel like a chatbot with a nice memory.

OpenClaw treats scheduling as a core feature rather than an add-on:

“Automations are OpenClaw’s built-in scheduler for all recurring and one-shot work, including periodic monitors. The scheduler persists jobs, wakes the agent at the right time, and can deliver output to a chat channel or webhook endpoint. It supports one-shot reminders, recurring intervals and cron expressions, and inbound webhook triggers.”

The word to notice is “persists”. A cron job on the host would fire whether or not the agent is healthy; a persisted job with delivery attached either produces output in your chat or leaves a visible failure. That difference is what makes an agent’s schedule debuggable a month later.

Piece four: state you can copy

Memory is the part a hosted service gives you for free and a self-hosted one makes you responsible for. In OpenClaw’s documented layout there are two directories, and the split is meaningful:

~/.openclaw/ holds configuration, provider and channel credentials, auth stores and session data.
~/.openclaw/workspace/ holds the agent’s workspace — memory, skills, artifacts.

The first is the machine’s identity; the second is the agent’s. Backing up only the second gives you a portable agent with no credentials, which is often exactly what you want when migrating. The documented commands are openclaw backup create and openclaw backup restore <archive> --target <directory>, and the restore extracts to a staging directory before activation — a deliberate two-step, so you can inspect what you are about to revive.

One caveat the documentation is explicit about: absolute symbolic links in the archive keep pointing at their original paths. If your configuration lives outside the state directory, those links will resolve to the wrong place on a new host, and the restore will look successful while the agent starts with stale credentials.

The setting that does not survive the rebuild unchanged

Here is the honest cost of doing this yourself, and it is not hardware.

A hosted agent ships with an approval layer you did not have to design: the question “should it be allowed to do this” has an answer before you arrive. A self-hosted agent gives you the same machinery, but as configuration, and configuration has a specific failure mode — you can believe you turned it on and have turned on a notification instead.

OpenClaw’s own documentation draws that line sharply, in a passage about two settings that look like duplicates:

“The host exec policy is still the real approval gate; chat config only controls where the prompts appear and how you answer.”

So there are two layers: a policy that decides whether an action needs approval, and a channel setting that decides where you are asked. Enabling the second without the first produces a system that sends you cheerful messages about work it has already done. That is not a bug in the software; it is the difference between a product with a compliance team behind it and a box you configured on a Sunday.

Decide the policy before you connect the account that can move money.

What you are actually trading

	Hosted (Muse and similar)	Self-hosted (OpenClaw, Hermes)
The machine	Provided, patched, replaced	You choose, you patch, you replace
Ownership of the software	Retained by the vendor	Yours, under an open licence
Continuity	At the vendor’s discretion	As good as your backups
Approval layer	Designed for you	Configured by you
Cost model	Subscription	Machine + your hours
What you can carry away	Your content	Everything, including the runtime

The row that decides it for most people is the last one, and it cuts both ways. Being able to copy the whole thing is worth a great deal if you have built something you would hate to lose. It is worth very little if you never do the copying — which is why the backup command belongs in the first week, not the first emergency.

The other row worth pausing on is cost. A self-hosted agent is not free; it is a small monthly machine plus an amount of your time that is easy to underestimate and hard to invoice. If the model runs locally as well, that arithmetic gets harder still, and the bill has lines people usually leave out.

A reasonable first week

Pick the agent by reading its install page, not its feature list. The page tells you what the maintenance actually looks like.
Size the machine from the published floor, and accept that 1 GB is a real answer for a text agent.
Enable lingering before you install the daemon, then reboot and check from outside.
Connect one channel. Not four.
Write the approval policy down before the first account is connected.
Run a backup and restore it into a scratch directory. An untested backup is a rumour.

The result will not feel like a product. It will feel like infrastructure — which is what it is, and what the hosted version is too, underneath the interface. The difference is who holds the keys, and whether you can carry them somewhere else.