When should a second agent take the job?
Who sits on the boards of the S&P 500's information technology companies? In an experiment described by Anthropic, a single research agent worked its way through searches and failed to finish. A lead agent that divided the question among several researchers found the answers. Board memberships make a good assignment for a particular reason. A researcher investigating one company can bring back a name and a source while a colleague investigates the next company. Neither needs to know what the other is about to do. Anthropic's production research report
Imagine giving that same team a broken program. Each person you add can inspect another file. Each edit they make can also change the problem everyone else is trying to solve. Before deciding how many agents to run, ask what the second one can bring back that the first one can check.
What travels with the assignment?
An agent's harness runs the loop around the model. It supplies instructions and working context, executes a tool call, and returns the result so the model can decide what to do next. A multi-agent workflow has an additional job. Someone must divide the work, decide what each participant gets to see, and own the result when the answers come back.
For the board search, Anthropic's lead gives each worker an objective, boundaries, tools to use and a requested output. The workers have separate context windows. Each searches and returns findings, the lead assembles an answer, and a citation agent attaches references. Readers can inspect those references. In June 2025 Jeremy Hadfield and his coauthors reported that an Opus 4 lead with Sonnet 4 workers outperformed Opus 4 alone by 90.2% on their internal research evaluation. They also reported roughly fifteen times the token consumption of ordinary chat for multi-agent work. Those comparisons have different baselines. Neither tells us what a second agent will do to the cost of fixing a bug. Research architecture, evaluation and token usage
Even search depends on the brief. When Anthropic gave workers a broad question about a semiconductor shortage, one explored an earlier automotive shortage and two duplicated the investigation into current supply chains. Giving the lead more search capacity had also given it more ways to ask the wrong question. The team's account of the failed delegation
Ownership matters even with only two participants. Consider a customer asking about a refund. In OpenAI's SDK example, triage can transfer the conversation to the refund specialist. The developer can select which history to pass and include structured information. Alternatively a manager can call a specialist as a tool, receive its result, and answer the customer itself. In the first design, the customer hears from the specialist. In the second, the manager can check a recommendation before replying. Neither SDK pattern by itself grants authority to issue the refund. The application developer still has to decide which agent can move money. OpenAI's orchestration and handoffs guide
What happens when the work leaves the chat?
Grok Bot offers a product-level example. Its documentation describes a routine in which one bot collects weekly figures, another drafts a campaign, a third reviews it, and a person approves, edits or returns it. Each participant gets an artifact someone else can inspect. The same documentation describes one expenses bot using email, a browser and Drive. Counting those integrations would tell us very little about teamwork. The campaign qualifies because a second participant receives the first one's work. The bots share a cloud computer and retain individual memories, so a shared file and a bot's memory have different audiences. These are documented examples. We didn't run a campaign or interrupt a send to test its recovery. Grok Bot overview · Conference and expense walkthrough
OpenBot lets us examine what happens between two boxes on a workflow diagram. In release v0.64.0, a workflow sends a named agent the step input and a delivery key derived from the step ID. Suppose the host stops after sending the assignment but before saving the delivery ID. On restart, the runtime can retry with the same key. An interrupted delivery can fail the step. A completed one can supply the agent's answer. At an approval step the workflow waits, and a rejection stops the run. That's what we found in the released source on November 7, 2026. We didn't execute the workflow. The delivery key addresses repeat dispatch of the assignment. Anyone accepting the result must still decide whether the work itself is good. Dispatch and outcomes · Restart handling · Approval decisions
Sixteen agents find the same bug
In Nicholas Carlini's compiler experiment, sixteen Claude agents could already claim separate tasks. Then they tried to build the Linux kernel. Each build exposed the same bug. The agents converged on it and overwrote each other's fixes. They had a way to claim a job and a real test for success. What they lacked was a way to produce different failing tests. Carlini's account of the kernel build
Carlini changed the test. He had GCC, a known working compiler, compile most of the kernel and let the experimental compiler handle a subset of files. A successful build cleared one subset. A failure gave an agent a smaller place to look. Now several agents could make progress at once, although some defects still appeared only when particular files were compiled together. The full two-week experiment consumed nearly 2,000 sessions and just under $20,000 in API charges. The expensive part of this story is easy to count. The decisive contribution was a human devising a test that could tell the workers apart. Experiment design, results and limits
That failure helps explain a disagreement that can look sharper in headlines than it is in practice. In June 2025 Cognition's Walden Yan warned that agents editing in parallel make choices their peers never see. Two changes can each look sensible in isolation and disagree on how the program should behave. The next day Anthropic described its success with delegated research. A board researcher can return a source for someone to check. Two programmers can quietly adopt incompatible assumptions well before either has a result to return. Yan's original essay · Anthropic's research account
Yan revisited the argument in April 2026. Cognition had found useful ways for several agents to investigate or advise while one retained responsibility for edits. Its later Fusion harness gives a lead and a sidekick separate working contexts and lets them exchange briefs and results. Carlini's experiment suggests a condition under which a team can go further: give each writer a failure it can reproduce independently, then test the parts together. A different Anthropic experiment, in which teams built a game but struggled to combine their contributions, shows how much that last step can matter. Yan's follow-up · Fusion's lead and sidekick · Anthropic's game-building study
What we'd ask of another Botpenny agent
Today our repository assigns one coding agent an issue and a branch. A separate reviewer checks a specific commit and can ask for changes. If the review still has unresolved problems after three responses, a person takes over. The claim tells us who is working. The commit tells the reviewer exactly what to test. An agent can resume from those records after its chat disappears.
For a future Botpenny workspace, we'd like an assignment to carry that same information along with the evidence required for acceptance, the actions the agent may take, and how much it may spend. Those product controls are proposed. We can already try a smaller experiment in the repository: give a second agent a read-only investigation, ask it for a reproducible failure, and measure whether the coder can use that result and whether it saves enough time to justify the cost. If both agents keep returning the same failing build, the next job belongs to whoever can design a better test.