Hermes Flightdeck

One mission. Three agents. One verified result.

Comment

Inspiration

I use development agents for tasks that can run for a long time and involve multiple tools. I found that a conventional chat quickly becomes a poor control center: I have to wait for one action to finish before starting the next, roles become blurred, and a statement like “the tests pass” is difficult to verify without going back through the entire conversation history.

Telegram is convenient for making changes, but a single chat session limits parallel work on the same project. Threads allow multiple sessions, yet the instructions and conversations are no longer hosted solely on my own infrastructure, and the experience remains constrained by Telegram.

I wanted to define a mission once, keep the work on my own server through Hermes, and review a clear final result. Flightdeck grew from that idea: rather than adding more chat windows, it establishes an engineering protocol between multiple agents.

What it does

Mission Mode compiles a development goal into a controlled workflow:

  1. The user selects an authorized Git project, starting branch, constraints, and acceptance criteria.
  2. The Architect analyzes the mission and produces a plan without modifying the code.
  3. The Builder works in an isolated branch and Git worktree, runs checks, and creates a candidate commit.
  4. Flightdeck verifies that commit and transfers it to the Verifier’s clean worktree through a controlled server-side cherry-pick.
  5. The Verifier performs independent checks tied to the acceptance criteria.
  6. The Evidence Layer recognizes only structured results as evidence: tool outputs, exit codes, Git state, and runtime artifacts.
  7. The Architect session is reused to ask GPT-5.6 for a final decision: ready, needs_work, or blocked.

Flightdeck never merges automatically into main and never deploys a mission automatically. It produces a candidate for human review together with Markdown and JSON reports.

What makes it different

Most multi-agent demos add more chats. Flightdeck adds the engineering protocol between them:

  • real isolation by session_id, branch, and worktree;
  • a verified Git handoff between Builder and Verifier;
  • an independent Verifier that does not trust the Builder’s account of its own work;
  • acceptance criteria linked to identifiable evidence;
  • a final decision that cannot mark a criterion successful without valid proof;
  • an exportable, reviewable execution trail.

How we built it

Flightdeck is a React and TypeScript application served by an Express backend. It communicates with the Hermes gateway through JSON-RPC and WebSocket.

Deterministic application code handles the project allowlist, canonical paths and worktree isolation, role and phase transitions, event routing by session_id, Git handoff and safe conflict rollback, evidence parsing and redaction, decision-schema validation, local persistence, and exports. A fail-closed rule prevents a false READY result.

GPT-5.6 with xhigh reasoning effort performs architectural analysis, implementation work, independent verification, and the final recommendation constrained by the evidence registry.

Flightdeck does not put an OpenAI key in the browser. Hermes keeps its Codex OAuth session on the server, while Flightdeck communicates only with the authenticated Hermes gateway. The judge demo uses an isolated Hermes profile, a dedicated Git repository, and three real sessions running in a no-network sandbox. It cannot access personal projects or secrets.

How I collaborated with Codex

Codex was my development partner during Build Week. I used it to explore the architecture, implement Mission Mode, write tests, reproduce defects, conduct critical reviews, and run verification campaigns across browsers and screen sizes.

I remained the decision-maker. I chose to retain manual chat, limit a mission to three roles, require independent verification, prohibit automatic merges, isolate the judge demo from my real Hermes account, and refuse to treat an agent’s claim as evidence. When reviews uncovered reproducible issues—late interruptions, incomplete rollback, malformed local restoration, insufficient redaction, or mobile accessibility defects—the work continued until those issues were fixed, with regression tests and final validation.

Challenges we ran into

Truly isolating multiple agents

Three branches are not enough when agents share the same files. Flightdeck creates a dedicated branch and worktree for each role and passes that exact path to the corresponding Hermes session.

Distinguishing a claim from evidence

An agent can say that tests pass without providing a reproducible result. The Evidence Layer accepts structured events only and keeps a criterion in the unknown state until it has been proven.

Transferring work without compromising Git safety

Before the cherry-pick, the server validates the mission identity, candidate ancestry, branch head, and cleanliness of the Verifier worktree. If a conflict occurs, the operation aborts without force-pushing, destructive cleanup, or forced branch deletion.

Making interruption terminal

Asynchronous events can arrive after an interruption. The Mission reducer acts as a terminal-state firewall: a stopped mission cannot become active or completed again because of a late event.

Providing a safe public demo

The judge environment runs three real Hermes sessions but exposes no personal project, credentials, or network access. The demo repository and backend are dedicated to the competition.

Accomplishments that we're proud of

  • A mission described once becomes a complete, visible workflow.
  • All three roles have genuinely isolated Git environments.
  • A real commit is handed to the Verifier without giving the browser the ability to issue Git commands.
  • A criterion cannot be marked successful without valid, cited evidence.
  • Interruptions, rejected approvals, partial failures, and Git conflicts have explicit recovery paths.
  • The public demo is real, isolated, responsive, accessibility-tested, and able to export reviewable reports.

The feature I am most proud of is the Evidence Layer: even a persuasive agent response cannot produce READY unless every acceptance criterion has structured passing proof.

What we learned

A credible multi-agent product depends less on the number of agents than on the quality of the boundaries between them. Isolation, event provenance, state transfer, and evidence validation matter more than prompt orchestration alone.

AI is especially useful when it participates in a complete loop: propose, implement, test, receive independent criticism, correct, and repeat. Flightdeck makes that loop visible and controllable.

What's next for Hermes Flightdeck

  • Connect additional agent runtimes while preserving the same evidence contract.
  • Add configurable mission policies based on repository type.
  • Expand runtime artifacts and before-and-after comparisons.
  • Let teams comment on and sign reports before a human merges the work.
  • Build a library of reproducible missions and reusable acceptance criteria.

Try the judge demo

  1. Open the public demo.
  2. Click New mission.
  3. Keep the prefilled Accessible Dark Mode mission.
  4. Click Launch mission.
  5. Follow the Architect, Builder, and Verifier through the final READY decision.
  6. Open the structured evidence and exit codes, then export the Markdown or JSON report.

No installation or personal Hermes account is required.

Built With

Share this project:

Updates