Imagine holding the winged helmet of Hermes, the Greek god who travelled between the divine and mortal worlds. Its wings promise speed and the freedom to travel far. Now bring it down from Olympus and place it on a different Hermes: Hermes Agent, the open-source harness from Nous Research, one of the best and most capable agentic harnesses. That helmet gives Hermes the ability to keep going: to take on a body of work, carry it through review and repairs, and finish within the authority you grant it.
Hermes Helmet is the open-source software factory I built at Machine Wisdom AI around that idea. It adds a process for long-running autonomy, with connected tasks, review, and guardrails. Five requirements shaped the design:
- An identity of its own. The agent should act under its own account, with a clear separation between who is doing the work and who is accepting it.
- Access I deliberately share. It should be able to use the repositories and tools it needs, within permissions I have chosen.
- A record I can inspect. I should be able to understand what it did, which tools it used, and how it reached a decision.
- A way to learn from feedback. Corrections should inform the next attempt and future guidance, so the same lesson survives a handoff.
- Room to work without me. I should be able to set direction and let the agent proceed through a multistage plan without asking for approval at every stage.
You set the direction; your first officer sees it through
I don't want to stretch the Greek mythology analogy too far. The operating model I actually had in mind while building the project was a large ship. You are the Captain on the bridge, setting the destination and watching the voyage. You cannot keep running down to the engine room to give the crew its next instruction or check every repair. You need a first officer who turns your direction into work, coordinates the crew, and sees that work through.
Codex, Claude Code, or another Hermes instance acts as the first officer and directs the worker Hermes through that process, keeping the goal in view as the work moves between stages. The separation between the first officer and the worker reflects what I have always wanted between humans and their agents: agents acting on our behalf under their own identities. When an agent uses our OS account and credentials, it effectively acts as us. The industry has accepted this shared identity model as the status quo, so I challenged it and built something better.
In Hermes Helmet, you are the Captain, and the coding agent running on your computer is your first officer. The first officer runs as the same OS user as the Captain and uses the Captain's credentials, which is the industry standard. What makes Hermes Helmet unique is how the Hermes agent runs with a different identity, making it clear who is doing the work.
This is a familiar pattern for those who run OpenClaw as a personal assistant with its own email address. Claire Vo describes giving her agent its own account and forwarding selected email in How I AI, following the approach she uses with a human executive assistant. Giving agents distinct identities is also a principle of the Blueprint Alliance.
However, coding agents don't make this separation and they act as the user, regardless of whether they are running in the cloud or on the computer, directly or in a container.
In Hermes Helmet, you put together a written plan with your coding agent, then delegate authority to it as first officer to carry that plan through: assigning tasks, reviewing results, directing repairs, and merging when authorized. Hermes is the crew, writing code, running tests, and making repairs under its own worker identity. You decide the goal and the limits; your first officer handles the work within them and brings you decisions that need your authority.
The skills bundled with Hermes Helmet give the first officer its operating instructions, and the Hermes worker runs in Docker. I use Codex as my first officer; the skills also work with Claude Code and other harnesses that support the Agent Skills format. The Hermes Kanban board and linked GitHub records let me look in on progress while the agents carry the work forward.
How Hermes Helmet carries a task through to completion
You use your coding agent to turn the agreed goal into linked GitHub issues; I use Matt Pocock's skills such as to-spec and to-tickets. Then you tell it to use the Hermes Helmet skills to follow each change through review, necessary repairs, and an authorized merge. The Hermes Kanban board shows the assignments; GitHub holds the implementation and acceptance records.
I used this workflow to deliver the installation and local-memory improvements in FAVA Trails 0.7.0. FAVA Trails is my agent-memory project. Its requirements plan called for a smaller installation burden and clearer control over where stored context goes for review. That meant coordinated changes across the installer, model configuration, credential handling, coding-agent setup, and repository synchronization.
The work was split into issues with concrete outcomes, then delivered through separate pull requests:
| Required outcome | Implementation |
|---|---|
| Preserve a compatible Jujutsu installation instead of replacing it with an older default. | Installer requirement and completed change. |
| Show where memory review sends data, and keep a configured local-only path from silently falling back to a cloud provider. | Review-destination requirement and completed change. |
| Reject supported credential patterns before normal storage or remote review. | Credential-handling requirement and completed change. |
Register the memory service with coding agents without changing the application's .env file. | Setup requirement and completed change. |
| Offer shorter tool descriptions to coding agents and make synchronization work sensibly for repositories without a remote. | Tool-description change and local-repository change. |
The review-destination work shows why the handoff matters. Review found an error path that could copy credential text from a provider exception into diagnostics and stored metadata. The first officer requested a repair, and Hermes pushed the correction to the existing branch and PR. After a further correction to the reported status code, the first officer approved the repaired version, which was then merged. The worker continued from the GitHub review instead of needing me to relay the comments into a new conversation.
You can see the identity boundary in those records. The worker account, yia-mw-agent, authored each of the linked implementation PRs. Review and merging used my Captain account, timeleft--, through the first officer. The worker also prepared the release, leaving publication on the Captain side. The result is available in the published 0.7.0 package. The broader plan also includes a separate cross-session learning evaluation, which remains open.
This is the continuity I mean by a software factory: a body of work can move through assignments, implementation, necessary repairs, and acceptance while preserving who did what. The Captain and Crew operating model describes parent and child tasks, dependencies, and bounded parallel work. Cursor Projects helped put words to the broader experience of directing a body of work through a coordinator. Hermes Helmet gives me that operating model in source I can inspect and adapt.
FAVA Trails also gives those records a human reading surface. Rich Views turns existing Markdown into a local reader for decisions, their history, and their relationships, so I can regain context without asking an agent for another summary.
Separate worker identity and delegated authority
The worker's GitHub credentials determine what it can access. Your first officer uses your credentials and the authority you delegate for review and merging, so configure both accounts to match their responsibilities. Hermes Helmet also has a repository allowlist to control where it dispatches work, and it uses a GitHub personal access token (PAT) that ultimately governs what the worker can actually do. The public preview notes explain the boundary.
Teams can keep their authority policy and deployment configuration in a private company repository, using the published runtime without maintaining a fork.
The identity discussion at Oktane 2026 makes this a fitting moment to share the design. The Blueprint Alliance white paper emphasizes explicit agent identity and traceable delegation. In this workflow, those principles show up in the accounts that implement, review, and accept a change. They are also questions I explore in the two axes of agentic automation.
Keep the workflow as models change
I used several open-weight models successfully through OpenRouter. GLM 5.3 was my latest and best choice when an annual Grok offer made switching attractive. I want to make those choices on quality and economics while retaining the task records, review process, and authority policy I have built around the worker.
The model configuration documentation covers hosted providers and compatible local endpoints. Local inference needs its own server and hardware; the public Compose setup does not start that server.
Put Hermes Helmet to work
Hermes Helmet is available under Apache 2.0 as a public preview. You install the CLI and bundled skills for your coding agent and start the worker separately from the published Docker image, without building it yourself. It uses a stable release of the official Hermes Docker image as its base. Optional memory integrations can be added separately.
Start with the Hermes Helmet quickstart, or point your agent at the setup skill. You need a separate worker GitHub account and token, plus access to your chosen model provider. Then you can send one GitHub issue through the factory. If you like it, please star the Hermes Helmet repository.