Octop: A Multi-User AI Assistant Platform Running in ~/.octop/
The Scenario: One Home, One Machine, Five Agents Working at Once
Imagine running one process on your home server. Your partner asks it "What's the weather today?" on Feishu (Lark) and gets the answer there. Your mom asks it to look up health insurance info on DingTalk, and it answers on DingTalk. You ask it on Discord to run a Python snippet, and it executes in the terminal and returns the result. Five agents, five users, three IM platforms, one process — and all data lives under ~/.octop/.
That's what TencentCloud's Octop aims to do.
It climbed to 386 stars in a day — not as explosive as BrowserSkill's 1,350 — but Octop solves a completely different problem: BrowserSkill is "let the agent use your browser," while Octop is "let one process serve the AI needs of a whole family or team."
A "Digital Life Form": From a Tool to a Species
Octop's README has a striking line: "It's not just a tool — it's a digital life form that can operate in parallel."
The "digital life form" phrasing is a bit hyperbolic, 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, Octop's 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 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 (WeChat Work), HTTP/SSE/WebSocket — all channels share one control plane.
- Families / small teams: 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-first teams: teams that mainly communicate on Feishu/DingTalk.
- Single-machine deployment: no distributed mode. All agents run in one process; scalability is limited.
- Tencent-centric: the connector ecosystem leans Tencent; non-Tencent users may find it less useful.
- Python 3.12+: a fairly high version requirement.
The core insight of this architecture: what families and small teams need is not "a stronger chatbot" but "AI infrastructure that serves multiple people across multiple channels simultaneously."
MBTI Persona Templates: Giving Agents a "Personality"
Octop has an unusual feature: 16 MBTI persona templates. You can assign each agent an MBTI type — an INTJ agent leans toward logical analysis, an ENFP one toward creative divergence.
It looks like a gimmick at first, but there's logic to it. 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 collections, letting users get differently-flavored 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 16 MBTI types as defaults instead of asking users to write from scratch.
"All Data in ~/.octop/": Privacy as the Default
Octop's most fundamental design constraint: all data stays local. The README repeatedly emphasizes "all data under ~/.octop/".
This constraint has several consequences:
1. SQLite by default: No PostgreSQL install 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 execution requires approval.
Together these form a "privacy-first" assistant architecture. Compared with cloud offerings like OpenAI ChatGPT, Anthropic Claude, and Google Gemini, Octop's pitch is: your conversations, workspaces, and credentials all live on your own machine.
Connector Ecosystem: Tencent Suite + OAuth + MCP
Octop's connector system supports three kinds of integrations:
1. Tencent suite: Tencent Docs, Weibo trending, Tencent News, etc. A natural advantage of being a TencentCloud project. 2. OAuth gateway: Generic OAuth integration with any OAuth-capable service. 3. MCP gateway: Model Context Protocol support for 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, which greatly expands its capability boundary.
Bidirectional ACP: Agents Calling Agents
Octop's bidirectional ACP (Agent Communication Protocol) is a highlight feature. The octop acp command lets Octop communicate bidirectionally with IDE/terminal AIs (e.g., OpenCode, Claude Code).
What does this mean in practice? You can start a task in Octop's web dashboard, Octop delegates it to Claude Code in your IDE, and Claude Code's result flows back into Octop's conversation. Agents are no longer islands — they can delegate tasks to each other.
It 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 and collaborate on work.
Comparison with Other Self-Hosted AI Assistants
| Dimension | Open WebUI | Dify | Octop |
|-----------|-----------|------|-------|
| Multi-user | Yes | Yes | Yes (JWT isolation) |
| Multi-agent | Limited | Workflow orchestration | Parallel multi-agent + ACP |
| IM integration | Limited | Limited | Feishu/DingTalk/QQ/Discord/WeCom |
| Deployment | Docker | Docker | Single process (octop run) |
| Data storage | Local | Local | Local (~/.octop/) |
| Persona templates | No | No | 16 MBTI templates |
| Remote desktop | No | No | Yes (Linux/Windows/macOS) |
| Browser automation | No | No | Headless Chromium |
Octop's differentiation: it's not just a chatbot — it's more like an "AI operating system." Remote desktop, browser automation, terminal AI, IM integration, cron jobs — these make it more of a "digital employee" than a "chat window."
Use Cases and Limitations
Where Octop fits best:
Limitations:
Deeper Insight: From "Personal AI Assistant" to "Household AI Infrastructure"
Most AI assistant products of the past two years have been "personal assistants": one user, one chat window, one agent. Octop proposes a different direction: shared AI infrastructure for a family or small team.
The challenge of this direction: multi-user isolation, multi-channel access, multi-agent collaboration — the combination of these three "multis" is far more complex than a single-user chatbot. Octop offers a viable solution via "single process + JWT isolation + MCP gateway."
The "all data in ~/.octop/" constraint is a rebellion against the cloud-AI paradigm. It assumes: there exists a group of users willing to trade convenience for privacy. How big that group is will determine how far Octop can go.
---
The Octop GitHub repo is at https://github.com/TencentCloud/Octop , MIT licensed, and pip install octop gets you started. If you have a home server or small team server and want an assistant platform where "all the data stays in your hands," Octop is one of the most complete options available today.
The idea of "one process serving the whole family" may become the new standard for self-hosted AI assistants. Like a home router — you don't install one in every room. One is enough.