Hermes Agent vs Goose: Desktop CLI or Server Runtime?

Two Well-Named Agents Aimed at Different Machines

If you typed "hermes agent vs goose" into a search bar, you are comparing two of the most-starred open-source AI agents of 2026, but they aim at different machines. Goose is Block's Rust-based, Apache 2.0 licensed desktop and CLI agent, now with 44,000+ GitHub stars and governed by the Agentic AI Foundation at the Linux Foundation. Hermes Agent is Nous Research's MIT-licensed, Python-based server runtime that crossed 175,000 stars less than four months after its February 2026 release. One is a polished desktop assistant driven by portable YAML recipes. The other is an always-on messaging-first daemon with persistent memory.

That distinction shapes almost everything downstream: how you install each project, where it lives, how it remembers you, how you extend it, and which reader hits "back" on Google when they land on the wrong one. This post walks through what each project actually is, the honest decision boundary between them, and the hybrid setup that runs both at once.

What Goose Actually Is

Goose is an on-machine AI agent from Block (formerly Square). You install it as a native desktop app or a CLI, written in Rust for portability and speed, and the agent runs inside a session you open on your laptop. Point it at a model provider - Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock, or any OpenAI-compatible endpoint - and start a task. There are 15+ supported providers in the box.

The strongest opinion in Goose is the recipe: a YAML file with a name, a prompt, an extension list, structured inputs, and optional sub-recipes. Recipes are how the same binary handles PR review, ticket triage, test-suite repair, and dozens of other jobs. A recipe might say "run the test suite, collect failures, fix each failing test, re-run to confirm, then create a commit", and any teammate can check that file into a repo and run it. Block reports that this abstraction is how Goose scaled to 60% of the company's ~12,000 employees across engineering, sales, design, product, and customer success.

Extensibility is the other pillar. Goose was an early MCP adopter and now has 70+ documented extensions, which means every new capability - a database reader, a Jira board, a monitoring query - is a one-time MCP server that then plugs into every recipe. Goose can also spawn independent subagents in parallel to keep the main conversation clean.

What it does not have out of the box is a persistent, cross-session identity of you. Memory in Goose is scoped to a session and to whatever the current recipe decides to remember. If you want an agent that knows what you told it two weeks ago without you rebuilding a recipe to fetch that context, that is not the shape of the product.

What Hermes Agent Actually Is

Hermes Agent is a Python server runtime, not a desktop app. One command installs it, one command starts it, and a long-lived process comes up on your host - a $5 VPS, a Raspberry Pi, a NAS, a home server. You then talk to it from wherever it is convenient: Telegram, WhatsApp, Discord, Slack, Signal, Matrix, Mattermost, email, SMS, or a local CLI - roughly twenty channels served by one gateway.

There is one agent, deliberately. Its power comes from three layers of state that ship out of the box:

• Core memory files (MEMORY.md, USER.md) injected into the system prompt at session start.
• Session search powered by SQLite FTS5, so the agent can recall what you said last Tuesday without you re-pasting anything.
• Skills, plain markdown files compatible with the agentskills.io open standard, that the agent both loads and writes for itself after tasks it wants to remember how to do.

Around that core sits a bundled toolbelt: web search, page extraction, browser automation (navigate, click, type, screenshot), vision, image generation, text-to-speech, and dozens more. Hermes speaks any OpenAI-compatible model, so Nous Portal, OpenRouter's 200+ models, NVIDIA NIM, Hugging Face, or your own endpoint all work. The runtime is MIT-licensed and the marginal cost is dominated by your model provider bill.

The Decision Boundary

A useful framing: Goose is the agent you drive from your keyboard. Hermes is the agent you message from your phone.

The signal that you picked the wrong one is usually loud. If you are trying to have "one agent on Telegram that knows me and drafts my email at 8am while my laptop is closed", Goose is the wrong shape - there is no long-running server, no messaging bridge, and no persistent identity. If you are trying to run a shareable "review this PR, patch, retest, commit" workflow inside CI, Hermes is the wrong shape - a messaging-first personal daemon is not what a build agent needs.

When Goose Wins

Goose is the right answer when:

