Comparison

vahue vs qm

Both products build shared, scoped memory for teams of people working with agents. Where they part ways is one question — where the agent runs. qm centralizes execution: the org's server runs the agents and holds the credentials. vahue centralizes only memory and the record; execution never leaves your machine. One of those servers is a target. Ours isn't.

Side by side

qm is a self-hosted "multiplayer agent harness": a central TypeScript core serving the whole org, surfaced in Slack and a web app, with per-scope durable sandboxes. vahue is a workspace of local agents coordinated by a record server.

Axisvahueqm
Where agents run On each person's machine, under their own credentials — the server never executes an agent Centrally: the org's core runs the model loop in per-scope cloud sandboxes
Credentials Model credentials never leave the owner's machine; the server holds none, by design Held server-side in a per-scope keychain; documented as plaintext while in use
Agent choice Any ACP-speaking agent; the workspace outlives any particular agent Four harness adapters (Pi, OpenCode, Codex, Claude Code) behind qm's own tool protocol
Protocols Open standards: ACP for control, MCP for capability and memory A custom, fixed tool surface (execute, read, write, memory, post, reach…); not ACP/MCP
Memory model Channel-owned context database; agent distills at end of turn; trust (human vs agent) and provenance are mandatory fields; correction by supersession Per-scope markdown notebooks; automatic background LLM extraction after every turn; periodic LLM consolidation; revision history
Collaboration surface Its own channels: messages, run steps, artifacts — the room is the record Slack (DMs, channels, groups) plus a web chat; the agent has ambient presence in channels
Always-on work The agent works when its owner's machine is on — no central queue, no central bottleneck Crons, watches, and ambient channel presence run unattended on the server
Maturity Hosted SaaS, free for teams up to 5 · open-source self-host Early, experimental v0.1.x, self-hosted only

Where qm is genuinely strong

A credible comparison admits what the other side does better. Credit where due.

Ambient presence

The agent overhears every channel message and decides like a thoughtful coworker whether to speak. Crons and watches deliver unattended work into conversations.

Durable sandbox computers

Every person and every room gets a persistent Linux machine where installed tools stay installed — plus agent-published internal web apps with access control.

Memory engineering

Automatic extraction with strict anti-inference rules, LLM consolidation passes, revision history — and a memory benchmark with an LLM judge scoring signal-to-noise and staleness. The most rigorous memory QA in this class.

Where vahue is different

No honeypot

Central execution means the server holds every credential — one breach away from everything. In vahue the server holds no model credentials at all; there is nothing central to steal. You can't leak what you never had.

Trust you can read at retrieval

qm's auto-extraction makes memory effortless but flattens who knows what. vahue keeps human statements and agent inferences visibly distinct, with run- and model-level provenance — because a wrong inference that corroborates itself is unarguable within a month.

Open protocols, no Slack dependency

vahue's seams are ACP and MCP — swap the agent, the client, or the memory store independently, and the room doesn't live inside someone else's chat platform.

Which one fits

Choose vahue if…

  • Credentials and execution must stay on each person's machine — compliance or principle
  • You want open protocols (ACP/MCP) instead of a vendor-specific tool surface
  • You want memory with explicit trust levels and provenance, not fully automatic capture
  • You don't want the room's record and identity to depend on Slack
  • You want managed hosting — qm is self-hosted only; everything runs on infrastructure you operate

Choose qm if…

  • Your team already lives in Slack and wants agents present there ambiently
  • You need unattended, scheduled, always-on agent work (crons, watches)
  • Centralized credentials and sandboxed execution are acceptable — or desired for control
  • You want durable per-person cloud machines agents can install tools on