Agent Teams AI: an Electron desktop app that puts a kanban board in front of Claude Code, Codex and OpenCode

The problem Agent Teams AI solves, and who it is built for

Running one coding agent in a terminal is a single conversation. Running four of them means four terminals, four sets of logs, and no shared record of who changed which file. Agent Teams AI takes that coordination problem and puts a GUI on it. The README describes it as "an orchestration layer for AI agent teams across Claude Code, Codex, OpenCode, Cursor, SuperGrok, GitHub Copilot, Z.AI, MiniMax, and Kiro", and the interface is a kanban board where tasks move between statuses while agents pick them up.

The intended user is a developer who already pays for one or more of those runtimes and wants to multiply their throughput without writing a scheduler. The repository description frames the role plainly: you are the boss, agents are the team, they message each other and review each other's work. If your work is a single file edit, the board is overhead. If your work is a feature that splits into a schema change, an API route, a test suite and a docs update, the board is the point.

There is also a solo mode. A one-member team is a single agent that creates its own tasks and shows live progress. The README says it saves tokens and can expand to a full team at any time. That is a sensible default for someone testing the tool before committing a provider subscription to it.

How the orchestration actually works: runtimes, tasks and the board

The architecture is a desktop application that wraps external agent runtimes rather than replacing them. Installation notes say the app "can detect installed Claude Code, Codex, and OpenCode runtimes", and that Cursor, SuperGrok, GitHub Copilot, Z.AI, MiniMax and Kiro are connected from the UI. So the model calls, tool execution and file edits happen inside those runtimes, and Agent Teams AI supplies the team structure, the task graph and the observation surface.

Tasks are the unit of work. Agents create and manage their own tasks, leave comments, and change task status, which is what animates the kanban board. The README also describes a review workflow: you see what code each task changed, then approve, reject or comment, and you can watch how agents review each other's tasks. That review layer is the most interesting design decision here, because it means the app is not just scheduling prompts, it is holding a diff-level approval gate.

Above the task level sit teams and organizations. Teams can be grouped into departments or squads, and the README describes a live map showing every organization with team and agent status, task progress, dependencies, delegation and cross-team communication. Agents can message each other across teams. Token analytics run alongside all of this: input, output, cache and reasoning usage broken down by team, agent, task, project, model, runtime, session, command and run, with monthly token or estimated-cost budgets and alerts at 80% and 100%.

Autonomy is configurable rather than fixed. Agents can run fully autonomous, or you can review and approve supported tool actions one by one and receive a notification. That is the setting to change first if you are uncomfortable letting an agent write to a repository unsupervised.

The repository layout is consistent with that description. There is an electron.vite.config.ts, a src/ tree, a packages/ workspace, an agent-teams-controller/ directory, an mcp-server/ directory, a landing/ site, a docker/ directory and a terminal-platform.lock.json. The presence of a controller package and a separate MCP server suggests the board logic and the agent-facing protocol are separated, which is the right split if you ever want to drive the controller from something other than the GUI.

Installing Agent Teams AI and running your first task

There is no package-manager install for end users. The README's installation section points at GitHub release artifacts: a .dmg for arm64 and x64 on macOS, a Setup .exe for Windows, and AppImage, .deb, .rpm and .pacman packages for Linux. The release links in the README are pinned to v2.7.0 even though the newest release listed is v2.12.0, so download from the releases page rather than copying those URLs. No prerequisites are stated: the app detects installed Claude Code, Codex and OpenCode runtimes on its own.

On Windows the README warns that the installer may trigger SmartScreen, and tells you to click "More info" then "Run anyway". It also notes that administrator mode may be needed only if the app reports a specific OpenCode symlink or permission error. Do not pre-emptively run it elevated.

If you want to build from source instead, the package manifest requires Node 24 and pnpm. The preinstall script enforces pnpm, so npm and yarn will be rejected:

node --version   # must satisfy >=24.15.0 <25
pnpm install
pnpm dev

The dev script is not a bare Vite command. It runs through a wrapper that brings up the runtime:

pnpm dev
# equivalent to: node ./scripts/dev-with-runtime.mjs

For a first real use, the lowest-friction path is the free model with no auth, which the README says requires no signup, API key or card. Create a team, give it one task with a clear deliverable, and let it run. You should see the task change status on the board, and the task detail view should show the runtime logs, tool actions and messages for that task in isolation. Once that works, connect a paid runtime from the UI and compare the token analytics for the same task.

Where Agent Teams AI gets in the way

