Hermes Gate: Compiling Judgment Into a Removable Approval Layer

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

I built Hermes Gate, a small product prototype for a problem I think every serious agent user runs into eventually:

At first, the agent asks too many questions.

Then you get annoyed and tell it to proceed.

Then it proceeds through something it should have asked about.

That is the whole tension. Human-in-the-loop is obviously safer, but it does not scale when the work is low-importance, repetitive, and mostly bounded by preferences you have already expressed a hundred times.

Hermes Gate is my attempt at turning that into a usable control surface. It is not a chatbot. It is an approval gate that learns which decisions are stable enough to stop bothering me about.

The prototype has three pieces:

• A landing/product surface that explains the idea without exposing private prompt history.
• A simulated approval gate showing which kinds of decisions can move toward automation.
• A privacy model for learning from recent decision patterns without publishing raw session text.

The key design choice is that the approval gate is removable, but not fake-removable. The system starts with review on. It only earns zero-touch behavior after it sees repeatable accept/reject patterns under the same conditions.

That sounds small, but I think it is the entire product category.

Demo

The demo is a Next.js site called Hermes Gate.

The first viewport shows the core mechanic:

• Project: low-risk site polish
• Gate state: Review on
• Questions like “Which edits get accepted without review?” and “Which signals force the approval gate back on?”
• A next-action rule: proceed automatically only after repeated clean acceptances under the same conditions.

The rest of the page explains the system as:

1. Observe recent decision behavior.
2. Model the preference and risk conditions.
3. Gate low-risk autonomy while disputed calls stay in review.

I intentionally did not build a giant dashboard. That was the failure mode I wanted to avoid. A normal user does not need a strategy wall. They need to know whether the agent is allowed to keep going.

Code

Repository:

https://github.com/dodge1218/hermes-autonomy-substrate

Latest contest hardening commit:

c468a1e Harden Hermes contest package against private-context leaks

The repo contains the Next.js app, the build docs, the quality scorecard, and local screenshots from desktop and mobile QA.

One note on access: this build was developed around sanitized preference examples because the source material is private operator history. The public-facing product avoids private text, internal traces, local environment details, and unrelated work streams by design. That privacy constraint is part of the build, not something bolted on afterward.

My Tech Stack

• Next.js App Router
• TypeScript
• Tailwind CSS
• shadcn-style Button primitive with Radix Slot
• Lucide React icons
• GSAP for restrained motion
• Static metadata and JSON-LD
• Local desktop/mobile screenshot QA

I used a minimal stack because the product idea is not “look how many integrations I can wire up.” The hard part is the boundary model: when does an agent stop asking, and what evidence makes that safe enough?

How I Used Hermes Agent

Hermes Agent is interesting here because Hermes already cares about learning from experience. The obvious version of memory is “remember the chat.” I do not think that is enough.

The useful version is more like:

• What did I accept?
• What did I reject?
• What conditions changed the answer?
• Which categories are low-risk enough to automate?
• Which categories should never be inferred from old behavior?

So I used Hermes as the conceptual center of the project: an agent that does not just store memories, but turns repeated work into skills, preferences, and gate rules.

The build process leaned on that idea in a very direct way. I started from the actual operating problem: I have agent-heavy workflows where the human review step is sometimes valuable and sometimes pure drag. High-risk work should not be mined into casual autonomy rules just because it appears in the same history. Low-importance product work is different. Small copy edits, site polish, project packaging, repetitive QA, and bounded preference calls are exactly where an approval gate can earn trust.

That became the product shape:

• Recent behavior matters more than stale history.
• Private text should not be published or treated as the artifact.
• The model should learn decision conditions, not private text.
• Approval should be visible first, then removable later.

This is where Hermes fits better than a generic agent wrapper. The learning loop is not decoration. The whole point is to let the agent improve its own operating surface over time.

The Part I Think Matters

Most agent products still treat human-in-the-loop as a checkbox.

Human approval: on or off.

That is too crude.

The real question is: under what conditions does this specific user consistently make the same decision?

If the answer is stable, the agent should stop asking. If the answer is unstable, sensitive, high-impact, or based on a context the system cannot observe, the gate should stay on.

That is the product I want: human-in-the-loop replacement as a service, but earned one narrow category at a time.

Not “trust the agent.”

Trust the evidence that this decision no longer needs me.