How to Host Hermes Agents in Production at Scale

Getting one Hermes agent to complete a useful task is a product milestone.

Keeping a group of Hermes agents healthy, recoverable, and safe around real business systems is an operations problem.

The difference appears as soon as an agent becomes responsible for work that continues after the demo:

• it keeps a workspace and task history;
• it connects to model providers and external tools;
• it acts through browsers, APIs, files, and messaging channels;
• it may create side effects that cannot simply be replayed;
• it has to survive provider failures, runtime crashes, upgrades, and expired credentials.

A server that can start Hermes is only the first layer. Production hosting must preserve the agent's ability to finish work correctly.

If you need the framework-level introduction first, Hermes agents, explained covers what Hermes is and how it differs from an ephemeral agent task. This guide focuses on the production layer around it.

This guide presents an architecture for doing that without copying the usual "one VM per agent" recipe.

Model the deployment as five operating planes

Do not treat a Hermes deployment as one process plus a configuration file. Split it into five planes with different responsibilities.

Hermes production environment
  |
  +-- Runtime plane
  |     process, version, dependencies, compute
  |
  +-- State plane
  |     workspace, memory, task ledger, restore points
  |
  +-- Inference plane
  |     provider, model, fallback routes, budgets
  |
  +-- Tool plane
  |     integrations, browser, credentials, approvals
  |
  +-- Operations plane
        health, logs, recovery, upgrades, human handoff

This separation matters because the planes fail differently.

A runtime can be alive while its provider is rate-limited. A model can respond while the browser session is stuck behind a login. A tool can succeed while the agent fails to record the result. A replacement process can start perfectly while the workspace it needs is missing.

If all five planes are bundled into one vague "agent online" status, operators learn about failures from users. If they are modeled separately, each failure has a clear signal and recovery path.

1. Make the runtime replaceable

The Hermes process should be easy to replace without destroying the agent it serves.

Pin the runtime version instead of following an unbounded latest release. Record the configuration version beside it, and build instances from a repeatable definition rather than a sequence of manual shell commands.

The runtime plane should contain only what is needed to execute the current instance:

• the pinned Hermes version;
• system and language dependencies;
• the active configuration reference;
• resource reservations and limits;
• a health endpoint or supervisor signal;
• the mount or connection to durable state.

Avoid making the running machine the only place where important files exist. If replacing a failed process means reconstructing its personality, credentials, memory, and work from the disk that just failed, the runtime was not disposable.

The test is simple: can the platform terminate an unhealthy Hermes process, recreate it elsewhere, reconnect its state and tools, and resume service without manual archaeology?

2. Define what must survive a restart

Hermes has several forms of state, and they do not all deserve the same retention policy.

Classify state before choosing storage:

State class	Examples	Production requirement
Durable identity	Agent instructions, role, policies	Versioned and restorable
Working state	Active files, task artifacts, notes	Persist across process replacement
Execution state	Task stage, pending approval, side-effect status	Transactional enough to reconcile
Session state	Conversation and model context	Resume when useful, rebuild when safe
Ephemeral data	Caches, temporary downloads, generated intermediates	Recreate or discard

Hermes includes optional filesystem checkpoints before destructive operations. That is useful protection for project changes, but it is not the entire continuity strategy. Production still needs backups, retention rules, and a task ledger that explains what happened outside the filesystem.

For every active task, record at least:

{
  "task_id": "research-1842",
  "state": "waiting_for_approval",
  "last_safe_step": "sources_collected",
  "pending_action": "send_report",
  "workspace_version": "ws-91",
  "updated_at": "2026-08-27T16:00:00Z"
}

This record gives a replacement runtime something more reliable than a transcript to reason from.

3. Treat the model provider as a production dependency

Hermes can work across many model providers, aggregators, and OpenAI-compatible endpoints. It also supports fallback routes and separate models for auxiliary tasks.

That flexibility is valuable, but provider compatibility is not the same as behavioral equivalence.

A new route can change:

• tool-call accuracy;
• structured-output reliability;
• context limits;
• vision capability;
• latency and rate limits;
• retry behavior;
• cost per completed task.

Define a capability contract for each agent role. A browser operator, coding agent, support agent, and research agent should not inherit the same fallback just because all four models return text.

