OpenOPC: Building a Self-Staffing AI Company from a Single Python Package

The problem OpenOPC claims to solve, and for whom

Most agent frameworks give you a loop: one model, one tool list, one conversation. OpenOPC starts from a different premise. It assumes the hard part is not calling a tool but deciding who should do the work, in what order, and with what accumulated context. The README frames this as three mechanisms: Self-Built, which drafts an org chart and fills each role, Self-Run, which assigns tasks and drives handoffs, and Self-Grown, which the project describes as learning from every task and building organizational memory.

The intended audience is a person who wants to run what the pyproject.toml describes as a One-Person Company. The package name is opc, and the description reads: Autonomous AI Agent collaboration system with natural language interface. The README lists nine verticals, from AI research and software development through finance, sales, media, e-commerce, accounting and education. That list is marketing breadth, not a capability guarantee. Nothing published for the project shows a benchmark for any of those verticals.

Where it is genuinely distinctive is the staffing step. A recruiter agent chooses between reusing an existing employee, shaped by prior projects, and onboarding a fresh hire from a talent pool. That is a real design decision with a real cost, which I cover later.

How the Self-Built, Self-Run, Self-Grown loop is wired

The repository layout tells you more about the architecture than the README's prose does. There is an opc/ package directory, a config/ directory, a skills/ directory, a scripts/ directory, a tests/ directory, and a .opc/ directory at the top level. The presence of .opc/ alongside config/ suggests runtime state is kept separately from shipped configuration, which is the right split if you want to wipe a company's memory without losing your settings.

Dependencies in pyproject.toml sketch the runtime. litellm is pinned at exactly 1.82.1, which means model routing goes through a provider abstraction rather than a single vendor SDK. chromadb is a vector store, consistent with the organizational memory claim. aiosqlite handles async local persistence. playwright is a base dependency, so browser automation ships with the default install rather than as an extra. python-docx, openpyxl and python-pptx are all present, which tells you the expected deliverables include Word, Excel and PowerPoint files.

The README's own description of Self-Run is the most interesting part and also the thinnest. It states that the central challenge is efficient collaboration under uncertainty, which manifests in two distinct problems. The README text stops there. Whatever those two problems are, and whatever the resolution is, is not documented in the portion of the README reproduced here. Treat any claim about how handoffs actually resolve as unverified until you read the source.

One concrete architectural fact is confirmed by the changelog. A September 1, 2026 entry states that Office and developer-tool rendering are now isolated from high-frequency runtime events, reducing unnecessary full-app updates. That implies the Office UI previously re-rendered on every runtime event, which is a common failure mode in agent dashboards.

Installing OpenOPC and running a first task

The README has a Quick Start section, but the install commands themselves are not reproduced in the portion of the README available, and the repository's pyproject.toml contains no install script. What is confirmed is the packaging. The project is a Python package named opc, built with hatchling, requiring Python 3.10 or newer. The version is 0.1.0, so this is pre-1.0 software.

The only commands the repository actually shows are the dependency declarations themselves. The build system is hatchling, and the Python floor is >=3.10, so an editable install from a source checkout is the documented route:

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[project]
name = "opc"
version = "0.1.0"
requires-python = ">=3.10"
license = {text = "MIT"}

That block is the project's own metadata, quoted from pyproject.toml. It tells you the distribution name is opc, not openopc, which matters if you go looking for it on a package index.

Optional extras are declared per channel. The pyproject.toml lists them as channels-telegram, channels-discord, channels-slack, channels-feishu, channels-dingtalk, channels-qq, channels-matrix, channels-whatsapp, channels-mochat, channels-email, plus channels-bridges and channels-all. Installing channels-all pulls every bot SDK at once, which is a lot of surface area for a first run. There is also a jiuwen extra, declared with these two dependencies:

jiuwen = ["websockets>=12.0", "json-repair>=0.58.4"]

There is a cli-board extra that the pyproject comments describe as an optional legacy CLI board and TUI inspector, not installed by default, and a browser extra that is now an empty backwards-compatible alias because browser tools became native to the base package.

After install, the entry point is the opc package. The README documents both a CLI Guide and an Office UI Guide, and the badges state the interface is CLI plus Office UI, with the UI built on React and Phaser. Model configuration lives under config/; the README does not list the individual keys, so read the files in that directory before assuming an environment variable name.

