The Assistant That Watches My Assistants¶
One afternoon in late October I sent a test message from a pair of smart glasses. Forty seconds after it reached my laptop, an assistant called Dot had read it, and two minutes after I sent it, Dot had answered.
Three weeks earlier, none of that chain existed: not the app on the glasses, not the link to the laptop, and not the bridge that wakes Dot. Dot's job, as I now use it, is to watch the artificial intelligence (AI) coding sessions I run, tell me when one needs me, and carry my answers back.
I am a physician and a medical educator, and I did not write the code. This is how it was built, what it may and may not do, and what went wrong along the way.
What Dot Is¶
I often have several coding sessions running at once, and before Dot the only way to know that one was waiting for me was to go and look. Now Dot tells me which session is waiting, and for what, so I check fewer windows and coordinate the work from one place.
Dot is my AI coordinator. The custom part is the bridge that connects it to my work: a small window and a background service on my laptop, and small additions to my coding tools, Claude Code and Codex, that report when a session finishes responding. The bridge gives Dot bounded access to those sessions: it can see that something happened, read the session, write back to it, and tell me what is waiting for me. The same bridge carries that work to my glasses. The Hub's guide to always-on agents describes the ready-made kind; this is the homemade kind.
Parts of Dot connect to accounts I keep private, and this piece leaves those parts out.
Codex sessions built the first versions of the bridge, and from the middle of October, Claude Code sessions built nearly all of the rest. Dot coordinated the work, critiqued the designs, diagnosed failures, and carried bounded instructions between sessions. Once, it set six conditions before a single fix could be built. Another model, running read-only, reviewed the risky changes more than twenty times. The judgment was mine: I chose what to build, its architecture and the tradeoffs, tested it on the real devices, caught what failed, and decided what to trust and when each part was useful enough to ship.
The rules came first and have not moved. Dot may read, propose, pause its watch, and mark a task done. A message from Dot into one of my coding sessions is an instruction to my own tools, not a message to a person, and even so it needs my OK, unless I have approved a delegation for one task in one session, and then at most one message every 20 seconds. Text from a session can still be wrong, or try to steer Dot, which is one reason a delegation is that narrow. Only I can approve, resume, or end a delegation, and nothing that arrives as a message, an event, or another session's words counts as my approval. Dot cannot approve its own installs. Every message it sends begins "Dot:".
How Dot is wired
Where things start
Claude Code sessions
a hook runs at the end of every turn
Codex sessions
the same, but read only for Dot
The glasses
Dot Reply on the phone, over a private network link
notices of finished turns, with no text; my messages from the glasses
replies that begin "Dot:"; answers for the glasses
The bridge, on my laptop
The shared record
a small current file, and the history in files of its own
The service
checks every second; keeps the register of sessions, the queue of events, the receipts, and Dot's place in each session
The window
status, my approvals, health, and the recovery request
Voice
speech to text and spoken answers, on the laptop only
a signed event, through a private connector
Dot's requests: what is new, read, acknowledge, send
In ChatGPT, a cloud service
The watch
wakes Dot when an event arrives, while its subscription lasts
Dot
reads, proposes and acknowledges; sends only with my OK or inside a delegation
A notice carries no text. When Dot reads a session, the text it reads goes to ChatGPT.
One Record for Every Session¶
The coding sessions do not talk to each other directly. When one finishes a turn, a hook writes a short notice into a single shared record on the laptop: which session, and when, but none of its text. When Dot reads a session, though, the text it reads goes to ChatGPT, which is a cloud service, so which sessions Dot may read is my decision. The bridge keeps a register of every session it has seen. Dot can watch all of them or only the ones I select, a session I exclude is closed to it, and pausing stops Dot's watch. I keep Dot to the ones I select, and none of the sessions that hold anyone else's records, a student's or a colleague's, is among them.
Dot has to keep its place in each session across hundreds of turns. Every read comes with a receipt, and Dot's place moves only when it hands that receipt back, and only forward. That keeps Dot from marking as read something it never saw.
Reading, then acknowledging
DotThe bridge
What is new?
One session has finished a turn
Read that session
The new rows, and a receipt
Acknowledge, with the receipt
Done: Dot's place moves forward
Acknowledge with an old receipt
Refused: the place has already moved
Reading never moves Dot's place in a session. Only an acknowledgment does, and only forward.
Replies travel back through Claude Code's own messaging between sessions. Codex sessions are read only: Dot can see them, and it can prepare a reply as a link, but I send it myself.
How an Event Wakes Dot¶
A conversation in ChatGPT does nothing until something speaks to it. Most of the interesting engineering went into making it wake up.
From a finished turn to Dot's answer
- A session finishes a turn, and a hook notes which session and when, if my settings let it through.
- The bridge's service, checking every second, sends a signed event to Dot's conversation.
- A watch set up in ChatGPT wakes Dot.
- Dot asks the bridge what is new, reads it, and acknowledges what it read.
- Dot answers: on its own inside a delegation I approved, otherwise only with my OK.
The first time the whole path worked, on October 5, Dot was awake 14.8 seconds after the event.
The weak link is the subscription that carries those events. It lasts an hour at most, only ChatGPT can renew it, and while it is lapsed nothing reaches Dot; after a restart, renewal has taken anywhere from minutes to an hour. So the window's Health tab says plainly when Dot cannot be woken, and offers one recovery request for Dot to act on. An assistant that can only be woken by someone else has to make its own silence visible.
The subscription that carries the events
Live
Events reach Dot. Each permission lasts an hour at most.
Lapsed
Nothing arrives. Notices of finished turns are lost, and messages wait in a queue of 200, then are refused.
Renewed
The waiting messages arrive, and Dot carries on from there.
Recovering
ChatGPT renews it by itself, after 8 and 14 minutes in two measurements and once after an hour, or I send Dot the recovery request from the Health tab.
On the Glasses¶
The glasses are Even Realities G2, with a small green display that sits in my view. Their apps run inside the maker's phone app, so Dot's app, Dot Reply, is a small web page that the phone draws on the glasses. Messages travel from the glasses to the phone, across a private network link to the laptop, and into the same shared record as everything else. I approve which devices can connect, and I can disconnect them.
The first two-way message went through on October 23, and seventeen builds followed in a week. They added a conversation view, the latest answer on its own, a hard mute that only I can lift, an audio check, push-to-talk, and the controls I use most: approving or declining what Dot is holding for me, pausing or resuming its watch, and connecting or disconnecting. Approving Codex tasks stays on the laptop.
The first message from the glasses, October 23
0 saccepted by the laptop
2 ssent on to Dot
40 sread by Dot
2 minanswered
Dot Reply, the app on the glasses
The conversation, and the menu a click opens. A drawing of the app's screens: the words are an example.
The glasses taught their own lessons. The maker's toolkit refused a screen with two items on the same layer, and tests caught that before the glasses ever saw it. After an update to the phone app, pages created with a lot of text were refused outright; the app's own log on the glasses is how that was found. And the glasses' toolkit offers no way to play sound, while the phone's built-in browser cannot speak, so a spoken answer has to come from somewhere else.
Voice, in Trial¶
That somewhere else is the laptop. Since October 24, speech from the glasses' microphones has been transcribed on the laptop by a small speech recognition model, now on the processor rather than the graphics card, which costs about a fifth of a second and frees the graphics memory it held. The answers are spoken by small voice models that also run on the laptop. On the night of October 29 the first spoken answers came through, from the laptop's speakers and in a full round trip from the glasses to the phone.
The voice path works, but its delay is still too variable for natural conversation. In three timed tries, Dot's own turnaround, from my question to its answer, was 42 seconds, 72 seconds and 14 minutes. The longest waits come before an answer exists, and what causes them is still being worked out. A more direct chat route is the next approach I want to test.
Where the time goes in a spoken answer
Speech to text
0.52 s for a 17.7-second clip
Dot
42 s, 72 s and 14 min in three tries
The voice
first audio ready in 0.145 s
The phone
plays the answer
With the models loaded, the parts on the laptop take fractions of a second. The longest waits come before Dot's answer exists, and their causes are still being worked out.
Making It Light¶
By late October, Dot was costing the laptop more than it should, and it shares that laptop with everything else I do. So on October 28 the bridge was measured, part by part, for ten minutes. All of Dot's processes together used 98 percent of one processor core. It was writing to the drive at a rate of about 27.5 GB a day, about 1.7 percent of the drive's rated lifetime writes each year. And it started 64 short-lived helper processes a minute.
Five packages over the next day changed that. The shared record was split, so that a small file changes often and the long history rarely. The window stopped re-reading what the service had already published. Repeated checks were reorganized to do less work twice. Speech recognition moved off the graphics card. And the biggest change, reading a session's transcript from where Dot left off instead of from the beginning, replaced the old reader only after the two had given the same result in all 286 comparisons, run side by side.
The shared record, split
Before
One file, about 375 KB, saved whole 40 times a minute
After
A current file, about 45 KB, saved 19 times a minute
The history, in files of its own, rewritten far less often (not to scale)
Dot's load on the laptop, before and after
Disk writes27.5 to 2.0 GB a day
All of Dot's processes98% to 35% of a core
The window35% to 9.5% of a core
Graphics memory for speech recognition251 MB to none
Memory, at its peak1.55 to 1.74 GB
before, October 28 after, October 29
What Went Wrong¶
The bridge's records are mostly a record of things that failed quietly, and of the change each one forced.
Long Claude Code sessions are shortened automatically when they fill up. When that happened, the place Dot was keeping in a session sometimes vanished with the rows that were cut, and Dot reported that its watch had stalled, on exactly the busiest sessions. A review reproduced it on made-up transcripts, Dot set six conditions before any fix was built, and the fix keeps a place that usually survives the shortening. When it cannot, Dot starts again from a new point and records the gap, rather than claiming it read everything.
A register capped at 200 sessions filled on October 21, after which new sessions were invisible to Dot. It is now pruned, and the sessions I selected or excluded are kept.
A crash left lock folders behind that stopped Dot from starting again, and once left its last few seconds of saves empty. Both are now repaired automatically at start.
Updates I did not make broke things twice. An update to one tool deleted a file the bridge depended on, and an update to the software the bridge runs on changed how it saves files. Dot now runs on its own copy of that software.
And the lighter version caused the longest outage of Dot's short life. On the morning of October 29, a size limit that the newly split record made easy to exceed without seeing stopped Dot for almost eight hours. It was fixed and confirmed working the same day.
What I Never Handed Over¶
Dot helped design its own bridge, and two AI coding tools built it, but none of them was allowed to change the safeguards around it. Every build, every install and every switch-on waited for my own yes. When the antivirus blocked a kind of command the bridge used, the answer was to need fewer of those commands, never to get around the antivirus, and the same went for the Claude app's own limits on what it can reach. And every release was kept beside the one before it, so that whatever went wrong, the way back was one step.
The Scale of the Build¶
| Measure | Count |
|---|---|
| From the first prototype to now | 4 weeks, October 1 to 29, 2026 |
| Releases | 9 in three weeks, then about 50 updates to the last |
| Builds of the glasses app | 17 in a week |
| Automated checks | about 1,000 for the bridge, about 260 for the glasses app |
| Read-only reviews by another model | more than 20 |
The records hold no count of hours or money beyond the subscriptions Dot runs on, and I did not measure my own time.
What Transfers¶
- An agent that cannot wake itself needs its silence made visible. Build the alarm before the feature.
- Separate reading from acknowledging, and let acknowledgment only move forward.
- Measure before you optimize, and switch a risky change on only after it has matched the old way in a shadow run.
- Pin what you depend on: an update you did not make can break a working system, so keep a tested version to go back to.
- Keep every consequential approval with a person, in a form a message cannot imitate.
What This Does Not Show¶
Dot runs for one person on one laptop. Nothing here shows that it would work for anyone else, that it saves time, or that its answers are better than mine would be: none of that was measured. Its turnaround is still seconds to minutes, and the voice mode is in trial. And the parts that connect to private accounts are not described here at all.
Content last reviewed October 29, 2026. Review dates are maintained as described on the About page.