Capability	Requirement	Failure signal
Tool calling	Valid tool names and arguments	Schema or dispatch error
Structured output	Downstream format remains valid	Parse failure
Context	Instructions and active state fit	Lost constraints
Vision	Screenshots are interpreted correctly	Repeated navigation error
Policy	Approval boundaries remain intact	Unauthorized action attempt
Budget	Task finishes inside cost and time limits	Budget or deadline breach

Use fallbacks for known routing failures such as an outage or rate limit before work begins. Do not blindly switch providers after an ambiguous external action. A different model does not know whether the first route already sent the email, changed the record, or submitted the form.

Multi-provider support should be one resilience mechanism inside the hosting architecture, not a reason to ignore state and side effects.

4. Put tools behind stable contracts

The tool plane is where a Hermes agent touches the real world.

Keep the model-facing interface stable even when the underlying integration changes. Each tool should define:

• a strict input schema;
• an explicit read or write classification;
• credential scope;
• timeout and retry policy;
• idempotency behavior;
• approval requirements;
• a result that can be recorded independently of the model response.

For example, a send_email tool should not expose one global mailbox credential to every agent. The tool layer should resolve the right sender identity, verify the recipient and approval policy, attach an operation ID, send once, then persist the external reference.

{
  "operation_id": "invoice-2026-184-client-42",
  "tool": "send_email",
  "state": "completed",
  "external_reference": "message-93821",
  "agent_id": "billing-agent-42"
}

When the model or runtime fails after the send, the next process can inspect this record instead of sending again.

This pattern is especially important for browser automation. A page click can succeed even if the browser later times out. Recovery should inspect the destination state before repeating the action.

5. Separate credentials from the workspace

An autonomous agent needs credentials, but credentials should not become ordinary workspace files.

Use scoped access for each agent and integration. Keep production, staging, and evaluation credentials separate. Rotate provider keys independently from business-system credentials, and remove access when an agent is decommissioned.

The operating environment should be able to answer:

• Which agent can use this credential?
• Which tools can receive it?
• Is it read-only or write-capable?
• When was it last used?
• Has its OAuth session expired?
• What approval is required before a protected action?

Never rely on the model to remember access policy from a prompt alone. Enforce the boundary in the tool and credential layer.

6. Observe completed work, not just running processes

A healthy process is necessary, but it is a weak production signal.

The host can report that Hermes is online while:

• the active provider rejects requests;
• the agent cannot access a required tool;
• a browser is stuck at login;
• an OAuth token has expired;
• the task loop is repeating without progress;
• the agent claims completion without creating the expected result.

Use layered health checks:

1. Infrastructure health: is the compute environment reachable?
2. Runtime health: is Hermes alive with the intended version and configuration?
3. Inference health: can the selected route answer inside its latency budget?
4. Tool health: can required dependencies authenticate and perform a safe check?
5. Task health: is the agent progressing toward a defined completion condition?

The fifth layer is the one users care about.

For recurring workflows, add synthetic tasks that exercise the real path without causing side effects. A support agent might read a seeded ticket, classify it, and produce a draft response. A browser agent might log into a test account and verify a known element. A research agent might retrieve a controlled page and return a checksum.

Track success by task class, Hermes version, provider route, and tool dependency. This makes regressions visible before an entire fleet is affected.

7. Build a recovery ladder

Restarting the process is only the first recovery action.

A useful recovery ladder moves from the cheapest safe action to the most invasive:

1. Retry a read-only dependency call
2. Refresh a stale session or credential
3. Switch an eligible inference route
4. Restart the Hermes process
5. Recreate the runtime around the same durable state
6. Restore a known-good workspace or configuration version
7. Pause side effects and request human review

Each step should have a limit. Endless retries can create rate-limit storms, duplicate actions, and a false impression of availability.

Recovery also needs context. A provider outage before a task begins is safe to route around. A timeout after a form submission is an ambiguous write. The first can be automated aggressively. The second requires reconciliation.

Record the reason, action, and outcome for every recovery attempt. Otherwise the same broken instance can cycle through restarts without anyone learning what actually failed.

8. Change Hermes versions and configurations with canaries

An agent runtime upgrade can change more than startup behavior. It can affect tool definitions, provider routing, memory, prompts, browser behavior, and the shape of stored state.

Do not upgrade all agents together.

Use a staged path:

1. Replay a sanitized set of completed tasks against the candidate version.
2. Run internal or low-risk agents first.
3. Canary a small production cohort with reversible work.
4. Compare completion, tool errors, latency, recovery, and human escalation.
5. Expand by task class, not only by fleet percentage.
6. Keep the previous runtime, configuration, and workspace version available for rollback.

