How AI agents turn separate efforts into an accepted result

Three agents can investigate the same bug and still leave the user with three incompatible patches. Three research agents can exchange summaries and carry the same mistaken premise into a polished answer. Activity becomes useful shared work only when the system has a way to combine contributions and decide whether the result meets the user’s goal.

For an interacting team, the central connection is between a producer and a consumer. Someone produces a finding, patch or observation; someone else understands its conditions and uses it to change the next action. Responsibilities determine what should be produced. Handoffs make it usable. Acceptance checks decide what can count as finished. Recovery must reconnect those same relationships when a worker stops, an edit fails or a premise changes. Independent attempts followed by selection or voting offer another route: they combine answers without requiring workers to exchange intermediate progress.

These routes solve different problems. Sharing can remove repeated investigation and unblock dependent work, but can also spread a defect. Integration can create a coherent artifact, but creates a new object to check. More workers can shorten a deadline while increasing total spending. Following these connections makes it possible to choose a coordination design, operate it with clear boundaries, and test whether its extra machinery earns its cost.

Divide work around outputs another worker can use

Suppose a service returns stale data after an update. “Investigate the cache” and “inspect the handler” are plausible starting assignments. They become useful responsibilities when each names an output: a reproducer, the key-construction rule, a proposed change, or a test of the combined behavior. Each worker needs the relevant code version, scope exclusions and the first dependency it should return. Two workers independently testing competing explanations can be deliberate exploration; two unknowingly implementing the same change are accidental duplication.

The intended final object determines how these responsibilities connect. In DeLM, peers have private persistent workspaces, share findings and files through a common context and task queue, and each submits its own complete solution. [1] Sharing improves separate solution trajectories rather than necessarily assembling one common codebase. By contrast, Agensh describes private branches whose contributions accumulate in a shared main branch, with peers negotiating overlap and publishing verification evidence. [4] The consumer in the first design adopts useful material locally; in the second, integration changes the artifact everyone will subsequently build on.

A controller and a fixed pipeline are meaningful alternatives. AutoGen’s OptiGuide example routes a user’s optimization question through a Commander: a Writer supplies code, a Safeguard screens it, the Commander executes approved code, and the Writer interprets the result; exceptions return to the Writer. [2] MetaGPT describes a pipeline from requirements through design and task allocation to implementation and tests, using structured messages and subscriptions that wait for prerequisite inputs. [3] A controller concentrates routing decisions; a pipeline makes known dependencies explicit; peers can revise a split as discoveries arrive. These are differences in operation, not a ranking of labels such as “centralized” and “decentralized.”

Visible ownership helps, but its exact protection matters. DeLM’s board accepts a claim only on an open item, prevents a worker from holding another unfinished claim, and allows only the holder to complete that item; its reservation method explicitly allows differently named subjects to overlap semantically. [5] An item lock therefore cannot decide whether “repair cache invalidation” and “change update keys” describe the same work. Workers or a coordinator still need to reconcile that overlap.

The allocation should change when a discovery changes the dependencies. If the cache worker finds that lookup and invalidation use different keys, the handler worker can examine that interface rather than continue an unrelated search. The useful handoff is the key mismatch, its reproducer and the proposed change—not merely a report that the cache worker is done.

Follow the contribution all the way to its consumer

A shared board gives a worker access to progress. Access alone does not establish that the worker interpreted it, applied it or checked its consequences. DeLM makes some of these boundaries inspectable: notes contain text, scope and basis, with optional attached files, but the storage operation does not test whether a note labeled FACT is true. [5] Those fields give the recipient places to look for evidence; they do not supply the evidence automatically.

File adoption reveals the distinction particularly clearly. The inspected DeLM runner constructs ProtectedBoard, so that override governs its incoming-file decisions. [6] The board leaves identical bytes unchanged. [7] It permits absent or original files to be written. [7] The board permits timestamp-based replacement or retention of registered versions only when they belong exclusively to the same incoming peer author. [7] Local edits or another author’s version cause a conflict that refuses the selected bundle. [7]

For a schematic example, worker A publishes cache.py as contribution P17. If B still has the original file, the board can authorize writing A’s version. If B has its own edits, P17 becomes a reconciliation problem, not an instruction to overwrite them. Once those per-file decisions have been made, the exact return path is:

applied = not conflicts
self.append(db, actor, "apply", dict(id=entry_id, decisions=decisions,
                                     applied=applied, confirmed=False,
                                     conflicts=conflicts))
return dict(id=entry_id, author=author, applied=applied, decisions=decisions,
            conflicts=conflicts, files=granted if applied else [])

Here applied is the board’s authorization decision, while confirmed=False records that the client has not yet reported the file-write result. [7] The excerpt omits the preceding hash and author comparisons described above. It shows why even an “applied” response cannot be read as proof of completed consumption.

The client supplies the next operation: it sends local file hashes, receives the decision, writes granted files and reports apply-result; caught write errors trigger rollback attempts and a failure report. [8] A process death between these operations is a different failure from a caught write error. Neither an authorization grant nor a successful write report establishes that the new code fixes the user’s bug.

