How CoLateral Is Built with AI Coding Agents

Every task gets its own agent, branch and worktree, a single Integration Agent is the only thing allowed to land the work, and scheduled loops hunt bugs on a timetable. This note describes how that works, from the rules the repository records, including the parts that have gone wrong.

Key takeaways

• As of 7 October 2026, 2,856 of the 6,227 commits on CoLateral's main branch (about 46 percent) carry a Co-Authored-By trailer naming Claude, so AI coding agents wrote a large share of CoLateral.
• CoLateral's repository gives every coding task one owner agent, one branch, one worktree and one pull request, and coding agents never merge their own work.
• CoLateral's Integration Agent is the only thing that puts ordinary feature work on main, and it validates the combined result itself instead of trusting an agent's earlier passing run.
• CoLateral registers twelve recurring agent loops, one of them switched off, each with a stated cadence, budget and model policy, including a scored bug-hunt called the nightly gauntlet.
• All of CoLateral's rules for coding agents live in one file, AGENTS.md, which is kept under 300 lines and routes to 33 topic files.

Is CoLateral really built by AI coding agents?

A large share of it, yes, and I can show the count rather than assert it. As of 7 October 2026 the main branch holds 6,227 commits, and 2,856 of them carry a "Co-Authored-By" trailer naming Claude. That figure records where an agent signed its work, not how much of each change a human directed or reviewed, so treat it as a measure of visible agent involvement and not as a split of credit.

commits with a Claude co-author trailer

2,856

commits on main

6,227

test files in the tests folder

1,498

registered agent loops, one switched off

12

Agents are fast and they overlap, so most of the repository's rules exist to keep them from stepping on each other. I cover the livestreams, where the work happens in the open, in building CoLateral in public.

How does one founder run many coding agents at once?

By making the unit of work small and the rules mechanical. The workflow document opens with them: "One task is one branch, one worktree and one PR. Coding agents never merge." In order:

1. Start. The agent begins with `npm run task:start`, which cuts a fresh branch from the latest main, never from a stale local copy, into its own worktree.
2. Work. It changes only what the task asks.
3. Submit. `npm run task:submit` rebases onto the latest main, runs the validation gate, pushes the branch and opens the pull request. If the rebase conflicts it pushes nothing and lists the files.
4. Stop. The coding agent does not merge. It reports the pull request number and the exact checks it ran.

Agents must claim ownership of their files before overlapping work and never reset, stash or clean another agent's checkout. Intake is limited to six unfinished ordinary pull requests before another feature starts, which the document calls "coordination backpressure".

What does the CoLateral Integration Agent do?

It is the only gate between an agent's branch and main. A scheduled task on my Windows machine runs it every ten minutes while the machine is awake and I am signed in. Each pass takes open, non-draft pull requests oldest first and sorts them: safe to integrate, needs rebase, needs human review, or duplicate. A merge that is clean can still be wrong, and the repository says so with a specific case: "A clean merge can still revert newer work (PR #1479 did)". So when main changed the same files since a pull request began, a person or the Claude Integration Agent reads it first.

It validates the combined state itself, and an agent's own green run does not count. A failure records the exact pull request head, the main commit and the failing tests, and leaves main untouched. The workflow is blunt about the rest: "No test is skipped to land a PR."

Some paths never auto-land. A short list covers the money path, the desktop shell, the agent runtime and persistence, for a reason I would give myself: "These are the places where a plausible-looking green patch does the most damage". A pull request touching them waits for me with a needs-nic label.

What is the nightly gauntlet?

The gauntlet is a scheduled cloud agent that runs a scored bug hunt against a backup of the repository. Its runbook gives it roles: an orchestrator, and subagents named Scout, Reproducer, Surgeon, Adversary and Judge. Surgeon, the role that writes the patch, runs on Opus because "that is where a wrong patch costs the most"; the others run on Sonnet. It files issues labelled `agent-found` with a severity from S0 (critical) to S3 (cosmetic) and opens `agent-fixed` pull requests, but never merges anything. The desktop release notes for versions 1.0.63 through 1.0.69 are each headed "Nightly gauntlet fixes".

It also taught me what unbounded agents cost. The runbook records that before 2026-09-08 the gauntlet ran nightly with an iteration cap of 8 and no subagent ceiling, and "its sessions lasted four to forty-seven hours against a stated two-hour budget". It now has three iterations, twelve subagents and two nights a week.

What are the CoLateral agent loops?

The gauntlet is one of twelve recurring runs in a registry file, `agents/LOOPS.md`, which is the one place cadence, budget and model policy live. Slowing or pausing a loop is an edit to a row. As of this writing:

The model policy is short. The orchestrator does the cheap work itself and delegates only work that changes code, one subagent per independent item, up to a stated ceiling. Every report ends with a line giving agents used against agents allowed, so an overrun shows in the report rather than on a bill.

What goes wrong when AI agents build a product?

Plenty, and the repository keeps the record. Three examples:

• A quiet night that was not. A loop killed by a usage limit exits in seconds and was still logged as finished. The loop documentation counts six of eleven runs across two days in early September dying this way, and its heading says it plainly: "A run killed by a usage limit still logs as done".
• Work that never left the branch. A usability run on 2026-09-05 committed a harness and six tests to a local branch, spawned five background agents and ended its turn to wait. The run stopped 22 minutes into a 180 minute budget and the branch was never pushed. The rule that came out of it: push before you spawn helpers.
• Finished is not landed. The Day 54 recovery audit, written after interrupted agent sessions, says it directly: "A committed task or a prompt sent to a replacement agent was not evidence that the changes reached main." AGENTS.md carries the same lesson: a card saying Finished "is not an owner release or proof that a task ran".

One measurement shaped a rule. The explore-versus-execute note counted 5,995 Claude Code transcripts on one machine on 2026-09-09 and found agents spending minutes exploring before changing anything. The rule it produced is now in AGENTS.md: "A change is Grep plus Edit."

What rules do the coding agents follow?

One file. The CLAUDE.md in the repository is a pointer, and it says why: "AGENTS.md is the single source of truth for every coding agent working in this repo (Claude Code, Codex, and anything else)." AGENTS.md is deliberately kept under 300 lines, enforced by a test, and anything topic-specific goes into one of 33 files under `docs/agents/`. Its own guidance for editing it is a sentence I like: "Adding a paragraph here is a decision to spend that paragraph on every session in the repo, forever."

One safety rule shapes the product as well as the process: AGENTS.md requires human approval before any agent writes project-critical data or sends email.

How does this connect to the CoLateral product?

The product and the process share a problem: several agents, one human, one shared state. CoLateral puts coding agents like Claude Code and Codex on one Project Canvas, and the workflow notes that CoLateral sessions claim task worktrees while their terminal process runs. The resource guard, which limits how many agents run at once and puts the oldest to sleep first, exists because opening a project with eight agents on it used to start eight CLI processes before anything had been asked of them, and I asked for a setting that limits that.

For the agents CoLateral itself runs and how each got there, see AI agents in CoLateral. For the wider story of how the product reached this point, read the history of CoLateral. To try the workspace, download CoLateral; the About page has the livestreams and the Discord if you want to ask how any of this works.