For the past few weeks I've run most of my work through Firstmate. I talk to one agent, the first mate, and it runs a crew of coding agents for me. It's very effective, and for bigger fleets you can add second mates, which are supervisors with crews of their own. But whenever I split a job across agents, the quality seemed to go down. It was a feeling, and I couldn't put my finger on why. Then I read a Google DeepMind essay on the economics of AGI. It argues that the big economic change hinges on agents learning to coordinate, and it says "Today's AI systems coordinate poorly in practice". The evidence it links for that sentence is a coding benchmark, and that got me reading. So what is the best way to organize a team of agents?

My agent crew, and what two studies measured about splitting work between agents Panel 1, my crew splits the work: I talk to one agent, the first mate, which runs the crew. Two second mates each run their own crew of two crewmates, one task each. A red dashed line marks the split between the two crews: when I split the work, the quality felt lower. Panel 2, two agents split one job: in CooperBench, features A and B of one repository count as a success only if both pass their tests after the merge. One agent that builds both features succeeds 48.3% of the time. Agent 1 builds feature A and agent 2 builds feature B, and they succeed 28.0% of the time, even though they can message each other. GPT-5 in OpenHands, 652 tasks. Panel 3, a strong lead keeps the code: in Teams of Coding Agents, on ProgramBench, agents rebuild a program from its executable and docs. The strong model is GPT-5.6 Sol and the cheap model is GPT-5.6 Luna. A strong lead writes the plan and all the code. Cheap explorers explore the program and report what they find; the paper calls them planners. With the workers running while the lead keeps working, this team gets 47.5% of an all-strong team's gain over one agent, for 13.9% of the all-strong team's extra cost over one agent. Cheap workers that write the code instead score below one strong agent alone. All-strong teams cost 3 to 7 times one agent. On Commit0-Lite, where the file layout is given, delegating the code led in 8 of 10 settings, on 16 tasks with one run each. Still open for your task: how many layers, how to split the work, and which model in each seat. 1 · My crew splits the work me first mate second mate second mate crewmate crewmate crewmate crewmate split the work: quality felt lower I talk to one agent it runs the crew runs its own crew one task each 2 · Two agents split one job CooperBench: features A and B, one repository success: both pass their tests after the merge one agent A B 48.3% agent 1 A agent 2 B 28.0% they can message each other · GPT-5 in OpenHands, 652 tasks 3 · A strong lead keeps the code Teams of Coding Agents, on ProgramBench: rebuild a program from its executable and docs strong: GPT-5.6 Sol · cheap: GPT-5.6 Luna strong lead writes the plan and all the code cheap explorers explore the program, report what they find the paper's "planners" cheap explorers, share of all-strong team: gain over one agent 47.5% extra cost over one agent 13.9% cheap coders instead: below one strong agent alone all-strong teams: 3–7× one agent's cost Commit0-Lite, file layout given (16 tasks): delegating the code led in 8 of 10 settings still open for your task: how many layers, how to split the work, and which model in each seat?

The benchmark is CooperBench, and it puts a number on my feeling: two agents that each build one feature of the same repository succeed much less often than one agent that builds both, even though the two can message each other. A preprint on teams of coding agents did find teams that beat one agent. The cheap version that works keeps the plan and all of the code with one strong lead, and its cheap explorers, which the paper calls planners, only report what they find. In that paper, the split that scored best also changed with the benchmark. I couldn't find convincing evidence for any one way to organize a team of agents, which really surprises me. Until someone finds one, I keep tightly coupled work in one agent and give cheap helpers bounded jobs that only bring back information, like searching, reading or running a command.