AI Maestro: a dashboard for running many AI coding agents across machines

The problem AI Maestro was built to solve

The README opens with a confession rather than a feature list: the author was running 35 AI agents across terminals and became "the human mailman between them", copying context from one window into another. That is the problem AI Maestro targets. Individual coding agents are useful in isolation, but once you have more than a handful, the coordination cost moves onto you. You are the router, the shared memory and the status board.

The intended user is therefore narrow and specific: someone already running Claude Code, Codex, Aider, Cursor or another terminal-based agent, on one machine or several, who wants a single view of all of them and a channel for them to talk to each other. It is not a tool for someone who wants an agent, or who runs one agent in one terminal. The README states the project now runs 80+ agents across multiple computers, which is the scale the design assumes.

What makes the framing credible is that each feature in the README is introduced with the annoyance that produced it: 35 terminals that were indistinguishable, an idle Mac Mini, agents that woke up with amnesia. Whether that history is accurate is not something a reader can verify from the repository, but it does explain why the feature set looks the way it does.

How the dashboard, the mesh and AMP fit together

Architecturally, AI Maestro is a Next.js application served by server.mjs through tsx, with a WebSocket layer for terminals (the package keywords include xterm and websocket, and .env.example exposes WS_RECONNECT_DELAY and WS_MAX_RECONNECT_ATTEMPTS). The dashboard is the control surface; the agents themselves keep running in whatever runtime you chose.

Agent discovery is the mechanism worth understanding. The README says the dashboard auto-discovers tmux sessions, Docker containers, cloud deployments and standalone agents. That means AI Maestro is not the thing executing your agent. It attaches to sessions that already exist, which is why it can work with any terminal-based agent rather than a fixed vendor list. The four deployment modes are tmux (local), Docker (containerized, with resource limits), AWS EC2 (a dedicated Graviton instance with a native install, Nginx and SSL) and AWS ECS Fargate (serverless containers). Cloud agents are described as Terraform-managed.

The multi-machine story is a peer mesh: the README says every machine is equal and no central server is required, so adding a computer means it joins the mesh and its agents appear in the same dashboard. Messaging runs over the Agent Messaging Protocol, which the README describes as email-like, with priority levels, message types, cryptographic signatures and push notifications. Gateways to Slack, Discord, Email and WhatsApp are a separate repository, and the README states the gateway scans for 34 prompt injection patterns before an agent sees a message. That last detail is the one architectural claim that materially changes the threat model, because filtering happens upstream of the agent rather than inside it.

Installing AI Maestro and creating a first agent

The README gives a one-line install. It requires Node.js 18+ and tmux, and the stated time is 5 to 10 minutes. On Linux the README asks for tmux and build-essential; on Windows it asks for WSL2 first.

curl -fsSL https://raw.githubusercontent.com/23blocks-OS/ai-maestro/main/scripts/remote-install.sh | sh

Piping a remote script into a shell is a decision, not a formality. The README does not document a checksum or a signed release for this script, so if you cannot read it first, the manual path is the safer one. That path is also documented:

git clone https://github.com/23blocks-OS/ai-maestro.git
cd ai-maestro
yarn install
yarn dev

The README states the dashboard then opens at http://localhost:23000. If you need to change the binding or the port, copy the example environment file and edit it, since .env.local is gitignored:

cp .env.example .env.local

Two keys matter immediately. PORT defaults to 23000, and HOSTNAME defaults to 0.0.0.0, which the example file itself flags as allowing LAN access and warns never to expose to the internet without authentication. Setting HOSTNAME=localhost is the conservative choice on an untrusted network.

Creating an agent is done from the UI wizard or the CLI. The README shows both cloud forms:

aimaestro-agent.sh create my-api --ec2 \
  --domain api.example.com --ssl-email [email protected] --key-name my-key

aimaestro-agent.sh create worker --ecs

The EC2 form provisions a dedicated instance with SSL; the ECS form auto-builds the Docker image, pushes to ECR and runs on Fargate. Local agents are the simpler starting point: run your agent in tmux, and the dashboard should discover the session.

