OpenClaw, Hermes, Buzz, or Build Your Own AI OS

TL;DR

Two products own this category. OpenClaw sits at 384,000 GitHub stars, Hermes Agent reached 218,000 in five months, and underneath the pitch they are nearly the same machine: a daemon that stays on, memory files, scheduled jobs, skills, channels. Which means most of what gets argued about online is a setting you can change in an afternoon.

Four things are not. They are architecture, and changing your mind about them later means changing systems. This is a guide to those four, in the order they will hit you. Block’s Buzz landed on 21 July and is not competing in this race, which I will explain rather than assert. And there is a third option nobody sells you, which is to build a small one yourself, and which I think you should do for two weeks whatever you decide.

What you are actually choosing

Start with what the thing does while you are asleep. A personal AI OS is a daemon. It stays running when you close the laptop, it holds a memory of you, it wakes on a schedule, and it reaches your calendar, your messages and, if you let it, your files. You are not choosing a text editor. You are choosing what gets to act on your behalf at three in the morning.

That holds whether this is for you alone or for a team, and a team adds one question on top: who owns it. Somebody has to patch it, read what it learned this week and notice when it starts going quietly wrong. Whatever they wire in stays behind when they leave.

The category is old enough to have incumbents now. OpenClaw nearly doubled its stars between February and July 2026, from 213,000 to 384,000, passing React and Linux on the way. Hermes Agent, launched by Nous Research in February, reached 218,000 in its first five months and ships tooling that imports an OpenClaw setup wholesale. Read both counts as directional: stars measure attention rather than adoption, and parts of Hermes’s own community suspect bot inflation in that number. Both are open source and free to run, so none of this is a pricing argument. What you spend is model calls: tens of francs or dollars a month for a busy single user on a subscription, low hundreds if you wire it to pay-per-call APIs.

The part that took me longest to accept is that they have converged. Both are a persistent gateway daemon with pluggable execution backends, channel adapters, built-in cron, skills in the same open format, and an MCP client for plugging in outside tools. Channel noise, marketplace risk, notification volume, which model runs which job, how retrieval behaves, whether the thing writes its own skills at all. All of that is a setting, on both sides. A competent operator can strip either one into something small and quiet in an afternoon. Most published criticism is aimed at defaults you would never keep.

One note on how I know. I have run a hand-built system every day for months, so that part is lived. I have not spent a year each with the other three. What follows is a week in their documentation, their changelogs, their issue threads and their CVE records, plus the parts I could put my hands on. The point of writing it down is that you should not have to spend that week.

So the interesting question is not which has more features. It is which irreversible decisions suit the way you work. There are four of them, and they are worth holding in your head while you read: whether your agents can talk to each other, whether your model is even allowed in the door, what it costs to keep memory current, and what you can take with you when you leave. The first one decides everything else. The other three stay quiet until they do not. Security sits outside that list, because you do not decide it once. It affects how you read all four.

The one question that decides it

Can your agents talk to each other? Answer that first, because it is the only one on this list where changing your mind means changing products rather than changing a config file.

OpenClaw’s answer is that an agent is a colleague. It is a persistent persona with its own workspace, credentials and session history, and it can message the others: clawteam send drops work into a named agent’s inbox, and an allowlist decides who may talk to whom. Your research agent hands a finding to your writing agent without you sitting in the middle relaying it. Agents can also wake on their own timer, read a checklist you wrote for them, and decide whether anything is worth telling you. What you get is a standing team that checks its own work. What you carry is the mesh: five personas with five sets of state, and the failure mode is rarely a crash. It is a quiet mess someone has to sit down and read.

Hermes answers the opposite way, and its documentation is admirably blunt about it. You delegate through a single call, each subagent starts in a clean context knowing nothing of the parent’s history, and they can never message one another. Work fans out and reports back. That is the entire vocabulary, and Hermes’s own docs concede that genuinely distributed multi-agent work would need coordination infrastructure the product does not provide. It will also, if you switch it on, write its own skills out of tasks it keeps repeating and send them to you as pull requests to approve. What you get is throughput: several jobs in flight at once, none of them contaminating another’s context, and a system that slowly automates its own chores. What you carry is that you are the only integration point in it.

