Case study
One engineer, a factory of agents
Taylor Gagne is the principal engineer at Turing Labs, a YC-backed company building AI for consumer-product R&D. On the side — and increasingly not on the side — he has been building Cybertron: a spec-driven orchestrator that takes a task, decides which model and which harness should do it, and dispatches it. Cybertron is his. The layer underneath it that actually runs the agents, on whichever of his machines has capacity, is agi-cli. This is how the two fit together, in his words and his screenshots.
Muqsit Nawaz · Published July 29, 2026
The idea: route the task, not the tool
Taylor did not start from a tool. He started from a scheduling problem. In April, months before any of this was wired together, he described what he wanted to build:
“I want to try and build an intelligent router or task assignor agent that takes a ticket understands the context then assigns it to the best model + harness for the job.”
The word doing the work there is harness. Not “model.” He had already concluded that the choice of Claude Code vs Codex vs Droid was a routing decision on par with the choice of Opus vs Sonnet — and that a system worth building had to treat both as variables:
“Yeah I want the execution layer to run basically any harnesses.”
That single requirement is the reason this case study exists. An orchestrator that can only drive one vendor's agent is a wrapper. One that can drive all of them needs something underneath it that speaks every harness, and that is the gap agi-cli fills.
What Cybertron is
He named it after the Transformers planet — “My factory is named Cybertron like transformers lol” — and the design is stricter than the name suggests. It is spec-driven by construction: a task cannot exist without a spec, and a spec is what the reviewer grades the finished code against. Around that sit a memory system for durable knowledge (implementation patterns, failure cases, codebase conventions), a routing engine that ranks agents on observed success rate and latency, and an always-on backlog orchestrator with budget caps, rate limits, and quiet hours.
It is not a toy. It reviews its own pull requests, blocks the merge when the review is damning, and lets another agent fix the finding before the merge is allowed through.
[cybertron-review] verdict: request_changes — Cybertron's reviewer catching a leaked setInterval and a block of unreachable dead code in Cybertron's own daemon, with the fix attached as a suggestion.Where agi-cli sits
The clearest description of the split is his own, and it is worth reading twice because it is a precise statement about layering:
“Because the factory is like harness++ but it needs harnesses to call into — agi-cli provides more factory useful features than vanilla Claude Code.”
A factory is not a harness. It is the thing above harnesses — but it is useless without something to call. Cybertron owns specs, routing, memory and review. agi-cli owns everything below the routing decision: which binary to launch, which account to spend, which machine to run it on, where the transcript goes, and how the credentials get there. By July he put it plainly: “I think the current cybertron codebase relies on agi-cli.”
The traffic runs both directions. He is pulling agi-cli's primitives up into his own UI — “You know I’m just gonna start putting UI wrappers in cybertron on different agents features lmao” — and wiring its extension points in underneath: “Connecting more and more of agents hooks and skills [in]to cybertron.” Even the parts of his setup that are not Cybertron are built the same way; his GitHub monitoring, he notes, “is agi-cli + the fleet.”
Every machine he owns
The step that turned this from a program into a factory was mundane. On July 4 he installed the CLI everywhere and put the machines on one network:
“I actually setup my agents cli plus tail scale on all my computers so might have a fun week.”
After that the machines stop being separate. Work goes to whichever box is free, by flag — “Yeah I told it do a swarm:plan on one of my other hosts” — and when a dispatcher started favouring one account too hard, the fix was a sentence, not a scheduler rewrite: “Had to tell it to load balance with agents when it dispatches.”
Capacity, for him, is measured in subscriptions across vendors rather than in seats:
“I’ll be at 4 claude max + 1 codex max + droid(factory) max + grok max.”
Four Claude accounts, plus Codex, plus Droid, plus Grok — pooled behind one CLI, on a fleet that includes his laptop, Linux desktops, and, memorably, a Windows racing-sim rig that turned up in the fleet stats. That is the shape of the problem agi-cli was built for: multi-vendor and multi-machine, not one or the other.
What it looks like running
Because every harness writes its transcript to one indexed store, Cybertron can render them all in a single timeline — Claude sessions and Codex sessions side by side, headless runs alongside interactive ones, each with its worktree and its live status.
The same plumbing shows up in smaller moments. When he asked an agent to check Datadog for a bug and there was no Datadog MCP server wired up, it did not stop:
“Told sol to check data dog to do a bug fix was like no data dog mcp cracked open agents browser logged in to data dog and read the logs lol.”
The honest ceiling
The most useful thing Taylor said about running agents at scale is not a feature request. It is a warning, and it cuts against the marketing of everyone in this category, including us:
“I think the bulk of people actually get stuck at 2-3 agents tbh. And actually I think most companies seem to think that all their engineers can operate with the 5+ agents swarms and do magic product speed but in reality most can’t really operate like that because most aren’t used to the rapid context switching.”
The bottleneck is not tokens or machines. It is the human being asked to hold five parallel threads of work in their head. Even Taylor, who is about as far along this curve as anyone we talk to, hits a wall he describes in the plainest possible terms: “Starting to get a bit slow running 7 agents lmao.”
Which is a decent argument for why he is building Cybertron at all. If a person tops out somewhere around three agents, the way past three is not discipline. It is to give the context-switching job to a program — a spec to grade against, a router to assign the work, a reviewer to block the bad merge — and let the human read the summary.
He sends the patches back
The part we did not expect: when agi-cli was missing something Cybertron needed, he wrote it. Four of his changes are merged, and the largest one exists specifically so an orchestrator like his can target machines directly.
| Merged | What it does | Size |
|---|---|---|
| #1122 | Hosts become first-class run/task execution optionsso a dispatcher can send a task to a named machine | +1712 / −152 |
| #1231 | Surface Claude org identity (type + team name) per accounttells four signed-in accounts apart | +317 / −9 |
| #1183 | Droid usage bars via the Factory billing limits APIcapacity you can see before you dispatch | +255 / −31 |
| #1232 | Show every blocking window in the compact usage bars5-hour, weekly and monthly limits at a glance | +34 / −8 |
Read the list in order and it is a single story: a person building a router needed to know, at dispatch time, which machines exist, which accounts are which, and how much capacity each one has left. Every one of those is a routing input. The orchestrator on top made the requirements obvious, and the fixes landed in the layer where they belonged.
Try it
Cybertron is Taylor's. The layer under it is open source, and it is the part you can have today: one CLI that installs and runs every harness, pools your accounts, dispatches to any machine on your network, and writes every transcript to one searchable place.
curl -fsSL agi-cli.sh/install.sh | shQuotes are Taylor's own, published with his permission, lightly trimmed for length and never for meaning. Screenshots are his, with one internal workspace path masked.