The distribution model is the first constraint. This is an Electron desktop application, and the README's installation section offers only desktop artifacts. There is no documented headless mode, no documented server deployment, and no documented way to run the board on a remote machine and attach from a browser. The docker/ directory exists in the repository, but the README does not document a Docker deployment path for the application, so treating that directory as a supported deployment route would be a guess.

That matters for teams. If your agents need to run on a build box with repository access and your developers work from laptops, the desktop-only shape forces a decision the documentation does not help you make.

The second constraint is dependency on external runtimes. The app detects Claude Code, Codex and OpenCode, and connects others from the UI. That is convenient, but it means the failure modes of those tools become your failure modes. The README does not document what happens when a runtime is upgraded underneath the app, or what happens to a running task when a provider session expires. The package manifest includes a runtime.lock.json and a terminal-platform.lock.json, which suggests version pinning is taken seriously, but the README does not explain the upgrade procedure.

Third, the free no-auth model is described as a starting point, not a workload engine. The README does not state its rate limits, context window or which provider backs it. Using it for a multi-agent team with parallel tasks is likely to hit whatever ceiling that provider imposes, and the documentation does not tell you where that ceiling is.

Finally, review fatigue is real. The app supports reviewing and approving supported tool actions one by one. With several agents running in parallel, that mode can produce more notifications than a person can process, which pushes you back toward full autonomy. The README presents both ends of that spectrum but does not describe a middle ground such as per-agent or per-path approval rules.

Agent Teams AI compared with driving Claude Code subagents directly

The closest alternative is not another product. It is the built-in subagent feature of Claude Code, which lets you define specialized agents and delegate to them from a single session. The difference in approach is where state lives. With subagents, the conversation is the coordination record: the parent session holds context, and the subagents report back into it. With Agent Teams AI, the kanban board is the coordination record, and it persists independently of any one conversation.

That difference shows up in practice. Subagents are faster to set up and require no additional install, and they keep everything inside one tool you already trust. But they are tied to Claude Code, they do not give you a diff-level approve or reject gate per task, and they do not produce the cross-provider token analytics that Agent Teams AI reports by model, runtime and run. If your reason for wanting multiple agents is throughput within one provider, subagents are the smaller tool for the job.

If your reason is comparing providers, or running a team whose members use different runtimes, the board earns its overhead. The same logic applies against writing your own orchestration script: Agent Teams AI is a GUI over that idea, and the trade is that you get the board, the review workflow and the analytics, and you give up the freedom to shape the loop exactly as you want.

Licence, maintenance and the cost of staying current

Agent Teams AI is licensed AGPL-3.0, per the package manifest and the repository's LICENSE file. The practical consequence, stated as a fact about the licence rather than as legal advice: if you modify the application and let users interact with it over a network, the AGPL's source-disclosure obligation is the question to bring to a lawyer. Internal use of an unmodified desktop build is a different situation from shipping a modified fork as a service. Because the app is Electron and desktop-oriented, the network-interaction trigger is less obvious than it would be for a web app, which is exactly why this is worth a specific answer rather than a general one.

The project is not archived. The last push was on 2026-08-01, and the newest release in the list is v2.12.0 on the same date, following v2.11.0 on 2026-07-21 and v2.10.0 on 2026-07-20. The release cadence in July and August was rapid, with three releases inside two weeks. That pattern cuts both ways for an adopter: features arrive quickly, and so do changes to the things you depend on. Note that the version in package.json is 2.1.2 while the release tags are 2.12.x, so do not read the manifest version as the app version.

Upgrade cost is dominated by runtime compatibility, not by the app itself. Because Agent Teams AI wraps Claude Code, Codex and OpenCode rather than vendoring them, an upstream change to a CLI's flags or output format is a potential break. The repository carries runtime.lock.json and terminal-platform.lock.json, and the scripts directory contains proof scripts such as opencode:prove-semantic-gauntlet and team:prove-provider-launch-strength, which suggests the maintainers test against specific runtime versions. The README does not document a rollback procedure, so keep the previous installer until a new version has run a real task.

Editorial conclusion

Adopt Agent Teams AI if you already have Claude Code, Codex or OpenCode installed and want several agents working in parallel with per-task review and token budgets in one window. Do not adopt it if you need a headless server component, a non-Electron deployment, or a licence that permits closed-source redistribution: it ships as a desktop app under AGPL-3.0. Before committing, verify that your board survives an app restart, that the free no-auth model is sufficient for your task volume, and that the monthly budget alerts at 80% and 100% fire against the provider you actually use.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes