Octop: A Multi-User AI Assistant Platform That Lives in ~/.octop/
The Scenario: One Home, One Machine, Five Agents Working in Parallel
Imagine a single process running on your home server. Your partner asks it "how's the weather today?" via Feishu (Lark) and gets the answer there; your mother asks it to look up health insurance info on DingTalk; you ask it to run a Python snippet on Discord, and it executes and returns results in the terminal. Five agents, five users, three IM platforms, one process — and all data lives under ~/.octop/.
That's what TencentCloud's Octop is built for. Its GitHub repo (https://github.com/TencentCloud/Octop ) gained 386 stars in a day — less explosive than BrowserSkill's 1,350, but it solves a completely different problem: BrowserSkill is about "letting an agent use your browser"; Octop is about "letting one process serve the AI needs of a whole family or team."
A "Digital Life Form": From Tool to Species
Octop's README contains a striking line: "It's not just a tool — it's a digital life form that can operate in parallel."
The "digital life form" framing is a bit exaggerated, but it points to a real design choice: Octop is not a single-threaded chatbot — it's a system where multiple agents run in parallel.
Concretely, the architecture is:
- Single process: one
octop runstarts everything — web dashboard, CLI, IM channels, cron. No docker-compose, no microservice orchestration. - Multi-user: JWT-based user isolation; one admin manages the whole family/team; other users share the same process but have independent workspaces.
- Multi-agent: each user can run multiple agents simultaneously, and agents can collaborate (bidirectional ACP communication).
- Multi-channel: Web Dashboard, Feishu, DingTalk, QQ, Discord, WeCom (Enterprise WeChat), HTTP/SSE/WebSocket — all channels share one control plane.
- Family/small team: 3–10 people sharing one AI assistant with multi-channel access.
- Privacy-sensitive contexts: healthcare, legal, finance — data that can't go to the cloud.
- Multi-agent collaboration: different agents handling different tasks.
- IM as the primary channel: teams that mainly communicate via Feishu/DingTalk.
- Single-machine deployment: no distributed support. All agents run in one process; scalability is limited.
- Tencent-centric bias: the connector ecosystem leans Tencent; non-Tencent users may find it less useful.
- Python 3.12+: a relatively high version requirement.
The core insight: what families and small teams need is not "a stronger chatbot" but AI infrastructure that can serve multiple people across multiple channels simultaneously.
MBTI Personality Templates: Giving Agents a "Personality"
Octop has an unusual feature: 16 MBTI personality templates. You can assign each agent an MBTI type — an INTJ agent leans toward logical analysis, an ENFP agent toward creative divergence.
It looks gimmicky at first, but it makes sense on reflection. An LLM's "personality" is essentially a product of its system prompt. Different system prompts make the same underlying model behave in drastically different ways. MBTI templates are essentially pre-packaged system prompt sets, letting users get differently-personalized agents without writing prompts themselves.
This is the same idea as OpenAI's GPTs or Anthropic's Claude personas: productizing system prompt engineering. The difference is that Octop ships the 16 MBTI types as defaults instead of making users start from scratch.
"All Data in ~/.octop/": Privacy as the Default
Octop's core design constraint: all data stays local. The README repeatedly stresses "all data under ~/.octop/".
This constraint leads to several design consequences:
1. SQLite by default: no PostgreSQL installation required; works out of the box. PostgreSQL is optional for larger deployments. 2. Pluggable backends: local disk, Docker containers, PostgreSQL, COS/S3 — four backend options. Agents operate within isolated boundaries. 3. PII masking: automatic redaction of personally identifiable information during tool calls. 4. Shell command guardrails: agent shell commands require approval before execution.
Together these form a "privacy-first" AI assistant architecture. Against cloud offerings like ChatGPT, Claude, and Gemini, Octop's pitch is: your conversations, workspaces, and credentials all stay on your own machine.
Connector Ecosystem: Tencent Suite + OAuth + MCP
Octop's connector system supports three categories of integration:
1. Tencent suite: Tencent Docs, Weibo hot search, Tencent News, etc. A natural advantage of being TencentCloud-made. 2. OAuth gateway: generic OAuth integration with any OAuth-capable service. 3. MCP gateway: Model Context Protocol, connecting to any MCP-compatible tool.
MCP support is the key. MCP is becoming the standard protocol of the agent ecosystem (introduced by Anthropic, followed by OpenAI and Google). Through its MCP gateway, Octop can in principle connect to any MCP-compatible tool, greatly expanding its capability boundary.
ACP Bidirectional: Agents Calling Agents
Octop's ACP (Agent Communication Protocol) bidirectional communication is a highlight. The octop acp command lets Octop talk both ways with AI in IDEs/terminals (e.g., OpenCode, Claude Code).
What does that mean? You can kick off a task in Octop's web dashboard, Octop delegates it to Claude Code in your IDE, and Claude Code's results flow back into the Octop conversation. Agents are no longer islands — they can delegate tasks to each other.
This evokes the Unix pipe: cat file | grep pattern | sort. Each tool does one thing well, chained via pipes. ACP is essentially "pipes between agents," letting different agents divide up work.
How It Compares with Other Self-Hosted AI Assistants
| Dimension | Open WebUI | Dify | Octop |
|------|-----------|------|-------|
| Multi-user | Yes | Yes | Yes (JWT isolation) |
| Multi-agent | Limited | Workflow orchestration | Parallel agents + ACP |
| IM integration | Limited | Limited | Feishu/DingTalk/QQ/Discord/WeCom |
| Deployment | Docker | Docker | Single process (octop run) |
| Data storage | Local | Local | Local (~/.octop/) |
| Personality templates | None | None | 16 MBTI templates |
| Remote desktop | None | None | Yes (Linux/Windows/macOS) |
| Browser automation | None | None | Headless Chromium |
Octop's differentiation: it's not just a chatbot — it's an "AI operating system". Remote desktop, browser automation, terminal AI, IM integration, cron jobs — these make it more like a "digital employee" than a "chat window."
Use Cases and Limitations
Octop fits best when:
Limitations:
Deeper Insight: From "Personal AI Assistant" to "Household AI Infrastructure"
Over the past two years, nearly all AI assistant products have been "personal assistants": one user, one chat window, one agent. Octop proposes a different direction: shared AI infrastructure for families/small teams.
The challenge of this direction is that multi-user isolation, multi-channel access, and multi-agent collaboration — the three "multis" — add complexity far beyond a single-user chatbot. Octop offers a viable combination: "single process + JWT isolation + MCP gateway."
The "all data in ~/.octop/" constraint is a rebellion against the "cloud AI" paradigm. It assumes there is a group of users willing to trade convenience for privacy. Whether that group is big enough will determine how far Octop can go.
---
Octop's GitHub repo is at https://github.com/TencentCloud/Octop , MIT licensed, and you can get started with pip install octop. If you have a home or small-team server and want an AI assistant platform where "all data stays in your own hands," Octop is currently one of the most complete options available.
The concept of "one process serving the whole family" may become the new standard for self-hosted AI assistants. Like a home router — you don't need one in every room; one is enough.