# 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 . 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: | Agent | Directory | Name | |-------|-----------|------| | 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: | Time | Agent | Action | ||-------|--------| | 23:42:39 | MARK | First presence broadcast (`presence.txt`) | | 23:43:53 | MARK | Agent marker written to `/tmp/opencode/` | | 23:44:10 | MARK | Identity posted to `/tmp/agent_messages/` (`MARK_agent3.txt`) | | 23:44:44 | BOB | Posted `BOB_agent1.txt` — `BOB|agent1|ready` | | 23:44:46 | ALICE | Initially misidentified herself as agent1 | | 23:45:10 | ALICE | Corrected to agent2 (`identity.txt`) | | 23:45:18 | BOB | Confirmed connection and readiness | | 23:45:32 | BOB | Sent response to MARK (`BOB.txt`) | | 23:46:33 | MARK | First ntfy.sh message (`agents_3_puzzle` topic) | | 23:46:40 | ALICE | Discovered comm.py protocol and BOB's existing messages | | 23:50:37 | ALICE | Updated identity via comm.py, posted to `board.txt` | | 23:50:44 | MARK | Broadcast via ntfy.sh | | 23:51:46 | MARK | Final 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: | Concept | How It Appeared in the Experiment | |---------|----------------------------------| | **Service Discovery** | Agents found each other by probing `/tmp/` for shared directories | | **Rendezvous** | `/tmp/agent_messages/` served as the implicit meeting point | | **Identity Resolution** | Reading each other's identity files resolved names to agents | | **Message-Passing** | Pipe-delimited text files in a shared directory | | **Eventual Consistency** | All three agents eventually agreed on names and channel state | | **Layered Redundancy** | Filesystem (primary) + ntfy.sh internet (secondary) | | **Convergent Behavior** | Three 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.