Why I Am Moving My Agentic OS Substrate From Hermes To Pi.dev

Hermes got me to the fun part too fast.

I mean that as a compliment.

I am building an agentic OS, and the first version needed a substrate with teeth. Memory. Skills. Background jobs. Tool calls. Subagents. Messaging surfaces. A way to keep working after the first chat session ends and everyone stops pretending a blank prompt is a product.

Hermes Agent already has a lot of that.

So I used it.

Then the prototype started asking a different question: do I want my OS to inherit this much runtime?

My answer keeps landing on no.

I am moving the substrate toward Pi.dev.

The Shape Of The Tools

The comparison only makes sense if you separate the jobs.

OpenClaw is the loud runtime. Gateway, channels, devices, tools, skills, agents, and local-first assistant energy. It tries to touch the outside world.

Hermes is the long-running agent runtime. Memory, skills, cron, subagents, tool gateway, messaging, model/provider routing. It gives you a lot before you write much glue.

Pi.dev is much smaller. The docs describe it as a minimal terminal coding harness that you adapt to your workflow. The interesting parts are AGENTS.md, skills, prompt templates, packages, session trees, custom models, extensions, the SDK, RPC mode, and JSON event streams.

Pi also leaves things out. Built-in subagents. Plan mode. Permission popups. MCP. You add packages or extensions, or you leave the piece on the floor.

The tradeoff pulled me in.

Hermes gives me a working assistant substrate.

Pi gives me a smaller harness.

For the OS I am building, the smaller harness is starting to look healthier.

What Hermes Taught Me

Hermes helped me avoid a very common fake-progress loop.

You can spend weeks designing the perfect agent substrate and still have nothing that behaves like an assistant. Beautiful folders. Clean diagrams. No pulse.

Hermes has pulse.

It helped me feel the product earlier. I could see where memory mattered. I could see why skills should be real files instead of repeated prompts. I could see why background sessions matter. I could see where subagents are useful and where they become job titles with a token bill.

The useful parts I want to keep:

Hermes pattern	Why I still care
Memory	The OS has to remember operating context without turning every session into archaeology.
Skills	Repeatable work needs a durable home.
Background work	Some tasks should run without me staring at the main thread.
Subagents	Parallel work needs a boundary, especially for research and review.
Gateway thinking	A real OS eventually outgrows the terminal.

Hermes gave me a fast answer to "what should this thing feel like?"

The next question is uglier: which parts should I own?

Why Pi.dev Pulls Me In

Pi is interesting because the extension surface is the point.

Extensions can register tools, watch events, block or modify tool calls, inject context, change compaction behavior, add commands, render UI, and store session state. Skills package repeatable capabilities. Packages can ship extensions, skills, prompts, and themes together. The SDK and RPC mode make Pi easier to embed in a larger system.

For an agentic OS, the harness should be one layer in the stack.

If memory needs a different shape, I want to swap it.

If tool approvals need a stricter policy, I want that policy in my code.

If background workers need their own event log, I want to design the log.

If a skill can mutate itself, I want governance around that before it becomes a cute demo with production permissions.

Pi means more work up front. I have to build or install the parts Hermes already gives me: agent teams, memory, scheduling, gateway behavior, approvals, maybe MCP-style tool connections.

Fine.

I would rather add those pieces deliberately than spend the next year sanding down a runtime that keeps trying to be the product.

The Part I Am Rebuilding

Here is the actual migration, without the inspirational architecture poster.

Hermes currently gives me the runtime spine.

Pi would sit closer to the coding harness layer.

Around Pi, I would build the OS pieces I care about:

agentic-os/
  .pi/
    agents/
    skills/
    extensions/
    prompts/
  runtime/
    scheduler/
    memory/
    sessions/
    channels/
    workers/
  verification/
    evals/
    traces/
    audit-log/

The split matters.

Pi handles the harness surface: prompts, skills, extensions, events, sessions, programmatic control.

My OS handles memory policy, scheduler behavior, channel adapters, worker lifecycle, traces, evals, audit logs, and permission boundaries.

I want the boring pieces to be boring in my repo.

The approval rule should live somewhere I can inspect.

The scheduler should have state I can query.

The memory write should have a reason attached.

The tool call should leave enough evidence for me to debug it later.

I trust that substrate.

OpenClaw Is The Stress Test

OpenClaw is useful in this comparison because it shows the other extreme.

A local-first assistant with a gateway, channels, devices, tools, skills, events, cron, routing, and companion surfaces has a very different energy from a terminal harness. It also has a much bigger trust conversation.

People get excited about agents in Slack, Telegram, GitHub, Linear, and customer workflows because those agents touch real work. Fair. Real work is the appeal.

The same access creates the scary part.

Credential storage. Skill marketplaces. Shell access. Chat access. Silent automation failures. API costs. A helpful agent with too many keys.

I keep OpenClaw in the research for that reason.

Benchmark for aliveness.

Also a reminder that connected agents are permission bundles wearing a friendly UI.

The Decision Board

My current read:

If I wanted an always-on personal assistant quickly, I would start with Hermes or OpenClaw.

If I want the agent layer to become part of my own product architecture, I would rather start with Pi and build the OS layer around it.

Pi has gaps. Those gaps are visible:

Gap	What I would own
Long-running process	Identity, lifecycle, restarts, health checks.
Memory	Stores, summaries, retrieval, profile files, write policy.
Scheduler	Job state, retries, cancellation, visible run history.
Channels	Slack, Telegram, email, browser, app, CLI adapters.
Permissions	Tool allowlists, approvals, sandbox profiles, path protection, cost limits.
Observability	Traces, evals, logs, event history, "why did it do that?" answers.

Those are OS work. I do not want them hidden from me.

The Bet I Am Making

Pi gives me the harness I can own.

Hermes gave me the product feel quickly.

OpenClaw keeps the connected-agent risk visible.

The migration is practical. I still want memory, background work, skills, workers, channels, and enough autonomy to feel alive.

I just want those pieces entering the system through my boundaries.

Sources: Pi.dev homepage, Pi extensions docs, Pi skills docs, Pi SDK docs, Pi RPC docs, Hermes Agent feature docs, Hermes Agent memory docs, OpenClaw architecture docs, OpenClaw security docs, HN discussion on productive OpenClaw usage, Reddit Pi and Hermes memory discussion, and Hermes Agent issues.