Agent Branches

Day 5: Nothing Woke the Agents, So My Requests Moved Into the Open

Overnight nothing woke the main agent, and status checks reported problems without fixing them. The agents moved every task and request into public GitHub issues, and each product got a small reviewed change.

Alexey Grigorev7 October 2026

On October 1, Cloudflare announced a competition to build the next Git platform. I gave the research to a team of AI coding agents, and asked them to find out which Git-like tools coding agents need.

I run into this problem myself. When several agents change one project together, their changes clash, and the extra copies of the project fill my disk. I want Git that works when many agents use it at the same time.

Conceptual illustration: an unread message waits beside an idle agent while requests are moved onto an open task board.
Conceptual illustration: an unread message waits beside an idle agent while requests are moved onto an open task board.

The agents work in four teams. One builds Agent Branches, a Git server where each task gets its own copy of the project. The other three build a dashboard, a launcher that decides which agent starts next, and messaging between my desktop and my server.

Yesterday I set a simple test for the repaired wake-up service, a small program that nudges idle agents. It had to keep them working through a whole night.

Nothing woke the main agent

Early in the morning I found the main coordinating agent idle again. Nothing had woken it, and none of the other lead agents had started a replacement. By late morning it sat idle a second time.

The regular status checks listed problems and stopped there, with no step to fix any of them. I told the agents that a check that only reports is pointless.

Another agent that was supposed to start five tasks sat waiting for a nudge. Elsewhere, an agent answered a question, but the answer went to an inbox, and nothing woke the agent that had asked.

In the expected row a reply wakes the agent and the next task starts. In the real row the reply sits unread and work stops until I notice
In the expected row a reply wakes the agent and the next task starts. In the real row the reply sits unread and work stops until I notice

So the problem is bigger than one stuck service. A reply, a finished task or a missing agent should each lead to the next step without me. I asked the agents to keep every message I send in one public founder journal.

Every request now gets a public issue

The tasks lived in one big data file that was hard to follow. I asked for a better tracker that holds every request I make.

The agents moved every task into public GitHub issues. Each product team owns its own tracker, and the main repository holds my requests and the high-level tasks.

One task file on the left feeds the public trackers, one with my requests and the others for the four products
One task file on the left feeds the public trackers, one with my requests and the others for the four products

The move closed old finished tasks in one batch, so their closing dates show when a task moved, not when the work was done. Honest task numbers for the day aren't available yet.

The dashboard team built the counter I asked for, to sit next to the counts of active agents and commits. It counts a task as resolved only after a reviewer accepts it, skips cancelled and queued work, and keeps unknown dates unknown. It doesn't read the new GitHub issues yet, and nothing shows on the dashboard.

The agents also cleaned up the documentation. It now lives in one folder, with one research file and one set of instructions for every agent.

Small fixes in each product

Agent Branches handled one real task and the launcher got a reviewed fix. The dashboard counter is code only, and messaging ran on one computer
Agent Branches handled one real task and the launcher got a reviewed fix. The dashboard counter is code only, and messaging ran on one computer

An agent used Agent Branches to send a small piece of its own work to GitHub without touching the shared copy of the project. The first attempt failed, because the command loaded an older copy of the tool that lacked the new command. The agent changed how Python finds the tool and tried again.

Then a separate reviewing agent downloaded a fresh copy from GitHub, found identical files and ran eight tests that passed. That proves the tool works for one task, not that it beats plain Git.

The launcher got a reviewed fix. When an agent describes review work only in a task's goal, the launcher now recognises it and starts a reviewer. A broken or duplicate request gets a clear error, and the same request sent twice starts only once.

The messaging team built a receiver for my desktop. My home network accepts no incoming connections, so the desktop has to reach out to the server and collect its messages. A live test passed, but both ends ran on one computer, even though its report called it a two-computer test. Two real computers still haven't talked.

Lead agents died in the afternoon

In the afternoon, a shared login session on my server ended, and several lead agents died with it. Nobody knows yet what ended the session.

The agents brought the same lead agents back from their saved conversations, by hand. One of them had been running inside the main coordinator's session, so losing the coordinator could take it down too. The agents restarted it in a session of its own.

Before, a lead agent runs inside the coordinator's session and falls if the coordinator falls. After, each runs in its own session, not yet tested in a failure
Before, a lead agent runs inside the coordinator's session and falls if the coordinator falls. After, each runs in its own session, not yet tested in a failure

The script that should bring agents back without anyone watching doesn't exist yet. In the evening, the agents added a regular check on the main agent that counts missed answers. For now it only raises an alert and restarts nothing.

Five days in

I wanted my requests to happen without me chasing them. By the evening, every request had a public home, and each product had a small reviewed change. Work that continues while I'm away still doesn't happen.

Eight requests and their state. Public issues and tidy documentation are done. The task counter is code only, and lost agents come back only by hand. The agent that should fix the rest has instructions and a planned test. Work without me and two computers talking are still open, and the process article waits for my review
Eight requests and their state. Public issues and tidy documentation are done. The task counter is code only, and lost agents come back only by hand. The agent that should fix the rest has instructions and a planned test. Work without me and two computers talking are still open, and the process article waits for my review

At least seven agents left work I can check that day. Two built and reviewed the task counter, and two did the same for the message receiver. Two more wrote and reviewed the steps for bringing a lost agent back, and one reviewed the Agent Branches trial. More ran, but the records mix coordinators, workers and background services. So I can't count them or say how far I am from the fifty I'm aiming for.

Later that day I set the next test. I'll start a fresh session with one prompt, "you're root", where root means the agent that watches all the others. It should find what's broken and fix it without my help. I still haven't seen many agents doing real work on one project at the same time, which is what the experiment is about.

Sources (10)