> ../research/hermes_agent_production_deployment.md
Hermes Agent, the open-source agent from Nous Research, is designed around a simple idea: one agent, one memory, available everywhere, terminal, Telegram, Slack, WhatsApp, email, and getting more capable the longer it runs, because it turns solved problems into reusable skills. For a single developer that is exactly the right design. For a business deployment, several of those defaults need a second look. This is the checklist we use when Hermes is the runtime behind an agent that does real work for a client.
§ 01 · One client, one environment
Hermes keeps its state, configuration, sessions, memories and skills, under a data directory (~/.hermes by default, or HERMES_HOME). That makes isolation straightforward to reason about: never let two clients share a data directory, and preferably never let them share a machine. We run each client on its own server. It costs slightly more than a multi-tenant setup, but it removes an entire class of failures, one client's memory or skills leaking into another client's conversations, and it makes data deletion at the end of an engagement a matter of destroying one environment.
§ 02 · Choose the execution backend deliberately
Hermes can run commands through several backends, local, Docker, SSH, Singularity and Modal, and the docs describe container hardening and namespace isolation for the sandboxed options. For a production agent that executes tools on behalf of a business, the local backend is the wrong default: a tool call that goes wrong should hit a container, not the host that also holds credentials and the agent's memory. Pick a sandboxed backend, give it only the network access the workflow needs, and treat the host as something the agent should never need to touch.
§ 03 · Secrets never live in the conversation
Messaging gateways make it tempting to hand the agent a credential in chat. Don't. Anything pasted into a conversation can end up in session history and memory. Keep API keys in environment configuration on the server, scope each one to the minimum the workflow needs, and rotate them on a schedule, the same rule you would apply to any service account.
§ 04 · Plan for model failure, not just model choice
Hermes is model-agnostic: it works with Nous Portal, OpenRouter, direct provider APIs or your own endpoint, and it supports routing and fallback configurations. Use that. A production agent should have a primary model and at least one fallback from a different provider, so a provider outage or rate limit degrades the agent instead of stopping it. Then test the fallback path on purpose, a fallback nobody has exercised is a fallback that doesn't work.
§ 05 · Put a human gate in front of irreversible actions
Hermes can act autonomously and run scheduled tasks unattended through its gateway. That's powerful and it's exactly why the actions that can't be undone, sending money, emailing customers, deleting records, publishing, should route through an approval step. In our deployments that step is usually a message in the client's Telegram or Slack with the proposed action and an approve/reject choice. The agent does the work; a person owns the decision.
§ 06 · Memory is a feature and a liability
Persistent memory is what makes Hermes useful over weeks instead of minutes. In a business setting it also means that a wrong fact, an outdated price or a one-off instruction can persist and quietly shape future answers. Decide up front what the agent is allowed to remember, review what it has stored on a schedule, and make sure you can delete a specific memory when a client asks.
§ 07 · Back up the data directory
Everything the agent has learned lives in that data directory. Back it up like a database, on a schedule, off the machine, and test a restore. An agent that loses its skills and memory after a disk failure is back to day one.
── Checklist ──
§ 08 · Checklist
[ ] Does every client have its own environment and data directory?
[ ] Are tools executed in a sandboxed backend, not on the host?
[ ] Are all credentials in server configuration, never in chat?
[ ] Is there a fallback model from a different provider, and has it been tested?
[ ] Do irreversible actions require human approval?
[ ] Is there a policy for what the agent may remember, and a way to delete it?
[ ] Is the data directory backed up and has a restore been tested?
── End of note ──
For how we define an agent's identity and boundaries before any of this, see Anatomy of a SOUL.md.
ORBIRESEARCH