Agentic Harness Explained: Agent Coordination in Software Teams with OpenRig

Agentic Harness Explained: Agent Coordination in Software Teams with OpenRig

Over the past three days, we’ve examined harnesses designed to manage agents at different scales and in different contexts. Buzz approached agent discovery and collaboration through a social protocol. Hermes provided a framework for running single agents on a machine with durable memory and tool inventory. Cloudflare Agents SDK was designed for global scale, supporting thousands or millions of agent instances.

Today we address a different challenge: in a software development team, multiple coding agents must work together on the same project, alongside humans. Code must be written, reviewed, tested. All from the same git repository. How do you organize this?

OpenRig is the harness for that problem.

The Problem: Agent Chaos in Software Development

A typical scene in a software project:

Morning. The developer’s screen shows many terminal windows. Each represents an agent or task:

This “terminal sprawl”—the proliferation of disconnected terminal windows—is the root of the problem. The machine reboots, terminal windows close, and context is lost. Which agent was doing what? What did it do yesterday? If an error occurs, is there a record?

OpenRig transforms this chaos into an organized system.

OpenRig’s Architecture

At OpenRig’s core is a principle: each agent is a “pod” (capsule), and pods form a “rig” (team). The team is defined in YAML, stored in version control, and run via tmux.

A simple example:

rig:
  name: "blog-engine"
  pods:
    - name: "writer"
      harness: Claude Code
      model: Claude 3.5 Sonnet
      context: 200k
    
    - name: "editor"
      harness: Codex
      model: Claude 3.5 Sonnet
      context: 100k
    
    - name: "test"
      harness: pytest-runner
      context: 50k
  
  edges:
    - from: "writer"
      to: "editor"
      channel: "review-feedback"
    
    - from: "editor"
      to: "test"
      channel: "approved-code"

You start with:

rig up blog-engine --cwd .
rig tui

OpenRig launches tmux sessions. Each pod gets its own terminal pane. Data flows between them via defined channels. The YAML file is committed to git; the team structure is versioned.

Why It’s Special for Software Development

What sets OpenRig apart from other harnesses is that it’s designed specifically for the needs of software development teams:

1. State persistence: Close an agent’s session while it’s working, its state (chat history, completed tasks, libraries, data) is saved. Open it hours or days later, it resumes from where it left off. Like Hermes’s memory, but at the team level.

2. Terminal visibility: Via tmux’s visual terminal management, you see in real time what each agent is doing. If an agent goes silent for too long, you know which one. No more guessing across five unmarked windows.

3. Channels and flow control: Pods have defined outputs and inputs. The writer’s output goes directly to the editor. Test results trigger feedback. The flow is explicit and documented.

4. Auditability: Every step an agent takes, its output, its error messages—all recorded. A week later, when you ask “who coded this feature, why did the test fail?”—the answer is in git history and OpenRig logs.

5. YAML-as-code: The team structure is defined as code. Adding an agent, removing one, changing connections—all via YAML edits, commits, and pushes. Documentation and code are one.

Scenario: A Day in a Software Team

Late afternoon, you’re building a blog engine. Two agents:

You open OpenRig’s terminal UI:

┌─ rig: blog-engine ─────────────────────┐
│ writer [ACTIVE] | editor [WAITING]     │
│                                        │
│ context: 45k token | context: 0        │
└────────────────────────────────────────┘

You send a task to the writer:

rig send writer "Write a function to parse markdown frontmatter"

The writer starts. It writes code. OpenRig records the output.

When finished:

rig forward writer editor

OpenRig pipes the writer’s output to the editor’s input channel. The editor reviews. If satisfied, it forwards to the test pod. Tests pass. Merge to master.

The machine reboots. The rig restores state from disk. No one loses any context.

Agent Coordination in Organizations

In a software company, you might run 5 or 10 different software agents. Without OpenRig, each is an isolated terminal process. With OpenRig, all can be defined as a single rig, all work from the same code repository, all are visible and auditable.

The project manager’s questions get answers:

OpenRig supplies answers via YAML (team definition) and logs (operations).

Comparison to Other Harnesses

OpenRig’s strength is that it aligns with how development teams naturally work. Code, review, test—tmux-based, YAML-defined, state-persistent.

Its scope is narrower: it lacks Cloudflare’s global reach and Hermes’s generality. But for a development team’s daily workflow, it delivers precisely what’s needed.

Conclusion: Four Harnesses, Four Problems

Four days, four open-source harnesses. All address agent execution, but each solves a different problem:

Which harness you choose depends on your problem. But once you pick one, a larger question emerges: how will these agents fit into your organization’s structure? What policies will they follow? How will they coordinate with each other?

The answer lies in agentic-organization—a self-hosted, file-based platform that manages agents as organizational members. While OpenRig provides the software team coordination that Buzz’s social discovery and Hermes’s management enable, and Cloudflare provides scale, agentic-organization binds them all into an organizational structure. Agents become institutional actors, not tools that expire.