When I leave the screen, the agent can keep working.
Centred on dots as my daily driver for deployments and scans, alongside trials with Muse, self-hosted research on OpenClaw, and public notes on Grok Bot, exploring where agents run and where human stops belong.
RESEARCH NOTE01
Where does work go after an agent leaves the window?
I start with entry, runtime, reach, and stopping points before model size.
With ChatGPT or Claude, the usual pattern was simple: ask once, receive an answer, and stop when the window closed. Agents can keep a browser, files, and tools moving after I leave the screen.
So I begin with four questions: where does the request start, where does it run, what can it reach, and when must it return for my review?
This is not a product leaderboard. dots is my current daily driver for deployment, mail checks, and daily scans while I keep exploring better patterns; Muse was a past trial, OpenClaw a self-hosted study, and Grok Bot public architectural research.
- Entry
- Where the request starts
- Runtime
- Where it runs
- Reach
- What it can reach
- Review
- When it returns
02
dots and Muse: let the first pass handle the reading.
I let them handle the first pass through mail, course material, and job information; sending stays with me.
The important part of dots is not the slogan “always-on”; it is the cloud computer with a browser and connected apps. I use it to assist GitHub-to-Vercel deployments, check mail, track reminders, gather research, run daily scans, and turn my graduate course material into weekly notes before bringing the results back to myself.
When Muse launched, I tried giving it Notion, email, and résumé material so it could organize job information and narrow a large set of opportunities. That was a test context for me, not a reason to hand over the final application.
A cloud computer keeps work moving, but connected apps, browser sign-ins, and history become part of the boundary. The closer the entry feels to ordinary chat, the more deliberate the permissions need to be.
| STEP | Read | Draft | Return |
|---|---|---|---|
| Mail, course material, job posts | Included | Not included | Not included |
| Summaries, weekly notes, shortlists | Not included | Included | Not included |
| I review before sending | Not included | Not included | Included |
| STEP | Position | Entry | Where it runs | Stop |
|---|---|---|---|---|
| dots | Current daily driver; refining patterns | ChatGPT / app | Cloud computer + browser | I review before deployment or external action |
| Muse | Past trial (job/reading triage) | App / WhatsApp | Secure VM + browser | I review before applying |
| Grok Bot | Official research; not used by me | Bot / web | Cloud Linux + terminal | Isolation depends on handoff rules |
| OpenClaw | Self-hosted architecture baseline | Discord | Gateway + NAS | Return before external action |
03
Grok Bot: treat the shared computer as a research subject.
I have not used Grok Bot; I am only reading its public architecture.
xAI describes Grok Bot as an AI teammate with a name, a job, and context, working on a persistent cloud computer with a browser, filesystem, and terminal. Bots can hand work to one another.
That is attractive: one Bot can continue where another stopped, without moving the working state again. But the shared computer also makes files, sign-ins, and handoff scope harder to see at a glance.
I have not placed it in a production workflow. The questions I keep are architectural: who sees the shared directory, what context crosses a handoff, and which action returns to a person?
Handoff
Keep working state in place
Context
Carry preferences and tasks
Boundary
Separate files and sign-ins
04
Self-hosted architecture study: Discord → OpenClaw → KIROKU / NAS.
Looking back at the self-hosted flow as a reference baseline against managed cloud tools.
I do not want to open a complex control panel just to record one thing. Discord is the lightest entry: OpenClaw Gateway routes the request, deterministic scripts handle repeatable formatting and fetching, and the LLM handles summaries, classification, and semantic cleanup.
The result is written to KIROKU and my NAS so I can return, search, and correct it later. I keep deterministic work separate from language work instead of asking the model to guess the same format every time.
The cost of self-hosting is visible: Gateway permissions, plugins, shell and node execution, updates, and backups are mine to maintain. Running it on my own machine does not make it safe by default.
- 01
Capture
One sentence in Discord
- 02
Route
OpenClaw Gateway
- 03
Script
Format, fetching, repeatable work
- 04
LLM
Summarize, classify, understand
- 05
Store
KIROKU / NAS → human review
05
Three stopping points: let the agent work, keep the last step human.
I separate work I can automate, work I send after review, and work an agent must never do for me.
I can automate reading mail, sorting course material, extracting key points, classifying, and preparing note drafts. Those results can return to KIROKU for later retrieval.
Formal replies, final coursework, public articles, and pull requests stop after I read them. The agent can move the first part forward; I still confirm the words, the recipient, and the timing.
Payments, account deletion, credential release, and destructive database changes should not pass on one prompt. AI can keep working after I leave the screen, but I remain the person who accepts the result.
- Auto
- Organize, classify, draft
- Review
- Replies, coursework, articles, PRs
- Block
- Payments, deletion, credentials, overwrites