how to add observability to your hermes agent in 60 seconds

The Agent You Cannot Watch

A coding agent runs in front of you. You watch the tool calls scroll past, and when it does something stupid you hit escape.

A Hermes agent does not work like that. It sits behind a chat gateway — Slack, Telegram, a cron trigger — and it runs when you are not looking. That is the entire point of it, and it is also why the failure you care about is the one nobody saw. By the time somebody reports that the bot "did something weird on Tuesday," the only record is a chat log that shows what it said, not what it did.

Fixing that takes two commands. Here is the whole thing on video, then the same steps written down.

Sixty Seconds, Start to Finish

Three things happen, and only two of them are commands:

1. Install the failproofai npm package globally.
2. Run failproofai config and take the recommended option.
3. Paste an API key with the events:add permission.

That is it. No SDK to import, no wrapper around your agent, no code change in Hermes at all.

Install the CLI

npm install -g failproofai

Global, so the binary is on your PATH wherever Hermes runs. The CLI is free and MIT-licensed.

Run failproofai config

failproofai config

This is the command that does the work. It sets up the binaries and the environment so that Hermes's logs are forwarded to your dashboard — the nitty-gritty of where the hooks live and how events get shipped is handled for you.

Take the recommended option when it asks. Then it wants an API key.

Paste a Key With events:add

The key comes from the dashboard at app.befailproof.ai, under Keys. Add a new key and give it the events:add permission — that is the one that lets the machine send log events up to your dashboard.

The CLI will also mention policies:pull. You do not need it for observability; it is what lets this machine pull managed policies down later, when you move from watching failures to blocking them. Adding it now costs nothing and saves a key rotation then.

Name it after the agent it belongs to. In the video the key is called Kim, because that is the name of the Hermes agent it is instrumenting. It reads like a nicety and it is not: when a second agent shows up, or when you rotate a key six months from now, the name is the only thing telling you which machine goes dark if you revoke it.

Create it, copy it, paste it into the CLI. Done — every action your Hermes agent takes is now being forwarded.

If you are scripting the install rather than sitting at a prompt, the same connection can be made non-interactively:

export FAILPROOFAI_KEY="<your-key>"
failproofai config --connect https://app.befailproof.ai --token "$FAILPROOFAI_KEY"

Check it landed with failproofai config --status, which reports cloud connectivity, the daemon, and enforcement state.

What Shows Up in the Dashboard

Go back to the dashboard and the events are already flowing in. What you get is not a chat log:

• Every tool call, with its input, its result, and how long it took.
• Every model request — which model, how many tokens, how many rounds of inference a single message turned into.
• Every hook and policy decision, so you can see what was allowed and what was refused.
• Every error, attached to the step that threw it rather than buried in a log file.

All of it grouped into sessions you can replay span by span. The Tuesday incident stops being a story somebody tells you and becomes a trace you can open.

What Hermes Can and Cannot Gate

Worth being exact here, because Hermes is a gateway rather than a coding CLI and its hook surface is narrower than Claude Code's.

Hermes runs at user scope only — there is no project-level or local-level policy install for it. And of the events it exposes, PreToolUse is the one that can actually block. Post-tool, session, and subagent-stop verdicts are recorded, but they are not gates: they tell you what happened, they do not stop it.

So the honest framing is that this setup buys you complete observability and one enforcement point — the moment before a tool runs. That one point happens to be where the destructive actions live, which is why it is the one that ships first.

Once the Events Are Flowing

Observability is the half that shows you the failure. The other half is stopping it from happening twice:

• Run an audit over the history you have just started collecting — failures cluster themselves into named modes, so the dominant pattern surfaces without you writing a single query.
• Turn the pattern into a policy. The 39 built-ins cover the common destructive classes; a custom policy is a match on an event and a function that returns allow() or deny().
• Point the same CLI at your other harnesses. The adapter layer normalises twelve of them — Claude Code, Codex, Cursor, Copilot, OpenCode, Goose, OpenClaw and the rest — to one set of canonical events, so a policy you write once behaves the same everywhere.

If you want the longer version of the enforcement half, the safety hooks guide walks through the policy layer end to end, and agent observability covers what to do with the traces once you have them.

Welcome to failproof ai.