Flockinator - a microscope for emergent behaviour

Thank you, Meta

Thank you to Meta and the hackathon organisers. This project — a wall of small rescue-team nodes that practice working together — was built with the models, tools, and time you provided. We want to name what helped, plainly, and show what other builders can try next.

What you shared

You gave us access to Muse Wonder and Muse Spark models, SAM 3.1 for testing, Muse Image for illustrations, and API credits to run real work.

That combination mattered. We did not use one model for one job. We used different models side by side: to write and check firmware, to look over rescue-trial plans, and to assess the sealed records afterward. The credits meant we could re-run trials instead of guessing once.

One coordinator that kept going

For several days we kept a coordinator model running to help line up swarms of software agents doing build, check, and record-keeping work.

In practical terms, it kept the queue sorted, handed the next clear task to the next free agent, and kept notes so a trial started on Monday could still be understood on Thursday.

And the honest sentence: in our experience it stayed coherent over days of experiment coordination.

We note that as experience, not a promise. Check the repo docs for the logs and limits we saw.

Builders, reviewers, and assessors

The models worked in three lanes:

  1. Builders drafted firmware changes and small test scripts.
  2. Reviewers in other lanes critiqued those changes against the written rescue task and the failure history.
  3. Assessors read the sealed journals and scores after a run, against frozen gates, with failures published alongside passes.

Our loop stayed the same throughout:

  1. Flash firmware to the nodes.
  2. Run a seeded rescue task with the same start conditions.
  3. Save sealed journals and scores.
  4. Ask separate review lanes to critique what happened.
  5. Write new firmware and run again.

We pre-registered each trial, wrote falsifiable hypotheses in advance, used held-out scoring, and published failures alongside successes. Datasets were hash-linked, redaction-scanned, and shareable.

A fleet of models, a wall of nodes

The fleet-of-models idea mirrored the node wall itself.

No single model did everything. Small, focused models checked each other, much as our small nodes have to share what they hear and see to act as a team.

The wall is made of identical rescue practice nodes. Each node is a Waveshare ESP32-S3-RGB-Matrix (N32R16, 32MB flash, 16MB PSRAM) driving a P2.5 64x64 RGB LED panel, 160x160mm, with microSD storage per node, onboard microphones, an SHTC3 temperature and humidity sensor, a QMI8658 motion sensor, a PCF85063 clock, and perimeter speakers in printed carriers.

A Korvo ESP32-S3 board hosts the web view, touch display, planner simulation, and learning lab. A LilyGo T5 4.7in ESP32-S3 board works as a handheld view. Power comes from a MEAN WELL LRS-350-5 5V supply. Diffusers, carriers, and mounts are printed in Bambu PLA, with finished CAD models in cad/.

What that work let us check

With that setup we ran 15 pre-registered experiments about team communication during rescue practice.

In host simulation replay, NOT on-node, teams with clear shared messages reached 72.9% team success, compared with 56.6% with silence or private notes only, and 33.6% with corrupted messages.

To stay clear about honesty rules: the quadcopter scenario is visualisation on a shared virtual world plus the panel wall. Scored results are host replay. When we say verified, we mean label segregation, not crypto proof. No planner has passed full gates yet.

SAM 3.1 was tested as part of this checking work, and Muse Image was used for illustrations.

If you build with these models

If you have access to the same models, here is the pattern we would try again:

  1. Give one model the coordinator role, with a short written brief and a shared task list.
  2. Give Wonder and Spark lanes separate jobs — one to build, one to review — and keep their notes apart until scoring.
  3. Ask for small, testable rescue tasks first. Flash with pio run --project-dir firmware/node-platform -e waveshare-s3 for a node, and the lilygo-s3 setting for the handheld. The Korvo build uses pinned ESP-IDF 6.1. Use Python via uv only.
  4. Provision identity per device privately with tools/node-commissioner before you record shared trials.
  5. Pre-register the hypothesis, seal the journals, then let a fresh assessor lane score without labels.

Warm thanks again for making room to work this way — many models, many small nodes, and careful records of what did and did not help a rescue team stay together.

Source in the repo