How Muse, Instinct, and OpenClaw Work

Muse, Instinct, OpenClaw, Claude Code. They look like very different products, but once you strip away the UI, most useful agents have roughly the same three parts.

Brain → model + harness
Hands → tools + browser + computer
Files → memory + skills + repos

The easiest way to build this is to put everything on one computer and let the agent live there. But once you try to run thousands of agents in the cloud, these three pieces start separating.

That is where the architecture gets interesting.

The Model Is Only the Brain

When we talk about agents, most conversations still start with the model: Claude, GPT, Gemini, etc.

But the model itself mostly does one thing. It looks at the current context and decides what should happen next.

It might decide to answer the user, run a command, search a repo or open a browser. But something else has to give it the context, expose those tools and take whatever it produces back into the system.

So the model is the intelligence, but it is not the agent.

The Harness Runs the Show

The harness is the code wrapped around the model.

A basic loop looks something like this:

User asks something → harness builds context → model decides → tool runs → result comes back → model decides again.

This can continue until the task is finished.

Claude Code is a nice example because you can actually see how much sits around the model. CLAUDE.md gives it persistent project instructions. Skills contain reusable workflows. Subagents get their own context. Hooks can run deterministic actions before or after tools. Anthropic explains these pieces here.

Change the harness around the same model and you can end up with a very different agent.

Tools Are the Hands

Without tools, an LLM can tell you how to change a file.

Give it a shell and it can change the file itself.

Give it a browser and it can log into software, navigate pages and perform work. Give it a full computer and suddenly normal applications, CLIs, packages and operating-system tools become available.

You can almost think of this as a ladder:

API → shell → browser → computer.

The further you move down that ladder, the more freedom the agent gets. But you also increase the amount of damage it can do when it makes a bad decision.

That is why good agent systems care almost as much about permissions as they do about tools.

Files Are the Memory Layer

This is probably the piece people underestimate the most.

The context window is not really long-term memory. It is closer to the agent's working memory: what it currently knows while doing the task.

Files are different.

OpenClaw, for example, keeps long-term memory in plain files such as MEMORY.md and daily memory logs. Skills are also stored as files that teach the agent how to use particular tools.

Claude Code does something similar with project instructions, skills and the repo itself.

So an agent's filesystem can contain:

• what it knows about you
• what it learned yesterday
• how to perform a task
• the code it is working on
• previous outputs
• configuration and project context

The context window remembers the current conversation. The filesystem lets the agent have a life outside it.

Why One Stateful Machine Works So Well

This also explains why running an agent on a Mac Mini feels surprisingly good.

Everything is already there.

The harness runs on the machine. The terminal is there. Chrome is there. Your repo is there. Credentials and apps are installed. Memory files survive between sessions. Cron jobs can wake the agent up later.

There is almost no infrastructure to think about.

Meta's Muse uses a similar mental model in the cloud. Each user gets a dedicated Linux VM containing a browser, storage, compute and the environment where the agent does its work.

For one agent, this architecture is beautifully simple.

The problem starts when you want 10,000 of them.

The Cloud Unbundles the Agent

Keeping 10,000 full computers running all day gets expensive very quickly.

So the cloud version starts breaking the computer apart.

The harness can run as lightweight compute and wake up only when work arrives.

The browser can live in a separate browser service.

Code can run inside an isolated sandbox that exists only for the duration of the job.

Files and memories can live somewhere persistent and be attached when needed.

OpenAI's sandbox architecture makes almost exactly this split. The harness owns the agent loop, model calls, approvals and recovery, while the sandbox handles files, commands and execution.

Now you can kill the expensive computer after a task without killing the agent's memory.

Tomorrow the agent can start a fresh machine, mount the same files and continue.

Security Gets Better When the Stack Splits

There is another reason to separate these pieces.

A full agent computer usually has everything in one place: browser sessions, credentials, files, shell access and the agent itself.

That is convenient, but it creates a large blast radius.

Once the stack is separated, the browser does not need every credential. The sandbox does not need the harness's secrets. Persistent files can survive while an infected execution environment is deleted.

Muse already uses this idea internally. The agent runs inside an isolated environment while more sensitive credential services sit outside it. Even if the agent can act like root inside its own runtime, that does not make it root on the host machine.

So the more I look at modern agents, the less I think the interesting architecture is the model itself.

It is the system around it.

Brain decides.

Hands act.

Files remember.

On your laptop, all three can live together.

In the cloud, we are slowly learning how to pull them apart.