24 channels. One database. One human gate.
Wiring a model to your accounts is the easy part. Making it cheap enough to run every fifteen minutes, and safe enough to let near a real inbox. That is the whole project.
Twenty four places a message can arrive.
Each one is a kernel. Each kernel exposes named verbs. Nothing here is a screenshot of a dashboard. It is the fleet.
Telegram runs two ways: a bot and a personal MTProto session. Gmail carries four OAuth personas.
One calm screen on top of all of it.
Twenty four channels resolve into a single queue: what needs her, in one place, in the order it should be answered. One row per person, not per channel, and the phone is the approval door.
A brand emails. Twenty four channels, one row per person.
The whole history is there, whichever channel each part of it came in on.
Ask it about the account in plain words. Nothing typed here can reach the customer.
Dropbox and all three channels. It answers from what it actually opened, then hands a draft down into the box.
And it stops there. Nothing leaves until she taps it.
The queue is assembled by verbs, not by a model reading inboxes. Every item that would leave the system stops here and waits for a tap.
A verb is a Python call. It costs zero tokens.
verb (n.) a deterministic function on a kernel. Same input, same output, no model in the path.
164 of the 263 verbs are reads. Reads are where the token bill accumulates in an agent-shaped system, and reads are exactly what a deterministic call does for free. That is the whole trade. It is also why the loop can run every fifteen minutes instead of once, when you remember to ask.
No external watcher, no hook, no policy file. The constraint is compiled into the verb itself and shaped to the specific irreversible action: a structural sendUpdates=none on every calendar write, a Luma write function that simply does not exist, an approval hash check on every send path, a POST_ALLOWED env gate on public posts.
No file ever records which machine or host a channel lives on. Every call re-asks the live session, through the authenticated same-origin API, never the rendered DOM, which the docs call a rumour. A written-down location is a photograph of a moving thing.
Not a setting. Not a default that can be flipped in a config. One shared, fail-closed gate is the only way out of the system: every send hashes its whole payload, spends the grant once, and resolves every ambiguous state to not approved.
A click path that works once in a throwaway script is a violation, not a deliverable, until it is promoted into kernel.py. That rule is why the count is 263 and not a folder of scripts nobody can call twice.
Every channel writes into one store.
messages.db. One SQLite file, single writer. Twenty four inboxes stop being twenty four inboxes at the moment they land in the same table.
Alongside it, accounts.json is an expected-identity registry, not a credential store. It answers "which of her personas should be logged in here," and nothing else.
Forty one invariants. One of them is the wall.
Security here is not a posture, it is a registry. Every rule this system must never break is written down, numbered, and checked by a machine, including nine non-capabilities: things it is forbidden to ever grow.
The floor is the part that matters. 26 lives in a committed file, and the suite fails if fewer than 26 pass, so loosening the standard means typing a smaller number into version control on purpose. A check that has ever passed may never quietly fail again.
One store. Many readers.
The messenger is one reader sitting on top of the store, not the thing itself. This is where the same store goes. Events, market research, outbound, and the video engine, which renders a cut and then publishes it back out through the same channels and the same gate as every other send.
Adding a system means writing a reader, never a second database. That is the whole reason the store is the product and the inbox is only the first thing built on it.
The hard parts were the consent layer and the token economics.
Everyone can wire a model to a tool. Those two are what stand between a company and pointing an agent at real customer accounts, and they are the two that got built here first.