Comparison
Lobu is the open-source backend for AI teammates that watch, remember, and act. Connectors and webhooks build a live org knowledge graph; agents look it up and branch into a sandbox to do work — with per-channel isolation, OAuth, and credentials agents never see.
Prefer a shorter product-facing overview? See Compare lobu (OpenClaw, Claude Tag, Viktor, Town).
This page is the deeper technical comparison against other ways to run agents for multiple users, including Claude Tag (@Claude in Slack).
At a glance
Section titled “At a glance”| Lobu | OpenClaw (direct) | Claude Tag | |
|---|---|---|---|
| What it is | Open-source backend for multi-user agents | Single-tenant agent runtime | @Claude in Slack (team agents, beta) |
| Multi-tenant | Per-user/channel isolation | Single-tenant — shared filesystem | Per-channel @Claude |
| Platforms | Slack, Telegram, WhatsApp, Discord, Teams, Google Chat, REST API, MCP | CLI and API | Slack (beta) |
| Embeddable | Mount inside Next.js, Express, Hono, Fastify | No | No |
| Self-hosted | Single Node process (embedded Postgres, or BYO Postgres) | Single process | Cloud only |
| Model support | Any provider via config | Any provider | Anthropic only |
| Runtime | OpenClaw | OpenClaw | Claude |
| Network isolation | Gateway-mediated egress, domain filtering | Host network | Platform-managed |
| Secrets handling | Gateway proxy, workers never see credentials | Direct env vars | Platform-managed |
| MCP support | Proxied through gateway with secret injection | Direct | Yes |
| Agent Protocol / A2A | Not yet | No | No |
| Built-in evals | YAML eval framework with model comparison | No | No |
| Memory | Append-only org graph (connectors, entities, automations) | Local filesystem | Channel-scoped, admin-provisioned |
| Custom connectors / automations | Yes (lobu.config.ts) | Skills + local setup | Admin-provisioned tools only |
| Worker lifecycle | Persistent subprocess per channel; reaped on config change / shutdown | Always running | Managed |
| Config format | lobu.config.ts (TypeScript) + IDENTITY/SOUL/USER.md | CLI flags | Dashboard |
| License | Open source | Open source | Proprietary |
Memory benchmarks
Section titled “Memory benchmarks”Lobu’s bundled memory system is benchmarked against Mem0 and Supermemory on public datasets. Same answerer (glm-5.1 via z.ai), same top-K, same questions.
LongMemEval (oracle-50)
Section titled “LongMemEval (oracle-50)”Single-session knowledge retention.
| System | Overall | Answer | Retrieval | Latency |
|---|---|---|---|---|
| Lobu | 87.1% | 78.0% | 100.0% | 237ms |
| Supermemory | 69.1% | 56.0% | 96.6% | 702ms |
| Mem0 | 65.7% | 54.0% | 85.3% | 753ms |
LoCoMo-50
Section titled “LoCoMo-50”Multi-session conversational memory.
| System | Overall | Answer | Retrieval | Latency |
|---|---|---|---|---|
| Lobu | 57.8% | 38.0% | 79.5% | 121ms |
| Mem0 | 41.5% | 28.0% | 66.9% | 606ms |
| Supermemory | 23.2% | 14.0% | 36.5% | 532ms |
See the memory benchmarks methodology for fairness guardrails and reproduction steps.
Sandboxing model
Section titled “Sandboxing model”Lobu runs as a single Node process. Each user/channel gets its own worker subprocess that the gateway spawns on demand.
Single-process
Section titled “Single-process”Uses just-bash (virtual bash) + Nix for reproducible packages. Each user gets an isolated virtual filesystem and bash session. Resource use and concurrency depend on workload, model calls, and host capacity, so benchmark the deployment shape you plan to run.
- Subprocess boundary per user —
child_process.spawnper session; SIGKILL recoverable. - Workspace persistence —
./workspaces/{agentId}/survives gateway restarts. - Egress through gateway proxy — workers run with
HTTP_PROXY=http://localhost:8118; allowlist/blocklist + LLM egress judge enforced at the proxy. - Linux production hardening — when
systemd-runis available, the worker spawn becomes a transient unit withMemoryMax,CPUQuota,IPAddressDeny=any(kernel-level egress), capability drops, andNoNewPrivileges. macOS dev hosts fall back to plain spawn.
Comparison to other sandboxing approaches
Section titled “Comparison to other sandboxing approaches”| Lobu | E2B | |
|---|---|---|
| Isolation | Subprocess + just-bash + isolated-vm + (Linux) systemd-run | Firecracker microVM |
| Self-hosted | Yes (single Node process) | Cloud API |
| Network control | Gateway proxy + domain filtering + IPAddressDeny on Linux | Sandbox-level |
| Startup time | Instant (in-process gateway, subprocess workers) | <200ms |
| Persistence | Directory per agent | 24hr max |
| Per-user isolation | Yes (per-channel/DM subprocess) | Per-sandbox |
MCP proxy and credential isolation
Section titled “MCP proxy and credential isolation”Workers call MCP tools through the gateway. The gateway resolves ${env:VAR} secrets and injects OAuth tokens before forwarding to the upstream MCP server. Workers never see credentials — they receive opaque proxy URLs.
| Lobu | Claude Tag | Direct MCP | |
|---|---|---|---|
| Secret injection | Gateway proxy resolves at request time | Platform-managed | Direct env vars |
| OAuth management | Lobu handles token refresh | Platform-managed | Manual |
| Transport support | HTTP, SSE, stdio (proxied) | Yes | All |
| Worker sees credentials | Never | N/A | Yes |
| Audit trail | Gateway logs all MCP calls | No | No |
For compliance-bound deployments, agent code never touches API keys or OAuth tokens — even if the agent is compromised.
Why Lobu for on-premise
Section titled “Why Lobu for on-premise”Hosted platforms (Claude Tag and similar) require sending your data, prompts, and agent memory to a third party. For regulated industries (finance, healthcare, government) or organizations with data residency requirements, this is a non-starter.
Lobu runs entirely on your infrastructure:
- Data stays in your network — Postgres, workspaces, and memory are all self-hosted
- No external dependencies — the gateway, workers, and MCP proxy run on your machines
- Network-level isolation — workers use gateway-mediated egress, with kernel-level loopback-only enforcement on Linux production hosts
- Credential separation — secrets never leave the gateway process
- Audit everything — gateway logs all LLM calls, MCP tool invocations, and network requests
- Air-gapped compatible — with local LLM providers (Ollama, vLLM), Lobu can run fully disconnected
When to use Lobu
Section titled “When to use Lobu”Use Lobu when your agent needs more than one isolated user or channel:
- SaaS products — embed agents in your app where each user gets isolated persistence, tools, and context.
- Internal teams — deploy a single bot to Slack or Teams where every employee gets their own sandboxed agent.
- Customer support — agents that handle tickets autonomously with human-in-the-loop approval gates.
- Managed agent services — operate agents for clients with per-tenant isolation and network controls.
If you need a single personal agent for yourself, use OpenClaw directly.
Lobu vs OpenClaw
Section titled “Lobu vs OpenClaw”Lobu and OpenClaw are complementary. OpenClaw is the single-user runtime. Lobu adds multiplayer infrastructure around it: routing, isolation, credentials, memory, and delivery.
OpenClaw (~800k LOC) was designed as a single-tenant, single-user system. Production deployments need multi-tenant isolation, platform routing, credential separation, and network control — concerns OpenClaw doesn’t have opinions about.
| Capability | Lobu | OpenClaw |
|---|---|---|
| Architecture | Multi-tenant gateway + isolated workers | Single-tenant, single-user |
| Platform delivery | Slack, Telegram, WhatsApp, Discord, Teams, Google Chat, REST API | CLI and API |
| Worker isolation | Subprocess + just-bash + (Linux) systemd-run hardening | Runs on host |
| Secret handling | Gateway proxy injects credentials | Direct env vars |
| Egress control | Domain allowlists via HTTP proxy | Host network |
| Worker lifecycle | Persistent subprocess per channel | Always running |
| Deployment | Single Node process (embedded Postgres or BYO Postgres) | Single process |
Inside each Lobu worker, the full OpenClaw runtime runs untouched. Lobu rewrites only the gateway layer (~40k LOC) to be multi-tenant.
Lobu vs building it yourself
Section titled “Lobu vs building it yourself”What “we’ll build it ourselves” entails:
- Sandboxing: per-user worker lifecycle with workspace persistence
- Platform adapters: Slack Events API, Telegram, WhatsApp webhooks, each with their own auth flows
- Credential isolation: proxy layer that injects secrets without exposing them to agent code
- Network policy: domain-filtered egress through a gateway proxy
- MCP proxy: secret injection, OAuth token refresh, and routing for MCP servers
- Eval framework: automated quality testing across models
- Admin UI: per-agent configuration, connection management, status monitoring
Lobu handles all of this out of the box. The gateway is ~40k lines of TypeScript that took months to build and harden.