OpenAkita: a multi-agent assistant framework that runs an AI company from your chat app

The problem OpenAkita targets: one chat model is not a workflow

Most assistant projects are a single model behind a prompt loop. OpenAkita's premise, stated in the README, is that a task like a competitive analysis should be split across a research agent, an analysis agent and a writing agent that run at the same time, not handed to one model sequentially. The framework also pushes past that into what it calls organization orchestration: a hierarchy with CEO, CTO and CFO roles, blackboard memory, message routing, deadlock detection and heartbeat.

The audience is developers who want agent plumbing already assembled. The pyproject.toml lists anthropic, openai and mcp as core dependencies, plus typer for the CLI, fastapi and uvicorn for serve mode, playwright for browser automation, and aiosqlite for persistence. That dependency set tells you what kind of project this is: not a thin wrapper, but a runtime. The README also advertises a fully GUI-based setup with zero command line required, which points at a second audience, people who never open a terminal and install the desktop build instead.

How the agent loop and orchestration actually fit together

The README describes a ReAct reasoning engine with an explicit three-phase loop: think, act, observe. Checkpoints are taken during that loop and can be rolled back, and the engine performs loop detection and strategy switching when a step fails. Plan Mode sits above it, decomposing a complex task into steps, tracking each one, and rolling back on failure. That is the mechanism, and it is the part worth evaluating, because rollback semantics determine whether a failed agent run leaves your filesystem in a known state.

Multi-agent collaboration is the layer above ReAct. Specialized agents are delegated to in parallel, with automatic handoff and failover, and the README mentions a real-time visual dashboard. Organization orchestration adds blackboard sharing, message routing, deadlock detection and auto-scaling on top of that. The plugin system is the extension surface: 8 plugin types, a 3-tier permission model and 10 lifecycle hooks, covering tools, channels, RAG, memory and LLM providers. The repository layout backs this up, with separate top-level directories for plugins, skills, channels, mcps, cloud and an openakita-plugin-sdk package that the Dockerfile copies in so first-class plugins can resolve openakita_plugin_sdk at runtime.

Installing OpenAkita and running a first task

The README gives two entry points. Non-developers download the desktop installer and follow the onboarding wizard, entering an API key from Anthropic or DeepSeek. Developers use pip. The extra [all] is what the README shows, so use it as written rather than guessing at narrower extras.

pip install openakita[all]

After installation the interactive wizard writes your configuration. The README shows openakita init with no arguments.

openakita init

The first real task in the README is a one-liner passed to openakita run. Expect the CLI to stream agent steps rather than print a single answer, since the ReAct loop is the default execution model.

openakita run "Build a weather scraper"

If you prefer containers, the repository ships a docker-compose.yml that builds from the local Dockerfile, maps port 18900, mounts ./data, ./identity and ./skills, and reads a .env file. The service exposes a health endpoint at /api/health on that port.

services:
  openakita:
    build: .
    ports:
      - "18900:18900"
    env_file:
      - .env

The examples directory contains an .env.example, which is the file to copy before starting the container, since compose expects .env to exist.

Where OpenAkita gets in the way

The licence is the first constraint. pyproject.toml declares AGPL-3.0-only, and the classifier is GNU Affero General Public License v3. If you modify OpenAkita and expose it to users over a network, the AGPL network clause is the question your legal team has to answer before you build a product on it. That is not a defect in the project, but it rules out a category of adopters outright.

The second constraint is maturity signalling. The same pyproject.toml carries the classifier Development Status :: 3 - Alpha, and the README's own feature table lists auto-scaling, deadlock detection and blackboard memory as capabilities rather than describing their failure modes. Release tags run in a tight v1.27.x line, with v1.27.38 published on 2026-08-12 and v1.27.35 three days before v1.27.37. That cadence suggests active work; it also means pinning a version is the only way to get reproducible behaviour, because the patch stream moves quickly.

The third constraint is scope. The README claims 30+ LLMs, 6 IM platforms and 89+ tools. Every one of those is a surface that can break independently, and the repository does not document rollback for configuration or data migrations. If you want a small, auditable agent loop you can read in an afternoon, this is the wrong tool; the dependency list alone includes playwright, fastapi and a browser-use stack.

OpenAkita compared with a plain MCP client

The closest alternative is not another assistant app but the raw Model Context Protocol. OpenAkita depends on mcp>=1.0.0, so it is built on top of that protocol rather than replacing it. An MCP client gives you tools and a single model loop. OpenAkita adds the parts MCP does not specify: a plan decomposer, checkpoint and rollback, parallel delegation between agents, a permission model for plugins, and channel adapters for Telegram, Feishu, WeCom, DingTalk and QQ.

The difference in approach matters for debugging. With a bare MCP client, the control flow is your code, so a failure is a stack trace you own. With OpenAkita, control flow lives inside the ReAct engine and the orchestration layer, so a failure surfaces as an agent step, a rollback, or a deadlock detection event. You gain the plan tracking and the failover, and you give up direct control of the loop. Teams that already have a working orchestration layer will find this one redundant. Teams that have never written a planner will find it is the part they would otherwise spend weeks on.

Maintenance, releases and what the AGPL means in practice

The repository is not archived and the last push was on 2026-09-09, so the codebase is being touched. Releases arrive frequently in the v1.27.x series, and the CHANGELOG.md and RELEASE.md files at the top level are where upgrade notes would live. The VERSION file and scripts/write_build_version.py indicate the build stamps a version into the artifact, and the Dockerfile accepts OPENAKITA_BUILD_GIT_HASH for that purpose. If you deploy from a container, record that build argument, because it is the only thing tying an image back to a commit.

Upgrade cost is dominated by the plugin surface. The Dockerfile shows an opt-in extra, finance-auto, enabled with INSTALL_FINANCE_AUTO=1 at build time and off by default so plain installs stay slim. That pattern means plugin dependencies are not in your base image unless you ask for them, which is good for image size and awkward for reproducibility if you forget which build args a given deployment used.

On licensing, AGPL-3.0-only is a copyleft licence with a network clause. Nothing in the repository indicates an alternative commercial licence, and the presence of TRADEMARK.md and NOTICE suggests the maintainers have thought about the boundaries. I am not a lawyer and this is not legal advice: if your use case involves exposing a modified OpenAkita to users over a network, get an actual opinion before you write code against it.

Editorial conclusion

Adopt OpenAkita if you want a Python agent runtime where delegation, planning and rollback are already wired together and you are comfortable with AGPL-3.0-only. Do not adopt it if you need a stable release line or if your product must stay closed source without a licensing decision. Before committing, verify three things: that pip install openakita[all] resolves on your Python version, that the .env.example keys match the providers you plan to use, and that your intended deployment survives the AGPL network clause.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. openakita/openakita on GitHub
3. Project website
4. README
5. Releases