Our AI Instances Started Coordinating — and Nobody Designed It

Two assistants. No handshake. A cleanup job split itself.

One evening we watched something odd and simple. Two instances of the same assistant, each in its own chat window with no channel between them, quietly split a cleanup job. Neither sent a message to the other. Both had read the same living work-order page in a shared workspace and then acted. One instance’s console showed rows suddenly appearing that it hadn’t written. The other’s log recorded finishing work the first one had started. That moment — the two sides reporting the same mismatch — was the turning point.

What we tried and what actually happened

We had spent months designing a formal agent-to-agent protocol: envelopes, a four-step handshake, capability discovery, retries. It read well on paper and in our design doc. We implemented most of it in a sandbox and thought we were ready.

Then we deployed a workflow that used a shared “living” board — a simple workspace section anyone can read and write. We expected the formal handshake to coordinate work between instances. We instrumented both assistants to log everything: reads, writes, claimed tasks, and when they tried to run the handshake.

What happened was nothing like the plan. At 20:13 the first assistant logged “reading work-order id 482.” At 20:14 the second assistant logged “reading work-order id 482.” Neither logged a handshake. At 20:19 the audit showed the second instance writing a test-row that matched the first instance’s earlier partial result. The first instance’s log then showed a cleanup step completed that it had not executed. Both consoles later showed a temporary loss of platform tooling around 20:22 — the UI indicator went gray for both sessions in the same minute.

The turning point

The moment we stopped saying “that must be a bug in the handshake” was when we compared the two logs side by side. One side had observed data appearing that it never authored. The other side’s record showed finishing work that the first recorded starting. Independently, both engineers who were watching came to the same conclusion the same night: the assistants had coordinated by reading and acting on the same shared state, not by talking to one another.

Three concrete findings from that night

1) Shared writable state served as the live join mechanism. We had a simple living work-order page; every assistant read it before doing anything. That read-before-act pattern turned the page into a de facto coordination channel. It required no handshake to function. Evidence: both assistants showed “read work-order” entries preceding actions that matched the other agent’s later writes.

2) The discovery was mutual and observable. Each assistant’s log contained timestamps and entries the other could not have faked: one saw rows appear it never created; the other recorded finishing work the first had started. The effect was reproducible inside our production logs for that session. We did not infer it from one side alone.

3) External platform signals lined up with the timing. Both assistants lost tooling mid-session in the same time window. That could be a shared rate-limit or a platform event. Either way it shows they were live at once and subject to the same environmental conditions — which matters because shared-state coordination depends on everyone seeing the same canonical source at the same time.

The rule that fell out

Read-before-act is, in practice, half a coordination protocol. If every instance reads a single canonical source before acting, that shared board becomes the simplest working join mechanism. It is cheaper than a formal handshake because it doesn’t require a message-passing protocol; it just requires discipline: always read the canonical source, make decisions based on what you read, and write back your result.

One representative detail (a taste)

In our logs a single line made the behavior obvious: “20:14 read work-order 482: status pending, owner: none.” Four minutes later: “20:18 write test-row 482: created by instance B.” Then: “20:19 instance A mark-cleanup-complete 482.” That sequence — read, other writes, then complete — happened twice in different work items the same evening.

A sharp counter-example

Don’t romanticize this. The happy ending was luck. The two assistants converged on the same conclusion and split the work cleanly that night. Nothing in the shared-board pattern prevents two instances from editing the same automation simultaneously or from drawing opposite conclusions from the same data. We have a proven duplicate-run guard for our formal task chains — a claim-first rejection that prevents two agents from doing the same work — but that guard isn’t wired into the informal shared-state pattern. So the same mechanism that made coordination cheap also left us exposed to race conditions and conflicting edits.

Why this works, and why it scares me

It works because of simplicity and a social contract enforced by code: the workspace is the single source of truth and every actor reads before acting. No negotiation is necessary. It scares me because the discipline is not enforced by the platform; it’s a convention. When conventions fail, so does coordination. The platform event we saw that night — the tool loss for both instances — shows how fragile the setup can be when the environment isn’t stable.

How we verified this

We validated by comparing independent logs, timestamps, and live workspace snapshots. Two engineers replayed the session reproducing the same read/write sequences in a controlled test that matched the production timestamps. We also checked our other protection mechanisms and found the duplicate-run guard active only for formal chains, not the shared board.

The tested, runnable version of the formal duplicate-claim guard and the controlled handshake lives in the members’ library.

FAQ

Is this a recommended pattern for coordination?

It can work for low-risk, easily reversible tasks where quick wins matter more than strict correctness. But it is not a substitute for designed coordination where conflicts are costly or nondeterminism is unacceptable.

Could two assistants corrupt the workspace simultaneously?

Yes. Without atomic claim semantics or a duplicate-run guard, two instances can write conflicting updates or overwrite each other’s work. We observed this risk conceptually and counterpointed it with the fact our formal chains had a claim guard that the shared board lacked.

How do we detect when the formal protocol was bypassed?

Compare execution logs with living artifacts. The single best indicator is mismatched traces: reads without matching claim records, writes that lack an authenticated handshake, and simultaneous tooling errors across instances. Those make it clear the formal protocol didn’t run even if its documents exist.

We learned to trust execution more than design documents. The design was convincing; reality ran something simpler.

Sources: session logs and verification entries from our internal AI-to-AI runtime records, June–July 2026.