I do not use one AI assistant. I run a small engineering team made of agents.
I write the ticket. A coding agent picks it up, does the work, and opens a pull request. A reviewer agent reviews it. I read the result and approve what ships. My time goes to deciding what to build and judging the outcome, not typing every line.
Two pieces make this work: T3 Code as the place where the coding happens, and Grok Bots as the team that drives it.
The team
Each role is one bot with one job:
- Leads that coordinate the work,
- coders that run the coding threads,
- a reviewer that checks every pull request before I see it,
- ticket writers that prepare the work,
- a Linear sync that keeps the tracker current,
- an inbox and a daily prep that keep me oriented.
Splitting the work into roles matters more than any single prompt. A bot that only reviews is a better reviewer than a bot that also wrote the code. And when something goes wrong, I know which role to fix.
Where the code gets written
T3 Code is an open-source app for running coding agents such as Codex and Claude Code. Work happens in threads, threads belong to projects, and a project is a folder on my machine. The agents run where my code, tools, and credentials already live.
The bots never need to know how T3 Code works inside. They go through its command line.
The contract: t3 thread
A team of bots needs a small, stable surface, and the t3 command line already has one:
t3 thread start --json . "Implement the ticket and open a pull request"
t3 thread show --messages 3 <thread-id>
t3 thread send <thread-id> "Address the review comments"
t3 thread list --project .A few details in that surface make it a good fit for agents driving agents.
send never interrupts. If a coding agent is busy, the message becomes its next turn. A lead bot cannot cancel work halfway through by accident.
--wait has honest exit codes. It exits 1 when the run fails and 2 when the agent is waiting for an answer. "Needs an answer" is its own state, and the team treats it that way instead of reporting success.
--json gives data, not prose. State comes back structured, so nothing has to scrape text written for humans.
--worktree isolates a run. A thread can start in a fresh git worktree from a branch, so parallel tickets do not trample each other.
Because every action is a command, I can run any step by hand. When the team does something surprising, I type the same command and see exactly what the bot saw.
Where I stay in the loop
The approve step is mine. Everything before it can be automated: the ticket, the code, the review. Everything after it is a decision with consequences, so it waits for me.
That split is what makes the setup trustworthy. Agents are fast and tireless, and they are also confidently wrong sometimes. A second agent catches a lot of that. I catch the rest.
A public bot
I published a public Grok Bot that runs T3 Code from chat on your own computers through the t3 command line. It starts and checks coding-agent threads and handles project setup. It is the simplest version of the idea: one bot, one machine, a chat window.
What I learned
Roles beat one big assistant. Small bots with narrow jobs are easier to trust and easier to fix.
Use the seam that already exists. The command line was built for scripts, and a bot is a script with judgment.
Design for "needs an answer". Agent runs end in three states: done, failed, or waiting on a human. A system that cannot tell the third state apart wastes the human's time.
Keep the human on the decision. Automate everything up to the approve button, and nothing past it.