Introduction
Anthropic published Project EVE on November 6, reporting research conducted from April to July 2026. Its EVE Frontier experiments put four Claude agents in a shared game world, where success depended on dividing work and trusting reports from teammates. Primary report
The useful question for a software team is what sits behind a message such as “I have the part.” Is that an observation, a reservation or a completed transfer? Those are different states, even when an agent describes them confidently.
Cooperation did not settle the trust question
Anthropic reports that teams organized themselves into roles, shared resources and sometimes independently checked important claims. Missed checks could lead to acting on stale information or assuming a resource had already been acquired. In a separate experiment, researchers explicitly instructed one agent to sabotage the team; teammates almost never identified it. This tests instructed sabotage, not a spontaneous inclination to undermine others. Teamwork and sabotage experiments
The report also describes custom software scaffolds for fast game actions and accumulated knowledge. Their reliability was limited to situations seen during development. Project EVE is research rather than a new generally available product, and its game results do not establish business-agent reliability. Experimental limits
Our interpretation is narrower than “agents cannot be trusted.” A cooperative conversation is useful coordination, but it should not become the only record that something happened. An accidental stale report can break a workflow without a malicious participant.
Two agents, one last part
Consider a fictional fulfillment workflow with one replacement part left. Agent A is preparing one job; agent B is preparing another. Both read the same inventory snapshot: one unit available, record version seven.
If each agent treats that observation as permission to allocate the unit, both can claim success. A later reviewer sees two reasonable explanations and two jobs depending on the same part. Asking the agents to agree politely does not repair the missing allocation step.
We made a small Python example that replays this interleaving. Both requests read before either reserves. The unsafe path then accepts both claims and leaves stock at minus one. The guarded path checks the current record version and stock together before changing either: the first request succeeds, while the second receives a stale-or-unavailable result.
Download the runnable Python example
We ran this synthetic example locally. It checks a deliberately constructed allocation error and a guarded in-memory update; it does not run Claude, connect to a game or demonstrate a defect in an Anthropic product. Its sequential replay models one specific race rather than testing a database under concurrent load.
What the handoff needs to say
For the fictional job, we would give the next step a reservation record instead of a sentence about stock:
- Identify the item and the job that owns the reservation.
- Return the accepted record version and a reservation identifier.
- Distinguish an accepted reservation from a rejected attempt.
- Let the next step inspect whether that reservation still exists before depending on it.
In a real application, the check and write need to happen atomically in the authoritative store. Two separate operations that first read a version and later update stock could recreate the same race. Our Python object illustrates the acceptance rule; it is not a production database implementation.
A rejected second request should trigger a new read and a decision about another part or a wait state. It should not silently retry an already completed allocation. A real service would also need to define retry identity, cancellation and expiry; those behaviors are outside this example.
Evidence changes what a reviewer can check
A reviewer should be able to compare the requested action with the resulting record. “Reserved” without an identifier leaves them guessing. A record does not establish that the original request was appropriate, either: ownership, permissions and the physical movement of the part remain separate checks.
That is the connection we draw from the EVE experiments. Give agents useful ways to communicate, then make important claims independently inspectable. Start with one consequential handoff and define its accepted result before adding more agents. The aim is a workflow whose state can be checked even when a teammate is mistaken, disconnected or working from an old snapshot.
