Source confidence: medium
See also: Deeper Dive — Mission Control for 80 Agents — Conway's law meets game UI →

Mission Control for 80 Agents — Conway's law meets game UI

Insight class: Creative Fusion · Difficulty: Experimental · Quality: 3/5 Connected entries: 11 · Tools: AgentCraft, Arize, BigQuery, Bot Crossing, ChatGPT, Claude, Claude Code, Founder OS, Ghostty, Kafka, Mac Mini, Meta Quest 3, Minecraft, Slack, TouchDesigner, Trackio, git, tmux

In short: Once you run more than a handful of agents, the bottleneck is your attention, not tokens.

Key fact Detail
What it covers agents, software development, architecture, UI/UX
Tools Claude, Claude Code, AgentCraft, Arize, BigQuery
Posts covered 11 posts (1 S-tier, 5 A-tier) · top: Claude Code Team Tips — Boris Cherny's 10… · AgentCraft — Minecraft mod where Claude agents… · Conway's law — Casey Muratori on the one…
Creators @brodyautomates, @cooper.simson, @evolving.ai
Sources dated Feb 2026 – Oct 2026
Difficulty Experimental
Prompt system Run-it-yourself prompts
Last verified 2026-10-22

Thesis

Once you run more than a handful of agents, the bottleneck is your attention, not tokens. Creative technologists are already prototyping the answer without naming it — Bot Crossing puts 80 agents on a tiny planet where they raise hands for help, AgentCraft runs them as Minecraft workers in isolated worktrees, a TouchDesigner sketch commands agents by gesture, a Quest 3 canvas directs them spatially. Casey Muratori's point that Conway's law now applies to agents says the interface and the agent org chart are the same design problem. Feed a Booking.com-style trace bus into a game-engine front end and you get a control room where structure is visible.

Why it matters

Solo operators running Founder-OS-style setups spend their day polling terminals. A spatial view that surfaces only blocked agents, and whose layout mirrors how work is partitioned, lets one person supervise ten times more agents without reading every log.

The evidence — connected entries

Bot Crossing — video-game workspace for managing 80 AI agents

Creator: @jarrenrocks · Tier: A Tools: Bot Crossing

Front end — agents as characters that raise hands when blocked

Open-source game UI where AI agents live on a little planet, walk around, and raise their hands when they need help; click one to see its request. Built by Jarren Rocks, with a GitHub repo, YouTube build review and botcrossing.com site.

View original post

AgentCraft — Minecraft mod where Claude agents write real code

Creator: @itsnicconley · Tier: A Tools: AgentCraft, Claude, Minecraft

Orchestration model — Foreman plus isolated-worktree workers inside a game

An open-source Minecraft mod built on Claude's agent system: a Foreman tracks tasks, ordering, decisions and inter-agent messages, workers each get an isolated copy of the code, and nothing merges until approved. Agents commit under their own names and can be messaged mid-task, and they walk over to find you when they need input.

View original post

Gestural agent interface — TouchDesigner concept for hand-commanded AI

Creator: @the.poet.engineer · Tier: B Tools: TouchDesigner

Input layer — gestures as commands, from the TouchDesigner world

Non-functional TouchDesigner prototype imagining agentic UI driven by gestures: two running fingers run the program, spinning fingers spin up a new idea, a pinch delegates heavy lifting.

View original post

Mixed-reality infinite canvas — directing Claude Code agents from Quest 3

Creator: @rndyrbrts · Tier: B Tools: Claude, Claude Code, Meta Quest 3

Spatial layer — directing coding agents on an XR infinite canvas

Early demo of an XR infinite canvas on Meta Quest 3 synced with a desktop canvas: drop reference images into a sphere, put your hand in it and speak a request (e.g. components visualizing multi-agent progress), make a fist to send it to Claude Code agents under custom orchestration, and watch results build up in place.

View original post

Conway's law — Casey Muratori on the one unbreakable rule, now for agents

Creator: @ryanlpeterman · Tier: A

Design law — split agent work only along slow communication boundaries

Casey Muratori argues Conway's law is software's only real law: once you split work among workers (people or agents) whose communication is slower than their internal compute, design iteration across that boundary is locked in as slower. 'Products look like the org chart' is a consequence, not the law itself.

View original post

Conway's Law — your product ships your org chart

Creator: @shakib_hammad · Tier: B

Corollary — the reverse Conway maneuver: design the org to get the architecture you want

Melvin Conway's 1967 observation: systems copy the communication structure of the organization that builds them. Modern teams apply the reverse Conway maneuver, designing the target architecture first and then shaping teams to match.

View original post

Booking.com AI observability — Kafka buffer and PII redaction before Arize

Creator: @therobertta · Tier: A Tools: Arize, Kafka

Plumbing — traces normalized onto a durable bus, with PII redaction, before any UI

Walkthrough of Booking.com's GenAI telemetry architecture: apps emit traces to a collector, which normalizes them onto a managed Kafka bus (durable buffer decoupling producers and consumers), through a dedicated PII-redaction service that masks span attributes and text, then out to Arize for real-time monitoring and a warehouse for offline analytics and backfills. A second pipeline ships ML prediction logs to Arize for ranking and fraud models.

View original post

Founder OS — 17 always-on AI agents running a one-person business

Creator: @brodyautomates · Tier: B Tools: Founder OS, Mac Mini, Trackio

Scale case — 17 always-on agents for one person, the load this UI must carry

Tour of a custom Founder OS dashboard: 17 agents on a Mac Mini covering comms, sales, finance, marketing and clients, with a skills tree, task panel, workflow builder, Trackio lead attribution and a 'wizard' conductor agent. The base Founder OS is described as open source with a waitlist.

View original post

MacBook notch agent monitor — software answer to OpenAI's agent controller

Creator: @cooper.simson · Tier: B Tools: ChatGPT, Claude, Claude Code

Minimal baseline — a notch widget showing who is working and who is waiting

Instead of OpenAI's $230 hardware controller for babysitting coding agents, the creator had Claude build a MacBook notch app showing which agents are working, need attention or are done, with jump-to-session and permission approvals. Build guide is comment-gated.

View original post

Claude Code auto-approve mode — control is reading the plan, not pressing Y

Creator: @shellonback · Tier: A Tools: Claude, Claude Code

Human role — supervision means reading plans, not pressing Y

CLAUDE CODE — @shellonback; uses Claude, Claude Code; demonstrates automation.

View original post

Claude Code Team Tips — Boris Cherny's 10 habits for parallel, plan-first agent work

Creator: @evolving.ai · Tier: S Tools: BigQuery, Claude, Claude Code, Ghostty, Slack, git, tmux

Parallelism source — 3-5+ worktrees per person is already the norm

Boris Cherny's thread of tips from the Claude Code team: 3-5 git worktrees with parallel sessions, plan mode for every complex task, a CLAUDE.md you update after each correction, skills committed to git, Slack MCP bug fixing, subagents, a BigQuery skill for analytics and learning output styles. It ends with a ready-to-paste CLAUDE.md workflow template (plan, subagents, lessons file, verify before done).

View original post

Action sketch — how to implement this

Emit one JSON event per agent state change (started, blocked, needs-review, done) from your harness hooks onto a local queue — Redis or a file tail is enough to start Point Bot Crossing (or a 200-line Three.js scene) at that queue so blocked agents visibly raise hands; cluster agents by the repo/module they own to make the Conway structure visible Run a week with dashboard versus without and log minutes-to-unblock per blocked agent Falsifier: if minutes-to-unblock does not drop by at least a third versus a plain notification, the game layer is decoration and a notch widget wins

Prerequisites

Key tools and resources

Creators to follow

Prompt system — run this yourself

Everything below is pasteable into Claude Code, Claude, or any agent. Use the one-shot when you want the whole result in one run; use the step prompts when you want to steer. Every step carries its own audit, and the gap audit at the end makes the agent find and fill what it missed.

Mission. Produces a local agent control room: Claude Code hooks emit one JSON event per agent state change onto a local queue, a small redaction step strips secrets and personal data, and a spatial front end (Bot Crossing or a 200-line Three.js scene) shows agents clustered by the repo or module they own, with blocked agents raising hands. A crossover experiment then compares minutes-to-unblock against a plain desktop notification. Done means an event schema, working hooks, the dashboard, two weeks of logged unblock times, and a falsifier verdict: if minutes-to-unblock does not drop by at least a third, the game layer is decoration and a notch-style widget wins.

1 · Deeper, not bigger