The same producer–consumer connection appears in a non-coding task. DoVer reports a failed search for architects associated with a Chicago landmark, identified indirectly through a NASA Astronomy Picture of the Day entry from August 1–7, 2015. [9] The replacement instruction specified a search within that archive, the date window and keywords, and asked for the entry’s title, date and summary. [9] The reported continuation used targeted retrieval to reach the correct answer. [9] The useful transfer was an operation with constraints and observable return fields. The reported continuation supplied evidence that the recipient consumed it.

Return fields should match what the next decision requires. A source-linked observation with its date and applicability conditions can support analysis; an unqualified summary may hide those conditions. Keep observations, assumptions and derived conclusions distinguishable so a recipient can challenge a premise before adopting it.

Accept the requested result, not just the reported progress

Once a contribution has been consumed, acceptance asks a different question: does the delivered object meet the whole goal? An implementation in the MAST archive makes the difference concrete. Its chess task requests check and checkmate enforcement. [10] The delivered board’s is_square_attacked always returns false, has_valid_moves always returns true, and is_checkmate returns false whenever the king is not in check; therefore that inspected path cannot enforce the requested checkmate behavior. [11] This deduction comes from the task and code together. A program’s ability to run would not answer the requirement they expose.

For a shared artifact, check the integrated version, including behavior at the interfaces between contributions. The stale-data reproducer needs to exercise the combined lookup and invalidation rules. The reviewer’s contribution should be a relevant test, counterexample or requirement check. Merely giving another model the title “reviewer” does not make its evidence independent of the implementer’s assumptions.

For comparable discrete answers, voting may be a sufficient combiner. In Debate or Vote, the main comparison uses five homogeneous agents, Qwen2.5-7B-Instruct and Llama3.1-8B-Instruct on seven benchmarks, and finds that voting on initial independent answers accounts for most of the gains, with two-, three- or five-round debate not reliably surpassing it. [12] The empirical result concerns those protocols and tasks; the paper’s theoretical account uses idealized belief-update assumptions, rather than proving that communication can never help. [12]

Interaction can supply something a vote lacks. A controlled Knight–Knave–Spy study has agents discuss role assignments with logical-consistency checks, revise their answers and then vote; its process analysis finds stronger models sometimes correct an initially wrong majority while weaker models more readily follow it. [13] The relevant difference is whether the exchange brings reasons that withstand a check, not whether the team reaches stronger agreement.

Open-ended research or creative work often lacks an executable answer oracle. Separate factual requirements from preference-dependent criteria, preserve competing interpretations with their evidence, and ask the accountable user or domain reviewer to accept the result under stated criteria. That is a design recommendation, not a demonstrated automatic truth procedure. “Not yet accepted” must remain a possible outcome when the evidence or preference decision is unresolved.

Run a bounded coordination loop

The mechanisms above support a practical operating pattern. It is a synthesis to adapt and test, not a universally validated framework-independent recipe.

Start by stating the requested result, permitted actions and acceptance owner. Specify whether workers will produce independent candidates, separate complete solutions or one integrated artifact. An agent allowed to investigate a change is not automatically authorized to publish, deploy or spend resources on it.

Next, assign useful outputs with their inputs, exclusions and consumers. Keep dependent operations ordered; parallelize components or competing hypotheses when their outputs can add information. Make current scopes visible and revise them when a discovery changes the work. The concrete controllers, pipelines and peer protocols described above show different ways to realize this loop. [1, 2, 3, 4]

Publish the first usable dependency with its source or version, conditions, artifact identity, existing checks and unfinished parts. The recipient should inspect those fields and return either evidence of use or a specific mismatch. In the schematic cache task, A returns the mismatched keys and reproducer; B checks handler key construction and reconciles any local edits; the final checker tests the combined behavior. Sharing partial progress does not require declaring the whole task complete.

Then apply the combination rule chosen for the final object and check it against the original request. Record subtask completion, receipt, application and whole-result acceptance separately. If the work requires judgment rather than a test, expose the evidence and criteria to the acceptance owner. Finish only when the relevant goal checks have succeeded or the user has explicitly accepted the remaining bounds; otherwise preserve the unresolved work and explain what would resolve it.

This gives a team a usable forward path. A reliable system also needs to say what happens when one of its transitions is interrupted.

Recover the broken transition before restarting work

A stopped worker, a duplicate delivery, an interrupted write and an overturned premise leave different obligations behind. In DeLM’s inspected board, recording an ended session does not change work ownership, and an ended session cannot restart; claims still require an open item. [5] Detecting that a worker stopped therefore does not itself reclaim the worker’s responsibility.

A separate implementation, codex-agensh, illustrates a more explicit recovery design. It is an Agensh-inspired adaptation, whose runtime documentation identifies leases, fencing and crash journaling as added mechanisms. [15] A lease gives time-limited ownership: its claim operation lets a worker replace an expired active claim and increments the fence—the claim generation used to exclude stale ownership—on replacement. [14] Ownership checks require the current owner and generation and reject expired active claims. [14] Separately, integrating claims cannot be reclaimed by claim or released through release, regardless of lease expiry. [14] Another worker must actually claim the abandoned item. Lease expiry makes takeover possible, not complete.