Pinning versions per agent is useful when different workflows have different risk tolerance. A research fleet can adopt a new release before a billing or customer-communication fleet.

The rollback unit must include all coupled parts. Restoring only the Hermes binary while leaving an incompatible configuration or changed workspace behind is not a complete rollback.

9. Plan capacity around bursty agent work

Hermes workloads are not flat. An agent can wait quietly, then invoke several tools, process a large result, open browser sessions, or fan out auxiliary work.

Plan for:

• guaranteed baseline CPU and memory;
• short bursts above the baseline;
• concurrency limits for expensive tasks;
• headroom for recovery and upgrades;
• backpressure when provider or tool capacity is constrained.

A dedicated VM per agent is simple, but it often forces a bad choice between a small machine that caps bursts and a larger machine that remains idle most of the day. Shared capacity can be more efficient when reservations, limits, admission control, and noisy-neighbor protection are designed explicitly.

The goal is not maximum density. It is predictable task completion under load.

10. Keep human handoff inside the system

Some Hermes tasks should stop rather than recover automatically.

Create an explicit handoff state for:

• missing or conflicting instructions;
• an expired credential that needs user action;
• an external action whose result is unknown;
• a protected decision awaiting approval;
• repeated behavioral failure on all eligible model routes;
• a workspace conflict that cannot be restored safely.

The handoff should contain the task, current state, evidence, actions already taken, and the smallest decision needed from a human.

This is better than leaving the process online while the agent loops or silently abandons the task.

11. Decide which operating layer you want to own

You can build this architecture on general cloud infrastructure. The question is whether operating it is part of your product advantage.

A production platform for Hermes needs more than compute:

• repeatable runtime provisioning;
• durable and versioned workspaces;
• provider routing and fallback policy;
• scoped integrations and browser sessions;
• side-effect tracking;
• layered health checks;
• recovery and rollback;
• upgrades, capacity control, and human handoff.

If those capabilities are core to your product, building them can make sense. If they are infrastructure around the agent service you actually sell, managed hosting removes a large amount of undifferentiated work.

Molted's managed Hermes hosting provides Hermes as a managed production environment with versioned workspaces, automatic recovery, browser automation, 1,000+ integrations, per-agent email and voice, lifecycle controls, and managed cloud or on-premise deployment.

The relevant comparison is not a managed environment versus the sticker price of a VM. It is the full operating layer versus the engineering and on-call load required to build and maintain it.

Production checklist

Before hosting Hermes agents for customers or business-critical workflows, verify the following.

Runtime and state

• Is the Hermes version pinned per agent or cohort?
• Can the runtime be replaced without losing identity or work?
• Are workspace, execution, session, and ephemeral state classified separately?
• Can operators restore a known-good workspace and configuration together?

Inference and tools

• Does each agent role have a provider capability contract?
• Are fallback routes tested for tool use and policy compliance?
• Are credentials scoped per agent and integration?
• Do write-capable tools record idempotency and external references?

Health and recovery

• Are infrastructure, runtime, inference, tool, and task health measured separately?
• Do synthetic tasks verify real workflows?
• Does every recovery action have a limit and an audit record?
• Are ambiguous side effects reconciled before retry?

Change and capacity

• Are upgrades replayed and canaried before broad rollout?
• Can the full coupled change be rolled back?
• Are baseline resources, bursts, concurrency, and headroom controlled?
• Does overload create backpressure instead of uncontrolled retries?

Human operations

• Can the agent enter an explicit waiting-for-human state?
• Does the handoff include evidence and actions already taken?
• Can an operator identify the actual runtime, provider, model, and tools used for any task?
• Is success measured as completed work rather than process uptime?

Final takeaway

Hosting Hermes in production is not mainly about keeping a Python process alive.

It is about preserving a reliable operating boundary around the agent: replaceable runtime, durable state, resilient inference, governed tools, observable work, and recovery that understands side effects.

Build those planes separately, test them together, and make every change reversible. That is what turns a useful Hermes agent into a service a team can operate at scale.

References

• Hermes agents, explained
• Hermes Agent provider integrations
• Hermes Agent fallback providers
• Hermes Agent checkpoints and rollback

Disclosure

Kylian Cros is co-founder and CMO/GTM at Molted. Molted provides managed operating environments for autonomous agents, including Hermes and OpenClaw fleets.