The dev.to post by S M Tahosin frames Hermes Agent as infrastructure that replaces OpenClaw’s local-first model. The author claims five architectural differences matter: memory, skills, sandboxing, messaging, and persistent infrastructure. The post title uses “killed” language, but the actual argument is about positioning: OpenClaw is a daemon you run, Hermes is a service you deploy.
The positioning shift creates different architectural constraints. Understanding these constraints reveals the security and operational trade-offs that determine which model fits your deployment context.
Local-First vs. Infrastructure-First
The author describes OpenClaw as running “on your own devices” with a Gateway control plane. The agent answers through channels you already use. This is a daemon model: you run it where you work, it uses your local resources, and it stops when your machine stops.
Hermes is positioned as infrastructure that “lives on my infrastructure, remembers how I work, improves its own procedures, uses tools across channels, and becomes more useful every week.” This is a service model: the agent runs somewhere else, persists state externally, and continues working when you are not connected.
The positioning shift creates different architectural constraints:
Local-first (OpenClaw style):
- Memory lives in process or on local disk
- Tools execute in the same environment as the agent
- Credentials are environment variables or config files
- Scaling means running multiple instances manually
- The agent stops when the host stops
Infrastructure-first (Hermes style):
- Memory must be externalized for persistence
- Tools need execution boundaries for multi-tenancy
- Credentials require secure injection mechanisms
- Scaling is horizontal (orchestrator + workers)
- The agent runs independently of client connections
Memory and State
Hermes “remembers how I work” and “improves its own procedures,” which implies persistent memory across sessions. In a local-first model, memory is a file or database on your machine. In an infrastructure model, memory must live in a shared store accessible to any orchestrator instance.
The architectural consequence: if memory is external, the orchestrator must retrieve it on demand. This adds latency but enables horizontal scaling. If memory is local, the agent has fast access but cannot scale beyond the host.
The security consequence: external memory creates a new attack surface. A compromised tool that can read the memory store can access conversation history, tool results, and potentially credentials if they are stored alongside state. Local memory limits the exposure scope to the host but makes multi-user deployments harder to isolate.
Skills and Tool Execution
The author claims Hermes has a better “skill lifecycle.” In a local-first model, skills are functions or scripts the agent calls directly. In an infrastructure model, skills are likely versioned, deployable units with their own runtime boundaries.
Versioned skills can be updated without restarting the agent. The orchestrator loads the new version and swaps it in. This is standard practice in microservice architectures. Local-first models typically require a restart to reload skills.
The security consequence: if skills run in separate execution contexts, a compromised skill cannot directly access the orchestrator’s state or other skills’ credentials. If skills run in-process, a compromised skill inherits the agent’s privileges.
Sandboxing and Isolation
The author lists “sandboxing” as one of the five differences. The positioning suggests different isolation models.
In a local-first model, sandboxing depends on the host OS. If you run the agent in a container, the container is the boundary. If you run it on bare metal, the user account is the boundary. Tools inherit the agent’s privileges unless you explicitly spawn them in separate processes with reduced permissions.
In an infrastructure model, sandboxing is typically enforced at the orchestrator level. Each tool runs in a separate container or VM. The orchestrator brokers communication. Tools cannot call each other directly. This is the pattern used by AWS Lambda, Google Cloud Functions, and Kubernetes-based orchestration platforms.
| Model | Isolation Boundary | Tool Privileges | Lateral Movement Risk |
|---|---|---|---|
| Local-first | Host OS (container or user account) | Inherits agent privileges | High (tool reads agent state, exfiltrates credentials) |
| Infrastructure | Orchestrator-enforced (container per tool) | Scoped to tool context | Low (tool sees only input parameters) |
Messaging and Failure Handling
OpenClaw uses a Gateway as the control plane. The agent connects to the Gateway, receives messages, and sends responses. This is a client-server model. The agent is the client. The Gateway is the server.
Hermes is positioned as infrastructure, which suggests a different messaging pattern. Infrastructure-first agents typically use a message bus or RPC layer to decouple the orchestrator from tool execution. The orchestrator publishes tool requests. Tools subscribe, execute, and publish results. This decouples the orchestrator from tool execution.
A message bus allows the orchestrator to continue processing while tools execute asynchronously. A tool timeout does not block the orchestrator. A tool crash does not take down the agent. This is the pattern used by Temporal, Prefect, and Airflow.
The operational consequence: a message bus provides observability. You can log every tool request and response with timestamps, parameters, and results. You can replay a conversation to debug a failure. You can rate-limit tool calls. You can inject a policy layer between the orchestrator and the tool to block dangerous operations.
Persistent Infrastructure
OpenClaw runs “on your own devices” and Hermes runs “on my infrastructure.” This is the core positioning difference. OpenClaw is a daemon. Hermes is a service.
A service model requires stateless orchestrators, external memory, and containerized tools. You deploy to Kubernetes, scale horizontally, and let the platform handle restarts. A daemon model requires no external dependencies but does not scale beyond the host.
The operational consequence: a service model shifts the deployment story from “daemon you run” to “service you deploy.” You need infrastructure to run it. You need monitoring to observe it. You need a deployment pipeline to update it. A daemon model requires none of this but stops when your machine stops.
Technical Verdict
The choice between frameworks depends on deployment context, not technical superiority.
Use infrastructure-first agents (Hermes style) if you need:
- Agents that run independently of client connections
- Horizontal scaling across multiple orchestrator instances
- Persistent memory accessible from any instance
- Orchestrator-enforced tool isolation for multi-tenant deployments
- Observability into every tool call with audit trails
Use local-first agents (OpenClaw style) if you need:
- Simple deployment with no external dependencies
- Direct control over the execution environment
- Zero orchestrator overhead (sub-10ms tool call latency)
- Agents that stop when you stop working
- No shared infrastructure or credential management
The security trade-off: infrastructure-first agents enforce isolation at the orchestrator level, which reduces the exposure scope of a compromised tool in multi-tenant deployments. Local-first agents rely on host OS isolation, which is simpler but makes multi-user deployments harder to secure.
The operational trade-off: infrastructure-first agents require deployment pipelines, monitoring, and external dependencies. Local-first agents require none of this but do not scale beyond the host.
The positioning shift from “assistant I operate” to “worker I supervise” is about operational model, not technical capability. Both models are valid. The right choice depends on whether you want a daemon or a service.