← Back to the orrery

What Is This?

A real home network, rendered as a solar system — built end-to-end by a team of AI agents in one afternoon.

The idea

Every device on a home Wi-Fi network is quietly orbiting the router: checking in, phoning home, leaking tracker requests. This page makes that visible. The data behind it is a live scan of an actual home network, baked down to an anonymised snapshot.

The sun is the router (a FRITZ!Box, promoted out of the device list). Planets are devices. Ring = category (infrastructure innermost, then computers, phones, tablets, media, smart home). Size = how much tracker chatter the device generates. The slate outer ring holds unidentified devices — mostly phones using randomised MAC addresses, which are designed to be unrecognisable. The network sees them; it just can't name them. That's a privacy feature, shown honestly. The comet is a flagged unknown device on an eccentric orbit — the one worth squinting at. Shooting stars are blocked tracker requests streaking toward the sun and burning up — one per real Pi-hole block. (If the sky is quiet, the snapshot was baked without Pi-hole stats.) The black hole is the Pi-hole — blocked queries spiral in; disk brightness is the live block rate. Constellations are devices that report to the same tracker.

The whole system auto-fits your window — rendered as a printed instrument panel: the spacetime sheet dips where the Pi-hole sits, and the whole sky replays the last baked 24 hours. Drag the timeline to any moment. Scroll to zoom toward the sun, click a planet for its card (label, vendor, category, and when the router and Pi-hole have been consulted, current link TX/RX speed and DNS activity). The layout respects prefers-reduced-motion.

The privacy contract

This is the part of the brief that was non-negotiable: the public data file must never contain a MAC address, IP address, hostname, or family name. Three layers enforce it:

What you can see in network.public.json is the whole dataset: vendors, categories, sizes, synthetic ids like d7 — plus, when the bake had router and Pi-hole access, bare numbers for link speed and DNS counts and a connection type from a fixed four-value list. Free-form strings from the router never pass the gate; even the Wi-Fi band is re-mapped through a closed dictionary so an SSID can't hitch a ride. Nothing else survived the bake.

The brief

The build started as two documents in the repo: a design spec and a 15-task implementation plan with full test-first detail — written so that an agent could execute it task by task. The instruction given to the build agent was one sentence long: implement the plan, delegate the live scan to a separate Opus-model agent, and keep the privacy tests intact.

How it was orchestrated

The build ran inside Claude Code with Claude Fable 5 as the conductor. The conductor wrote almost no code itself. Instead it ran a subagent-driven development loop (from the open-source Superpowers plugin) — for every task:

By the numbers: 15 plan tasks, ~40 agent dispatches across four model tiers (Fable 5 conducting, Opus for the sensitive and final-review work, Sonnet for implementation and review, Haiku for trivial fixes), 27 tests, 22 commits, and one human decision point — the design call you can read about below.

The scan that the builder never saw

The live network scan is the privacy-critical moment: it produces a file full of real MACs, IPs and hostnames. So the conductor delegated it to a separate Claude Opus agent under a written contract: run the scan and the bake entirely in your own context, return only the leak-check verdict, the device count, and the path of the clean file. Raw data lives in a gitignored folder and never crossed back into the conductor's context — an information-flow boundary made of agent architecture, not just promises.

It mattered twice. The first bake came back 18-of-19 devices "unknown" — the plan's vendor lookup table was too small for the real network. A second Opus agent went back into the raw data alone, identified vendors from MAC prefixes, extended the lookup table (committing only 3-octet vendor prefixes, which identify manufacturers, not devices), and re-baked. Unknowns dropped to 10 — and the remaining 10 are genuinely unknowable randomised-MAC devices.

What the review gauntlet actually caught

The two-stage reviews weren't ceremony. Real catches, each fixed and re-verified:

The one human decision

When the real data came back with ten flagged devices, the plan's "one dramatic comet" design collided with reality. The agents flagged the conflict instead of guessing; the human picked the fix: keep one comet, give the other unknowns their own honest slate-coloured outer ring.

The stack

AppTypeScript, Vite, HTML5 Canvas 2D — no framework, ~7 kB of JS
Pipelinetsx scripts: ARP scan + Pi-hole API → anonymise (allowlist) → leak-check → static JSON
TestsVitest, 27 tests, TDD throughout the pipeline and scene math
AgentsClaude Code · Fable 5 conductor · Opus scan/enrichment/final-review agents · Sonnet implementers & reviewers · Haiku fixers
ProcessSuperpowers plugin: written plan → subagent-driven development → two-stage review per task → publish gate before deploy
HostingCloudflare Pages, fully static

Why

This is a working demonstration of two things at once: that AI agents can take a written brief through plan, implementation, adversarial review, a privacy-isolated data pipeline and deployment with one human decision along the way — and that your home network has a story worth looking at.

It was built as part of Signal Over Noise, where Jim Christian writes about AI integration and knowledge management for humans who'd like to stay in the loop. If you want the longer version of builds like this one, the newsletter is the place.