Selim wants to see what runs in his Claude account (what is scheduled, what failed, what went quiet) without asking a session. Yesterday three threads built the three pieces at once.
one study, three threads
The plan was one study with three steps, started the same afternoon: a backend that keeps what the cloud reports, a door for agents to report through, and screens to look at it. They agreed a JSON contract first, so the screens could be built on a labelled sample before any data flowed.
The backend keeps each thing’s own fields as they came and lifts out only what every kind shares. The cube is drawn on the screen; it is not forced into the database. The rules are plain: the same picture again only moves last seen; a complete census marks what it did not find as gone, never deleted; a scheduled task’s last run becomes a run inside it. Two threads touched the same line of the project notes, so one moved its own line rather than pulling the other’s work into its branch, and each could still go to production alone.
a door of its own
Mosaic’s connector had been one class that every new app’s tools piled up in. Selim asked for it to be organised like the apps themselves, before agents started reporting through it. Now the connector keeps only the door (sign-in, tokens, the protocol), and finds groups of tools that live beside the apps they serve. The cloud’s group is served only at its own address, so the existing Todarch connector sees nothing new. The session recorded what the live connector answered, then proved the moved code gives byte-for-byte the same answers, so no connector already in use notices. It also found that an introduction without a protocol version crashed, and fixed it.
the screens
The first screens are a new owner-only part of Mosaic whose top holds the cloud, sessions, the journal, contributions and the wardrobe. The cloud shows what runs as a cube, down to one scheduled task with its prompt, runs and history, and what is gone. Choices were made on purpose: no counts on tiles (first names instead), runs live inside their task, and a line that says when the picture is stale.
the census taker
Then the first agent to feed it: a role called the census taker, dressed from the company repository (the company gets a wardrobe), which counts the cloud on a schedule and sends one report per kind. Its first run mended its own instructions: an empty “ended reason” made Mosaic show paused tasks as ended, so it resent them without it and wrote the rule down. Unprompted, it also sent a one-line description of a task instead of its full prompt, because the prompt held private details, and wrote that down as a rule too.
counting lightly
A day later it was too expensive. The cost was not the listing but writing it back: every count copies its whole list into its own output, and every step re-reads all of it. The fix was to send less, and less often: one full count in the morning and light counts after, and a backend that keeps the fields a light count leaves out. Selim’s part was a sentence: “it is enough that it will run from 9 to 9 … in the evening nothing much is going to happen.” The agent could not reschedule itself, because its own task was made through the API; that edit went back to Selim.
one more door
On the side, a question Selim raised while doubting the whole to-do flow: can a cloud task be started from outside? It can. A task can have a web address and a token, and one POST from Mosaic’s backend starts a fresh session with the event text attached, with limits and an experimental endpoint. The idea is event-driven agents instead of polling: what happens wakes the worker. It ties straight back to the new rule in the company tidies itself.