OpenGoat: hierarchical AI agent organizations on top of OpenClaw

What OpenGoat adds to a single OpenClaw agent

A single OpenClaw agent is one conversation with one context. OpenGoat's README frames the project as a way to build "herarchical organizations of AI agents" that coordinate work across Claude Code, Codex, Cursor, GitHub Copilot CLI and Lovable. The unit of work is a role, not a prompt: you create a CTO, an Engineer, a Designer, and each gets its own workspace, its own skill set and a reporting line. The README's own example provisions a project-scoped CMO at ~/.opengoat/projects/<project>/cmo, installs the agent-browser skill by default, and bootstraps that agent from the project URL.

The audience is narrow and specific. You need Node >= 20.11, an OpenClaw installation, and a willingness to run a local server. If you are happy with one agent and one thread, the org layer is overhead.

How the hierarchy, sessions and task board fit together

Three mechanisms carry the design. First, reporting lines: opengoat agent create takes --manager or --individual and a --reports-to flag, so the tree is explicit rather than implied by naming. Second, session continuity: the --session flag on opengoat agent keeps a named thread alive across invocations, which is how a planning conversation survives between commands. Third, a task board: opengoat task create assigns an owner and an assignee, and opengoat task list --as engineer filters the board by role.

Skills are the part worth reading closely. The README states that OpenClaw agents use role-specific board skills (og-board-manager for managers, og-board-individual for individuals), while non-OpenClaw agents use a single og-boards skill. That split tells you the board integration is deeper when the agent runs on OpenClaw, and thinner for the other tools the project advertises. Coordination across Codex or Cursor is therefore real but not symmetric with the OpenClaw path.

Installing OpenGoat and creating your first org

The README's install path is three commands: install both packages globally, run OpenClaw's onboarding, then start the UI. The server listens on 127.0.0.1:19123 by default.

npm i -g openclaw opengoat
openclaw onboard
opengoat start

If you prefer containers, the repository ships a Dockerfile and a docker-compose.yml that map port 19123 and mount a named volume at /data/opengoat. Note the compose file sets privileged: true and seccomp:unconfined, which is a broad permission grant you should weigh before running it on a shared host.

docker build -t opengoat:latest .
docker run --rm -p 19123:19123 -v opengoat-data:/data/opengoat opengoat:latest

From source, the monorepo uses pnpm and exposes the CLI through ./bin/opengoat. The README also documents a workspace shim for agents executing commands from their own workspace.

pnpm install
pnpm build
./bin/opengoat --help

Once the server is up, the first real use is creating a project and then a manager. The README's workflow provisions the project, creates a CTO reporting to the default agent goat, and adds an individual engineer under that CTO with a coding skill.

opengoat project create https://myproject.com
opengoat agent create "CTO" --manager --reports-to goat
opengoat agent create "Engineer" --individual --reports-to cto --skill coding
opengoat agent list

After that, work is dispatched by role rather than by prompt. The README shows a CTO being asked to plan a roadmap and split it into streams, and an engineer being asked to implement a specific piece of middleware.

Where OpenGoat gets in the way

The org model assumes you know the shape of the team before you start. Creating a CTO and two engineers is a design decision you make up front; the CLI has no documented way to reorganize an existing tree, and the README does not document rollback for a bad agent creation. If your work is exploratory, a single OpenClaw session is less ceremony.

The Docker path is the clearest limitation. The compose file requests privileged mode with an unconfined seccomp profile and a 4 GB memory limit, and the Dockerfile installs openclaw@latest at build time via an OPENCLAW_VERSION build argument. That means two builds of the same image tag can pull different OpenClaw versions, and there is no documented lock on that dependency. For a reproducible deployment you would need to pin OPENCLAW_VERSION yourself.

Maintenance is the other consideration. The last push to the default branch was on 2026-04-12, and the three most recent releases (v2026.4.12, v2026.4.12-1, v2026.4.12-2) all landed on that same day. That is a burst pattern, not a steady cadence, and the repository is not archived.

OpenGoat versus running a single agent framework directly

The closest comparison is not another orchestrator but the underlying tools themselves. Claude Code, Codex and Cursor each give you one agent with its own context and no shared reporting structure. OpenGoat's difference is that it treats the organization as the artifact: the tree, the task board and the role skills are stored and queried through the CLI, and the same board is visible to every agent in the org. You give up the simplicity of a single tool's native session handling in exchange for cross-tool coordination.

A second difference is the OpenClaw dependency. OpenGoat does not replace OpenClaw; the docs instruct you to install and onboard it, and the external gateway flow points at a WebSocket endpoint with a token. If your team has standardized on something other than OpenClaw, OpenGoat still lists other tools as participants, but the README's own skill split suggests those agents get the generic board skill rather than the manager/individual pair.

Licence, packaging and upgrade cost

The repository is MIT licensed, and the README repeats that at the end. The npm package is published as opengoat under the @opengoat scope for the monorepo packages. One detail deserves attention: the Cargo workspace that contains apps/desktop/src-tauri declares license = "Proprietary" and edition 2024 with rust-version 1.94. The desktop client is therefore not covered by the MIT terms that apply to the rest of the tree. This is a description of the files, not legal advice; if you plan to redistribute the desktop build, read the licence files yourself.

Upgrade cost is mostly the OpenClaw pairing. The CLI and UI ship from the same monorepo version (2026.4.12-2), and the release script sync-version.mjs exists to keep versions aligned. The unaligned piece is OpenClaw, which the Dockerfile pulls as latest unless you override OPENCLAW_VERSION. Pinning that argument is the one concrete step that makes a rebuild deterministic.

Editorial conclusion

Adopt OpenGoat if you already run OpenClaw and want a manager/individual structure with per-role skills and a task board rather than a flat chat session. Skip it if you need a stable, long-lived release line: the last push was on 2026-04-12, and the desktop client lives in a Cargo workspace marked Proprietary even though the main repository is MIT. Before committing, verify that your OpenClaw gateway version matches what openclaw onboard produces, and check whether OPENGOAT_DEFAULT_AGENT or defaultAgent in ~/.opengoat/config.json is the right place for your entry agent.

Frequently asked questions

Official sources

1. License: MIT
2. marian2js/opengoat on GitHub
3. Project website
4. README
5. Releases