OpenRig can assign an agent a role. Who owns the result?

Imagine a developer asking one coding agent to fix an error on a payment page. Another agent is asked to review the change. Both terminals are still running the next morning, but the error has returned. Nobody can say which version was reviewed, whether the fix was released, or who accepted the remaining risk. Running two agents was easy. Giving each piece of work an owner, a record and a decision point was not.

OpenRig is an open-source system for operating coding agents such as Claude Code and Codex as a team. It has a local daemon, SQLite-backed state, tmux sessions, a command-line interface and a terminal dashboard. It does not replace the coding agents. It manages the system around them: where a session lives, which role it fills, how teammates communicate and how a team can be brought back after stopping. That is a useful foundation for work that extends beyond one prompt. It is not the same as proving a change is ready for production.

A conversation is not a task record

OpenRig describes a rig as a team and a seat as a stable role and address within it. Related seats can be grouped into pods. A builder might have one address, a reviewer another. The person or conversation occupying a seat may change while that address remains useful. This is more durable than naming terminals “agent one” and “agent two,” because work can be routed to a known role rather than an arbitrary shell window.

But addressing someone is only the first step. rig send can ask a specialist a quick question. If the reply resolves the question, there is no need to create a formal work item. A request that needs an owner and follow-up should be recorded differently. OpenRig’s rig queue provides a way to assign work to an address, have it claimed and track its progress. The project’s own documentation draws this distinction between sending a message and recording an assignment. Without it, “I told the reviewer” can be confused with “the review was completed.”

The difference resembles a normal engineering team. Asking a colleague in chat whether a library supports a feature is a conversation. Requesting a security review of a particular change needs a target, an expected output and a place for the decision to live. An agent can answer the first in a message. The second should survive after the chat window closes.

A stable seat also does not make old context permanently reliable. Dependencies move, requirements change and conversations accumulate assumptions. The ability to contact the same role tomorrow is valuable. It does not remove the need to check the current repository state and the precise version under review.

Follow the payment-page change

Suppose the error is limited to one validation branch. The human owner records how to reproduce it and what the page should show instead. The builder receives a bounded task: change that branch, add a regression test and report the commit or diff and test result. The reviewer receives a separate assignment pointing to the exact candidate. They inspect the behavior, look for adjacent cases and state whether the evidence is sufficient. If a case remains unresolved, the task should say so rather than treating silence as approval.

This workflow is possible with a small team. A builder and reviewer are enough to expose the handoff. What matters is not the number of seats but the connection between the task, the code and the decision. The builder’s terminal can show that code was written. The reviewer can send a message that sounds positive. Neither is a substitute for identifying which commit was examined and what tests ran against it.

OpenRig makes the team visible. Commands such as rig ps show running seats; the terminal UI helps an operator see how the team is arranged and which sessions need attention. That visibility answers an operational question: is someone working, waiting or stopped? It does not answer a quality question: is the payment behavior correct under the conditions that matter to customers? The code diff, test output and review record are separate evidence.

The final release decision matters for the same reason. Even a thorough review of a branch does not show that the deployment used that branch or that production configuration matches the test environment. For a high-impact change, the release gate needs an accountable human or an explicitly governed process outside a casual agent conversation.

Persistence has a boundary

OpenRig can maintain a team over time. Its documentation covers stopping a rig, snapshotting its topology and bringing it back by name. This reduces the work of rebuilding a coordinated set of terminals every morning. Yet persistence is easily overstated. A restored team is not proof that a half-finished command is safe to repeat. Before resuming work, the builder still needs to inspect the repository, uncommitted changes and the last trustworthy test result.

Access deserves the same caution. OpenRig’s documented setup and launch behavior can change workspace trust settings and provider integration files. Operators should inspect those effects before adoption and choose permissions for each role deliberately. A review seat does not automatically need deployment credentials. A builder that can write to a local repository does not thereby need authority to merge into the main branch. Team structure and access policy touch each other, but one is not a substitute for the other.

A narrow first test

A team considering OpenRig can test it with one small repository change rather than a large autonomous development program. Define the task in writing, identify who is building and reviewing, and name the evidence needed to close it. After the builder finishes, check whether the reviewer received the exact candidate, whether the test output can be traced to that candidate and whether unresolved questions remain visible. If those answers require reconstructing a chat transcript by hand, the coordination layer is not yet doing enough work.

Then verify three outcomes separately: the assignment has a recorded disposition, the change passed the agreed checks and the authorized person or process made the release decision. OpenRig can make the first handoff more durable and the team’s state easier to inspect. The latter decisions still need the organization’s own rules. The goal is not to make agents look like employees; it is to prevent the work they do from becoming an unowned series of terminal events.

OpenRig addresses coordination inside a coding team, while the question of where those agents sit in the wider company remains separate. For that organizational layer, agentic-organization is a self-hosted, file-based platform for managing AI agents as first-class members of an organization chart.