01Direction
Human Captain
Agree on the goal and written plan, then delegate authority.
IdentityYour account
Captain’s Bridge
Hermes HelmetOpen-source software factory
Give Hermes the wings to carry your plan through, under its own identity
Controlled autonomy with agent identity
Hermes Helmet carries an accepted GitHub plan through implementation, review, repair, and authorized merge, with controlled autonomy and Hermes working under its own identity.
Built for people who already work with coding agents and have a project they cannot avoid finishing. You keep the plan that holds your intent, one accountable first officer you can question about what was built, and a record on GitHub you can inspect and correct.
With Captain’s Bridge, read a cited account of what changed, right beside your conversation.
WorkerSeparate identity
Inspect the work
Captain’s Bridge
See what the work came to.
Check it against the records.
After you delegate, ask your first officer to open Captain’s Bridge. It reads the saved records of one chat and writes an account of the work that cites those records. You see what changed and what is still open without scrolling through every tool call, and each statement points to the records it came from.
The Bridge keeps recorded facts, the account your first officer interpreted from them, and acceptance of the work apart. Your first officer reviews and accepts work under the authority you delegated. The Bridge does not verify that an account is true, and it does not verify delivery, so open a cited record when a statement matters.
CodexClaude Code
In Codex, the Bridge is a read-only panel that re-reads the chat’s saved records when you refresh; it does not monitor. Claude Code takes a different path. The guide covers what each host does and does not show.
Read how Captain’s Bridge worksAn illustrative view of an account
What changed
Start with the purpose and outcome, then explore the changes recorded in your conversation.
What remains unresolved
See the open questions and unfinished work the account lists beside what has already moved forward.
Inside the work
Follow the handoffs, reviews, and repairs the chat recorded. Open the supporting records and before-and-after comparisons where the account includes them.
These three views show how an account is organized. They are an illustration, not a capture of a real chat.
The delivery path
One plan. Connected work. Explicit authority.
GitHub keeps the issues, pull requests, reviews, repairs, and acceptance visible from start to finish.
- 01PlanCaptain + first officer
- 02ImplementHermes crew
- 03ReviewFirst officer
- 04RepairHermes crew
- 05MergeWhen authorized
Why delegate this way
A large project needs its design to survive the code that arrives.
A coding agent writes quickly. You carry the work between steps: you assign the next task, read the pull request, relay the review comments, and decide whether merging is safe. Meanwhile the design you care about has to stay intact while a lot of code arrives, and noticing where the work has wandered from it is your job too. Hermes Helmet is built to take over the relaying and leave the plan, the questions, and the corrections with you.
Your written plan carries your intent
You shape the next deliverable with your coding agent and record it as GitHub issues, with a parent issue, sub-issues, and explicit dependencies. A small change can be a single issue. Nothing starts until you accept the plan and state the outcome, the scope, and whether merge is authorized. The agent that helped you write the plan then works from that same plan. A plan does not make an agent follow it. It gives the implementation, the review, and your own later reading something to be measured against.
One first officer answers for the work
After you delegate, your coding agent becomes the first officer. It coordinates the assignments, explains what was done, reviews each change, directs repairs, and accepts the result within the authority you gave it. You can ask it why a decision was made. It is not a second human who approves every step. Its responsibility also does not hang on a single chat session: checkpoints on your machine and the records on GitHub let a later first officer pick the work up instead of starting over.
The record shows who did what
Hermes works under its own GitHub account. Its commits and pull requests appear under the worker's login, and the first officer's reviews and merges appear under yours. Review belongs to a specific commit: only a formal review by the Captain login on the current head counts, and a merge is withheld if the head has moved. The documentation describes these checks as part of the design.
Your part is to set direction, accept the plan, decide merge authority, look at status when you want to, correct what looks wrong, and close the parent epic.
Who acts
You set the direction. Your first officer sees it through.
Put together a written plan with your coding agent and record the work as linked GitHub issues. Then authorize that agent to carry it through with Hermes.
02Coordination
Coding-agent first officer
Assign work, review it, direct repairs, and merge when authorized.
IdentityUses the Captain's OS account and credentials
03Implementation
Hermes crew
Implement, test, open pull requests, and repair the same change.
IdentityIts own worker account and credentials
Identity and authority
A worker identity inside Docker Compose
The first officer stays on your workstation, using your credentials to assign and accept work. Hermes runs in the Compose stack with its own GitHub account, token, and checkout.
Captain identity on the workstation, GitHub in the middle, and the Hermes worker identity inside Docker Compose.
You, the Captain, give a written plan and delegated authority to the first officer, who uses your OS account and GitHub credentials. The first officer assigns work, reviews, and handles authorized merges on GitHub. GitHub issues and review feedback reach the issue and review poller in the Hermes container. Hermes Kanban assigns the Hermes worker, which uses its own GitHub account and token to commit, open pull requests, and repair them. Worker checkouts, credentials, and task history stay on a persistent volume at /opt/data.
Captain identity · your workstation
You · Captain
Written plan + delegated authority
First officerYour OS account + GitHub credentials
GitHub
Issues · pull requests · reviews · checks
Docker Compose · deploy/compose.yaml
Hermes container · worker identity
Issue and review poller
to
Hermes Kanban
to
Hermes workerOwn GitHub account + token
Persistent worker volume · /opt/dataCheckouts · credentials · task history
Delivered work
Review found a defect. Hermes repaired the same pull request.
Younes used Hermes Helmet to deliver installation and local-memory improvements in FAVA Trails 0.7.0. The implementation, review, repair, and acceptance remain visible in the public GitHub record.
- PlanRequirements issue 107
- ImplementationPull request 111
- ReviewRepair requested
- RepairHermes updated the same branch
- ResultPublished in FAVA Trails 0.7.0
yia-mw-agent authored the implementation. Review and merging used the Captain account, timeleft--, through the first officer.
Evidence from saga a2ui
A written design gave the questions something to hold against.
While building saga a2ui, Machine Wisdom AI's open-source framework for agentic apps with A2UI and MCP Apps, Younes Abouelnagah saw agents depart from the intended architecture several times. He noticed because the first officer's explanations placed a responsibility in the wrong layer. Because the first officer had the written plan, he could question the work against that plan instead of re-explaining the design from memory. That account is his.
Model choice
Keep the workflow as models change
The coding agent acting as first officer, the model used by Hermes, and each actor's authority remain separate choices. You pick the first officer's host and model in that agent's own tooling; the documentation reports the first-officer workflow as exercised through Codex. The worker's provider and model are set on the worker. By design, moving it to another provider keeps its GitHub account, leaves your repository policy in force, and leaves merge authority with the first officer. Optional FAVA Trails and OpenViking keep shared project knowledge available across connected clients; the delivery workflow works without them.
What you retain
- Source you can inspect and adapt
- Task records and review history
- Explicit authority choices
- Freedom to change providers
What adoption asks of you
Your first officer is an agent you already use. The worker is a separate piece: it runs in Docker under a second GitHub account that you create and own, with its own token, a policy file, and a repository allowlist. The policy is yours, and a team can keep it in its own private repository without forking the core. This is real setup. The case for Hermes Helmet is the factory it gives you, the one you were about to assemble yourself from agents, scripts, and manual handoffs.
Take the helm
Give Hermes a written plan and the room to carry it through.
Start with one GitHub issue, explore the recorded work in Captain’s Bridge, then delegate a larger plan when you are ready.
Open the Hermes Helmet quickstart