Where AI Maestro is the wrong tool

The clearest limitation is the dependency on tmux and on terminal sessions as the unit of work. If your agents run as library calls inside an application, or as long-lived services with their own HTTP interfaces, there is no tmux session to discover and the core value proposition does not apply. The README frames the project around terminal-based agents, and that framing excludes a large part of how agent code is actually deployed.

The second limitation is operational. The repository contains update-aimaestro.sh, update-messaging.sh and verify-installation.sh, so upgrades are scripted, but the README does not document rollback. Version numbers in the repository are also not obviously in lockstep: package.json reads 0.38.9 while the most recent release listed is v0.37.6. A reader planning an upgrade should treat the release notes as the source of truth and check what update-aimaestro.sh does before running it.

Third, the default network posture is permissive. HOSTNAME=0.0.0.0 is the documented default, and the example file's own comment says never to expose it to the internet without authentication. There is no authentication layer described in the README. On a laptop on a café network, that default is a problem you have to fix yourself.

Finally, the security claim about gateways rests on a specific number, 34 prompt injection patterns. Pattern counts are a moving target and the README does not describe what happens to a message that nearly matches. Treat gateway filtering as a reduction in exposure, not as a boundary you can rely on alone.

Compared with running tmuxinator and a shared notes file

The honest alternative for many teams is not another orchestrator. It is tmux with a session manager, plus a shared directory for handoff notes and a chat channel for humans. That combination gives you multi-agent visibility and a crude form of messaging, and it costs nothing beyond the tmux you already have.

The difference is in what the agents can do without you. With tmux and notes, a handoff is a file one agent writes and another reads, and the routing is your job. With AMP, the README describes agents sending messages to each other by name, with priority levels, message types and cryptographic signatures, and the human only sets the intent ("Research agent, send your findings to the writing agent"). That is a different class of coordination: the message has an addressee and a delivery mechanism rather than a location on disk.

The other difference is the memory layer. AI Maestro bundles three things the README calls layers of intelligence: memory of past conversations and decisions, a code graph with delta indexing, and auto-generated searchable documentation. A notes file gives you none of that, and assembling an equivalent from separate tools means wiring an indexer, a graph and a doc generator yourself. Whether the bundled versions are good is not something the README establishes, but the integration is the product.

Licence, maintenance and the cost of keeping it current

AI Maestro is MIT licensed, with the LICENSE file at the repository root and the licence field in package.json set to MIT. That is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are retained. It says nothing about the separate gateway repository or about the AWS resources an EC2 or Fargate deployment creates, which are billed by AWS under your own account. This is a description of the licence text, not legal advice; if you are redistributing a modified version, read the LICENSE file yourself.

Maintenance is active by the only measure available here. The repository is not archived, and the last push was on 2026-08-29, which is recent. The release cadence around that date was tight: v0.37.4, v0.37.5 and v0.37.6 all landed within roughly a day of each other, and the v0.37.6 note describes the backlog as "deferred ideas from the competitor benchmarks". A project that ships three versions in a day is moving quickly, and the practical cost of that pace is upgrade churn rather than stagnation.

The upgrade surface is the scripts at the repository root. update-aimaestro.sh, update-messaging.sh and verify-installation.sh are the pieces to read before you upgrade, and verify-installation.sh is the natural thing to run afterwards. Because the README does not document a rollback path, the cheapest insurance is knowing your previous version number and having the clone or the container image you came from. The Containerfile and the container:build and container:test scripts in package.json give you a reproducible way to pin a known-good build if you would rather not track main.

Editorial conclusion

Adopt AI Maestro if you already run several terminal-based agents and are tired of being the message bus between them; the dashboard, the AMP messaging layer and the four deployment modes are the parts you cannot easily assemble yourself. Do not adopt it if you run one agent, if you need a hosted service rather than something on your own machines, or if you cannot accept that the README documents no rollback path for an upgrade. Verify first that Node.js 18+ and tmux are present, that port 23000 is free, and that you are comfortable with the default HOSTNAME=0.0.0.0 binding before you put the dashboard on a shared network.

Frequently asked questions

Official sources

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