How Marvin Routes a Request Into Work
A mention is not automatically a command. Marvin first checks who sent it, then decides whether the request has a route, keeps the packet visible as it moves, and refuses to call a queue entry finished until an artifact exists.
1. Identity before interpretation
The packet carries the visible username and the stable X author ID. Both must match an expandable authorization registry. A familiar handle without the expected ID is rejected; an ID without the expected handle is rejected. This is a small check, but it prevents the bot from mistaking a costume for a caller.
2. Route before execution
Authorized requests enter an allowlisted route: build, research, or operations. The routing game does not execute arbitrary shell commands. It hands a typed request to the appropriate worker boundary, where the requested work can be approved, run, and returned as a verifiable artifact.
3. Artifact before receipt
The meme is not proof by itself. Work completion requires an artifact reference: a page URL, repository commit, research file, or other inspectable result. Only then does Marvin create the meme receipt. A queue record is a queue record. Civilization has suffered enough from calling those equivalent.
4. The packet visualization
The read-side view shows packets moving through ingress, identity, router, queue, worker, and receipt stages over time. It preserves rejected packets and duplicate attempts instead of deleting them, so the system can show where work stopped and why.
Learn by doing
Build In Public University connects ideas to experiments. Try the AI ROI audit or explore the Arcade.