I got tired of babysitting coding agents

Brasth — Fri, 18 Sep 2026 04:20:40 +0000

I love coding agents. I also got tired of being their night-shift project manager.

The loop looks familiar:

prompt → wait → almost right → correct → wait → open a second agent → they step on the same files → exit 0 → you still will not merge.

That last part is the one that broke me. Process finished. Tests maybe green in the agent's story. Diff still not something I would put on main without another human pass. I was paying twice: once for the models, again with my attention.

So I built Rig.

Not another coding agent

Rig is not a chat box that "codes for you." It is the harness between agents you already use.

You keep talking to a parent CLI (Codex, Grok, OpenCode, and friends). When the work is real (fix, implement, change code), the parent does not dump your messy thread into another model and pray. It turns intent into scoped work. A worker runs that work over MCP. The parent then verifies with real checks. Done means verified, not exit 0 vibes.

If one agent in one thread is enough for your life, you do not need this. Rig is for people who already bounce between tools, already try parallel work, and already got burned by "it said done."

How it works (short version)

The spine is boring on purpose:

Parent scopes files. Owned paths, not "edit whatever looks related."
Parent writes a brief. Change / don't-change / acceptance. The child works from that brief only. Your parent chat is not forwarded as the child prompt.
Worker runs over MCP. Handoff is tool calls and job state, not copy/paste between terminals.
Parent verifies. Requirements, checks, accept. Exit 0 is execution. Verified is acceptance against what you asked for.

That last step is the product. I do not want another agent that feels finished. I want a control plane that refuses to call it done until checks pass.

Adaptive workflows (default)

New default behavior: when the work should split, the parent owns a DAG of disjoint workers. Parallel only when file (and resource) scopes do not overlap. Children never spawn children. The parent advances the graph, handles ASK/allow/deny, and alone marks the workflow verified after its own checks.

So parallelism stays under the parent instead of a pile of nested agents inventing more agents. You can still run single-job mode if you want; adaptive is the default in .rig/harness.toml under [orchestration].

Watch it once

Failing taskboard
Codex parent
Rig TUI
Grok worker over MCP
Parent verifies
Tests green

Demo: https://youtu.be/KuhHMH--oGk

Repo: https://github.com/Brasth/Rig

Quickstart (edit the harness, then type normally)

curl -fsSL https://raw.githubusercontent.com/Brasth/Rig/main/install.sh | bash
cd your-repo
rig init
rig doctor

Prefer configuring parent and workers in .rig/harness.toml:

parent = "codex"

[workers]
codex = false
grok = true
claude = true
cursor = false
opencode = false
omp = false
pi = false
agy = false
devin = false

[orchestration]
mode = "adaptive"
max_nodes = 12

Enable only workers you actually have installed. Fully quit the parent once after install, open a new thread in that repo, and type a normal prompt (for example: Fix the failing tests in tests/test_cli.py). Do not use rig run for everyday work.

Questions stay on the parent. Side ideas can park in the queue without derailing a live job. Jobs and file ownership live under .rig/ in the repo, not in a chat you already lost.

If the pain matches

I built Rig because I was tired of babysitting. Same models. Less glue.

Free and open source: https://github.com/Brasth/Rig

Demo again if you want the one-minute version: https://youtu.be/KuhHMH--oGk

I am on X as @brasthapp if you want to yell at the founder about MCP or verification.