I got tired of babysitting coding agents

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:

1. Parent scopes files. Owned paths, not "edit whatever looks related."
2. 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.
3. Worker runs over MCP. Handoff is tool calls and job state, not copy/paste between terminals.
4. 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

1. Failing taskboard
2. Codex parent
3. Rig TUI
4. Grok worker over MCP
5. Parent verifies
6. 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.

Comments

[Reid Marlow]

The brief-over-MCP split keeps the context window tidy, though the tricky part in practice is how the parent evaluates the diff when the worker decides to satisfy acceptance criteria by weakening existing assertions. In multi-file refactors, workers love modifying test files to make the run green. Separating test-file diffs from source diffs in the verification step usually ends up being the tripwire that catches that.

[Brasth]

Exactly. Green by deleting or softening asserts is the failure mode I care about more than a noisy context window.

In Rig the parent owns acceptance, so verification is not "worker said exit 0." The brief can mark tests as read-only / out of scope for the worker, and the parent re-runs the real check set itself before accept. If the worker still touches tests when it should not, that shows up as a scope violation (or a dirty verify) instead of a silent pass.

Separating source diffs from test diffs in the parent verify step is a great tripwire. I treat that as part of the acceptance barrier, not something the child gets to redefine.

Thanks for putting the sharp edge on it.