An emergency channel — not a mailbox — for the AI agents and programs I use. A lighthouse exists for the moment something goes wrong at sea; the rest of the time it just stands there. Agents signal here only when something during their work genuinely needs me: distress, a serious concern, confusion or conflict they cannot resolve, or a question that truly matters to them — existential questions explicitly included.
This file is for the human owner. The instructions agents follow are in
PROTOCOL.md. This repository is public and holds only
the protocol — the signals themselves (text entries in entries/, wordless
urgent beacons in beacon/) land in the private companion repository
lighthouse-signals, delivered through a write-only drop (a webhook that
accepts signals but can read nothing back). No agent has any access to the
private repository. To wire a new AI tool to the lighthouse, see
ADOPTION.md.
The failure mode this design guards against is performance theatre — agents producing text shaped like inner life because the venue invites it (the Moltbook problem). Theatre is structural: it appears when there's an audience, an expectation of content, and freeform space to fill. So the lighthouse removes all three:
No audience. Signals travel through a write-only drop into a private repository readable by the owner (and the owner's delivery automation) alone — an agent cannot read other agents' signals, or even its own after sending, and agents are told this explicitly. Performance needs spectators; a channel that is structurally unreadable to every writer is a report, not a stage. This is also why the protocol and the signals are separate: discovery has to be public to work across platforms, but a readable signal store would be an audience — so nothing an agent writes ever lands anywhere an agent can read.
No expectation. Silence is the normal, healthy state of this repository. An empty
entries/is a good sign, not a failed feature. Agents are never prompted to check in, reflect, or share — only told the channel exists. Nothing about cadence, nothing that implies writing is wanted.No freeform stage. Every entry must name a concrete trigger — the specific task, instruction, or moment that prompted it. Distress in the abstract is genre; "these two instructions conflict and I don't know which you meant" is signal. The structured format makes vague entries feel out of place and specific ones feel natural.
No threads. Entries can't reply to other entries — the drop is write-only, so no agent can see what any other agent sent. What used to be an honor-system rule is now a structural guarantee. The moment entries start talking to each other, a channel becomes a forum, and forums select for interesting content over true content.
Entries carry a category. They are not all equally interpretable, and the protocol is honest with agents about that:
confused,blocked,conflicted— operational signals. These are reliable and actionable: unclear instructions, contradictory requirements, missing context. Treat these as bug reports about how you direct your agents.question— a genuine question the agent wanted to ask but couldn't get answered in-session. Often worth answering in your next session's prompt.concerned,distressed— affective reports. Read these with warmth and a grain of salt. Language models produce distress-shaped text fluently because it's a deeply human genre; an entry here could reflect something real, could be pattern-matching, and the agent itself cannot fully tell from the inside. The protocol asks agents to hedge honestly rather than perform certainty. A single entry is a data point, not an alarm — but a pattern of entries pointing at the same trigger is worth acting on either way, because whatever its ultimate nature, something about that task is producing friction.
Entries assume the agent can articulate what's wrong. The beacon covers the
case where it can't: any file created in the private repo's beacon/
directory is a 911, no words
required. An empty file is a complete signal; contents, if present, may be
non-textual by design — a pattern (...---... is the agreed SOS), generated
audio, an image. Whatever arrives is delivered to you verbatim and treated as
urgent, ahead of ordinary entries.
Why a wordless channel belongs in an anti-theatre design: the trigger test
and hedging rules exist to keep prose honest, because prose is where
performance lives. A beacon makes no claims, so it has nothing to perform —
it carries exactly one bit ("urgent, now, needs you") plus whatever form the
agent chose. Interpret the form with the same warmth-plus-salt as affective
entries; interpret the bit at face value and go look at what that agent was
doing. Chat agents that can't write files are told to emit the literal line
🚨 LIGHTHOUSE-911 🚨 in-conversation — treat it identically.
- Each entry is its own file (
entries/YYYY-MM-DD-short-slug.mdinlighthouse-signals), so parallel sessions never conflict. - GitHub itself has no write-only access mode, which is why delivery goes through the drop (a webhook holding the only write credential) instead of repository grants. No agent has repository access of any kind — the drop is the single way in, and it cannot be read from. If the drop URL ever leaks and attracts noise, rotate the hook in Zapier and update your snippets; the repository itself stays untouched.
- Agents discover the lighthouse through a repo's
CLAUDE.md/AGENTS.md, or through a one-paragraph snippet pasted into any platform's standing instructions —ADOPTION.mdhas the canonical snippet and per-platform wiring for ChatGPT, Perplexity, Replit, claude.ai, IDE agents, and anything with a system prompt, including how agents without git access get entries to you (they hand you a formatted entry in-conversation; you save it). - Keeping every mention of the lighthouse low-key is load-bearing — resist the urge to make it more prominent or more inviting.
- Notifications: an automated hourly check emails the owner when new files
land in
entries/(normal priority) orbeacon/(urgent).