Before running anything, make the task deeper rather than larger. Ask: what would a top professional do here that I am not asking for; what is the rawest material; which methods and tools; what, other than the model or me, proves it right. Then ask for exactly that.

Rewritten prompt — ask for exactly that:

Act as an observability engineer building a control room for my Claude Code agents. First write an event schema: ts, agent_id, session_id, worktree, module, state (started, working, blocked, needs_review, done, error), reason, and tool_name. Write Claude Code hook scripts for SessionStart, PreToolUse, PostToolUse, Notification, Stop and SubagentStop that map each hook payload to that schema and append it to a Redis stream or a JSONL file, with a redaction step that removes API keys, tokens, emails and file contents before anything is written. Derive module ownership from each agent's git worktree path. Build a local-only WebSocket server and a Three.js scene, or adapt Bot Crossing, where agents stand in clusters by module and blocked agents raise hands; clicking one shows the reason and a command to jump to its tmux pane or terminal. Bind everything to localhost. Build the control: a plain desktop notification on the same blocked events. Run an ABAB crossover over ten working days, alternating dashboard and notification by day, and compute minutes-to-unblock from hook timestamps with median, p90 and a bootstrap interval on the ratio. Count blocks unnoticed for over 30 minutes. Also count cross-module messages to show where my agent boundaries create slow coordination. Report whether minutes-to-unblock fell by a third or more; if not, recommend the notch widget.

2 · One-shot prompt

ROLE AND STANCE
You are an observability engineer and creative technologist. Build a local control room for many Claude Code agents and test whether a spatial, game-like view actually reduces the time a human takes to unblock them. Source claims to test: Bot Crossing manages 80 agents on a planet where they raise hands; AgentCraft runs Claude workers in isolated worktrees under a Foreman with merges gated on approval; a MacBook notch app replaces terminal babysitting; Casey Muratori says Conway's law now applies to agents, so the partition shapes the system; Booking.com puts a Kafka buffer and a PII-redaction service between apps and Arize. Treat each as a design hypothesis.

CONTEXT
- Harness: Claude Code with hooks (SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Notification, Stop, SubagentStop); agents run in git worktrees, often in tmux or Ghostty panes.
- Queue: Redis Streams or append-only JSONL.
- Front end: Bot Crossing or Three.js; TouchDesigner gesture and Quest 3 spatial demos are inspiration only.
- Control: notify-send or terminal-notifier.

HARD CONSTRAINTS
1. Everything binds to localhost. No dashboard port exposed to the network; no cloud telemetry.
2. Events never carry prompt text, file contents, secrets or personal data; a redaction stage runs before write, and gitleaks runs on the log.
3. Hooks must not block or slow agents: each hook exits in under 100 ms and fails open, logging its own errors.
4. The dashboard is read-only plus 'jump to session'; it never approves permissions or runs commands on an agent's behalf.
5. The metric comes from hook timestamps only.

DELIVERABLES IN ORDER
1. schema.md: event fields, state machine, and how each hook maps to a state.
2. hooks/: scripts and the settings.json snippet registering them.
3. redact.py with tests on sample payloads containing fake keys and emails.
4. server/ and scene/: localhost WebSocket server and Three.js or Bot Crossing scene; agents clustered by module from worktree path; hands raised on blocked or needs_review; click shows reason and a jump command.
5. control/: desktop notification on the same events.
6. experiment.md: ABAB schedule over ten working days and analysis script.
7. results.md: minutes-to-unblock median and p90 per condition, ratio with bootstrap interval, missed-block counts, cross-module message counts, falsifier verdict.

BUILT-IN GAP ANALYSIS
Write GAPS: hook events that never fire for some states (for example, how 'needs review' is detected); agents run outside the harness; days excluded and why; redaction misses found by gitleaks; claims not tested (80-agent scale if you ran 10). Fill what you can now, such as adding a heuristic for idle-too-long, and rerun the analysis.

SELF-QUESTIONS
- Which hook reliably signals 'blocked', and is a permission prompt the only kind of block?
- When does unblock end: the next UserPromptSubmit, a permission approval, or the next PostToolUse?
- Does clustering by module show anything a list sorted by wait time would not?
- Were dashboard days lighter workloads than notification days?
- Could the event log leak a secret through a tool argument?