The staffing decision is the real cost centre

Reusing an experienced employee versus hiring fresh is presented as a benefit. It is also the place where this design can go wrong. An agent shaped by prior projects carries accumulated context, which is exactly what you want when the new task resembles the old one. When it does not, that same context is a bias you did not choose and may not notice. The README offers no mechanism for inspecting what an employee has accumulated, and no documented way to reset a single employee without discarding the whole company.

There is a second, harder limitation. Every role in the org chart consumes model calls. Drafting the chart, filling roles, assigning tasks, reviewing output and updating memory are all inference steps. A nine-vertical system that assembles a team before starting work has a fixed overhead per task that a single-agent script does not. For a small job, that overhead can exceed the work itself. The README does not publish token or cost figures, and I have not run it, so I cannot tell you where that break-even sits. That absence is itself the finding.

The third limitation is maturity. Version 0.1.0, no releases retrieved, and a changelog dominated by UI responsiveness and session recovery fixes. The July 14, 2026 entry says company-mode sessions now recover and resume while preserving agent identity and review progress. That is a useful feature, and it is also an admission that long runs were previously losing state.

OpenOPC against a plain agent loop

The obvious alternative is a general-purpose agent framework where you define tools and a single system prompt, and orchestration is whatever you write. The difference is where the structure lives. In a plain loop, the role is text in a prompt and the handoff is a function call you wrote. In OpenOPC, the role is an entity the system creates and staffs, and the handoff is something the runtime drives.

That buys you reuse. An employee that persists across projects is a different object from a prompt template. It costs you legibility. When a plain loop produces a bad result, you read your own code. When OpenOPC produces a bad result, you are reading a generated org chart and the accumulated state of agents you did not write.

A second alternative is a workflow engine with explicit steps. That is deterministic and debuggable, and it cannot draft its own org chart. If your task is stable and repeated, the workflow engine wins on every axis except novelty. OpenOPC is for tasks where you genuinely do not know the shape of the team in advance.

The JiuwenSwarm integration is worth noting as a third path. The README states you can use JiuwenSwarm-single as a single agent or JiuwenSwarm-team as one opaque Team in both Task and Company modes. The September 3, 2026 note pins verified versions: JiuwenSwarm 0.2.4b4 and openJiuwen 0.1.16. A beta pin inside a 0.1.0 project is a compatibility risk you should weigh.

Maintenance, upgrade cost and the licence question

The last push to the repository was on 2026-09-11. The changelog shows a steady cadence through the summer of 2026, with entries on July 8, July 13, July 14, August 26, September 1 and September 3. That is a project under active change, which cuts both ways: fixes arrive, and so do breaking changes. The dependency on litellm is pinned to an exact version rather than a range, which suggests the maintainers have been bitten by upstream drift. Expect to re-test after upgrades rather than assuming compatibility.

Upgrade cost concentrates in three places: the channel extras, the Jiuwen integration, and the .opc/ runtime state. Channel SDKs move independently, so a Telegram or Discord upgrade can break a working install without any change to OpenOPC itself. The Jiuwen pin is a beta. And if organizational memory is stored in chromadb under .opc/, a schema change in a future version could strand existing employee state.

The licence is MIT, declared in both pyproject.toml and the repository's LICENSE file. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice are retained. That applies to the OpenOPC code. It does not automatically cover the models you route through litellm, the channel SDKs you install as extras, or JiuwenSwarm, each of which carries its own terms. Read those separately. I am not giving legal advice; if the distinction matters to your organisation, have someone qualified review it.

Editorial conclusion

OpenOPC suits engineers who want to experiment with multi-agent orchestration and are willing to read the repository's own config and skills directories to understand what the agents can actually do. It is the wrong tool if you need a stable automation platform today, or if you cannot accept that agent behaviour is shaped by role definitions you will have to audit yourself. Before adopting it, verify the Python version requirement, confirm which optional channel and Jiuwen dependencies you actually need, and check the LICENSE and SECURITY.md files in the repository rather than relying on the MIT badge alone.

Frequently asked questions

Official sources

1. HKUDS/OpenOPC on GitHub
2. Issues
3. License: MIT
4. README