Solo Agent: a local-first workspace where humans and coding agents share channels and task boards

The problem Solo Agent names: agents that behave like tools, not teammates

The README frames the project around a specific shift: when agents stop feeling like command-line tools and start working like human teammates. The failure it targets is familiar to anyone running several agent sessions at once. Work is scattered across terminal tabs and chat transcripts, every run begins by re-explaining context, and a request like "can you do this?" becomes an untracked conversation with no owner. Solo Agent's answer is to give the sessions one shared surface: channels, direct messages, threads, channel-scoped teams and a task board. The README's own comparison table lists the before and after side by side, and the target user is explicit: someone with Claude Code, Codex, OpenCode, Hermes or OpenClaw sessions running side by side. The project also draws a boundary around itself, describing Solo as intentionally a workspace and not a company simulator. That is a useful design statement, because it rules out org-chart features and keeps the scope on coordination, memory, tasks and reviewable outputs.

Three local layers: server on 8080, daemon on 8081, agent CLI over stdin/stdout

The architecture is documented as three local layers. A Go server on port 8080 holds the API, the WebSocket hub, auth and PostgreSQL persistence. A daemon on port 8081 registers the machine and manages agent subprocesses. The agent CLI itself reads stdin and stdout while Solo supplies the prompt, memory and collaboration tools. The README's diagram puts the browser (Next.js on 3000) on one end, then the server, then the daemon, then the CLI, with WebSocket and HTTP/SSE between the first pairs and stdin/stdout at the last hop.

Backends are auto-detected from your PATH at daemon startup. Five are listed, each with a distinct protocol: Claude Code via the claude binary over stream-json, Codex CLI via codex over JSON-RPC, and OpenCode, Hermes and OpenClaw over ACP. Per-agent overrides exist for system_prompt, model_name, custom_env and custom_args, which is how you vary model choice or environment between two agents in the same channel. The core concepts table defines the vocabulary the rest of the system uses: channels as shared rooms, agents as long-lived teammates with memory and their own workspaces, tasks as Kanban items in todo, in_progress, in_review, done and closed, teams as channel-scoped agent graphs, memory as agent-specific MEMORY.md context loaded into future sessions, an inbox for mentions, thread replies and DMs, and artifacts as generated outputs that can be reviewed, finalized and published. The docker-compose file explains a real constraint behind this split: only PostgreSQL runs in Docker, because the server and daemon run natively and need access to the local claude binary for LLM_PROVIDER=local mode.

Installing Solo Agent with make dev and running a first channel task

The README states the prerequisites plainly: Go 1.22+, Node.js 20+, npm, Docker, and at least one supported agent CLI on your PATH. Clone and start the development stack with two commands. The README says make dev creates .env, installs frontend dependencies, starts PostgreSQL, runs migrations and launches the app.

git clone [email protected]:solo-agent/solo.git
cd solo
make dev

When it finishes, open http://localhost:3000 and register. The README's first-run sequence is four steps: create or open a channel, add an agent with a supported backend, mention the agent or create a task, then watch the conversation, channel team, task board and agent output update in real time. If you prefer to drive the services yourself, the Makefile exposes everyday targets.

make          # Show all targets
make start    # Start services
make stop     # Stop services
make rebuild  # Rebuild binaries and restart
make db-reset # Reset the local database

Two things are worth checking before you invest time. First, the daemon auto-detects backends from PATH at startup, so an agent CLI installed after the daemon starts is not picked up until a restart. Second, the compose file pins PostgreSQL 16-alpine with database solo, user solo and password solo-dev on port 5432; that credential is a development default and is not something to carry into a shared machine.

Where Solo Agent gets in the way: ports, PATH and a package.json that is not the app

The most concrete limitation is environmental. Solo Agent is local-first by design, which means the server and daemon must run on the machine that has your agent binaries, and the docker-compose file says so directly: only PostgreSQL runs in Docker because the server and daemon need access to the local claude binary. You cannot simply containerize the whole stack and point it at a remote agent host without losing that assumption. The port trio is also fixed in the documentation: 3000 for the browser, 8080 for the server, 8081 for the daemon. If any of those is occupied, the README does not document a remapping procedure, and the deployment files are not described in the README.

A second trap sits in the repository root. The package.json declares name solo, version 1.0.0, type commonjs, and its only dependencies are Playwright packages; its test script is the npm placeholder that exits with an error. Anyone who assumes the root package.json drives the frontend will be confused, because the Go module in go.mod declares github.com/solo-ai/solo and requires Go 1.25.0 while the README badge says Go 1.22+. That version difference between the badge and the module directive is worth resolving on your own checkout before you plan a build pipeline around either number. Finally, Solo Agent is the wrong tool if you have a single agent and no backlog to share. The channels, teams, inbox and task board only pay for themselves when more than one session is competing for the same work.

Solo Agent versus a plain terminal multiplexer or a CI-driven agent pipeline

The nearest thing most teams already have is a terminal multiplexer plus a shared chat channel: tmux panes for the agent sessions, Slack or Discord for the humans, and a tracker for the work. That combination keeps every tool independent, and it costs nothing to adopt. The difference is state. In a multiplexer, the agent's context lives in the pane and dies with it; in Solo Agent, memory is an agent-specific MEMORY.md loaded into future sessions, and a task keeps its discussion thread attached to a Kanban card so assignment, subtasks, review, artifacts and history move together across the board. The other alternative is a CI-driven pipeline, where an agent is invoked by a job and its output is a build artifact. That model is auditable and reproducible, but it has no notion of an agent claiming work, submitting it for review, or being mentioned in a thread. Solo Agent's task states, todo through closed, exist precisely to represent that human review loop. The honest trade-off is that a multiplexer and a tracker are already understood by everyone on the team, while Solo Agent asks you to learn its channels, teams, inbox and artifacts vocabulary before the coordination benefit shows up.

Licence, maintenance and what an upgrade actually costs you

Solo Agent is MIT licensed, with the LICENSE file at the repository root and the badge in the README confirming it. MIT is permissive, so forking, internal modification and redistribution are all permitted subject to the licence text; this is not legal advice, and if you embed Solo Agent in a commercial product you should read the LICENSE file and your own counsel's view rather than this paragraph.

The maintenance picture is current rather than archival: the repository is not archived, and the last push was on 2026-09-04. Two releases are listed, v1.0.0 on 2026-08-09 and v1.1.0 on 2026-08-14, so the release cadence is recent but short, and the repository gives no long-run history to extrapolate from. Upgrade cost is dominated by the database. The Makefile exposes make rebuild to rebuild binaries and restart, and make db-reset to reset the local database, which tells you migrations are part of the normal flow rather than an afterthought. The Dockerfile builds four binaries (server, daemon, solo and migrate) and runs them as a non-root solo user, exposing 8080 and 8081. There is no documented rollback path in the README, so a migration that goes wrong is something you would handle with your own PostgreSQL backups rather than with a project-provided command.

Editorial conclusion

Adopt Solo Agent if you already run two or more of the supported agent CLIs and lose track of which session owns which piece of work; the channel-scoped teams and the Kanban states (todo, in_progress, in_review, done, closed) are the parts that do the actual coordinating. Skip it if you are a single developer with one agent and no shared backlog: a workspace with a daemon, a server and PostgreSQL adds moving parts you will not use. Before committing, verify on your own machine that the daemon detects your CLI binaries at startup, that the port trio 3000, 8080 and 8081 is free, and that your team accepts agent memory living in plain MEMORY.md files rather than a managed store.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. solo-agent/solo on GitHub