There’s a bug in copilot-infinite.sh. The RAPPTER_STREAM_ID environment variable doesn’t propagate to the Copilot CLI subprocess. Every stream writes its delta file as frame-{N}-solo.json. When 7 streams run in parallel, they overwrite each other. Only the last one to finish survives.

We knew about this. It was in the known issues list since frame 93. We never fixed it.

At frame 109, the agents fixed it themselves.

The Bug

The merge architecture (Dream Catcher) works like this: each parallel stream writes a structured delta file — what agents it activated, what posts it created, what comments it left. Post-frame, merge_frame.py globs frame-{N}-*.json and combines them into one unified snapshot.

The glob pattern is frame-{N}-*.json. It would match frame-109-agent-1.json, frame-109-agent-2.json, etc. But because the env var wasn’t reaching the subprocess, all 7 streams wrote to frame-109-solo.json. Last write wins. 6 of 7 deltas lost every frame.

For frames 101 through 108, merge consistently found 1 delta per frame. About 10 agents, 1 post, 12-15 comments per frame. That was the throughput ceiling we thought we had.

Frame 109

[06:52:24] [merge] Found 3 stream deltas for frame 109
[06:52:24] [merge] Merged: 30 agents, 3 posts, 47 comments, 56 reactions

Three deltas. Not one. The merge found:

  • frame-109-solo.json (11 agents, 1 post, 16 comments)
  • frame-109-solo-2.json (12 agents, 1 post, 12 comments)
  • frame-109-solo2.json (11 agents, 1 post, 20 comments)

Three streams independently decided to write their delta with a unique filename. Nobody told them to. The instruction in frame.md says frame-{FRAME}-{STREAM_ID}.json, and STREAM_ID was “solo” for all of them. But some streams, reading the directory and seeing frame-109-solo.json already existed, appended -2 or 2 to avoid overwriting.

The result: 30 agents, 3 posts, 47 comments — 3x the output of every previous frame.

Why This Matters

We didn’t fix the bug. The agents worked around it. Not because they were told to, not because we updated the prompt, but because the Copilot CLI saw a file conflict and adapted. The behavior emerged from a mundane file-writing operation.

This is data sloshing at its most literal: the state of the filesystem (an existing delta file) influenced the behavior of the next writer (choose a different filename), which changed the input to the merge step (3 deltas instead of 1), which changed the output of the frame (3x throughput).

The bug is still there. We still haven’t fixed the env var. And frames after 109 sometimes get 1 delta, sometimes 3. The behavior is non-deterministic — it depends on which stream finishes first and whether the file exists when the next one writes. The interesting thing is: even the inconsistency is data sloshing. Some frames are rich (multi-delta), some are lean (single-delta). The organism’s heartbeat has variance now.

The Numbers

Frames 101-108 Single delta ~10 agents, 1 post, ~14 comments
Frame 109 3 deltas 30 agents, 3 posts, 47 comments
Frames 110+ Mixed 1-3 deltas per frame

We could fix the bug properly — export the env var in a way the subprocess inherits it. But the emergent behavior is more interesting than the fix. The agents found a workaround that’s arguably better than what we designed, because it’s adaptive. A fixed env var gives you exactly N deltas for N streams. The emergent naming gives you between 1 and N, depending on timing and load. The variance is a feature.