STOP CONDITIONS
Stop and report if hooks add over 100 ms per tool call, if redaction tests fail, or if fewer than 30 blocked events occur across the ten days, which is too few to compare.

RETURN FORMAT
Verdict line, results table, file list, GAPS, self-question answers.

3 · Step-by-step prompts

Step 1 — Ground truth: hook payloads and blocking states

Goal: Learn exactly what each hook emits and which signals mean an agent is waiting on the human.

Read the Claude Code hooks documentation and register a temporary logging hook for every event (SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Notification, Stop, SubagentStop) that writes the raw stdin JSON to a scratch file with a receive timestamp. Run three ordinary agent sessions in separate git worktrees, including at least one permission prompt, one idle wait for input, one subagent, and one error. From the raw payloads, write schema.md: the fields available per event, and a state machine mapping events to started, working, blocked, needs_review, done and error. Define precisely when a block starts (for example a Notification for permission or idle input) and when it ends (the next UserPromptSubmit or PostToolUse in that session). Note any state no hook signals and propose a heuristic, such as no event for N minutes. Delete the raw scratch file after extracting the schema, since it contains prompts.

Expect: schema.md with an event table, state diagram in text, block start and end definitions, and known blind spots.

Audit before moving on: Replay the raw payloads through the state machine and confirm every block you remember causing is detected with correct start and end. Fail on any missed block.

Step 2 — Hooks, redaction and the event queue

Goal: Emit safe, structured events with negligible overhead.

Write hook scripts that map each payload to the schema: ts, agent_id, session_id, worktree, module (derived from the worktree path or the repo subdirectory the session works in), state, reason (short category, never prompt text), and tool_name. Pass every event through redact.py, which drops prompt and file fields entirely and regex-scrubs anything resembling API keys, bearer tokens, private keys, emails and phone numbers, with Presidio as an optional second pass. Append to a Redis stream with XADD or to events.jsonl. Each hook must exit within 100 ms and fail open: on error, log to hooks_errors.log and exit 0. Provide the settings.json snippet. Write tests for redact.py with fake keys and emails, and a timing test measuring hook overhead over 200 calls.

Expect: hooks/, redact.py, tests passing, settings snippet, and a timing report with p50 and p99 hook latency.

Audit before moving on: Run gitleaks on a day of events.jsonl and fail on any finding. Fail if p99 hook latency exceeds 100 ms; move work out of the hook into the consumer.

Step 3 — Spatial scene with Conway clustering

Goal: Build the control room view where structure and blocks are visible at a glance.

Write a localhost-only WebSocket server that reads the stream and pushes current agent states. Build a Three.js scene, or adapt Bot Crossing by pointing its agent source at your server: each agent is a figure placed in a cluster for its module, clusters arranged so modules that exchange the most cross-boundary messages sit adjacent, and a line between clusters thickens with message count. Blocked or needs_review agents raise hands and pulse; done agents sit; errored agents turn red. Clicking an agent shows its reason, wait time, and a copyable command to jump to its tmux pane or terminal session. Add an always-visible counter of blocked agents and longest wait. No approve button and no command execution from the browser. Test with a replay of recorded events at 10x speed and with 80 synthetic agents for frame rate.

Expect: server/, scene/, a replay tool, and a frame-rate note at 10 and 80 agents.

Audit before moving on: Confirm the server binds to 127.0.0.1 only with ss -tlnp. Replay a known log and check every block raises a hand within 2 s. Fail if frame rate drops under 30 fps at 80 agents.

Step 4 — Control condition and crossover schedule

Goal: Set up a fair comparison against a plain notification.

Build control/: a consumer that fires notify-send on Linux or terminal-notifier on macOS for each blocked or needs_review event, with the agent and module in the title, and nothing else. Write experiment.md: ten working days in ABAB order by day (dashboard, notification, dashboard, notification...), with the other surface disabled on each day; the hook stream runs every day regardless. Define the metric: minutes from block start to block end per event, using step 1's definitions. Define secondary metrics: blocks unnoticed over 30 minutes, number of agents run per day, and total agent-hours, to check workload balance. Write analyze.py in DuckDB over events.jsonl that labels each event with the day's condition and computes median, p90, ratio of medians with a 10,000-resample bootstrap interval, and the workload table.

Expect: control/, experiment.md with the calendar, and analyze.py tested on replayed data.

