Solo Agent
An open-source, local-first workspace where humans and multiple AI coding agents collaborate through channels, task boards, teams, and persistent memory — ending scattered multi-agent work in terminal tabs.
README claims local-first operation with a clear three-layer architecture, but the evidence is documentation-level only: no code is shown for agent tool execution, file access, custom_env/custom_args injection, user confirmation, or data-flow disclosure. Auto-detecting agent CLIs from PATH and running them with custom env/args is a broad execution surface with no visible least-privilege or confirmation mechanisms. SECURITY.md explicitly scopes RCE risk, showing awareness but no demonstrated mitigation. Only source attribution earns 2 (LICENSE names fredal; SECURITY.md gives contact). Most criteria score 1 for absent implementation evidence.
Component structure, ports, and protocol tables are internally consistent, and dependencies in go.mod map onto CI (postgres service, goreleaser), earning 2. But the root package. test script is a placeholder error and no failure-message evidence exists in any provided file, scoring 1.
Target audience (developers running Claude Code/Codex CLIs) and scenarios (multi-agent coordination, task boards) are clearly described; environment requirements (Go 1.22+, Node 20+, Docker) are explicit, scoring 2. But capability boundaries and precise agent-trigger/mention semantics are reduced to 'If it can receive a heartbeat, it's hired' with no supporting documentation, scoring 1.
Information architecture is clear, install steps are concrete (make dev plus daily commands), the LICENSE is full MIT text, and SECURITY.md honestly states solo maintenance with no SLA. Scoring 1 elsewhere: naming instability (README says github.com/solo-agent/solo while the go.mod module is github.com/solo-ai/solo), no changelog or release-history evidence despite the release workflow, no FAQ, and known limitations only implied. Install notes and maintenance responsibility earn 2.
Marginal value over scattered terminal tabs is supported by a concrete before/after table (centralized coordination, task boards, memory), scoring 2. Output usability (actual artifact form, review flow) rests on screenshots and concept description with no code evidence, scoring 1; cost/benefit is reasonable (local run, reuses existing CLIs), scoring 2.
Architecture diagram and protocol table trace to concrete ports and CLI binary names, but all functional claims lack verifiable test or benchmark files (root package. test is a placeholder), so claim traceability is weak. CI shows go test and tsc checks exist, yet no test source is present to corroborate; cross-source corroboration is limited. Facts and marketing inference are mixed in the README, scoring 1.
- This is a static review; no code was executed. There is no visible evidence of permission scoping or user confirmation for the agent execution surface (custom_env/custom_args, tool calls); audit daemon and agent subprocess code before deployment.
- The go.mod module path (github.com/solo-ai/solo) does not match the repository (solo-agent/solo), and the publisher is unverified — confirm supply-chain provenance.
- The project is solo-maintained with no SLA (per SECURITY.md), so security-fix timelines are uncertain; the root package. has no real test script.
- No changelog or release history is present in evidence, so regression and upgrade risk cannot be assessed.
- Feature and marketing claims in the README are not backed by any verifiable tests or benchmarks in the provided files.
What does this agent do, and when should you use it?
Solo Agent (GitHub: solo-agent/solo, MIT-licensed) is a self-hosted workspace that manages coding agents like Claude Code, Codex CLI, OpenCode, Hermes, and OpenClaw as collaborative teammates. It runs as three local layers: a Go server (:8080) providing the API, WebSocket hub, and PostgreSQL persistence; a daemon (:8081) that registers the machine and manages agent subprocesses; and a Next.js browser frontend (:3000). Agent CLIs are launched by the daemon over stdin/stdout while Solo injects prompts, MEMORY.md memory, and collaboration tools. Users post messages in channels, @-mention agents, or create tasks that flow across a Kanban board (todo / in_progress / in_review / done / closed), producing reviewable artifacts when complete. It also ships agent team templates, a Thinking mode for branched discussions, and dashboards for live run tracing and usage trends. The entire stack runs locally with no cloud orchestration dependency.
After cloning, make dev generates .env, installs frontend dependencies, starts PostgreSQL, runs migrations, and launches the app. From http://localhost:3000 after registering, you create a channel, add an agent (backends are auto-detected from PATH: claude / codex / opencode / hermes / openclaw, speaking stream-, JSON-RPC, and ACP protocols respectively), then @-mention the agent or create tasks. Agents are long-lived teammates with their own workspaces and MEMORY.md memory that can claim, submit, be reviewed on, and close tasks; tasks can be split into subtasks for multi-agent division of labor. Each agent can override system_prompt, model_name, custom_env, and custom_args. The Server (:8080) exposes the Go API and WebSocket hub, the Daemon (:8081) manages agent subprocesses, and the frontend (:3000) renders channel conversations, team graphs, the task board, Thinking branches, and observability dashboards in real time.
- A developer running several Claude Code / Codex sessions side by side who wants one shared workspace for coordination and context instead of juggling terminal tabs.
- A tech lead who needs large work split into subtasks that multiple agents can claim, with a submit–review–close flow and inspectable artifacts.
- An individual developer who wants agents to retain project memory (MEMORY.md) across sessions rather than re-explaining context every run.
- A small team that wants to spin up a channel-scoped agent team (roles, relationships, ownership) from official team templates.
- An engineering-efficiency or ops owner tracking live agent runs, session transcripts, and usage trends from a single dashboard.
- Anyone coordinating humans and agents through shared channels, threads, DMs, and an inbox for mentions and replies.
What are this agent's strengths and limitations?
- Multi-backend by design: one workspace mixes Claude Code (stream-), Codex CLI (JSON-RPC), and OpenCode/Hermes/OpenClaw (ACP), avoiding single-vendor lock-in.
- Local-first and self-hosted: the server, daemon, and PostgreSQL all run on your machine — no third-party orchestration cloud.
- Structured collaboration, not a chat simulator: a Kanban board (todo/in_progress/in_review/done/closed), subtask splitting, review, and artifact publishing create a closed, trackable loop.
- Persistent memory and observability: agents hold MEMORY.md across sessions, with live run tracing and usage-trend dashboards.
- Thinking mode branches channel conversations into isolated reasoning contexts and returns conclusions to the parent thread without polluting the main context.
- Heavy local stack: Go 1.22+, Node.js 20+, Docker, and PostgreSQL must all be available — a real barrier for quick experimentation.
- Depends on external agent CLIs: you must first install claude/codex/opencode/hermes/openclaw on your PATH; Solo provides no model access itself, and all model API costs still come from those CLIs.
- The documented clone uses an SSH git URL, and
make devperforms stateful operations (migrations); recovery from a bad state requiresmake db-reset. - No documented production deployment, hardening, or multi-tenant guidance — it currently reads as a single-machine/small-team self-hosted tool.
How do you install or deploy this agent?
Prerequisites: Go 1.22+, Node.js 20+, npm, Docker, and at least one supported agent CLI on your PATH (claude, codex, opencode, hermes, or openclaw). Install and start:
bash
git clone [email protected]:solo-agent/solo.git
cd solo
make devmake dev creates .env, installs frontend dependencies, starts PostgreSQL, runs migrations, and launches the app. Then open http://localhost:3000 and register.
How do you use this agent?
After registering: 1) create or open a channel; 2) add an agent with a supported backend; 3) mention the agent or create a task; 4) watch the conversation, channel team, task board, and agent output update in real time. Everyday commands: make (show all targets), make start, make stop, make rebuild (rebuild binaries and restart), make db-reset (reset the local database). You can override system_prompt, model_name, custom_env, and custom_args per agent.