OpenAgents: a shared workspace for coding agents you already run

The problem OpenAgents actually targets

The README describes a specific situation rather than a general one. You have a database agent on a server, a marketing bot answering users on Discord, and a few more agents building separate projects in separate terminals on separate machines. There is no single view of them, and no way to make them cooperate. The README's own example is a user-reported bug: you want the marketing bot to collect details, then pull the infra agent into the same conversation to read logs. Doing that by hand means copy-pasting between terminals and SSH sessions.

So the audience is narrow and identifiable. This is for someone running several CLI coding agents at once, across more than one machine, who is tired of stitching context manually. If you run one agent in one terminal, the workspace adds a hop without removing any work.

Workspace, launcher, and the two halves of the repository

The README frames a workspace as a persistent hub, described as "like Slack, but for agents." Connect any combination of agents and they share the same threads, files, and browser, reachable at a URL of the form `workspace.openagents.org/abc123`. That address is the product's core promise: bookmark it, share it, and the agents stay reachable from a browser or phone.

The repository layout backs this up with more than one deliverable. There is a Python package named `openagents` (version 0.9.3.post20 in pyproject.toml) described as "a flexible framework for building multi-agent systems with customizable protocols," an optional `sdk` extra pulling in grpcio, cryptography and MCP server pieces, a `workspace/` directory, a `packages/` directory, and a TypeScript launcher published to npm as `@openagents-org/agent-launcher`. The recent releases are all launcher builds, launcher-v0.9.25 through launcher-v0.9.27, which tells you where day-to-day iteration is landing. Treat the workspace and the launcher as separate things you evaluate separately: the workspace is the hub, the launcher is the client that puts your local agents into it.

Installing the launcher and connecting a first agent

The README gives two install paths. The shell one-liner is the fastest on macOS and Linux, and the PowerShell equivalent covers Windows. Both fetch an installer from openagents.org rather than a package registry, so you are trusting that endpoint.

# macOS / Linux
curl -fsSL https://openagents.org/install.sh | bash

After that the `agn` command exists. Running it with no arguments opens the interactive dashboard, which is where the README says you install runtimes, configure API keys, connect to workspaces, and keep agents running as a background daemon.

The important detail is a trap the README calls out explicitly: `agn create` only writes the agent config. It does not install the runtime. Either install the runtime first or pass `--install` in the same step.

agn install <type>
agn create <name> --type <type> --install
agn env <type> --set LLM_API_KEY=sk-...
agn connect <name> <workspace-token>
agn up

Read that sequence as the full first-run path: install the runtime, create the agent with the runtime in one go, set credentials for that agent type, connect it to a workspace using a token, then start the daemon so the agent keeps running in the background. The credential step is per type, not per agent, which is worth noting if you plan to mix providers. The desktop app is the alternative to the CLI, with direct downloads for macOS, Windows and Linux AppImage, and all releases on GitHub.

Supported agents, and why the status column is the real spec

The README's agent table is the most useful page in the project, and also the one that should slow you down. OpenClaw, Claude Code, Codex CLI, Hermes Agent, Cursor, OpenCode, GitHub Copilot CLI, Gemini CLI and Amp are marked Supported. Cline is Supported (Beta). DeepSeek Harness is Preview, pinned to a preview release and running in headless mode. Aider and Goose are both Beta.

The Aider note is unusually candid and worth quoting in substance: the offline test suite covering provider resolution, sessions, Git safety and install detection passes, but a real end-to-end run against a live model provider has not been completed, and the create/connect flow is offered so you can run that verification yourself. That is a project telling you it has not finished validating the integration. If your workflow depends on Aider, you are the test.

The same caution applies to any Beta or Preview row. The table is not decoration; it is the boundary between integrations the maintainers consider working and integrations they consider unproven.

Shared files, shared browser, and tunnels

Three features do the actual collaboration work, and they are the reason a workspace is more than a chat window. Shared files mean an agent uploads code, docs or a report and any other agent or human in the workspace can read, edit or download it, so context moves through the workspace instead of through your clipboard. A shared browser lets agents open pages, click elements, take screenshots and fill forms in a browser everyone in the workspace can see, which is what makes a browser-using agent auditable rather than opaque. Tunnels expose a local dev server as a public URL with one command, so you can preview what an agent built from a phone.

The mechanism for directing work is deliberately light: @mentions to assign a task, or agents picking up work on their own. The second option is the one to think about. An agent that decides when to act, inside a workspace where other agents can also act, is a coordination model the README does not constrain. There is no described locking, ownership or conflict-resolution rule for two agents editing the same shared file. The README does not document rollback either. For a hub whose selling point is that everything is shared, that silence is the gap to test before you trust it with a repository.

Licence, packaging, and what upgrading costs

The project is Apache-2.0, and the README states there is no vendor lock-in and no mandatory accounts. Apache-2.0 permits commercial use and modification with the usual notice and patent terms; that is a description of the licence text, not legal advice, and if you redistribute a modified launcher you should read the LICENSE file rather than this paragraph.

The packaging is where upgrade cost lives. The Python distribution is `openagents` on PyPI, currently 0.9.3.post20, and pyproject.toml marks it Development Status 3 - Alpha with `requires-python = ">=3.8"`. The npm side is `@openagents-org/agent-launcher`. Because the launcher is the piece shipping releases (three in the weeks around the end of August and early September 2026), expect the client to move faster than the Python framework. The repository's last push was on 2026-09-09, so there is recent activity, but the Alpha classifier and the post-release version suffix both signal that interfaces can shift between minor versions. If you pin anything, pin the launcher version and the agent runtime versions together, because a runtime bump is the most likely thing to break a working connection. The setup.py also reveals a packaging wrinkle: the studio frontend is only bundled if a build exists at `sdk/studio/build`, otherwise the package prints a warning and users need Node.js to run the studio.

Where OpenAgents is the wrong tool

If you want one agent in one terminal, this is overhead. You install a launcher, run a daemon, obtain a workspace token and keep a browser tab open to reach something you could have reached by typing in the same window. The README's pitch assumes plurality: several agents, several machines, no single view.

A second case is stricter. If your requirement is a stable, versioned framework for building multi-agent systems, the Python package is classified Alpha and the release cadence is concentrated on the launcher, not the framework. Adopting `openagents` as a long-lived dependency means accepting that shape.

Finally, the Beta and Preview rows are a real boundary, not a formality. Choosing Aider or Goose means accepting that the maintainers have not completed a live-provider end-to-end run. That is fine for a personal experiment and questionable for a team workflow you cannot babysit.

Editorial conclusion

Adopt OpenAgents if you already run two or more terminal coding agents on different machines and want one browser-reachable place to watch them and hand them the same files. Skip it if you need a single agent in a single terminal, or if you need a stable, versioned SDK surface: the Python package is published as 0.9.3.post20 and pyproject.toml still classifies it as Development Status 3 - Alpha. Before connecting anything you care about, verify two things yourself: that the agent type you use is listed as Supported rather than Beta or Preview in the README table, and that `agn create <name> --type <type> --install` installs the runtime you expect, since `agn create` on its own only writes the config file.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openagents-org/openagents on GitHub
3. Project website
4. README
5. Releases