OpenOPC: Autonomous AI Company Orchestration from the HKUDS Lab

What OpenOPC does and who it is for

OpenOPC is described in its README as a system for building a personal AI-native company, meaning an autonomous team of AI agents organised around a specific goal. It is designed for developers, researchers, and teams who want to automate complex, multi-step projects without scripting each handoff manually.

The system covers nine declared verticals: AI technology and research, software development, financial investment, sales growth, content and media, industry assistants for support or legal intake, accounting and finance, brand and e-commerce, and education and training. The README describes the system as assembling the right team and delivering end-to-end results in each of these areas.

OpenOPC differs from simple prompt chains or workflow automations. Its core claim is that the organisation is built and run by the system itself, not configured by the operator. Given a goal, the system drafts an org chart, fills each role by choosing between a returning employee with accumulated context and a fresh hire, and then executes the work through structured collaboration.

Self-Built: how the organisation is staffed before work begins

The Self-Built phase runs before any task execution. Given a goal, OpenOPC derives the roles and reporting structure the task requires. A recruiter agent then fills each role. The README describes two filling strategies: reusing an existing employee that was shaped by prior projects, or onboarding a fresh hire from the talent pool.

Existing employees carry accumulated context from earlier work; fresh hires start without prior context. The README notes that this distinction matters: experienced employees may surface relevant past decisions, while fresh hires avoid anchoring on previous work when a role demands an independent perspective.

The result of Self-Built is an org chart with assigned roles. This chart becomes the structure the Self-Run phase uses to distribute and track work.

Self-Run: task execution through a work-item state machine

Self-Run is the orchestration phase. The README describes its central challenge not as raw execution but as efficient collaboration under uncertainty. It addresses two problems: dynamic collaboration orchestration and blocker handling.

Work items move through a state machine where each item's phase determines its position in a kanban view, its owner, and whether it is ready to proceed. A manager agent decomposes items, assigns them, and reviews results across five modes: execute, delegate, review, integrate, and rework. Decomposition defines a dependency DAG:

- Independent items proceed in parallel. - Dependent items wait until their prerequisites are resolved.

When a blocker appears mid-run, the system resolves it at two levels. Within the team, a blocking message pauses the sending agent and activates the role best positioned to resolve it. When the blocker exceeds the team's authority, the system escalates to the human owner. The README describes this escalation as invoking human judgment precisely when needed, rather than halting the entire run.

The kanban and office views render this orchestration in real time. A more responsive Office UI was noted in a September 2026 update, which isolated rendering of office and developer-tool components from high-frequency runtime events.

Self-Grown: organisational memory across projects

Self-Grown is the learning phase. Each completed project updates the system's organisational memory, which is used in future runs to inform staffing decisions and task execution. The README describes this as always delivering smarter results over time.

The memory component is backed by ChromaDB, which appears in the dependencies as chromadb>=0.4.0. ChromaDB is a vector database that stores and retrieves context efficiently. SQLite is used for lighter structured state (aiosqlite>=0.19.0).

The result is that employees who are reused across projects carry the context they accumulated in previous assignments. A software development employee who worked on a Python project will carry that context into the next Python task. The trade-off is that accumulated context can anchor an agent to past patterns even when the new task requires a different approach, which is why the recruiter sometimes chooses a fresh hire.

LiteLLM integration, MCP support, and channel connectors

OpenOPC uses LiteLLM (litellm==1.82.1 in pyproject.toml) for model calls. LiteLLM is a unified interface for calling models from different providers, which means OpenOPC can route agent calls to any provider LiteLLM supports without changing the orchestration code.

The system also supports MCP (Model Context Protocol), with the mcp>=1.28,<2 dependency listed in pyproject.toml. MCP allows agents to call external tools through a standardised interface.

Channel integrations allow agents or the system to communicate through external messaging platforms. The pyproject.toml lists optional extras for: Telegram, WhatsApp, Discord, Feishu, Mochats, DingTalk, email, Slack, QQ, and Matrix. A channels-all extra installs the full set.

A JiuwenSwarm integration added in August 2026 allows connecting a self-organising swarm as a single agent or as a team unit in both Task mode and Company mode. The September 2026 update notes that setup requires JiuwenSwarm version 0.2.4b4 and openJiuwen version 0.1.16. A separate jiuwen extra in pyproject.toml installs the websockets and json-repair dependencies that the integration needs.

Maintenance status, licence, and limitations

OpenOPC has no GitHub releases and its version in pyproject.toml is 0.1.0. The last push was on 2026-09-11. The project appears to be in active development with frequent news updates, but the absence of a versioned release means there is no documented stable API surface or upgrade path.

The MIT licence is permissive. Source modifications and commercial use are allowed without the copyleft obligations that AGPL imposes.

The README references a Quick Start section that provides the install and run commands; that section is available in the full README at the repository but covers practical setup steps that are not repeated here.

A meaningful limitation is scope: OpenOPC is designed around the assumption that tasks can be decomposed into role-assignable work items and that agents can execute those items through an LLM API call. Tasks that require real-time sensor data, hardware interaction, direct database writes in production systems, or sub-second latency are outside the design assumptions. The dependency on an LLM provider also means performance and cost depend on the chosen model and provider SLA, not on the orchestration layer itself.

For teams that need a more established multi-agent framework, LangChain provides a mature ecosystem with documented chains, agents, and tool integrations, but delegates team structure and memory management to the developer. OpenOPC's contribution is automating those decisions rather than leaving them to configuration.

Editorial conclusion

OpenOPC suits developers and researchers who want to experiment with multi-agent orchestration where the system recruits its own team, manages handoffs through a structured work-item model, and builds cumulative memory across projects. Teams that need a production-tested, commercially supported agent framework should evaluate alternatives such as LangChain or AutoGen, both of which have larger ecosystems, documented upgrade paths, and community-maintained integrations. OpenOPC has no GitHub releases and is at version 0.1.0; treat it as research-grade software. Before starting, confirm that your LLM provider credentials are in the configuration, that you have reviewed the SECURITY.md file, and that you understand the JiuwenSwarm version requirements listed in the September 2026 release note.

Frequently asked questions

Official sources

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