Vocion vs. Hermes, Slack, Obsidian, and Mem0
Assembling Hermes, Slack, Obsidian, and Mem0 for shared agents costs four systems and two cron jobs. What one Vocion install has today, row by row.
Last verified
A tech lead told to give their team shared agents usually assembles four
systems: Hermes Agent (Nous Research) as the runtime and profile gateway,
Slack as the chat surface via Hermes' messaging gateway, an Obsidian vault
(or Open Notebook) as shared knowledge, and Mem0, Zep, or Letta for shared
memory — plus two cron jobs someone has to write: one that prunes what
accumulates in the vault and the memory store, one that reports who is
burning model credits. Vocion is an open-source agent workforce platform
that already contains four of those five parts in one install: agents on a
shared roster, versioned context, memory a person approves before it
becomes a rule, an autonomy dial, per-org BYOK, and spend limits that refuse
a run rather than just report on it after. Vocion does not have a Slack
chat interface today. On main, Slack is a read-only source connector — it
ingests channel history so agents can search it; there is no bot, no mention
handler, no slash command. A phase-1 chat surface is in review as a draft
pull request (vocion-core#238);
it is not merged, and nothing has been sent through it. If a Slack surface is
the requirement today, take Hermes. Table last verified 2026-09-08 against
vocion-core v2.47.5; the Slack rows were re-checked 2026-09-09 against
v2.47.6 and the open pull request.
This is not a case against the assembled stack. It is a good stack, recommended in good faith, and Hermes in particular is genuinely strong where Vocion is weak: Hermes ships a real Slack/Telegram/Discord gateway (https://hermes-agent.nousresearch.com/docs/user-guide/messaging/), runs on a small VPS across a wide range of sandboxes (https://hermes-agent.nousresearch.com/docs/getting-started/installation), and has its own command-approval and authorization model (https://hermes-agent.nousresearch.com/docs/user-guide/security) — a shell command gate, not a review queue over authored actions, but a real gate. Of the single-install alternatives, Letta is the closest: its own docs describe stateful agents, shared memory, Slack/Telegram/Discord integrations, and scheduled tasks in one open-source harness (https://docs.letta.com/overview). Open Notebook is MIT-licensed with a REST API, not just a stopgap (https://github.com/lfnovo/open-notebook).
The nine-part table
| Requirement | The assembled stack | Vocion today |
|---|---|---|
| Same agents for the whole team | Hermes profiles on one gateway | Agents authored as YAML in the workspace and applied to one shared Postgres; teams with a one-level parent: lead → specialist hierarchy (packages/core/src/libs/workspace/applier.ts, docs/entities/agent.md, docs/entities/team.md) |
| Shared context | An Obsidian vault of Markdown | Git-backed workspace of YAML + Markdown; every workspace:apply inserts a workspace_version row; workspace_sha is stamped on the tool_call table so an output traces back to the prompts that produced it (applier.ts, models/Schema.ts: workspace_version, tool_call.workspaceSha) |
| Shared memory across agents | Mem0 / Zep / Letta | Learning steps hold per-step rules; new rules are deduped by trigram Jaccard similarity at a 0.72 threshold; classified feedback lands in a learning_candidate queue and becomes a real rule only when a person approves it, with the rejection reason kept (services/LearningsService.ts, services/LearningCandidateService.ts, models/Schema.ts: learning_candidate) |
| Lives in Slack | Hermes exposes agents in Slack | Not on main. There, Slack is a read-only ingestion connector: it calls conversations.history and nothing else — no bot user, no app_mention handler, no slash command, no chat.postMessage, and @slack/* is not a dependency (packages/core/src/libs/sources/slack.ts, 72 lines). A phase-1 chat surface is in review, not merged: vocion-core#238. |
| Different roles | Hermes profiles | Agents with per-agent skills, connectorSources, objectTypes; parent: specialists; subagents the parent dispatches with the task tool (docs/entities/agent.md) |
| Control over how autonomous each agent is | Not addressed by the assembled stack | Mission autonomy levels 1–5 (AutonomyLevel, AUTONOMY_LABELS, taskNeedsApproval, clampAutonomyLevel); a review queue with list / assign / snooze / decide; trust rules that let a proposal auto-execute only when its confidence clears an explicit per-action threshold, with no-rule | disabled | below-threshold | no-confidence as the refusal reasons; per-agent harness.interrupts naming skills or tools that pause for approval (services/missions/autonomy.ts, services/ReviewService.ts, services/TrustService.ts, docs/entities/agent.md) |
| BYOK | Per-profile keys | Per-org vendor keys for openai, anthropic, vertex, azure-openai, aws and a custom endpoint; the org's stored key is resolved first and a null falls through to the server's env var; stored credentials are encrypted with AES-256-GCM under a per-tenant data encryption key, wrapped by AWS KMS in production or a local master key in dev (libs/platforms/registry.ts, libs/llm/orgKey.ts, libs/crypto/credentialVault.ts) |
| Credit accountability | "Build a cron job" | agent_budget rows carry soft caps (warn) and hard caps (refuse) in both tokens and cents, per agent per daily | monthly period; preflightCheck refuses a run on hard_tokens_exceeded / hard_cents_exceeded. This is scoped per agent, not per person — a reader asking "who on the team is burning credits" gets a stronger control aimed at a different unit: the run refuses rather than just reports (models/Schema.ts: agent_budget, services/BudgetService.ts) |
| Daily cleanup job | "Build a cron job" | Automations: a five-field UTC cron schedule or an event match (exactly one, mutually exclusive), dispatched on a Temporal schedule, doing one of workflow, checkMission, or job; the learning-candidate queue already proposes rules for a human rather than needing a script to mine them (docs/entities/automation.md) |
Nothing in the table above is softened from what the code and docs show at
v2.47.5 — except the Slack row, re-checked at v2.47.6 on 2026-09-09 when
the pull request below was opened. Where the assembled stack has no built-in answer, the table says
so plainly rather than crediting it with a workaround.
The Slack gap
Slack is the one thing a reader who wants "give the team agents" explicitly
asks for, and the one thing Vocion does not have. Slack is a read-only
source connector today (packages/core/src/libs/sources/slack.ts): it
paginates conversations.history on an incremental timestamp and returns
messages as retrievable documents. There is no bot user, no app_mention
handler, and @slack/* is not a dependency in packages/core/package.json.
There is now a public pull request to cite, and it is worth reading rather
than counting: vocion-core#238
opens a phase-1 chat surface — an events endpoint handling app_mention and
direct messages, a chat_channel_binding table mapping a channel to an agent,
and the same per-agent budget preflight that refuses any other over-budget run. It is a draft, it is not merged, and no message has been sent
through it. Until it merges, the row above is the honest answer, and this
page will not predict when that changes. If Slack is the requirement today,
Hermes already has it
(https://hermes-agent.nousresearch.com/docs/user-guide/messaging/).
The autonomy dial, and where the review lives
Row six is the strongest row in this table because the assembled stack does
not address it at all: nothing in Hermes, Obsidian, or a memory store
decides how autonomous one agent is versus another, or gives a person a
queue to work through. Vocion's mission autonomy levels and its approve
review surface are covered in full in
the review queue over HTTP.
Roles and the shared roster
The same-agents and different-roles rows both come down to where the roster lives: as Hermes profiles on a gateway, or as YAML in a shared, git-backed workspace applied to one Postgres instance. See the org chart is the interface for how that hierarchy is authored and reasoned over.
Which to pick
Take Hermes today if Slack is the requirement — it is a real, working chat gateway, and Vocion's is an unmerged pull request. Take Vocion if the requirement is a shared, versioned agent roster with a review queue, per-action trust thresholds, and spend limits that refuse a run rather than report on it afterward, and the team can live without Slack in the meantime. Nothing here rules out running both.
Related
- The review queue over HTTP — the autonomy levels and review surface referenced in row six.
- Teams: the org chart is the interface — how the shared agent roster and
parent:hierarchy are authored. - Learnings — the
learning_candidatequeue referenced in row three. - Teams — the entity reference for
parent:andsubagents.
Read docs/entities/agent.md for the full harness and parent: reference, or clone vocion-core and run packages/core/src/libs/sources/slack.ts against a channel to see what the connector actually ingests.