I went looking for a talk from Mario Zechner, the creator of Pi, because I wanted to understand why someone would build another coding agent when we already have a pile of them. I found: a talk called “Building pi in a World of Slop.”

Zechner described Pi as a minimal, extensible coding agent that should fit your workflows instead of forcing you into its workflow. He also made a point that should be printed on the box of every AI coding tool: code is not free. The model can produce it quickly, sure. You still own the review, the maintenance, the weird edge cases, and the next person trying to understand it six months later.

That framing explains Pi better than any feature list does.

I’ve also been reading about Hermes Agent, from Nous Research. Hermes is a useful comparison because it’s also an open, provider-flexible agent harness. But it isn’t trying to be Pi with a few extra switches turned on.

Pi and Hermes are trying to solve different problems.

Pi Gives You a Small Place to Start

Pi is a terminal coding harness with a deliberately small default: read files, write files, edit files, run shell commands. Underneath that CLI is a set of TypeScript packages for model access, the agent loop, sessions, and the terminal UI. You can use the CLI, run it through JSON/RPC, or embed the SDK in something else.

That last part is the point.

Pi deliberately leaves out things a lot of agent products treat as table stakes: MCP in the core, subagents, plan mode, permission popups, to-do lists, background shell work. This can look like a missing-feature list if you evaluate it like Claude Code or another finished product.

I don’t think that’s the right test.

Those omissions are Pi’s design. It’s saying: a harness should give you a stable loop, a tool boundary, sessions, and enough extension points to build the workflow you actually need. Then it should get out of the way.

Want MCP? Add it. Want a planning workflow? Make one. Want agents that coordinate over a message bus, work in separate git worktrees, or run in a weird internal deployment? You own the composition. Pi has extensions and packages for that, and now an explicitly experimental orchestration package, but none of it is presented as the one true way to work.

That’s a compelling idea if you’re building a specialized system. It’s also work. Both things can be true.

Hermes Starts With the System

Hermes starts from almost the opposite direction. It’s an integrated autonomous-agent platform with persistent memory, learned skills, built-in delegation, MCP support, scheduling, multiple execution environments, and surfaces that extend beyond the terminal into messaging and desktop interfaces.

Hermes is asking a larger question: what does an agent need to keep working over time, across channels, with memory of what it has already learned?

That’s not just a bigger Pi configuration.

When Hermes includes persistent memory and skill creation, it’s making those things part of the product contract. When it includes subagents and scheduling, it’s giving you an operating model for delegation and recurring work. You get more out of the box, and you inherit more of the system’s assumptions.

For a lot of people, that’s exactly right. If you want an agent to run continuously, show up in Slack or Telegram, remember prior work, and execute recurring workflows, building all of that from Pi primitives would be a very committed hobby.

Good for you, but I think most teams shouldn’t volunteer for that job unless the control model is part of what they’re building.

The Comparison That Matters

Here’s the version I keep coming back to:

	Pi	Hermes
Default posture	Minimal programmable harness	Integrated autonomous-agent platform
Core workflow	You compose the pieces	The product ships an opinionated system
Multi-agent work	Extensions, packages, or your own topology	Built-in delegation and parallel work
Memory	Session primitives and JSONL history	Persistent memory and skill-learning features
Best fit	A workflow or control plane you need to own	A capable agent system you want to operate

This isn’t a scorecard. Hermes isn’t “better” because it has more rows filled in, and Pi isn’t “purer” because it has fewer.

The question is where you want the complexity to live.

With Pi, much of it lives in the system you build around the harness. You have to decide how agents coordinate, what gets remembered, which tools are safe, and how approval works. In exchange, the result can fit your environment instead of being a very configurable version of someone else’s environment.

With Hermes, more of that complexity is already in the platform. You spend less time assembling basic capabilities, but you should understand its memory model, delegation model, security posture, and operational boundaries before you give it real work.

Neither choice removes responsibility. It just changes the shape of it.

Don’t Build a Harness Because It Sounds Fun

Agent harnesses are one of those things that sound like a great weekend project. You wire up a model, give it a few tools, add memory, spawn a couple subagents, and suddenly you have a tiny digital organization running in your terminal.

Then Monday happens.

The agent needs a permission model. It needs observability. It needs a way to recover from bad state. It needs sensible defaults for credentials and logs. It needs evaluation. It needs someone to own the changes when a provider API shifts or an extension becomes a security problem.

That’s why I like the Pi and Hermes comparison. It makes the tradeoff visible.

Use Hermes when you want an agent platform. It already has an opinion about the features an always-on, multi-surface agent needs.

Use Pi when the workflow itself is the product, or when the product assumptions are exactly what you need to escape. Pi’s small core is valuable because it leaves room for a different control plane.

And if all you need is a better code-review prompt or a way to query one internal system, build that inside the harness you already use. A skill, extension, or MCP server is usually a better answer than inventing an agent platform because you wanted one new capability.

This is the same point I landed on in a recent post: you think you want to build your own harness, but what you usually want is a wrapper around the one you already have.

Code is not free. Neither is a harness.

Sources & References

• “Building pi in a World of Slop” — Mario Zechner (talk) — Pi’s design philosophy, workflow fit, and the cost of generated code.
• Pi documentation — current product scope, installation, extensions, and operating modes.
• Pi usage documentation — default tool surface and deliberate core omissions.
• Pi monorepo — TypeScript package architecture and experimental orchestrator package.
• Hermes Agent documentation — persistent memory, skills, delegation, MCP, execution environments, and surfaces.
• Hermes Agent repository — open-source project and implementation reference.

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].