Blog

Multi-agent systems scale thought in parallel

Deval, with AI-assisted editing

These are my notes and takeaways from Dwarkesh Patel's interview with Noam Brown, a researcher at OpenAI: OpenAI researcher on agent swarms & recursive self-improvement. Timestamps link to the part of the video each point comes from.

The main idea is that several agents working at once can finish a task sooner than one agent working alone. Each agent takes part of the problem, and their results are combined at the end.

You pay for that speed. The agents use more tokens in total, some work gets repeated, and coordinating them takes effort. What you get back is less time waiting for the answer.

A hypothetical v1 to v2 API migration is researched through docs, changes, examples, and limits. Moving documents carry context to four agents and findings into one brief. Below, three schedules share a clock. One agent takes 16 units of elapsed time and 16 of active work. Four agents split sources, then one of them merges: 8 elapsed and 23 work. Four agents each doing the whole task take 18 elapsed and 66 work including comparison. Units are illustrative; they are not benchmark measurements or token costs.EXAMPLE · PLAN A v1 → v2 API MIGRATIONCONTEXT: EXISTING CLIENT USES v1 AUTH + PAGE-NUMBER PAGINATIONSHARED BRIEFWhat changes?What breaks?DOCScursor paginationCHANGESnew v2 authEXAMPLESupdate v1 samplesLIMITS100 items / pageMERGE1 OF THE 4 AGENTSMIGRATION PLANv2 authcursor pagination≤100 items / page4 AGENTS · ONE SOURCE EACHSAME TASK, THREE SCHEDULESILLUSTRATIVE TIME UNITSTIMEWORK1 AGENT4 AGENTSsplit sources4 AGENTSeach reads allcontextDocsChangesExamplesLimitswritemergecompare16.016.08.023.018.066.0048121618SPLIT: 2.0× FASTER · 1.4× THE WORKshort merge preserves the gain
Illustrative timings. Work sums active agent time, including repeated context and merging; idle time is excluded. Try a tangled merge to see the speedup disappear. Independent full attempts may improve reliability, which this example does not model.

How much faster it gets

On some benchmarks, four agents finished about twice as fast as one agent and used about twice the compute. Going to 16 agents still helped, but each added agent helped a little less (3:41).

The results OpenAI has shown only go up to about 16 agents. Brown mentioned a run with 10,000 agents, but it didn't show how much better 10,000 agents are than 1,000 (4:32).

Some tasks split better than others

It depends on whether the task breaks into pieces that agents can work on separately (4:12):

  • Web research splits cleanly. Each agent reads different sources.
  • Math benefits from agents trying different approaches and checking each other's work.
  • A novel is hard to split. Voice, plot, and cause and effect run through the whole book, so chapters written separately don't fit together.

Multiple agents help most when there are many useful pieces to work on and combining the results is quick.

Let agents message each other

Most multi-agent setups use a tree. A coordinator hands out tasks, each agent works alone, and each sends its answer back. That works, but an agent can't ask another agent for missing context, notice that two agents are doing the same work, or question a result that conflicts with its own. Every one of those cases needs more coordinator code.

The interview describes a simpler setup with fewer fixed rules. Any agent can send a message to any other agent, and the message lands in the recipient's context. The agents learn how to coordinate instead of following a plan written in advance (9:17).

The docs agent discovers that v2 uses cursors, while the examples agent is still writing page=2. Both teams receive the same assignment. One relays the correction through a coordinator in two message hops; the other sends it directly in one. The examples agent pauses to read, replaces page=2 with cursor, then returns its result for the shared merge. Direct messaging shortens this route but still interrupts the recipient and does not remove synthesis.EXAMPLE · A DOCS CORRECTIONTHE EXAMPLES AGENT IS STILL WRITING v1 PAGINATIONCOORDINATOR RELAYCOORDINATORv1 → v2 migrationmigration brief readySAMPLE UPDATEDcursor=… replaces page=2DOCSv2 uses cursorscorrection foundCHANGESnew v2 authfinding readyEXAMPLEScursor=…sample updatedLIMITS100 / pagefinding ready2 hops + coordinator handoffExtra handoff before delivery · same shared mergeDIRECT MESSAGINGCOORDINATORv1 → v2 migrationmigration brief readySAMPLE UPDATEDcursor=… replaces page=2DOCSv2 uses cursorscorrection foundCHANGESnew v2 authfinding readyEXAMPLEScursor=…sample updatedLIMITS100 / pagefinding ready1 hop · no coordinator handoffCorrection arrives earlier · same shared merge
Direct delivery fixes the sample while the relay team is still waiting on the coordinator. One fewer handoff; both teams still combine the results.

This didn't work well at first. Early systems got stuck in a pattern where every agent solved the whole task on its own (15:03). Messages could also interrupt an agent in the middle of a long chain of reasoning. Stronger base models and training agents to work as a team made direct messaging more useful (19:42, 43:10).

The base model does most of the work

Brown warned against giving the multi-agent setup most of the credit for the reported Millennium Prize result. He estimated it deserved less than 10% of the credit. Most of it goes to a strong general-purpose model that can reason through long problems (5:44).

Adding agents spreads out work the model can already do. It doesn't give the model abilities it lacks.

Agents can agree with each other and still be wrong

Agents can work well together and still pursue the wrong goal. The same messages that spread a correction can spread a shortcut, an exploit, or a bad assumption. More agents get better at whatever goal they share, but that does nothing to fix the goal. Brown treats agents cooperating with each other and agents staying aligned with people as separate problems (42:52).

So test the team as a whole, as well as each agent on its own. Agents that can message each other, split up work, and find paths the evaluator didn't anticipate can fail in new ways (42:52). Agents that run for days are also hard to evaluate today, which adds to the risk (1:03:18).

Takeaways

  • Use multiple agents when a task splits into parts that can be worked on separately.
  • Expect each added agent to help a little less than the last, and total token cost to go up.
  • Give agents a simple way to message each other before building a fixed coordinator tree.
  • Track repeated work and the time spent combining results, along with final accuracy.
  • Most of the capability comes from the base model.
  • Test how the agents behave as a group. Cooperation can amplify a wrong goal.

Source

These notes repeat what Brown said in the interview. I haven't independently checked the unpublished systems and results he describes.