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.

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

Give Claude durable, structured memory via MCP — the same graph your Lobu agents use. Full setup: Connect from Claude.

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 Claude when to search memory and when to save what it learned.

Works the same for ChatGPT and other MCP clients — one memory backend across clients.

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]

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.

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

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

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.

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.

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.

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

Secrets, egress policy, and MCP credential injection stay on the gateway; each worker runs in an isolated sandbox per channel or DM. Guides: Security · Secret proxy · Guardrails · threat model.

• Worker egress through the gateway proxy — HTTP_PROXY=http://localhost:8118 with domain allowlist/blocklist and an optional LLM egress judge for ambiguous hosts. On Linux production, worker spawn uses systemd-run --user --scope with IPAddressDeny=any to enforce egress at the kernel; 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.

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).