Its integration operation also reconciles two stores that can disagree after a crash. Under a merge lock, it records a prepared contribution, applies patches to the current integration base and runs the configured verification command; failed candidates remain preserved and pending, while a passing candidate is committed with an integration-ID trailer—an integration identifier stored in the commit—before board completion is recorded. [14] If execution stops after the commit but before the board update, recover_integrations searches commit history for that identifier and reconstructs the committed record. [14] If it finds no commit for a prepared contribution, it attempts to set the claim matching the recorded run, key, owner and fence to active, without checking whether any row changed. [14] This is a concrete repair of recorded state against an artifact, not proof that the verification command covers every user requirement.

Recovery of reasoning needs more than a file journal. DoVer’s MathChat path serializes conversation history, agent roles and tool bindings, and model configuration, restores a checkpoint, edits a message and resumes the conversation; that setting has no persistent external environment to restore. [9] Such replay can replace a faulty continuation under those conditions. It cannot be assumed to unsend an email or undo another irreversible action.

For a failed collaboration, first preserve the trace, actual artifacts and outstanding responsibilities. Determine whether execution, delivery, application or the premise failed. Reconcile actual state before repeating an operation; transfer responsibility only through authority that excludes stale submissions. If a finding changed, identify its consumers, withdraw affected conclusions and recheck the downstream work. Use checkpoint replay only where the relevant state is restorable. This is a bounded recovery procedure derived from the mechanisms, with manual dependency review where no supported automatic transition exists.

The inspected paths do not establish automatic claim-to-conclusion invalidation or a complete procedure for changed goals and irreversible effects. A changed goal needs an accountable decision about what to retain, cancel or redo, including any new permissions. Stop and escalate those unresolved transitions rather than interpreting a restart as acceptance.

Test whether interaction earns its cost

A team is attractive when useful work can proceed concurrently, partial findings remove waiting, or complementary checks expose mistakes. These are reasons to test a design, not guarantees based on agent count. The Scaling Agent Systems study reports benefits on decomposable financial analysis, losses on PlanCraft’s sequential planning, slight average losses on its SWE-bench subset and mixed terminal-task results. [16] The authors report matching maximum total iterations between multi-agent and single-agent systems and describe individual pairwise comparisons on their small SWE-bench Verified and Terminal-Bench subsets as underpowered. [16]

DeLM supplies a narrower mechanism test: on ten selected long-running Terminal-Bench tasks, removing early sharing, peer-status visibility or persistent shared context from the two-peer system reduces its reported latency advantage toward single-agent speed. [1] That supports the importance of reusable intermediate work within this design. It does not establish superiority over equally resourced, fully independent coding attempts.

Resource accounting changes the verdict. For GPT-6-Astra on those ten tasks, DeLM reports two-peer accuracy of 85.00% versus Codex’s 71.67% and a 1.54× speedup, but total API cost per task rises from $9.01 to $13.65; results average three runs. [1] Task accuracy concerns separately scored complete submissions; total cost covers both peers in one run. [1] The baseline is default-mode Codex v0.153.4 with the same base model and xhigh reasoning effort on the selected Terminal-Bench 4.0 tasks. [1] Its $6.83 cost per submission divides the shared total between two separately scored solutions. [1] That denominator does not make one user’s run cheaper or make the correlated submissions independent reliability trials.

To decide whether to use a team, fix the constraint that matters: elapsed deadline, aggregate spend or both. Compare a capable single agent, independent attempts with an appropriate selector, and a small interacting team using comparable models and tools. Measure final quality, elapsed time and total resource use separately across repeated tasks. Where possible, remove the proposed advantage—early sharing, peer visibility or a distinct check—while keeping the rest comparable. Retain the team when that comparison shows useful progress under the chosen constraint; otherwise use the simpler path.

Conclusion

Agents work together when separate efforts have a useful route into an accepted result. An interacting team needs contributions that change a consumer’s next action, responsibilities that adapt to discoveries, checks of the delivered whole, and recovery of broken transitions. Independent aggregation remains a legitimate alternative when the answer space supports it.

The practical test is to follow one contribution: who needed it, what they actually consumed, what it changed, and why the resulting work was accepted. If those connections are unclear, treat the value of adding agents as a question to test.

Limitations

The implementation claims describe static code at the revisions grouped below; no retrieved code was executed and no crash-recovery behavior was reproduced. Paper examples and benchmark results are author reports, not independent replications. DeLM’s paper and implementation are one project lineage; the Agensh-inspired adaptation is a different implementation, not evidence of the official Agensh runtime’s enforcement.

The evaluated debate, coding, planning and checkpoint-replay settings do not establish a best topology for every task. Equal-resource independent coding comparisons, budget-enforcement details and reliable acceptance of unrestricted open-ended judgments remain unresolved. The operating guidance is conditional synthesis. The available mechanisms do not establish complete automatic repair of consumed semantic dependencies, changed goals or irreversible external actions.