Research · May 2026
OpenHuman vs Hermes
Two open, self-hosted agent stacks landed in the same window, both claiming persistent memory, tool use, and autonomous skill — and they are not competing for the same problem. Mix them up at the architecture stage and you waste a quarter.
Two open stacks, two bets: a transparent Markdown memory tree for one desktop user, versus indexed session stores for a headless multi-tenant fleet.
1 · The two bets
One desk, or twenty platforms
OpenHuman (by tinyhumans) is a desktop app — a Rust core in a Tauri shell with a React front end — for one person's digital life. It pulls from over a hundred OAuth sources on a rolling sync, normalizes everything into provenance-tagged Markdown you can read and edit by hand, chunks and scores it in the background, and folds it into browsable per-source, per-topic, per-day summary trees. Its pitch is explicit: no vector-soup black box. The audit trail is just files on disk, and the backup story is your filesystem.
Hermes (by Nous Research) is the inverse: a headless Python framework you deploy on a cheap VPS or a GPU cluster and pipe through twenty chat platforms from one gateway. Memory is agent-curated — the agent decides what to persist — layered with a separate dialectic service that models each user across sessions, and full-text recall over a session store with lineage preserved across compressions. Skills are first-class, self-improving, and shareable, and execution fans out across six interchangeable backends from local shell to Docker to cloud sandboxes.
2 · Side by side
Where the designs diverge
| OpenHuman | Hermes | |
|---|---|---|
| Form factor | Desktop app (Tauri, Rust + React) | Headless framework (Python) |
| Primary surface | GUI + an Obsidian-compatible vault | CLI + messaging gateway + IDE protocol |
| Memory | Deterministic ETL into readable Markdown trees | Agent-curated records + indexed session store |
| Sandboxing | One process boundary — one operator | Six backends: local, Docker, SSH, cloud sandboxes |
| Multi-user | No — one human, one install | Yes — per-platform isolation and authorization |
| Blast radius | Your laptop | A container, a VPS, or nothing |
The honest trade-off underneath: OpenHuman bets on transparency over autonomy — the agent is bounded by what you let it see, and you can audit every chunk it reasons over, at the cost of scaling to exactly one user. Hermes bets on autonomy and reach over transparency — skills compound and platforms multiply, at the cost of more moving parts and "what does the agent know" becoming a query rather than a folder.
3 · The lessons
What generalizes past either product
- Memory shape follows form factor
- A single-user desktop app can afford a Markdown vault. A headless multi-tenant agent needs an indexed session store with lineage across compressions. Neither choice is portable to the other's world.
- Sandboxing is a deployment choice
- Hermes ships six execution backends because operators need the range; OpenHuman ships one because there is one operator. Isolation follows who runs the thing, not feature checklists.
- Self-improving skills are the live experiment
- Hermes is betting that shareable, self-improving skills become an ecosystem. Worth watching whether or not you build on it.
The first lesson is why Valor's own memory runs two stores at once: it is simultaneously a single-operator system (which earns it a legible file layer humans read) and an always-on agent consulted at tool-call granularity (which demands an indexed, ranked object store). The comparison's dichotomy, resolved by refusing to pick a side.