squad: multi-agent terminal collaboration over SQLite, no daemon required
Multi-AI agent terminal collaboration tool
At a glance
- What is it?
- squad is a Rust CLI that lets several AI coding agents in separate terminals coordinate through a shared SQLite state file. It is a thin coordination layer, not an orchestration engine, and the documentation leaves the runtime behaviour of the work loop largely to the agent prompts.
- Who is it for?
- Adopt squad if you already run several AI CLI agents in separate terminals and want their handoffs recorded in a file you can inspect, rather than trusting a single agent to hold the plan in its context window. Skip it if you need a scheduler that survives a crashed terminal, or if you want one process to own retries and ordering.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 113 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The coordination gap squad is built to close
A single AI CLI agent holds its plan in its own context. The moment you open a second terminal and start a second agent, that shared context disappears. Two agents working the same repository have no channel between them unless a human copies text back and forth. squad targets exactly that gap: it gives each agent a named identity, an inbox, and a task queue backed by a file on disk. The README frames the intended shape as one manager, several workers, and an optional inspector, each in its own terminal. The audience is developers already comfortable running claude, gemini, codex or opencode from a shell and willing to type slash commands. It is not aimed at people who want a hosted dashboard or a graphical orchestration product. The pitch is deliberately small: shell commands plus SQLite, and according to the README, no daemon and no background processes, with every command a one-shot operation.
SQLite as the message bus, agents as the runtime
The mechanism is a shared state directory. squad init creates a .squad/ folder in the project and adds it to .gitignore, so state stays local and untracked. Agents join with an ID and an optional role, and the join command auto-suffixes the ID when it is already taken, which is how three terminals all started with /squad worker end up as worker, worker-2 and worker-3. Communication runs through squad send and squad receive, with @all as a broadcast target and a --file flag that reads a message body from a path or from stdin. Structured work is separated from chat: squad task create produces an assignment, squad task ack claims a queued task, squad task complete closes it with a summary, and squad task requeue returns it to the queue, optionally to a different assignee. That separation matters, because a task has a status that can be listed and filtered, while a message is just a timestamped note. The receive command has a --wait flag that blocks until a message arrives, with a --timeout bound. This is the piece that makes the whole design work without a broker: each agent runs a loop that calls squad receive --wait, acts, sends a report, and loops again. The README describes the worker behaviour as checking for tasks via squad receive, executing assigned work, and reporting back. What it does not specify is the loop itself. That logic lives in the role instructions installed under .squad/roles/, so the reliability of the coordination depends on prompt text rather than on anything the Rust binary enforces.
Getting a session running: setup, init, and the slash command
Installation is Homebrew on macOS via brew install mco-org/tap/squad, a prebuilt archive from GitHub Releases on Windows, or cargo install --git https://github.com/mco-org/squad.git from source. The README states Rust 1.77+ and four supported platforms. Two commands precede any collaboration. squad setup installs the /squad slash command into detected AI tools, and squad setup --list reports which platforms were found and their status. Then squad init prepares the workspace: it creates .squad/, appends squad guidance to CLAUDE.md, AGENTS.md and GEMINI.md if that guidance is missing, and updates .gitignore. The --refresh-roles flag rewrites only the builtin manager, worker and inspector files under .squad/roles/, which gives you a way to pick up role changes without discarding custom roles you added yourself. After that, each terminal runs the slash command for its part: /squad manager, /squad worker, /squad inspector. Inspection commands are plain CLI: squad agents --all --json emits one JSON object per line including capability fields, squad pending shows all unread messages, squad history accepts --from, --to and --since filters where --since takes either an RFC3339 timestamp or unix seconds, and squad clean wipes all state. The JSON output is the practical integration point if you want to build your own status display instead of reading the human-readable tables.
The tmux launcher is a separate, optional program with its own dependencies
The repository ships scripts/squad-tmux-launch.sh, and the README is explicit that it is intentionally separate from the core Rust CLI. It reads project-local configuration from .squad/launcher.yaml, reads a task brief from .squad/run-task.md, generates manager and inspector prompt files under .squad/quickstart/, starts a tiled tmux session, and injects /squad commands into Claude panes. It can also create an isolated git worktree before launching agents, which is the more interesting capability, since it means a squad run can be confined to a branch rather than your working tree. The costs are real. It requires tmux, ruby and claude. Ruby is present because the script uses it to parse launcher.yaml, which is a notable dependency for a project whose core is a single Rust binary. The launcher is also Claude-specific in the sense that it injects commands into Claude panes, even though the core CLI advertises four client types. A --dry-run flag exists, and the README shows scripts/squad-tmux-launch.sh /path/to/project --dry-run as the way to inspect what it would do before it does it. Treat that flag as the entry point, not an afterthought.
Where the design breaks down
The no-daemon choice is the source of both the appeal and the fragility. Because every command is one-shot, there is no process watching for a worker that stopped mid-task. If a terminal is closed, or an agent exits its loop, the task it acked stays acked. The recovery path is manual: squad task requeue <task-id> puts it back, optionally with --to to name a new assignee, and squad leave <id> archives an agent while preserving unread work. Someone has to notice the stall and issue that command. There is no heartbeat described in the material and no automatic reclamation of tasks from agents that vanished. The second limitation is role drift. Because the work loop is defined by prompt files rather than by the binary, two agents given the same role can behave differently depending on how their model interprets the instructions, and the README offers no mechanism for validating that an agent actually followed its role. Third, the state is a local .squad/ directory that init adds to .gitignore. That is the right default for avoiding committed noise, but it also means the coordination record does not travel with the repository. If you want a durable audit trail of which agent did what, you have to export it yourself, for instance by capturing squad history output. Finally, the CLI is a coordination primitive, not a sandbox. Nothing in the described command surface prevents two agents from editing the same file, and the only isolation mentioned anywhere is the optional git worktree in the tmux launcher.
How this differs from a framework like LangGraph or CrewAI
The natural comparison is a Python multi-agent framework such as LangGraph or CrewAI. Those projects put the orchestration graph in your code: you define nodes, edges and state transitions, and the framework's runtime executes them, handling retries, branching and persistence inside a single process you control. squad inverts that. There is no graph and no runtime. The agents are the runtime, the coordination state is a SQLite file, and the interface between them is a set of shell commands the agent chooses to call. That means squad imposes no framework on the agents themselves: any CLI tool that can run a shell command can participate, which is why the README can list Claude Code, Gemini CLI, Codex CLI and OpenCode side by side. The trade-off is that you give up the guarantees a framework provides. A LangGraph run either advances or raises; a squad session advances only as long as the agents keep calling receive. If you need deterministic control flow and programmatic error handling, a framework is the better fit. If you want several existing CLI agents to share a task list without rewriting them as framework nodes, squad's approach is the one that does not require the agents to change.
Maintenance, protocol versioning and the MIT licence
The release cadence visible in the material is tight: v0.7.4, v0.7.5 and v0.7.6 all landed within roughly a week in late March and early April, and the last push to the default branch is dated 2026-05-26. A version series still in the 0.7 range after that many point releases suggests the interface is not yet frozen. Two details support that reading. The join command accepts --protocol-version <n>, and the agents command reports protocol-derived support booleans alongside raw and effective capability fields. Those exist because agents of different versions can be present in the same workspace, and the tool needs a way to describe what each one supports. If you build automation on top of the --json output, expect those fields to change. Upgrading the binary does not automatically rewrite your role files, which is deliberate: --refresh-roles is opt-in and touches only the builtin manager, worker and inspector files. Your own roles survive an upgrade, but they also will not receive fixes. The project is MIT licensed, which permits commercial use and modification; the repository includes a LICENSE file and the README carries an MIT badge. That is a statement about the licence text, not advice about your situation. If you plan to redistribute a modified squad, read the LICENSE file in the repository rather than relying on the badge.
Editorial conclusion
Adopt squad if you already run several AI CLI agents in separate terminals and want their handoffs recorded in a file you can inspect, rather than trusting a single agent to hold the plan in its context window. Skip it if you need a scheduler that survives a crashed terminal, or if you want one process to own retries and ordering. Before committing, run squad init on a throwaway repository and check what it appends to CLAUDE.md, AGENTS.md and GEMINI.md, then decide whether that guidance belongs in your tracked files.
Community notes