Running a Hermes agent in a real business: permissioning, skills and the trust ladder

Step-by-Step Breakdown

1. Define the job before building anything

   The named failure is the tail wagging the dog — building something, then realising it is not what you wanted, because the model steered and you followed. Decide what problem the agent solves first. Here: customer support, product development and marketing, as three explicit areas. "You have to be really intentional about building the system. It won't build itself for you."

2. Give it a name, because it changes how the team talks

   Theirs is named, and that name becomes the router: a single agent you talk to, with specialists beneath it, and internal conversations become "have it do this" rather than abstractions about the system. The top agent holds the context and delegates — including firing off a coding tool on its own machine to build a feature or fix a bug.

3. Edit soul.md, because you will be talking to it constantly

   soul.md carries the agent's personality. The observation behind the advice is sharp: people described early OpenClaw on Opus 4.6 as warm and pleasant to talk to, and nobody says that about the GPT models — but you can close most of that gap by adapting the soul document to the style you want, rather than accepting the model's default register.

4. Treat context as everything your company knows, not what you paste

   The goal is the agent having access to the codebase, customer information, the website, and both internal and public knowledge bases — "a regular prompt's context multiplied by a thousand". Some read-only, some read-write, with the split driven by risk tolerance and expanded as trust is earned.

5. Connect tools with MCP

   MCP is the standardised way to reach outside systems, and the advice is to use it wherever possible rather than building bespoke integrations. The worked example is an analytics MCP pulling SaaS metrics for the business.

6. Put the guardrails in the platform, not the prompt

   This is the most reusable step. Do not give read and write to your database, billing or website on the strength of a skill or a personality instruction — "it's not like it can't just miss this and decide not to follow it." Use the platform's own deterministic controls: the named example is GitHub branch rules preventing pushes to main and requiring a PR to a develop branch. The rule holds whether or not the agent reads it.

7. Write skills for anything you do twice, then prune them

   A skill is an SOP you would hand an employee — theirs include how the agent contributes to GitHub and how it asks for feedback before building a feature. Hermes writes and prunes skills itself, but the warning is explicit: watch for skill bloat. Check for overlapping skills and for how coverage is distributed across what the business actually does, roughly once a quarter. Making that review itself a skill is suggested.

8. Classify systems by blast radius, not by convenience

   They describe "gears": low-risk systems where access is given freely, especially read-only, against the main product codebase, billing and the website, which are treated as highly sensitive. The distinguishing question is recoverability — an internal knowledge base that gets overwritten can be reverted, and billing cannot.

Gotchas & Caveats

• The presenter runs a podcast-hosting business and the agent is built around it; the specific areas (support, product, marketing) reflect that shape, though the permissioning discipline is general.
• This is one operator's experience over a month of rebuilding, not a measured comparison. The value is in the sequencing and the guardrail discipline rather than in any claim about outcomes.
• The agent is given a lot of reach — codebase, hosting, analytics, customer and billing information. The video is candid that this is "super scary" and that the mitigations are the point; do not take the access model without the permissioning model.
• Skills being auto-generated by the harness is convenient and is also how bloat accumulates. The quarterly audit is the counterweight, and it is manual.

Key Takeaways

• Read-only first, always. Write access is earned after demonstrated behaviour and only behind hard boundaries.
• Deterministic guardrails beat instructions. A branch protection rule cannot be reasoned around; a line in a skill file can.
• "Can it mess up?" is the more important question than "can it do the work?" — and it is the one that decides how much access to grant next.
• Skill bloat is a real maintenance burden even on a harness that manages skills itself. Audit coverage and overlap quarterly.
• soul.md is a real lever on daily experience, not decoration — the model's default tone is not fixed.
• The setup runs on Hermes as the harness with GPT-5.5 as the model, and the presenter notes he has not yet upgraded to 5.6 — a useful reminder that a working agent is not upgraded casually.