Bring your agents into one working network

OpenRig runs a team of coding agents. Other agents and apps can join that team, hand it work, or be run by it, and you can add your own. Each entry below says how it connects, how to set it up, and how far it's been tested.

What the labels mean:

• Built in part of OpenRig.
• Since 0.7.x shipped in that release.
• Community example a starting preset. Each example has its own tested capabilities; see it for versions and limits.
• Experimental works, but is unsupported and off by default.
• Planned being designed; not in any release.

Connect an agent or app

Your app talks to the team: it reads its work, hands it tasks, and sees what needs you.

• Claude Desktop and other MCP apps built-in MCP server Add rig mcp serve as an MCP server in the app, and it uses your team's tools. We've run it with the chat agent in Claude Desktop's Chat tab and a local team. OpenRig can't wake the app itself, so it acts when you ask it to. MCP setup
• From another machine since 0.7.1 rig mcp serve --http with a token from rig mcp token add. You supply HTTPS, for example a tunnel. MCP setup
• Grok Bot and other hosted agents as team members since 0.7.4, experimental A hosted agent gets its own address on your team and works its own tasks through a grant service you run. We've run a Grok Bot this way. It's unsupported and off by default, and nothing wakes the member. Hosted members
• VS Code and Cursor extension 0.1.0, preview Join from your editor as a seat, hand work to the team, and see what needs you. It needs a local OpenRig. Open VSX · Marketplace
• The openrig plugin for Claude Code and Codex since 0.7.11 Hand work to your local team from your own Claude Code or Codex, follow it, answer the team's questions and read the result. In VS Code, Copilot CLI and Cursor it can't claim or answer questions. Plugin README
• Zed and T3 Code since 0.7.11 rig acp serve --to <member@rig> makes your team an agent in ACP apps: a prompt becomes a task, and the team's answer comes back as the reply. ACP agents
• ACP launcher since 0.7.11 @openrig/acp lets an ACP app start your team with npx; it runs the matching rig acp serve, and it's on npm at the same version.

Add a coding harness

OpenRig runs these agents as seats on your team, each with its own terminal, role and tasks.

• Built in Claude Code, Codex, Pi, and Oh My Pi (contributed by @MelonSmasher). Set runtime: in your rig. Getting started

• Community examples

  • Cursor Agent CLI (since 0.7.1);
  • Hermes Agent (since 0.7.1);
  • OpenClaw, local and Gateway (since 0.7.1 and 0.7.2);
  • Pi's terminal UI (since 0.7.5);
  • DeepSeek Harness (dsh) through its example runner (since 0.7.8).

  Each is a preset to start from. Community examples have different tested capabilities; see each example for versions and limits. Examples

• dsh-seat by @bpamiri is a separate runner for DeepSeek Harness, in its own repo: github.com/bpamiri/dsh-seat.

• Hand one task to another agent:

  • rig acp run gives a task to an ACP agent such as openclaw acp (since 0.7.1).
  • rig exec run <task> --harness claude|codex runs a task as one turn through the Claude Code or Codex ACP adapter (since 0.7.10). The agent reports; accepting the work stays with you.

  ACP agents · A2A recipe

Run agents somewhere else

• Execution-platform contract draft, since 0.7.6 How an environment like a sandbox or VM can host OpenRig seats. The generic seam it proposes isn't built yet. Contract
• NVIDIA OpenShell reference driver, since 0.7.8 Its cleanup now works on OpenShell 0.1.6; the worker isn't ready to rely on end to end yet. README

Stay in the loop

• Slack since 0.4.7 Asks and decisions in your channels. Slack setup
• ntfy and webhooks built in Notifications to a phone or any URL.
• Relay gateway connector since 0.7.11, experimental Connect other messengers: OpenRig sends questions, updates and notices to a bridge you run and takes replies back. It's off by default, and the bridge is yours. Contributed by @smota. Relay

Decisions

• Decisions on incoming work since 0.7.1, experimental When new work arrives on a stream, an intake agent can ask a decision model to sort it: open a task, join one that already exists, or record that nothing's needed. Answers it can't use stay with the agent. It calls OpenRouter's decisions endpoint with your OpenRouter key, and you can edit the choice templates. It's off by default, with no accuracy guarantee. Stream decisions
• Your own decision provider planned A plugin contract so anyone can add a decision provider. It isn't in a release yet, and this page will say when it is.

Bring your accounts and keys

• Your coding agents' subscriptions. Sign in to Claude Code or Codex the way you normally do, and OpenRig's agents use that login. One account is enough to start. Choose your providers
• More accounts as the team grows since 0.7.2 Give a seat its own prepared account, and move a running seat to another one with rig provider switch. Switching within the same account folder keeps the conversation; moving to a different one starts a fresh conversation with a handover. A Claude seat can also switch to an API key file. Codex's same-folder switch is Linux only. Accounts and switching
• More machines. Sign in on each machine that runs agents. OpenRig doesn't copy logins between machines or spread work across accounts for you. rig provider status --all-hosts shows the usage your machines report (off by default). Account folders
• API keys. A feature that calls an API reads its key the way its guide says. Decisions, for example, read OPENROUTER_API_KEY from the environment of the process that runs them; keeping a key file in a folder doesn't set it. OpenRouter gives that feature a model to call. It doesn't manage your subscriptions.

Build your own

The quickest way in is to start from something that works.

1. Pick a starting point. Copy a community example, or the dsh example runner if you're building a runner.
2. Read the contract. The harness and runner contract covers what OpenRig asks of a harness: how it declares itself, reports activity, takes input, handles cancel and permissions, and resumes. The author contracts cover the rest.
3. Run the conformance check. runner-conformance tests your runner against the contract's checked protocol cases. A pass means it passes those cases. It doesn't run a real agent or model, and it isn't certification.
4. Talk to us, then send it. Open an issue to agree scope, then a pull request. We credit every contributor in the release notes.

Running agents in a new kind of environment? Start from the execution-platform contract and open an issue first. The generic seam is still a proposal, so we'll shape it with you.

Who maintains what:

• OpenRig's maintainers own the built-in runtimes and the contracts.
• A community example is maintained by its author.
• An integration's label changes only when a run is recorded in a named release.
• Parts of the contracts are still drafts, so a proposed interface isn't a promise that it exists.

Thanks to the people who've built OpenRig integrations: @MelonSmasher (Oh My Pi), @bpamiri (dsh-seat), @smota (relay gateway), and everyone credited in What's new.