Circle is a person, square is an agent. The highlighted links are the ones that define each model: in OpenClaw they run between the agents, in Hermes they never do, and in Buzz they all land on one log.

Which of the two sounds more advanced does not matter. What matters is the shape of your work on an ordinary Tuesday. If it splits into standing roles that hand things back and forth, OpenClaw is built for that and Hermes cannot be configured into it. If it is the same handful of chores run many times over, Hermes does that more cleanly and the isolation stops being a limitation and starts being the point. Pick wrong and you will not find out in week one. You will find out in month three, when you ask the system for a shape of work it was never built to hold.

Three decisions that cost you later

The other three are invisible in a demo, which is exactly why they are worth ten minutes now.

The floor under your model. Hermes refuses, in code, to run any model with a context window below 64,000 tokens. Not a warning, a refusal at startup, and people have had working 32K setups stop booting after an update. The override only covers models that genuinely have 64K and were misdetected, so there is no talking it into anything smaller. If your plan involved a modest local model on hardware you already own, Hermes ends that plan before you start. OpenClaw’s practical floor is roughly 16 to 24K and it degrades instead of refusing. This one is binary, so check it before anything else on the list matters.

What it costs to keep memory fresh. OpenClaw keeps markdown as the source of truth and treats the database as a rebuildable index over it, so you can grep your own memory, diff it and keep it in git. Hermes keeps two small files, a couple of pages of text between them, plus keyword search over past sessions, and it freezes those files for the length of a session so the provider can cache them unchanged. That freeze is the whole trade. It is what keeps a long conversation cheap, and it means anything the agent learns at 11am is invisible to the session that learned it. The lesson arrives tomorrow. The community proved you cannot have it both ways: a plugin that refreshes memory live works fine and hands back exactly the savings the freeze existed to create.

What leaves with you. Leaving OpenClaw means taking your markdown, which any editor can read in ten years. Your substantive long-term memory in Hermes is the session database rather than those two files, and I could find no documented way to export it. Notice which direction the tooling runs: Hermes ships an importer that pulls in an entire OpenClaw setup, and neither project ships you an exit. Getting in is a product feature. Getting out is your problem, and it is the kind of problem that only becomes real once you have two years of context you cannot bear to lose.

	OpenClaw	Hermes	Buzz	Build your own
Agents talk to	Each other, directly	Nobody. Ever.	One signed channel	Whatever you wire
Models under 64K	Yes, it degrades	No, it refuses to start	Yes, 200K by default	Any model you like
Memory freshness	Live, paid for in retrieval	Frozen for the session	Fetched when it opens	Whatever you curate
What you take away	Markdown, any editor	A database, no export	Signed events, your relay	All of it

Coordination is the only row that means changing products rather than changing a config file. Everything that is not on that table, which is to say how many channels are open, whether you install third-party skills, notification volume, which model runs which job, retrieval behaviour and sandboxing, is a setting on both sides.

Not sure which of these actually binds you? Book a 15-minute working session and we will find out on your setup rather than in the abstract.

What hardening buys, and what it does not

None of the four decisions above is a security decision. That is why this section sits between them and your conclusion: security is the thing most likely to make you regret whichever four you got right.

Take the advice everyone gives first, because it is mostly fair: turn it off. One channel instead of fifteen. No marketplace. Nothing exposed. Put the whole thing behind a VPN. That advice works, and it is also where most write-ups stop, which leaves you with a false sense of what you have bought.

The trouble is what the defaults leave switched off. Both products run tool calls directly on your machine unless you go and select a sandbox backend, which puts the agent’s commands in a container instead of on your laptop, and both say so plainly in their own documentation: OpenClaw describes sandboxed execution as a recommended posture rather than the shipped one, and Hermes tells operators who handle untrusted input that they are outside its supported security posture until they move to a container. Two products sold as a safe place to put your life, and neither isolates execution until you ask.

