Agent Orchestrator (AO)

Agent Orchestrator is the desktop for a developer managing a fleet against a single repo. Twenty-six agents are supported, Claude Code, Codex, Cursor, OpenCode, Aider, GitHub Copilot, Droid, Kimi Code, Pi and Devin among them, each on its own branch, and a project-level planner breaks the work up and delegates it. The trait that decides it is the planner: you describe the outcome and cards appear.

You need a repository with more open tasks than you can babysit. Pick it if that is your week and you want an open licence. Pick Orca if you want the widest agent list, and Superset if you want a company behind the app.

The risk is the sentence in the README: the orchestrator plans tasks, spawns agents and autonomously handles CI fixes, merge conflicts and code reviews. An agent resolving a conflict between two other agents' branches without a human is where semantics get lost, and no container layer separates any of them from the host.

Turn the conflict handling off, or route every conflict to a person before merge. What it does right: each task gets an isolated browser profile, so an agent testing a UI cannot log into your session or read another task's cookies.

The architecture is two processes. 1. A local Go daemon monitors agent activity and source-control state and holds the truth. 2. An Electron app renders it as a board whose four columns run from Working to Ready to Merge, with live synchronisation between the two. 3. CI failures and review feedback are routed to the agent that owns the task, which closes the loop that most orchestrators leave open.

No benchmark is published, and the planner's quality is asserted, not measured. The observation: separating the daemon from the window is the design that lets a headless mode exist later, whether or not anyone builds it.

Untrivial AI released this in February 2026 and has published no price, which at 10,897 stars is a company still buying users. The features point at individuals, a desktop app and an opt-in mobile companion that only works on the home network, which is a consumer shape for a tool whose buyers are teams. Pricing power: none until a hosted or team tier exists.

Moat: the planner and the CI feedback loop, if they work; switching cost is a git branch. Likely acquirer: GitHub, whose pull requests and CI it already orbits. Position: watch for the pricing page, then decide.

The demo is a board that fills itself. Procurement: the README describes privacy-preserving telemetry that excludes personal data but records GitHub organisation ownership, which is on by default and is exactly the field our security review asks about. There is no SSO, no audit log, no admin console and no paid plan, so there is nothing to sign and nobody to hold to a retention policy.

Installation is a .dmg, .exe, .AppImage, .deb or .rpm, so every platform is covered. It does not run in CI. Onboarding is an hour. Not yet; telemetry off by policy and a vendor contact first.

Apache-2.0, which is the right answer, and the split into a Go daemon and an Electron front end means the interesting half is a process I could talk to directly if the protocol were documented; it is not yet. No MCP, no hooks, no model configuration, because the agents on the cards bring their own, and no way to point it at a local model except through one of them.

The community is a Discord and GitHub issues. A fork is a Go build and an Electron package, which is more than a weekend. Open, readable, not yet scriptable. Grudging approval of the licence, patience on the rest.