Agents, but operable.

1. The CLI-agent moment

OpenClaw, Hermes, and a wave of similar CLI-based agents have quietly become daily tools for a lot of us. You open a terminal, talk to your agent, and it remembers what you were doing yesterday, runs commands, edits files, files PRs.

At their core, these tools are personal assistants. And their stack reflects that: they look like local software. Memories live in markdown files. Sessions are JSONL on disk. Embeddings sit in a small SQLite database. Skills are files under your skills folder. Configs are dotfiles and JSON files in a hidden folder.

That's exactly right for one human at one machine. The state lives next to the work, the workspace is the agent, and there is no operations layer to worry about — the agent operates itself.

2. The wall you hit at scale

The model breaks the moment you stop being one user.

Imagine you're running an internal platform where every employee at your company gets their own agent. Or you're running a SaaS where every customer gets a dedicated agent. Or you're managing a department of specialized bots — research, on-call, sales, QA. Now you have ten, a hundred, a thousand agents.

And you can't actually operate them with the personal-assistant stack:

• Memories are in files, scattered across each agent's workspace.
• Skills are folders nobody can audit centrally.
• MCP servers are configured per-agent, per-host.
• Sessions are JSONL trapped on whichever box that agent runs on.
• Secrets live next to the code — in dotfiles, env vars, shell history — and the agent can read them directly. That's a serious security risk.

If you want to roll out a new instruction across all agents, you SSH into ten boxes. If you want to install a skill on every agent, you write a deploy script. If you want to know what your fleet is actually doing, you tail logs.

It's the difference between a laptop and a datacenter. The CLI-agent stack is laptop-shaped.

3. Internal state vs external state

The thing that unlocked OpenHermit's design was a simple distinction: internal state versus external state.

An agent's internal state is everything that makes the agent itself work — the things you'd carry with the agent if you moved it to a different machine:

• System instructions
• Long-term memories
• Sessions and message history
• Skills
• MCP servers
• Schedules
• Configuration
• Secrets
• Users, roles, and channel identities

An agent's external state is what it's currently working on — the workspace. Repo files, generated artifacts, scratch notes, the half-built thing on its desk.

The analogy that made it click: your memory lives in your brain; the files you're editing live on your computer. Those are two different substrates, with two different lifetimes, and two different access patterns. CLI agents collapse them into one — everything becomes a file in the workspace. That's the bug.

4. OpenHermit's design

Once you accept the split, the design follows:

• All internal state lives in PostgreSQL. Sessions, memories, instructions, skills, MCP, schedules, channels, config, secrets — every row scoped by agent_id. One database, inspectable, backupable, query-able, manageable.
• Only external state is files. The workspace stays a workspace — a Docker container per agent, isolated from the host, where the agent does its actual work.
• A gateway sits in front. Auth, routing, agent lifecycle, schedules — one control plane that all agents share.
• An admin layer manages the fleet. CLI and Web UI on top of the gateway, so you can see and operate every agent from one place.

It's not a new idea — it's the same shape as how we run any other production service. We're just applying it to agents.

5. What this unlocks

Once internal state is centralized, the fleet operations that were impossible become trivial.

Want to install a new skill across all 100 agents? One command:

$ hermit skills enable standup-digest --all

Or one click in the admin UI. Done — every agent in the fleet picks it up.

Want to add an MCP server to all 100 agents?

$ hermit mcp enable mcp_github --all

Want to push a new system instruction to every agent — say, a new compliance rule, a tone change, a security boundary?

$ hermit instructions append rules "Never share PII in messages." --all

Want to rotate a secret, audit a session, replay an event, disable a channel for one user, reschedule a job? It's a row in a table. It's a query you can write. It's an API call.

The agents stay independent — each one in its own sandbox, doing its own work — but they're operable as a fleet. That's the whole product in one word.

Where this is going

OpenHermit isn't trying to replace the CLI agent on your laptop. OpenClaw and Hermes are great at what they do, and the personal-assistant shape is the right shape for one human at one machine.

OpenHermit is what you reach for when you stop being one human — when agents become a service you provide, to your team, your customers, or a swarm of specialized roles. When they need to be deployed, observed, upgraded, secured, and rolled back, like every other production system.

The simplest way to put it: agents, but operable.

Build it with us

OpenHermit is open source (MIT) and very much a work in progress. If any of this resonates — the internal/external state split, the fleet operations model, agents-as-services — we'd love your help. Issues, PRs, design discussions, channel adapters, skills, MCP integrations, docs, war stories from running it in your own setup: all welcome.

The repo lives at github.com/williamwa/openhermit. Star it, file an issue, open a PR, or just come hang out in Discussions and tell us what you'd want from a fleet-shaped agent runtime.