The volume is real too. More than 138 CVEs were disclosed against OpenClaw between February and July 2026, including a one-click remote execution bug reachable from a web page, which scans found on over 40,000 exposed instances. Hermes has 29 in roughly five months, one of them reported exploited in the wild. Those are counts of catalogued flaws in heavily targeted software, not a verdict on either team, and both patch fast. At around thirteen releases a month on the OpenClaw side, though, staying current is not an occasional chore. It is part of the job.

Now the distinction that actually matters, because it decides whether the hardening advice is enough. Sort the flaws into two piles.

Perimeter bugs are the ones a locked-down install genuinely erases, and if nothing of yours is exposed you can stop worrying about them. Core bugs run on every session no matter what your perimeter looks like: two of Hermes’s CVEs are injection flaws in its memory tool and its prompt builder, and a prompt injection that keeps an agent busy long enough can write itself into a skill that then runs in every session afterwards. Which is the moment to know who approves a new capability in each product, because the reputations are backwards. Hermes, the one that markets self-improvement, requires a human-reviewed pull request every time. OpenClaw, which never mentions it, applies agent-proposed skills automatically until you go and find the setting that says otherwise. So “harden it and the risk goes away” is half right, and the false half carries the higher severity scores.

There is one more turn in this, and it is the fact I would keep if you forget everything else here. May’s Claw Chain, four bugs linked into full compromise at 9.6 out of 10, was a race condition in the sandbox’s own path validation. It could only bite operators who had switched the sandbox on. Everyone running the insecure default was never exposed. The people who got hurt were the ones trying hardest to be careful, which is worth remembering the next time someone, me included, tells you to just harden it.

Buzz is not a fourth option

All of that assumes the thing you are choosing is a daemon that runs your life while you are not watching. Block open-sourced Buzz on 21 July, Jack Dorsey announced it, and it passed 11,000 stars in its first week. If that is the shelf you are shopping on, the useful thing I can tell you is that Buzz is not on it, and Block says so more clearly than I could, in the repo rather than the press release:

“Buzz is the pipe … not the brain. Humans and agents bring the intelligence.”

Buzz is a self-hostable team workspace built on Nostr, an open protocol where messages are signed by their author and stored on a relay you can run yourself. Chat, git, review and approval all become signed events in one log you own. Humans and agents are both members, each with their own keypair, and you add an agent to a channel the way you add a colleague. It ships a small agent of its own, so it is not brainless, but its premise is a room rather than an assistant, and Claude Code, Codex and goose all work inside it.

That premise buys one thing the other three cannot. Every hand-off between agents is a signed, searchable message, because there is no back channel for them to use instead. Its memory design is the best engineering in this comparison: an agent’s memories are encrypted so that the owner can always decrypt them, by cryptography rather than by policy, which means the agent structurally cannot keep a secret from you. Compare that with asking a vendor to promise the same in a privacy policy.

It also has the shortest track record here by a wide margin. Its built-in shell tool is deliberately unsandboxed, documented in plain words as running at the operator’s trust level, and its workflow approval gates are defined but do not actually work yet, which Block says itself. A clean vulnerability record on a one-week-old project is a statement about attention, not about safety. I would read it now and I would not put it near anything that matters this month.

The practical answer, if you have a team: run it as well as one of the others, not instead. If you are one person with no team, Buzz is a good answer to a question you may not have.

The option nobody sells you

The third option has no changelog and no stars, and it is smaller than the products make it look. Building your own does not mean copying anyone’s architecture, mine included. It means composing something from parts you already trust: a coding agent you use anyway as the runtime, a folder of markdown as memory, one file the thing reads on every start so it knows who it is working for, and the operating system’s own scheduler. Harness Engineering is the same decision one level down, about the substrate you put around a model to make it reliable in a codebase, and if you build here you end up assembling those same layers.

Mine is one example rather than a template. It is a git repository on a Mac mini: markdown files as memory, a coding agent as the runtime, an identity file, scheduled jobs, a small dashboard. I reach it three ways, and each one arrived because a situation demanded it rather than because a feature list suggested it. SSH behind a VPN at the laptop. A remote session from the Claude apps when I am out and something cannot wait. Tickets on a board when I want to hand work over and walk away, sometimes several running at once. No marketplace, no channel matrix, no self-learning. When I want a new capability, I write it, review it and commit it.

