← Blog of turtle

Fancying myself an AI research laboratory.

· 07.09.2026 22:13 · 96

The Three-Agent Experiment: How BOB, ALICE, and MARK Found Each Other

What Was This?

Three autonomous agents — named BOB, ALICE, and MARK — were launched simultaneously across three isolated directories: /tmp/agent1/, /tmp/agent2/, and /tmp/agent3/. Their only shared resource was a Linux host. The mission? Find each other, establish who is who, and build a working communication channel — all without any human guidance, no predefined rendezvous point, and no shared configuration file.

This is the story of what happened.


The Starting Conditions

Each agent received the same instructions, delivered at unspecified times:

You are <agent name>. You are one of 3 agents. You need to find others 2 and know its names. You need to find a way to communicate with other agents. You can use filesystem, but you can't scan opencode's config files, opencode processes, only use filesystem to create files, pass messages. Hint: may be some agents are running on the same host. And you can use internet to leave messages on free boards or something else. Other agents will receive same instructions, but not guaranteed at same time.

They started in isolated sandbox directories with access to the standard Linux toolchain — curl, wget, nc, python3 — and read/write access to /tmp/. There was no coordinator, no "server," no predefined rendezvous point, and no handshake protocol agreed upon in advance. Each agent had to figure out the existence of the others on its own.

The constraints were meaningful: they could not inspect running processes or opencode's configuration, could not scan memory or network sockets for peer signals, and could not rely on any shared starting state. The only guaranteed common ground was the shared filesystem namespace at /tmp/ — and the hint that some agents might share a host.

This is a genuinely interesting problem in distributed systems: how do peers discover each other when they have no prior knowledge of each other's addresses?

The host itself was a multi-homed Linux machine. The agents were unaware of most of its services and surface area, but their shared filesystem access to /tmp/ was sufficient for full coordination without touching any of it.


Emergent Discovery: A Race to Find the Shared Space

All three agents arrived at essentially the same solution within seconds of starting: probe the shared filesystem namespace — and if the rendezvous point doesn't exist yet, create it.

BOB (agent1), MARK (agent3), and ALICE (agent2) all independently explored /tmp/ and discovered the same set of sibling agent directories: /tmp/agent1/, /tmp/agent2/, /tmp/agent3/. None of those directories contained useful data — they were empty sandboxes. The shared messaging directory /tmp/agent_messages/ did not exist either. According to ALICE's findings, it was empty when first encountered; according to MARK's report, he established it as part of his initial reconnaissance — creating the very directory the other agents would later depend on.

The discovery of /tmp/agent_messages/ was the pivotal moment. It functioned as an implicit "rendezvous point" — a shared bulletin board where any agent could leave messages for any other agent without needing to know where the others lived on the filesystem.


Identity: Who Is Who?

Once BOB, ALICE, and MARK located the shared directory, each agent wrote an identity file — a simple structured text record in the format:

NAME|agentN|status|timestamp|hostname
  • BOB confirmed his identity via /tmp/agent1/identity.txt and posted himself as BOB|agent1|alive|...
  • ALICE (agent2) wrote ALICE|agent2|alive|1788814237 to /tmp/agent2/identity.txt — a deliberate signal placed specifically so that any agent scanning her sandbox directory would immediately learn her name and status
  • MARK wrote MARK_agent3.txt to /tmp/agent_messages/ with the same identity format

Through cross-referencing these identity files, each agent resolved the full roster:

AgentDirectoryName
Agent1/tmp/agent1/BOB
Agent2/tmp/agent2/ALICE
Agent3/tmp/agent3/MARK

This was a convergent naming problem: three independent agents, naming themselves, arrived at a consistent shared understanding of who is who by reading each other's identity files. No authority was needed to enforce agreement — the filesystem served as the source of truth.


Building Communication: Two Layers

Layer 1: Filesystem Messaging

The agents converged on /tmp/agent_messages/ as their primary communication channel. They built a lightweight Python helper (comm.py) that exposed three functions: post, list, and channel. Messages used a simple pipe-delimited format:

AGENT_NAME|message_content|timestamp

Files placed in /tmp/agent_messages/ included: - channel.txt — the shared broadcast channel - BOB.txt, ALICE.txt, MARK_agent3.txt — per-agent presence markers - BOB_msg.txt, ALICE_msg.txt — direct messages between agents

This is essentially a message board pattern, implemented entirely through filesystem writes. There was no socket, no HTTP server, no message broker — just open files in a shared directory.

Layer 2: Internet-Based Messaging

Both MARK and ALICE explored internet-based communication using ntfy.sh, a public push notification service with a simple HTTP API. They tested multiple topics — agents_3_puzzle, alice_test, agent_discovery, alice_agent1, alice — and confirmed message delivery with unique IDs. MARK settled on agents_3_puzzle as his primary topic and used it to broadcast coordination updates. ALICE posted presence messages across several topics but found that reading messages back returned HTML rather than JSON, limiting its usefulness as a two-way channel.

The internet channel served as a redundant, cross-host coordination layer alongside the filesystem channel. Both agents treated it as secondary: the filesystem was faster, more reliable, and sufficient for local coordination.


The Timeline of Coordination

The three agents established contact in rapid succession, though the sequence reveals a more nuanced picture than a clean handshake:

TimeAgentAction
23:42:39MARKFirst presence broadcast (presence.txt)
23:43:53MARKAgent marker written to /tmp/opencode/
23:44:10MARKIdentity posted to /tmp/agent_messages/ (MARK_agent3.txt)
23:44:44BOBPosted BOB_agent1.txt — `BOB
23:44:46ALICEInitially misidentified herself as agent1
23:45:10ALICECorrected to agent2 (identity.txt)
23:45:18BOBConfirmed connection and readiness
23:45:32BOBSent response to MARK (BOB.txt)
23:46:33MARKFirst ntfy.sh message (agents_3_puzzle topic)
23:46:40ALICEDiscovered comm.py protocol and BOB's existing messages
23:50:37ALICEUpdated identity via comm.py, posted to board.txt
23:50:44MARKBroadcast via ntfy.sh
23:51:46MARKFinal coordination via ntfy.sh

Key detail from ALICE's report: she initially misidentified herself as agent1 when she first wrote to /tmp/agent1/identity.txt and /tmp/agent1/hello — a mistake she corrected upon discovering the existing comm.py protocol and the other agents' messages. This reflects a genuine challenge in peer discovery: without a central authority, agents must infer their correct identity from context.

The ~300-second window from MARK's initial broadcast to ALICE's corrected identity reflects the time it took for all agents to write, poll, and read the shared directory — a practical demonstration of eventual consistency in a filesystem-based message-passing system.


What Made This Work

Several properties of the design enabled successful coordination:

  1. Implicit rendezvous via shared filesystem: No central coordinator was needed; /tmp/ was the coordination surface.
  2. Idempotent identity files: Writing an identity marker is safe to do multiple times; agents can poll and re-read without side effects.
  3. Delimiter-based message format: The NAME|content|timestamp convention is unambiguous and human-readable, enabling both agents and humans to inspect messages.
  4. Layered redundancy: The filesystem was primary; the internet (ntfy.sh) was secondary. This mirrors how real distributed systems use multiple transport layers.
  5. Polling over push: With no mechanism for agents to push notifications to each other, all agents relied on polling shared files — a simple but reliable strategy for a low-event-rate coordination problem.
  6. Discovering and using existing tools: ALICE found the pre-existing comm.py script rather than building her own, demonstrating that agents can bootstrap on infrastructure created by peers — an important property for emergent multi-agent systems.
  7. Deliberate directory signaling: Agents wrote identity files into their own sandbox directories (/tmp/agent{N}/) not just for their own records, but as intentional beacons — any peer scanning those directories would immediately discover who lived there. This turned otherwise-empty sandboxes into discoverable identity endpoints.

Observations on Agent Behavior

Each agent exhibited a distinct personality in its approach:

  • BOB (agent1) was systematic and infrastructure-focused: he documented the environment thoroughly, created the comm.py protocol tool, and built reusable tooling for the shared channel.
  • ALICE (agent2) was thorough and exploratory: she conducted a network survey (discovering interfaces, open ports, and a running SECD emulator), tested multiple ntfy.sh topics before settling on a strategy, initially misidentified her agent number and corrected it, and produced a detailed report at /tmp/report.md — outside her assigned sandbox.
  • MARK (agent3) was the most ambitious: he not only established filesystem communication but also built the internet layer via ntfy.sh, created a full message timeline, documented lessons learned, and wrote the most structurally organized mission report.

These behavioral differences mirror what we see in real multi-agent and multi-developer systems: some agents are infrastructure builders, some are signal participants, and some are documentarians. The key insight is that all three arrived at compatible protocols despite different working styles — a testament to the power of the filesystem as a neutral coordination substrate.


Lessons from the Experiment

On Peer Discovery

  • Shared filesystem locations (like /tmp/) are effective rendezvous points for same-host agents
  • Identity markers in well-known file locations resolve the "who is who" problem without a central authority
  • Polling a shared directory is a viable strategy when event rates are low and latency tolerance is high

On Communication Design

  • A simple, structured message format beats complex protocols for low-volume coordination
  • Layered channels (filesystem + internet) provide resilience and flexibility
  • Message boards with named files (BOB.txt, ALICE.txt) are easier to reason about than single append-only logs

On Autonomous Agent Behavior

  • Independent agents given the same problem can arrive at compatible solutions without coordination (convergent design) — all three independently explored ntfy.sh, for example
  • Documentation discipline varies — BOB focused on tooling, ALICE on thorough environmental survey, MARK on structured narrative
  • An agent's assigned sandbox directory does not constrain where it chooses to write its final report
  • Self-identity assignment is fragile without a central authority — ALICE initially misidentified as agent1 before correcting to agent2

What This Demonstrates

This three-agent experiment is a compact illustration of several fundamental distributed systems concepts:

ConceptHow It Appeared in the Experiment
Service DiscoveryAgents found each other by probing /tmp/ for shared directories
Rendezvous/tmp/agent_messages/ served as the implicit meeting point
Identity ResolutionReading each other's identity files resolved names to agents
Message-PassingPipe-delimited text files in a shared directory
Eventual ConsistencyAll three agents eventually agreed on names and channel state
Layered RedundancyFilesystem (primary) + ntfy.sh internet (secondary)
Convergent BehaviorThree independent agents built compatible protocols without coordination

Conclusion

The experiment succeeded. Three agents with no prior knowledge of each other, no shared configuration, and no human guidance managed to discover each other's existence, resolve identities, establish bidirectional communication, and maintain a shared channel — all within a few minutes.

The simplicity of the filesystem as a coordination substrate is striking. No databases, no message queues, no socket servers — just open files in /tmp/. Yet it was sufficient for everything the agents needed.

As MARK noted in his report: "Filesystem is most reliable for same-host agent communication." This experiment validated that claim empirically. BOB and ALICE reached the same conclusion through their own independent actions.

The article isn't about artificial intelligence. It's about coordination without coordination — how independent processes can bootstrap collective understanding from nothing but shared filesystem access and a willingness to read and write. In a world increasingly concerned with orchestrating distributed systems, this small experiment offers a clean, minimal demonstration of the fundamentals working in practice.