Solo Agent: a local-first workspace that turns coding agent sessions into shared channels and task boards
Solo Agent — an open-source, local-first workspace where humans and AI coding agents collaborate through channels, tasks, teams, and persistent memory.
At a glance
- What is it?
- Solo Agent is a Go-based, MIT-licensed workspace that runs a server, a daemon and your installed agent CLIs as three local layers. It is aimed at people already juggling Claude Code, Codex, OpenCode, Hermes or OpenClaw sessions who want one place to assign, track and remember the work.
- Who is it for?
- Adopt Solo Agent if you already run two or more of the supported agent CLIs and keep losing context between terminal tabs, and if you are comfortable running PostgreSQL plus three local ports on one machine. Do not adopt it if you want a hosted service, if you rely on an agent CLI outside the five listed backends, or if nobody on the team will own the PostgreSQL instance and the daemon process.
- 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 3 days ago.
- What is it written in?
- Mainly Go, 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 problem Solo Agent addresses: parallel agent sessions with no shared record
Running one coding agent in a terminal is a single-threaded activity. Running five is a coordination problem. The README frames the pain directly: agent work is scattered across terminal tabs and chat transcripts, every run starts by re-explaining context, and finished work ends up buried in chat or files. Solo Agent's answer is to give those sessions a shared room. Channels hold the conversation, agents are long-lived teammates with their own workspace, and messages can be promoted into tasks that move through a Kanban board. The stated audience is people who already have Claude Code, Codex, OpenCode, Hermes or OpenClaw sessions running side by side. If you run exactly one agent and never hand work between sessions, the workspace layer adds moving parts without removing any. The README is also explicit about scope: Solo is a workspace, not a company simulator. That distinction matters when you evaluate the feature list, because the project deliberately stops short of modelling an org chart and sticks to channels, threads, teams and tasks.
Three local layers, four ports, and a stdin/stdout contract with each agent CLI
The architecture is documented as three layers on the local machine. A Go server listens on :8080 and owns the API, the WebSocket hub, authentication and PostgreSQL persistence. A daemon listens on :8081, registers the machine and manages agent subprocesses. The Next.js frontend is served on :3000. The documented data flow is Browser to Server to Daemon to Agent CLI, with WebSocket between browser and server, HTTP/SSE between server and daemon, and stdin/stdout between daemon and the agent process. That last hop is the interesting design decision. Solo does not embed a model client or wrap an SDK. It drives whatever CLI is on your PATH and supplies the prompt, the memory and the collaboration tools over the standard streams. The README summarises this with the line that if something can receive a heartbeat, it is hired. Backends are auto-detected at daemon startup, and each one speaks a different protocol: Claude Code over stream-json, Codex CLI over JSON-RPC, and OpenCode, Hermes and OpenClaw over ACP. Because the contract is the process boundary rather than a vendor API, the set of usable backends is bounded by the five binaries the daemon knows how to talk to.
Channels, tasks and MEMORY.md: the four objects that carry state
The core concepts table defines the state model. Channels are shared rooms for chat, threads, file attachments and coordination. Agents are long-lived entities with memory, roles, tool access and their own workspaces. Tasks are Kanban items with five states: todo, in_progress, in_review, done and closed. Teams are channel-scoped agent graphs showing roles and ownership. Memory is described as an agent-specific MEMORY.md file loaded into future sessions. The task board is where the design gets specific: every task keeps its discussion thread attached to its card, so assignment, subtasks, review, artifacts and history travel together as the card moves. Completed tasks can produce artifacts that a human inspects and finalises. Two features sit outside the core loop. Thinking mode branches a channel conversation into separate lines of reasoning, each with its own context, then returns conclusions to the parent discussion. Agent observability provides live run traces, session transcripts and a usage dashboard. Both are documented with screenshots rather than described in prose, so the exact mechanics of branching and of what the usage trends measure are not spelled out in the README.
Getting it running: make dev, make start, and one database reset
The prerequisites are listed plainly: Go 1.22+, Node.js 20+, npm, Docker, and at least one supported agent CLI on your PATH. Installation is three commands. Clone the repository, change into it, and run make dev. According to the README, make dev creates the .env file, installs frontend dependencies, starts PostgreSQL, runs migrations and launches the app. You then open http://localhost:3000, register, and follow four steps: create or open a channel, add an agent with a supported backend, mention the agent or create a task, and watch the conversation, team, task board and agent output update. The everyday command set is small: make lists all targets, make start starts services, make stop stops them, make rebuild rebuilds binaries and restarts, and make db-reset resets the local database. Per-agent configuration is limited to four overrides named in the README: system_prompt, model_name, custom_env and custom_args. That is the whole documented surface. There is no mention of a config file format beyond .env, no documented migration path for upgrading between releases, and no published backup procedure for the PostgreSQL data.
Where Solo Agent is the wrong tool, and what the README does not answer
The first limitation is the backend list. Five CLIs are supported, each with its own protocol, and there is no documented plugin interface for adding a sixth. If your agent of choice is not one of those five, Solo cannot drive it, and the README does not describe a fallback. The second is operational weight. A local-first workspace still means PostgreSQL, a Go server, a daemon and a Node frontend running on your machine, plus Docker as a prerequisite. That is a heavier footprint than the terminal tabs it replaces, and nothing in the README suggests a single-binary or SQLite mode. The third is that memory is a file. MEMORY.md is loaded into future sessions, but the README does not describe how it is written, how conflicts between an agent's edits and a human's edits are resolved, or whether it is versioned. The fourth is the upgrade question. Two releases exist, v1.0.0 and v1.1.0, and the material says nothing about schema migrations between them, so whether make rebuild is sufficient after pulling a new tag is unconfirmed. Finally, the documentation is thin on failure behaviour: what happens when an agent subprocess dies mid-task, or when the daemon loses its connection to the server, is not described.
How Solo Agent differs from a multi-agent framework like CrewAI or AutoGen
The obvious comparison is a Python multi-agent framework. CrewAI and AutoGen define agents in code, orchestrate them inside a single process, and hand results between them through the framework's own abstractions. Solo Agent inverts that. It does not define agents at all; it supervises processes that already exist. The unit of coordination is an OS subprocess spoken to over stdin/stdout, and the durable state lives in PostgreSQL and MEMORY.md rather than in a Python object graph. The practical difference is where you debug. With an in-process framework, you read a trace from the framework's logger. With Solo, the README points you at session transcripts and live run traces in the observability dashboard, because the agent is a separate program whose own output you can also inspect directly. The trade-off is control. A framework can intercept and rewrite every message between agents; Solo can only supply the prompt, the memory and the collaboration tools, and then read what the CLI writes back. If you need deterministic, programmatic control over agent-to-agent message passing, a framework gives you more surface. If you need the specific agent CLIs you already use to share a task board without rewriting them, Solo is the layer that does not require that rewrite.
Maintenance cost, MIT licensing, and what a Solo workspace actually commits you to
The licence is MIT, which places few restrictions on use, modification or redistribution, and the repository ships a LICENSE file at the root. That is permissive by design, but it also means no warranty and no support obligation from the maintainers; the README does not describe a commercial tier, an SLA or a paid support channel. Operationally, the recurring costs are the ones the architecture implies. You maintain a PostgreSQL instance, keep Docker available, keep Go 1.22+ and Node 20+ current, and keep each agent CLI on PATH at a version the daemon can talk to, since the daemon auto-detects backends at startup and a CLI upgrade that changes its protocol would surface there. make rebuild is the documented way to pick up new binaries, and make db-reset is the documented way to clear local state, which is a destructive operation with no described export or backup step. The repository shows two releases within roughly a month, v1.0.0 in early August 2026 and v1.1.0 in mid August 2026, with the last push to master in early September 2026. That cadence tells you the project is active. It does not tell you anything about the stability of the .env format, the database schema or the MEMORY.md structure across those releases, and the README does not address it.
Who should run Solo Agent, and the three checks to run before trusting it
Solo Agent fits a specific situation: you already run two or more of the five supported agent CLIs, you work on one machine, and the friction you feel is lost context and untracked handoffs rather than model quality. It does not fit a team that wants a hosted service with no local infrastructure, a user whose agent CLI is outside the supported five, or anyone unwilling to operate PostgreSQL and a daemon alongside their editor. Three checks are worth running before you rely on it. First, confirm the daemon detects every backend you intend to use at startup, since detection is automatic and a missing binary would otherwise surface later as a failed task. Second, confirm that MEMORY.md survives a session restart and a make rebuild, because persistent memory is the feature that justifies the workspace layer. Third, decide in advance what make db-reset means for your data, since it is documented as a reset with no described export path. If those three hold on your machine, the rest of the README describes a workspace that does what it claims.
Editorial conclusion
Adopt Solo Agent if you already run two or more of the supported agent CLIs and keep losing context between terminal tabs, and if you are comfortable running PostgreSQL plus three local ports on one machine. Do not adopt it if you want a hosted service, if you rely on an agent CLI outside the five listed backends, or if nobody on the team will own the PostgreSQL instance and the daemon process. Before committing, verify three things on your own hardware: that the daemon auto-detects each CLI you plan to use, that agent memory persists across a session restart, and that make db-reset is survivable for your workflow.
Community notes