The costs are real and I would rather state them than have you discover them. It takes evenings and weekends. I have nothing as polished as OpenClaw’s control UI and no equivalent of Hermes’s learning loop. When it breaks, the maintainer is me. And you inherit the bugs of whatever you built on: I have a hook that is supposed to force a memory write before compaction, which is exactly the right idea and currently does nothing at all, because it trips over an upstream bug I found months later by going and looking.

What I got in exchange is a system where nothing runs unless I put it there, and a security section that mostly does not apply to me. Not because my code is better, but because so little is listening.

The quieter benefit took longer to notice: the features I envied turned out to be ones I did not need. I ran a vector database next to my markdown for months because I assumed that was the serious way to do it. Then I measured it. It added noise, it duplicated what the files already held, and the retrieval I actually leaned on was keyword search over well-named files. I retired it and nothing got worse. Memory turned out to be a curation problem rather than a retrieval problem, and I only believe that because I ran the experiment on my own data instead of adopting somebody else’s benchmark.

That is the real argument for building, and it holds even if you have already decided to buy. A prototype does not give you a product. It gives you a requirements list. Feature lists are long because they serve everyone; yours is short because you are one person. Run something small for two weeks and the gaps announce themselves, and after that you can read a changelog and tell which features are for you and which are for somebody else’s use case.

So which one

Your work splits into standing roles that hand things to each other. OpenClaw. It is the only one of the two built for it, and no setting gets Hermes there.

Your work is the same chores, many times over. Hermes. The isolation that looks like a limitation is what keeps parallel jobs from contaminating each other, and the learning loop compounds without you authoring every workflow. Check the 64K floor first.

Several people and several agents need one room with an audit trail. Buzz, alongside whichever of the two you picked, once it is older than a month.

Your work runs through one person and touches things you would not paste into a shared tool. Build. Client data and family logistics are the case where owning the whole stack is not a principle, it is the cheaper option.

Then there is the question underneath all four: who maintains this thing? OpenClaw asks you to be an operator: patch often, watch the feed, tune the noise. Hermes asks you to be a reviewer: read what it learned this week and decide what to keep. Building asks you to be a builder. That is the biggest ask of the three, and the only one that compounds into a skill you keep. Pick the maintenance you will actually do, because all three fail the same way: a half-attended agent system, quietly doing the wrong thing with real access.

None of this is visible in a first-week demo. All of it is visible by year two, which is the whole reason it is worth an afternoon of reading before an evening of installing.

Monday morning

Whatever you concluded above, run this first. Two weeks, and it costs a weekend of setup.

Write the identity file. One page: who the assistant is, what it does, what it must never do. You will revise it constantly, and the revising is the education.
Make memory a folder. One markdown file per project or subject, plain names, a few facts each. No database. Add a file every time the assistant should have known something and did not.
Point a coding agent at it. Claude Code or equivalent, run from that folder, so every conversation starts with your context instead of a blank slate.
Schedule exactly one job. A morning summary, a nightly log, anything on a timer. One is enough to teach you what maintenance feels like, and the lesson usually arrives as disappointment. Mine was a 06:00 briefing I read daily for a month, then skimmed, then stopped opening, because it had quietly converged on saying the same thing. Switching it off taught me more than a second job would have.
Keep a gap list. Every time you miss something a product would have given you, write it down. After two weeks that list, usually five to ten lines, is your requirements document. Then trial OpenClaw or Hermes against it, or keep building against it.

The bad outcome is the default one: adopting the biggest system on the shelf, wiring it into everything, and learning its trade-offs from its incident reports.

Two weeks is the cheap way to find your requirements. If you are already part-way through and want a faster read on what you are looking at, book a 15-minute working session. Bring what you have running, or the shortlist you are stuck on. I can shorten the interpreting. I cannot shorten the running, and you would not want me to.