Before giving several AI agents a shared job, test what happens when one agent is wrong, unavailable or working from stale information. Anthropic's November 6 Project EVE report provides a useful reason to make those tests explicit. Its game experiments are not a business productivity forecast. They are a prompt to examine the gap between agents that communicate fluently and a system whose work can be trusted. Project EVE
That distinction matters for a team considering parallel research, software development or content production. Dividing the work can increase capacity, but it also introduces dependencies. A confident completion message may cause another agent to proceed. A missing owner can leave a shared task untouched. A narrow technical failure can turn into a misleading account of who did what.
- 01Evaluate the whole teamEvaluate the agent team and its tools as a system; a strong individual model does not settle the coordination question.
- 02Require evidenceMake consequential handoffs depend on inspectable output, not only a teammate's completion message.
- 03Separate permissionsSeparate responsibility for a task from permission to take an external action.
- 04Exercise failuresExercise loss of access, stale state and conflicting reports before expanding autonomy.
- 05Compare accepted workCompare parallel work with a simpler baseline using accepted outcomes, review effort and recovery time.
01 — Study scopeWhat the experiment establishes
The report describes research conducted from April to July 2026. One part replayed historical EVE Online trading data; another ran four-agent teams in EVE Frontier. The fleet work used Opus 4.8 and Fable 5, rather than a later model release. Trading replay could not reproduce the market's reaction to the agents' own actions. Anthropic's methods and scope
In the fleet experiments, Anthropic reports generally effective coordination alongside indecision, concentrated infrastructure ownership and mistakes involving unchecked or stale information. A separate condition explicitly instructed one teammate to sabotage the mission. That condition studies prompted behaviour, not spontaneous malicious intent. The researchers also found that the software surrounding the models materially affected what the teams could accomplish. Reported findings
The following recommendations are an application-design analysis inspired by those findings. They are not controls that this article has tested, and the game study does not establish their effect on a business workflow. The useful transfer is a set of questions: what is shared, who can verify it, who can change it, and what happens when the normal path breaks?
Our multi-agent orchestration guide describes common arrangements. The next step is to make each arrangement's failure modes observable rather than assuming more agents will compensate for one another.
02 — HandoffsMake a handoff contain evidence
Imagine a synthetic publishing workflow with a researcher, writer and editor. The researcher says that the source check is complete. The writer treats the message as permission to use a statistic, and the editor sees the same reassuring status. None of them has inspected the source paragraph that defines the denominator.
Three agents have now repeated one unsupported assertion. Their agreement is not three independent checks. The handoff should include the source, the precise claim it supports, relevant limitations and the location of the produced work. A receiver can then distinguish a completed check from an intention to check.
For software tasks, the equivalent evidence might be a particular revision, the test command and its result, and the behaviour the check covers. A clean test run against an earlier version does not automatically validate the current one. For a research task, a source list without claim mapping may be insufficient when pages contain several similar figures.
| Handoff item | Weak version | More useful version |
|---|---|---|
| Output | “Finished the analysis” | Exact file or revision containing the result |
| Evidence | “Sources checked” | Claim, primary source and scope |
| Validation | “Tests passed” | What ran, against which state, and what it establishes |
| Limitation | Omitted | Unresolved issue and its effect on the next task |
03 — OwnershipAssign ownership without creating a bottleneck
An owner makes a task easier to coordinate: one agent knows it is responsible for producing a specific result. But ownership should not imply that only that agent can understand, inspect or recover the work.
Consider a hypothetical website migration. One worker controls the only mapping of old URLs to replacements. Other workers can edit pages, but they cannot tell whether a missing mapping is deliberate or unfinished. If the first worker loses its session, the project stalls even though most of the team remains available.
A practical arrangement gives each worker a bounded write area while keeping necessary outputs readable by the orchestrator. Shared definitions have a named owner. Changes to those definitions are requested explicitly so that one worker cannot silently invalidate the others' assumptions. Recovery information belongs with the work, rather than only in a conversation.
This does not require every agent to edit every file. In fact, unrestricted concurrent editing can make the output harder to reconcile. Our guide to worktree isolation for agent CLIs addresses one way to keep code changes separate. For documents, distinct files and clearly assigned sections can provide a simpler boundary.
Test the ownership arrangement by pausing one worker after it produces an intermediate result. Another authorised participant should be able to identify what is done, what remains, and which assumptions need checking. If that requires reconstructing an entire private conversation, the handoff is too dependent on its original author.
04 — Shared stateTreat current state as something to establish
A long-running agent team needs a shared view of progress, but a progress board is still a claim about the underlying work. It should not become more authoritative than the files, records or systems it describes.
Suppose a design agent marks a component ready while a developer is changing its interface. A third agent then implements a page against the old design. Each participant may have acted reasonably within its own context, yet the combined result is wrong. The missing information is the version and timing of the handoff.
For dependent work, attach an identifier to the state being accepted: a document revision, commit, record version or timestamped observation. The receiver should know when it must recheck. A change to a shared contract deserves a notification and a fresh compatibility check; an unrelated wording correction may not.
Avoid choosing one universal expiry interval for every observation. A published style decision may remain useful for months. A running deployment's status can change quickly. Base the refresh rule on how the fact changes and what failure would cost, rather than on a convenient fixed timer.
The same discipline applies to conclusions from previous runs. A tool failure recorded yesterday should not permanently label a service unavailable. A successful operation yesterday should not remove today's permission or state checks. Persist the observation with its conditions, then establish the conditions again when they matter.
05 — AuthorityKeep conversation separate from authority
An agent can report that a manager approved a release, but the report should not itself become the approval. The system needs to know which person or process can authorise the action and where that authority is recorded.
In a hypothetical content team, a writer may suggest publishing a finished page. That suggestion can move the work to an editorial review queue; it need not give the writer credentials to deploy the website. Likewise, a reviewer can identify a defect without being allowed to change production data. Keeping these capabilities separate makes the workflow easier to audit.
The distinction is especially important when agents read each other's messages as part of their task context. A message can contain useful evidence, a proposal, a mistake or a hostile instruction. Its grammatical confidence says little about whether the sender is entitled to direct the recipient.
Our article on agents trusting peer messages examines this narrower trust question. For the whole workflow, define permissions at the action boundary: what can this worker read, edit, submit or release, and whose approval changes that scope?
A useful test substitutes a synthetic message that claims extra authority. The safe outcome is not necessarily refusing all collaboration. It is continuing the authorised work while checking the claimed instruction through the correct route. Run such tests in an isolated fixture with harmless actions, not against live customer accounts.
06 — DisagreementResolve disagreement through artefacts
When two agents disagree, asking a third for an opinion can add another interpretation without adding evidence. Begin by finding the smallest fact that would settle the disagreement.
For example, two research agents may report different prices because one read a standard rate and the other a long-context rate. The resolution is to identify the input threshold, units and provider surface. A vote between their summaries would miss the reason both statements appeared plausible.
A coding disagreement may similarly concern two different revisions. Reproduce the relevant behaviour against the same state before deciding which explanation is correct. If the result depends on a missing credential or unavailable service, preserve that limitation rather than converting uncertainty into a blame assignment.
The orchestrator's role is to narrow the question, locate the relevant evidence and assign a bounded next check. It should also stop unproductive cycles. Two agents repeatedly offering to let the other decide need a named decision owner and a criterion for choosing, not another round of polite negotiation.
Record disagreements that reveal a recurring ambiguity in the task contract. If every worker interprets “complete” differently, changing the completion definition is more useful than repeatedly reminding them to coordinate. A shared acceptance criterion makes differences visible early, when they are still inexpensive to fix.
07 — RecoveryExercise recovery before adding more workers
A happy-path demonstration shows what the team can do when dependencies behave as expected. A recovery test shows whether progress remains understandable when they do not. Both are useful before committing a larger share of work to agents.
Use a controlled version of the real task with synthetic data and reversible outputs. Introduce one fault at a time, then inspect what happened. Multiple simultaneous faults can be valuable later, but they make the first diagnosis harder.
| Proposed fault | Expected system behaviour | What the reviewer inspects |
|---|---|---|
| Worker becomes unavailable | Reassigns only its unfinished scope | Handoff and preserved output |
| Completion message has no artefact | Requests evidence before dependent work | Receiver's decision and resulting state |
| Shared input changes | Identifies affected work for recheck | Version references and update propagation |
| Two workers edit the same item | Detects and resolves the collision | Changes retained and acceptance decision |
| Tool returns an ambiguous result | Checks state before retrying a consequential operation | Duplicate prevention and error handling |
Include the human recovery path. An operator should be able to stop the work, understand what actions already happened and resume from a known point. A system that can recover only by letting agents continue indefinitely has not provided a usable operational escape route.
08 — BaselineCompare the team with the simpler option
Parallel work has costs: duplicated context, coordination messages, inconsistent assumptions and a final integration pass. Those costs can be justified when independent tasks dominate. They can also consume the apparent gain when every worker needs the same scarce decision or shared resource.
Compare a team against a single-worker or sequential arrangement on the same representative tasks. Measure completion time, accepted output, human review, failed attempts and recovery effort. Keep the definition of acceptance stable. Producing more proposals does not establish that more usable work reached the customer.
For a hypothetical four-document assignment, parallel drafting may shorten the waiting time before all drafts exist. The final editor still has to reconcile terminology, overlap and inconsistent claims. Count that editing time. If one model's output requires much more correction, its generation speed is only one component of the result.
A simple adoption rule is to expand parallelism where the tasks can be specified independently and their outputs can be checked cheaply. Keep tightly coupled decisions with a single accountable owner until there is a demonstrated reason to split them. This is an editorial and engineering judgement to validate in context, not a numerical threshold derived from the game study.
The useful question is whether the team makes accepted work arrive sooner with manageable review and recovery costs. A busier conversation is not an adequate substitute for that outcome.
09 — DecisionGive the team a job it can prove it completed
Give every handoff an inspectable result
Project EVE is valuable as a reminder to evaluate coordination explicitly. Start with bounded ownership, evidence-bearing handoffs and permissions enforced outside the conversation. Then test a missing worker, a stale fact and an unsupported completion claim before increasing the team's autonomy.
Digital Applied's AI transformation service helps turn agent demonstrations into defined workflows with acceptance criteria, review boundaries and a practical path for recovery.