Open-source personal assistants: OpenBot vs rakazo
Self-hostable AI assistants that act on your mail, calendar, docs and chat on your behalf. This page puts every verdict for the category on one page. Each question links to the full per-project answers and their code citations.
At a glance
● answered from code · — not applicable (the project does not do this) · ? insufficient evidence
How is the assistant architected?
Both published assistants split a web API from the agent loop, but they put the loop in different places.
OpenBot runs the loop inside its Hono server through CopilotKit's CopilotRuntime in Intelligence mode. Built-in Bots run in-process as BuiltInAgent; any other AG-UI server (LangGraph, Mastra, Pydantic AI and more) plugs in as an HttpAgent. Every browser and file action then passes through one ComputerGateway, which resolves the target, checks policy and writes an audit row before acting. Threads and learning live in CopilotKit Intelligence, an external service.
Rakazo keeps the API thin. threads.send writes a queued run and enqueues a Graphile job; a separate worker leases the run and drives the Pi agent runtime from a large executor.ts. All state, including the job queue and realtime fanout, sits in Postgres, and every backend (runtime, sandbox, connectors, memory) is an adapter-kit interface.
Choose OpenBot if you already build agents in several frameworks and want one governed front door for them. Choose Rakazo if you want one self-contained stack where runs are durable background jobs that survive restarts and can wait for approval or a takeover.
More projects in this category are being researched.
How are integrations (email, calendar, chat, docs) implemented?
Both projects lean on managed catalogues plus MCP instead of hand-written Gmail or Calendar clients.
OpenBot routes every catalogue entry through one transport seam with MCP's own listTools/callTool shape. Behind it sit MCP servers, Composio (one deployment key, per-person connections), a Google Drive REST adapter (because Drive's MCP server is gated), and built-in routines. OAuth uses PKCE with an encrypted state token, and credentials are AES-GCM encrypted at rest and write-only. Tools are listed at grant time; calls go through the same policy and approvals path as computer actions.
Rakazo builds a connector stack in the worker: user-installed connectors (remote MCP, Treg, OpenAPI documents), Composio, Pipedream Connect, and MCP (stdio only with MCP_STDIO_ENABLED and an allowlist). Connector secrets go into an encrypted store. Tools are discovered when a run starts, with no background sync. Rakazo also connects chat platforms (Slack, Telegram, WhatsApp, Sendblue) as places to talk to bots.
OpenBot suits an admin-curated catalogue with uniform governance. Rakazo suits users who want to bring their own APIs, including any OpenAPI spec, without operator work.
More projects in this category are being researched.
How is memory and user context stored and retrieved?
The two projects store memory very differently.
OpenBot keeps two kinds. Personal memories are free-text rows in Postgres, deduplicated by a content hash. Bots can propose observed facts that the person confirms or dismisses, and connected apps can be imported. PersonalMemoryMiddleware, an AG-UI middleware, injects them as a system message on every run. Conversation threads and learned skills are held by CopilotKit Intelligence, so a large part of the context is outside your database.
Rakazo keeps everything in its own Postgres. Messages are stored per thread and old history is compacted into an LLM summary that is injected into later runs. A MarkdownMemoryStore holds versioned Markdown documents per user, bot and scope, written and read through remember/recall_memory tools. Optional semantic providers (Serenity, Supermemory) add vector recall of up to five items, but only once a thread has been compacted. Memory text is passed through secret redaction before it reaches the prompt.
Pick OpenBot if a human-reviewed list of facts is what you want and you accept a hosted thread store. Pick Rakazo for self-contained, portable memory and long threads that need summarisation.
More projects in this category are being researched.
How are actions on the user's behalf gated?
This is where the two projects differ most.
OpenBot makes governance structural. A ComputerGateway is the only path to a Bot's computer: it resolves the clicked element from the server's own snapshot, evaluates CEL deny/allow rules (deny wins, errors deny, dry-run mode available), writes an audit row, and only then acts. An approvals service adds non-configurable safety hand-offs for credentials, security settings and payments, then team and personal rules (allow, pre_approved, ask, hand_off), then an optional LLM auto-review that fails closed.
Rakazo gates at the tool level. toolRequiresApproval exempts computer, browser, shell and file tools, always asks for destructive builtins, and judges connector tools by name prefix (unknown names ask). User rules by tool, connector or category override the default; Auto Review can only escalate to ask. Webhook-triggered runs are stricter. Each effect is recorded with an idempotency key.
OpenBot fits teams that need an audit trail and fine-grained control over what a browser agent clicks. Rakazo fits personal use where the sandbox is the boundary and approval is reserved for outward-facing tool calls.
More projects in this category are being researched.
How are LLM providers selected and configured?
OpenBot supports exactly three provider IDs: openai, anthropic and google, defined in shared/model-providers.json and checked by both TypeScript and Python loaders. BOT_PROVIDER and BOT_MODEL override the defaults, and per-provider base URL variables allow an OpenAI-compatible endpoint, which is the only route to a local model. Remote AG-UI Bots choose their own models, so the platform-level setting mostly affects built-in Bots. The approval auto-review uses structured JSON output.
Rakazo delegates to the Pi framework, which brings a large built-in catalogue. The deployment default is OpenRouter (PI_DEFAULT_PROVIDER, PI_DEFAULT_MODEL), with Anthropic as an alternative deployment key. Users connect their own credentials in the UI, by API key or by OAuth for ChatGPT, Claude, GitHub Copilot and xAI subscriptions. Bots can pin a model and thinking level, and local Ollama-style or OpenAI-compatible endpoints are first-class.
Choose Rakazo if users should bring their own models or subscriptions, or you want local models. OpenBot's narrow list is enough when an admin sets one provider for the deployment and agent frameworks handle the rest.
More projects in this category are being researched.
How is it deployed and self-hosted?
Both ship Docker paths, but their required services differ.
OpenBot needs Postgres (the compose file uses the pgvector image), a model key and a CopilotKit Intelligence project, managed or self-hosted; the server refuses to boot without Intelligence. scripts/start.sh brings up Postgres, migrations, Bot computers, the API, the routine worker and the app. Production can use a single published image carrying app, API and Chromium, with optional embedded Postgres, or the Helm chart in charts/openbot. A supervisor gives each Bot its own computer container; without it, all Bots share one.
Rakazo needs only Postgres 16, Docker and a model key. install-images.sh writes .env with random secrets and starts postgres, supervisor, api, worker and web from published edge images. There is no Redis: jobs and realtime run on Postgres. Computers can be local Docker or hosted E2B, Daytona, CreateOS or Box. infra/compose adds a Caddyfile, host hardening and egress restriction scripts.
Rakazo is the simpler fully self-hosted install with no required third-party service. OpenBot fits organisations that already use CopilotKit or want Kubernetes and SSO-oriented deployment.
More projects in this category are being researched.
The projects
- CopilotKit/OpenBot: Self-hosted platform where AG-UI agents get their own browser computer, with every action policy-checked and audited first.
- elie222/rakazo: Self-hosted persistent AI bots on a Pi agent runtime, with Postgres job queue, pluggable sandboxes and rule-based tool approval.