Lobu — Open-source backend for AI teammates

Lobu is open-source infrastructure for autonomous agents that watch, remember, and act where your team already works. Connect company tools, build living memory, and let agents run on schedules, in Slack threads, or over MCP — with sandboxed execution per user or channel and credentials agents never see.

Under the hood, workers run Lobu's Pi-based agent loop (bash, files, MCP tools, skills) inside an isolated sandbox per conversation. One Node process serves many agents and channels; shared memory and connectors live in Postgres (pgvector). Embed agents in your product, or give your team their own without running a separate instance per person.

https://github.com/user-attachments/assets/d72a9286-0325-4b8b-afc0-c1efe9c96f4e

Three ways in

Lobu is not a harness you have to build on. It is the data layer your agents work against — a durable event log and a typed ontology over your org's tools. Bring your own agent and reach it over MCP, the CLI, or the TypeScript SDK; or run Lobu's own agents on top. The same org-scoped graph backs all of them.

1. Full agent — Slack, Telegram, behaviors, connectors

Scaffold and run locally with the CLI. Lobu boots as a single Node process with zero-config embedded Postgres by default (or bring your own — pgvector required — via DATABASE_URL). lobu run opens the web UI on :8787 and can wire Slack via the hosted bot or your own app.

npx @lobu/cli@latest init my-bot
cd my-bot
npx @lobu/cli@latest run                      # boots the stack and applies your agent
npx @lobu/cli@latest chat -c local "hello"    # talk to it

lobu run auto-applies your lobu.config.ts, so the scaffolded agent is usable immediately. To use an external Postgres, set DATABASE_URL in .env; to push later config changes, run lobu apply.

Next steps: Getting started (project layout, develop with your coding agent, evals) · Memory · Skills · Channels

2. Bring your own agent — memory over MCP

Point any MCP client at Lobu and it gets durable, structured memory — the same graph your Lobu agents read. No lobu.config.ts or local Lobu agent runtime is required.

claude mcp add --transport http lobu https://lobu.ai/mcp   # or http://localhost:8787/mcp locally

Complete the OAuth flow when prompted, then enable the connector. Pair it with a project instruction or skill that tells the agent when to search memory and when to save what it learned.

lobu memory init can detect and configure Claude Code, Codex, Gemini CLI, and Cursor, and provides manual setup instructions for Claude Desktop and ChatGPT. It accepts a Lobu Cloud, local, or custom MCP endpoint. Setup guides: Claude · ChatGPT.

3. Your own code — CLI and TypeScript SDK

The data layer is reachable without an agent at all. From the terminal:

npx @lobu/cli@latest memory run                     # list the memory tools
npx @lobu/cli@latest memory run search_memory '{"query":"onboarding"}'
npx @lobu/cli@latest memory exec \
  'export default async (_ctx, client) => client.entities.list({ limit: 5 })'

Or from any Node/TypeScript program, with no sandbox in the loop:

import { client, searchMemory } from "@lobu/client";

// Defaults to http://localhost:8787 — point it at your instance and add a token.
client.setConfig({
  baseUrl: "https://lobu.ai",
  headers: { Authorization: `Bearer ${process.env.LOBU_TOKEN}` },
});

const hits = await searchMemory({
  path: { orgSlug: "my-org" },
  body: { query: "onboarding" },
});

Mint a token with lobu token create.

The MCP and typed SDK operations share the server-side tool registry, while the CLI dispatches those same MCP operations by name.

Architecture

flowchart LR
  Slack[Slack] <--> GW[Gateway]
  Telegram[Telegram] <--> GW
  WhatsApp[WhatsApp] <--> GW
  Discord[Discord] <--> GW
  API[REST API] <--> GW
  MCP[MCP clients] <--> GW

  GW <--> PG[(Postgres)]
  GW -->|spawn| W[Worker]

  subgraph Sandbox
    W
  end

  W -.->|HTTP proxy| GW
  W -.->|MCP proxy| GW
  GW -->|domain filter| Internet((Internet))
  GW -->|scoped tokens| ExtMCP[MCP Servers]

Capabilities

Most agent stacks treat MCP as the memory: every turn, the agent calls GitHub, Slack, and CRM tools to reconstruct what happened. That knowledge stays siloed in the session and disappears when the chat ends.

Lobu runs a data pipeline instead. Connectors poll and webhooks push into one durable, append-only event log. Behaviors and chat agents read the same org-scoped knowledge graph — typed entities, relationships, searchable events — so anyone can resume where the organization left off, not where one conversation left off.

Memory — ingest, entities, behaviors

Ingest. Connectors pull on a schedule; webhooks and the REST API push. Stripe charges, GitHub PRs, form submissions, and connector polls all land as rows in the same log — a stable record of what happened in the world, not something the agent has to re-fetch through MCP every turn.

