The problem
DenchClaw's CRM UI is the best local interface for agent-driven sales outreach — Kanban pipeline, contacts table, natural language queries, conversation history per lead. But it is hardwired to OpenClaw as its runtime. Anyone who wants a different agent backend has to abandon the UI entirely and manage their pipeline in markdown files.
The runtime and the UI are two separate concerns. They should be decoupled.
Why Hermes Agent specifically
Hermes Agent (Nous Research, MIT, 8k+ stars) operates at the same layer as OpenClaw — gateway, agent loop, skills, multi-channel messaging — but differs in ways that matter for outreach:
Self-improving skills loop
After completing a complex task, Hermes automatically writes a reusable skill document capturing what worked. Next time a similar task runs, it retrieves that document and executes faster and more accurately. Run 50 LinkedIn campaigns and Hermes is measurably better at the 51st. OpenClaw skills are static SKILL.md files — they don't update from experience.
Anti-detection browser (Camoufox) built in
Hermes ships Camoufox as its default browser backend — purpose-built for fingerprint evasion. OpenClaw uses the standard Playwright/Chrome stack. For LinkedIn, Instagram, and X automation where detection is the primary risk, this is a meaningful architectural difference, not a configuration option.
Memory architecture
Hermes stores session history and cross-session recall in SQLite with FTS5 full-text search and LLM summarization. At scale — hundreds of active leads, months of conversation history — this retrieves the right context reliably. OpenClaw uses flat markdown files, which work well at small scale but don't index.
Honcho user modeling
Hermes builds a structured model of the user's preferences, communication style, and goals across sessions using Honcho's dialectic approach. Over time it personalizes outreach drafts and next-step recommendations without being explicitly retrained. OpenClaw has no equivalent.
Parallel subagents
Hermes can spawn isolated subagents for concurrent workstreams — running LinkedIn enrichment, WhatsApp follow-ups, and email drafting simultaneously. OpenClaw runs a single agent loop per session.
The proposed change
Introduce a runtime adapter interface in DenchClaw that abstracts the OpenClaw-specific calls behind a common contract. Then ship a Hermes adapter as the second implementation.
DenchClaw Web UI (localhost:3100 — unchanged)
↓
Runtime Adapter Interface ← NEW
↙ ↘
OpenClaw Hermes Agent
Adapter Adapter ← NEW
(current) (REST → hermes gateway --api)
User selects runtime in config:
{
"runtime": "hermes",
"hermes": {
"apiUrl": "http://localhost:8000",
"profile": "dench"
}
}DenchClaw's frontend stays completely unchanged. The adapter translates DenchClaw's internal tool calls and CRM reads/writes to whichever runtime is underneath.
Minimal viable scope
Why this matters for DenchClaw
DenchClaw's moat is the UI. That UI should not be tied to one runtime's internals. A runtime adapter layer keeps users inside DenchClaw as they move between backends, and it future-proofs DenchClaw against OpenClaw's own trajectory — the original developer announced joining OpenAI and transferring the project to an independent foundation. DenchClaw shouldn't be stranded if OpenClaw's direction shifts.
References
The problem
DenchClaw's CRM UI is the best local interface for agent-driven sales outreach — Kanban pipeline, contacts table, natural language queries, conversation history per lead. But it is hardwired to OpenClaw as its runtime. Anyone who wants a different agent backend has to abandon the UI entirely and manage their pipeline in markdown files.
The runtime and the UI are two separate concerns. They should be decoupled.
Why Hermes Agent specifically
Hermes Agent (Nous Research, MIT, 8k+ stars) operates at the same layer as OpenClaw — gateway, agent loop, skills, multi-channel messaging — but differs in ways that matter for outreach:
Self-improving skills loop
After completing a complex task, Hermes automatically writes a reusable skill document capturing what worked. Next time a similar task runs, it retrieves that document and executes faster and more accurately. Run 50 LinkedIn campaigns and Hermes is measurably better at the 51st. OpenClaw skills are static SKILL.md files — they don't update from experience.
Anti-detection browser (Camoufox) built in
Hermes ships Camoufox as its default browser backend — purpose-built for fingerprint evasion. OpenClaw uses the standard Playwright/Chrome stack. For LinkedIn, Instagram, and X automation where detection is the primary risk, this is a meaningful architectural difference, not a configuration option.
Memory architecture
Hermes stores session history and cross-session recall in SQLite with FTS5 full-text search and LLM summarization. At scale — hundreds of active leads, months of conversation history — this retrieves the right context reliably. OpenClaw uses flat markdown files, which work well at small scale but don't index.
Honcho user modeling
Hermes builds a structured model of the user's preferences, communication style, and goals across sessions using Honcho's dialectic approach. Over time it personalizes outreach drafts and next-step recommendations without being explicitly retrained. OpenClaw has no equivalent.
Parallel subagents
Hermes can spawn isolated subagents for concurrent workstreams — running LinkedIn enrichment, WhatsApp follow-ups, and email drafting simultaneously. OpenClaw runs a single agent loop per session.
The proposed change
Introduce a runtime adapter interface in DenchClaw that abstracts the OpenClaw-specific calls behind a common contract. Then ship a Hermes adapter as the second implementation.
User selects runtime in config:
{ "runtime": "hermes", "hermes": { "apiUrl": "http://localhost:8000", "profile": "dench" } }DenchClaw's frontend stays completely unchanged. The adapter translates DenchClaw's internal tool calls and CRM reads/writes to whichever runtime is underneath.
Minimal viable scope
RuntimeAdapterinterface covering the calls DenchClaw makes to OpenClaw (send message, read session, execute tool, update CRM record)HermesAdaptertalking to Hermes' existing API server (hermes gateway --api)runtime: "openclaw" | "hermes"in DenchClaw settingsWhy this matters for DenchClaw
DenchClaw's moat is the UI. That UI should not be tied to one runtime's internals. A runtime adapter layer keeps users inside DenchClaw as they move between backends, and it future-proofs DenchClaw against OpenClaw's own trajectory — the original developer announced joining OpenAI and transferring the project to an independent foundation. DenchClaw shouldn't be stranded if OpenClaw's direction shifts.
References
hermes claw migratealready exists in Hermes CLI — the teams are already aware of cross-runtime users