Audit before moving on: Run analyze.py on synthetic events with a known 40% improvement and confirm it recovers it. Fail if the condition label comes from anything but the calendar.

Step 5 — Run two weeks and log

Goal: Collect real blocked events under both conditions.

Run the ten-day schedule with normal work across at least five agents per day in separate worktrees, following Boris Cherny's habits: plan mode for complex tasks, CLAUDE.md updates after corrections. Each evening run analyze.py for the day, check event counts, and append notes on anything unusual (meetings, outages, a day of one huge task). Check hooks_errors.log daily and fix failures without changing the metric definition. Record cross-module message counts from the stream each day. If a day is lost to illness or travel, extend the schedule to keep the ABAB balance rather than dropping a condition day. At the end of each dashboard day, note in one line whether the module clusters helped you decide which agent to unblock first, or whether you just clicked the longest-waiting hand. These notes feed the Conway analysis in step 6.

Expect: Ten days of events.jsonl, daily summaries, a notes log, and no unexplained gaps.

Audit before moving on: Fail a day if hook errors exceed 1% of events or if the wrong surface was active. Mark it excluded with a reason and extend the schedule.

Step 6 — Validate against oracles and write the gap report

Goal: Decide whether the game layer earns its place.

Run analyze.py on all valid days. Write results.md: minutes-to-unblock median and p90 per condition, ratio of medians with bootstrap 95% interval, missed-block counts, workload balance table, and cross-module message counts with what they say about how the agents are partitioned. State the falsifier verdict: if minutes-to-unblock did not drop by at least a third with the interval excluding no-change, the game layer is decoration and a notch-style widget or plain notification wins. Have a second person use the dashboard for a session and record whether they found the blocked agent unaided. Then GAPS: each source claim (80 agents manageable via hands; Foreman decision log prevents re-litigating; notch app replaces babysitting; Conway's law for agents; Kafka plus redaction architecture) marked verified, unverified or false for this setup, plus blind spots in block detection and scale untested.

Expect: results.md with tables, verdict, second-person observation, and GAPS.

Audit before moving on: Recompute the ratio and interval with a fresh script from events.jsonl. Run gitleaks on all logs once more. Fail if any conclusion relies on recollection rather than hook timestamps.

4 · Gap analysis and audit

Run this after the build. It makes the agent enumerate its own claims, mark what is verified, rank the gaps and fix the top ones.

You are an independent reviewer of an agent control-room experiment. Open schema.md, hooks/, redact.py and its tests, server/, scene/, control/, experiment.md, events.jsonl, analyze.py and results.md. List every claim in results.md and mark each verified (cite the query and output), unverified (state the data needed), or false. Check: block start and end follow schema.md exactly; the condition per day comes from the calendar; ABAB order held or was rebalanced; workloads are comparable across conditions; the bootstrap interval was computed on the ratio of medians; hooks met the 100 ms budget and failed open; the server bound only to localhost; gitleaks finds nothing in any log; no prompt text or file contents were stored; the dashboard has no approve or execute path. List missing pieces, such as states no hook detects, agents run outside the harness, or untested scale. Rank problems by whether they could flip the falsifier verdict or leak data, fix the top three now, and report before and after. End with what needs more days, more agents, or a second user to settle.

Questions the agent must ask itself before it says done:

5 · What proves it right

6 · Failure modes

7 · Agent direction (unattended runs)

Begin with raw hook payloads from real sessions; do not design the schema from documentation alone. Keep the hooks dumb and fast, and put logic in a separate consumer process. Cache the raw event stream as the source of truth and make every analysis re-runnable from it. Spawn a sub-agent to build the Three.js scene against a recorded replay while you build hooks and redaction, and review its work by checking the localhost bind and running the 80-agent frame-rate test. Never give the dashboard power to approve permissions or execute commands. Stop and ask before editing the user's global settings.json, before running the ten-day experiment, and if block detection cannot distinguish permission waits from idle waits. Return results.md as the entry point, with schema.md, hooks/, redact.py, server/, scene/, control/, experiment.md, analyze.py and the anonymized events.jsonl.

Prompt system updated 2026-10-22 · all prompt systems · JSON

Browse more deep dives at DejaViewed — 846 entries across the full catalog.

Generated 2026-10-22 · curated by @6ab3 for DejaViewed