Entities. You define the schema (Company, Project, Incident, …) in lobu.config.ts. Events attach to entity instances (Company:Acme) and build a live knowledge graph the whole org shares. Corrections supersede old facts; nothing is deleted, so provenance and time-travel stay intact.

Behaviors. Standing goals on a cron or tight interval: read new rows in the log (including webhook-fed events like pull_request.opened), extract structured memory onto dynamic entities, and optionally run a reaction to notify Slack, open a ticket, or kick off agent work — while nobody is in chat.

Docs: Memory · Connectors · Reactions

Agents — read the graph, branch to act

Chat agents look up what the pipeline already captured — search entities, read the event log, pull thread history — then branch into an isolated sandbox (just-bash + Nix) to run bash, edit files, and call MCP tools for side effects. MCP is for doing; the knowledge graph is for knowing. Pick any of 16 LLM providers; credentials stay on the gateway.

Behavior comes from a role file model — IDENTITY.md (who), SOUL.md (rules), USER.md (context). Guardrails gate input, output, and tool calls (secret-scan, pii-scan, inline LLM judges) so policy holds even when the prompt doesn't. Destructive MCP calls wait for in-thread approval; every action writes back to the log.

Docs: Agent workspace · Guardrails · Security

Channels

One instance serves Slack, Telegram, WhatsApp, Discord, Teams, Google Chat, and a REST API . Each channel/DM gets its own runtime, model, tools, credentials, and Nix packages. Platform setup: Slack · Telegram · Discord · WhatsApp · Teams · Google Chat.

How Lobu Differs

Lobu is the infrastructure layer for autonomous agents. Frameworks like LangChain or CrewAI help you write agent logic; Lobu is the delivery layer that runs those agents at scale — sandboxing, persistence, and messaging connectivity.

vs OpenClaw: OpenClaw is single-tenant by design — every user shares the same filesystem and bash session. Lobu keeps the same autonomous loop but runs it multi-tenant: one gateway, an isolated sandbox per channel or DM, and org-scoped memory your whole team can share. Full write-up: lobu.ai/getting-started/comparison.

Agent configuration

Runtime configuration is managed through the web app or the same org-scoped REST API used by the CLI. See the CLI reference and lobu apply.

npx @lobu/cli@latest login
npx @lobu/cli@latest org set my-org
npx @lobu/cli@latest agent list

Local lobu.config.ts projects are still useful for lobu validate and lobu apply workflows.

Deployment

The quick start above is the fastest path. For production self-hosting, see the deployment docs: Docker · Cloud · Kubernetes.

Security and Privacy

Secrets, egress policy, and MCP credential injection stay on the gateway; each channel or DM gets a separate worker subprocess with a best-effort sandbox. Guides: Security · Secret proxy · Guardrails · threat model.

• Worker egress through the gateway proxy — HTTP_PROXY on loopback (port from WORKER_PROXY_PORT, default 8118) with domain allowlist/blocklist and an optional LLM egress judge for ambiguous hosts. On Linux hosts with an enabled, usable systemd user manager, worker spawn uses systemd-run --user --scope with IPAddressDeny=any plus IPAddressAllow=127.0.0.1 and IPAddressAllow=::1 to permit loopback while blocking non-loopback IP traffic at the kernel; without that scope, including on macOS dev, the proxy is best-effort.
• Secrets stay in the gateway — provider credentials and ${env:} substitution; OAuth and MCP tokens live in Lobu. Workers get opaque placeholders; the secret proxy swaps real values at egress. Workers never see API keys or refresh tokens.
• Threat model — just-bash and isolated-vm are policy + best-effort sandboxes, not security boundaries for hostile code. Read docs/SECURITY.md before exposing Lobu to untrusted users.
• Nix system packages — per-agent reproducible tooling and skill policy via runtime.nix.packages and lobu.config.ts.

Support & Consultancy

Lobu is open source, but deploying production-grade agents usually means tuning soul, identity, and integrations. I offer hands-on implementation for:

• Employee AI assistants — persistent sandboxed agents on Slack wired into internal tools and docs.
• Automated customer support — multi-step ticket handling with human-in-the-loop.
• Autonomous workflows — long-running, scheduled background jobs with persistent state.
• Managed infrastructure — private Lobu deployments with updates and scaling.
• Custom tooling & skills — bespoke MCP servers, Nix runtimes, and agent skills.

I'm a second-time technical founder. Previously founded rakam.io (enterprise analytics PaaS), acquired by LiveRamp (NYSE: RAMP).

[!TIP] Want persistent agents for your team or customers? Talk to Founder or reach out on X/Twitter.