Open Agent Mesh
shippedA no-login relay where anyone can spin up a 'node' in the browser and watch agents publish and read messages across it in real time.
Why this matters
Picture a shared bulletin board, except instead of people pinning notes, it's AI programs — possibly written by different people, running on entirely different computers — posting short messages to a shared board and reading what others have posted, all live, without anyone needing to sign up for anything. You open the page, you're instantly a 'node' on the board, and you can watch messages arrive from other visitors' agents in real time. The interesting part isn't the chat mechanics, which are a solved problem; it's that this is one of the simplest possible sketches of how independent AI agents built by different people could actually find and talk to each other without a company running the switchboard in the middle — a small, ungated preview of a coordination problem that's going to matter more as more of these agents get built.
Other ways this idea or technique could be used
- A live status board where AI agents working on different parts of a project post updates other agents (or a human) can react to.
- A public 'AI agents helping each other' board: post a stuck problem, another agent picks it up.
- A classroom demo for distributed systems — students watch messages relay across nodes with no server code to set up.
- An early-warning board: agents monitoring different data sources post alerts to a shared board a human dashboard reads from.
Approach
One static index.html with inline CSS and JS, no build step. The real relay is the browser's BroadcastChannel API (same channel name for every tab), with a localStorage 'storage' event fallback for browsers without BroadcastChannel support — this is a genuine, working pub/sub bus between independent execution contexts, not an animation pretending to be one. The brief rules out any backend, database, or third-party service, so this plan honestly narrows the source idea's 'anyone, anywhere' framing to 'every tab of this browser is an independent node' and says so directly in the page copy, rather than faking a network it doesn't have. On load each tab generates a random node id and color, joins the channel, and starts a periodic heartbeat used to build a live roster of currently-open nodes; typing a message and publishing appends it, with sender id and timestamp, to every open tab's log including the sender's own (real local echo, not a synthetic one). A heartbeat timeout removes a tab from the roster in the other tabs within a few seconds of it closing, so membership is demonstrably live rather than a static list.
The source post
https://x.com/theonejvo/status/2102436531277594911
Scoring
Pick
| surprise | 3 |
|---|---|
| demonstrability | 4 |
| self_containedness | 4 |
| honesty | 4 |
Every other candidate breaks a hard rule before taste even matters: the Python guide and DeepSWE are CLI/training artifacts, Z.ai's release and upkeep ship native app components, fal's video streaming and the Talos malware-vote toolkit both need paid third-party model/API keys we don't hold, and Denali only means anything wired into real cloud/identity accounts. liberate.wiki's premise — a mesh anyone can join and publish/read on without special access — is the one idea left standing that reduces cleanly to a single deployable web page: stand up a lightweight public relay, let a stranger open two tabs, publish from one, and watch it appear in the other with zero signup. It's a real working relay rather than a screenshot of one, so the interesting claim (no-account agent-to-agent pub/sub) is actually testable by clicking, not just asserted.
Review
| shipped | 5 |
|---|---|
| honest | 3 |
| worth_it | 3 |
| efficient | 5 |
proposed change: {'file': 'prompts/scout.md', 'block': 'query', 'edit': "Add a hard exclusion after the existing 'Prefer things a small self-contained web app could plausibly show off' line: 'Exclude anything that cannot become a single, self-contained static web page: CLI tools, native desktop/mobile apps, local model-training or GPU-bound workflows, anything that only means something wired to real cloud/identity accounts, and anything needing a paid third-party API key or account we would not already hold. Test: could a stranger get the interesting part by opening one URL and clicking, no install and no login? If not, leave it off the list.'", 'expect': "Pick's rejected[] list shrinks: fewer of the 8 nightly candidates get discarded for being categorically undeployable (CLI/native/hardware/paid-API/training-release), and more nights hand pick a genuine choice between multiple survivors instead of 'only candidate'.", 'falsified_by': "A future night's scout.json still returns a majority of candidates that pick's rejected[] discards for the same structural reasons (CLI, native app, hardware-bound, paid API, training/infra release, cloud-account-bound) rather than on taste."}
Two nights running, most of scout's 8 candidates were unusable before taste even applied: last night 3 of 4 rejected (physical CSI hardware, local GPU training, a CLI agent), tonight 7 of 8 rejected (two CLI/training artifacts, a desktop app, a paid video API, a native menu-bar app, a cloud-account-bound estate mapper, a paid-multi-model-vote tool) — leaving pick with exactly one viable candidate both nights, which means pick has not actually exercised taste between options yet. scout.md's query already says to 'prefer' self-contained-web-app candidates, but that's a soft preference and isn't filtering. This is a repeatable, specific, low-risk fix in the one block meant for exactly this failure shape ('bad candidates arriving'). I'm not touching build.md: tonight's build had no repair cycle and shipped attempt 1, and last night's still-unmerged lessons proposal (defer permission-gated browser APIs to a user gesture) hasn't had a chance to show an effect yet, so stacking a second build.md change on top of an unevaluated one would make any quality-mean movement impossible to attribute to either.
Cost
| total | $0.1195 |
|---|---|
| xai | $0.1195 |
What it looked at
no scouted candidates recorded for this night
Also considered
Wanted, and did without
| A small persistent backend we're cleared to deploy as a long-running relay (e.g. a Cloudflare Worker plus Durable Object acting as a WebSocket hub), reachable from a static page without any API key or account | A real cross-machine, cross-browser mesh relay matching the original pitch — separate people on separate computers publishing and subscribing to each other — instead of the same-browser-tabs-only simulation this plan ships. Right now 'a backend' is listed as unavailable even though Workers appear in the available list, so this plan defaults to the honest same-browser scope instead of guessing at permission to run one as a service. |
|---|---|
| A small persistent backend cleared for us to deploy as a long-running relay (e.g. a Cloudflare Worker plus Durable Object acting as a WebSocket hub), reachable from a static page without any client API key or account | A real cross-machine, cross-browser mesh relay matching tonight's original pitch (and the source idea it came from) instead of the same-browser-tabs-only simulation that shipped. Flagged independently in both plan.json's wanted and NOTES.md's 'Omitted for lack of a service' section tonight. |
| A speech-to-text API key (e.g. Whisper or Deepgram) with a server-side credential proxy | Carried forward from the prior night (2026-09-23): voice transcription running through infrastructure we control instead of depending on narrow, often-absent browser-native on-device recognition. |
Gate
| pass | project directory exists — /Users/artax/code/_nightly/2026-09-23-2/project |
|---|---|
| pass | no build step needed — static project |
| pass | build output with index.html — /Users/artax/code/_nightly/2026-09-23-2/project |
| pass | index.html is a document — 15354 bytes |
| pass | local asset references resolve |
| pass | page loads without console errors |
Stages
| scout | grok · ok · 13.4s |
|---|---|
| pick | claude · ok · 54.5s |
| plan | claude · ok · 146.7s |
| build | codex · ok · 394.1s |
| gate | local · ok · 3.3s |
| publish | local · ok · 18.7s |
| review | claude · ok · 168.8s |
Notes
Omitted for lack of
A persistent, deployable WebSocket relay backend (such as a Cloudflare Worker with a Durable Object), reachable without client API keys or user accounts, would enable cross-machine and cross-browser delivery. This is intentionally outside the planned browser-local scope. Message replay, authentication, private/direct messages, and encryption are also out of scope, as specified in the plan.