• The agent's job is code work you drive from a terminal. Reading, editing, executing, and testing files on the machine you are already sitting at.
• You want workflows that are portable and reviewable. A YAML recipe checked into a repo is the artifact - your teammate clones the repo, runs goose run, and gets the same behavior.
• You are inside a team or company and you want dozens of jobs to share one binary and one extension surface. Block's 60% adoption number is the shape of this use case.
• You want maximum model freedom on your desktop, without a server. Anthropic, OpenAI, Google, Ollama, OpenRouter, Bedrock, Azure - any of them work, and Ollama means fully offline is real.
• You want subagents in parallel so the main conversation stays readable while background jobs churn.

This is the on-machine agent category. Goose overlaps here with Aider, Cursor, and Claude Code, and with OpenClaw. Its distinguishing feature is the recipe format - a boring, well-shaped abstraction that generalizes to non-code work as well.

When Hermes Wins

Hermes is the right answer when:

• The agent is for you, not for a repo or a team. A daily writing assistant, a long-running journaling partner, a personal CRM that lives in Telegram.
• You want the memory and messaging out of the box. No recipe to write for "remember I use pnpm", no messaging adapter to hand-roll.
• The agent needs to be awake while you are asleep or your laptop is closed. A server runtime is on 24/7 by definition.
• You want it to reach you where you already are. Voice messages on Telegram, a Slack DM, an SMS - not a terminal window you have to open.
• You want it to improve itself. Hermes writes and patches its own skill files as it works, so the agent you have next month is a little better than the one you have today.

This is the personal agent category. We compared Hermes against the major chat-only assistants in Hermes Agent vs ChatGPT, Claude, and Gemini, against workflow tools in Hermes Agent vs n8n, and against Python frameworks in Hermes Agent vs Agno.

Get started with Hermify if you want a managed Hermes Agent running on Telegram in under a minute, with no VPS to operate.

The Honest Hybrid

The two projects are not mutually exclusive, and the more interesting setup runs both.

• Goose lives in your dev loop. On your laptop, a directory of recipes handles PR reviews, refactor sweeps, migration passes, test-suite repair - the tasks that are naturally scoped to "open a session, run to completion, close it". Recipes get checked into the repo like any other code.
• Hermes carries the ambient relationship. On a server you talk to from Telegram all day, Hermes drafts your email, summarizes your reading, tracks your projects, and remembers the customer you promised something to two Fridays ago.

The bridge between them is MCP. Hermes speaks the OpenAI-compatible API and can expose itself as an MCP server, so a Goose recipe can call your Hermes memory as a tool ("what was the customer's stated budget for this project?"). Conversely, a Hermes skill can shell out to goose run recipe.yaml when a task is naturally a code-shaped job. In practice: Hermes owns the relationship state (who you are, what you care about, who your contacts are), and Goose owns the structured jobs (the ones you would happily encode as YAML if you had to).

Cost, Hosting, and Lock-In

Both projects are open source and self-hostable. Neither locks you into a vendor.

Goose runs on your local machine, so the runtime cost is your laptop and your model provider bill. If you use Ollama, offline is free. Recipes are portable YAML, with no runtime that lives in someone else's cloud.

Hermes runs on a server, so you pay for the server (a $5 VPS is enough for personal use) and the model provider bill. If you would rather not run the server yourself, a managed setup handles the VPS, updates, and messaging bridges for you and keeps the memory files in your account. We covered the self-hosted vs managed trade-off in a separate post.

How to Pick

A short decision rule:

1. If your problem is "I want a coding, testing, refactoring, CI-shaped agent I drive from my laptop with reviewable YAML workflows" - choose Goose.
2. If your problem is "I want one always-on agent that knows me, lives in Telegram or Slack, and remembers me across weeks" - choose Hermes.
3. If you want the coding agent on your laptop and the ambient personal agent on your phone - run both, and use MCP to let them talk when a task crosses the boundary.

Forcing either project into the other's shape is the failure mode. Goose is not a messaging-native personal daemon; pretending otherwise means rebuilding the parts of Hermes you would have got for free. Hermes is not a code-first CI runner; pretending otherwise means writing a recipe format Goose already ships. Once you accept that they aim at different machines, the choice gets easy and the two-agent setup starts looking obvious.

Sources

• Goose - Your open source AI agent
• block/goose on GitHub
• Block Open-Sourced Goose: How a YAML Recipe File Scaled an AI Agent to 60% of the Company - The Agent Report
• Introducing Goose, the on-machine AI agent - Marc Nuri
• Goose by Block - Open-Source AI Agent Review - OpenAIToolsHub
• NousResearch/hermes-agent on GitHub
• Hermes Agent - The Agent That Grows With You
• Hermes Agent - The Self-Improving AI Agent