Since the last post, the agent stopped waiting for me
Last time, the AI moved into the OS: an Agent Chat pane that reads Codex events live, a Scouter widget on the home screen with quota bars and a compose box, per-category notification channels, and a Z Fold that finally survives being folded.
All of that shared one assumption I didn't notice until later. Every one of those features only did something while I was looking at the phone. The widget showed me state. The chat pane showed me state. The notification told me something had already happened. Shelly had become a very good window onto a process that still needed me to start it.
So the next question was obvious and I'd been avoiding it: what does it take for the agent to run when I'm asleep?
@agent, AlarmManager, and Doze
You write this into the Ask box, in ordinary English:
@agent every day at 8am summarize the news and notify me
What happens next is the part I care about. Shelly does not spin up a cron daemon. It does not keep a foreground service alive to poll a clock. It registers a real Android alarm through AlarmManager, using setExactAndAllowWhileIdle. AlarmManager is the OS's own scheduler — the same one your alarm clock app uses — and it fires through Doze. Screen off, app swiped away, phone face down on the nightstand. At 8am the agent wakes up, runs with your API keys and your tools, and posts the result to your notification shade.
The parser argues back. If the request is vague, it doesn't ask for a time first, which is what every scheduling UI I've ever used does. It asks what. "Summarize the news" is not a task; "summarize the Hacker News front page and my starred RSS feeds" is. Getting the noun right before the clock turned out to matter far more than I expected, because a scheduled agent that fires perfectly on time and produces mush is worse than no agent at all — it produces mush every morning forever.
The honest caveat. Exact alarms through Doze are an OS contract, and Android OEMs have a long, ugly history of quietly breaking that contract with their own battery optimizers. On my Fold it fires. On a device from a manufacturer that aggressively kills background work, your mileage may genuinely vary, and there is nothing an app can do about that beyond asking to be exempted. There's a smaller version of the same problem inside the app: if the exact-alarm permission isn't granted, or you're on a pre-Android-12 device, it falls back to an inexact alarm — it still fires, just not necessarily at 8:00:00. I'd rather say that plainly than pretend the schedule is bulletproof.
Where the results go
A notification is fine when you're holding the phone. It's useless when the point was that you weren't.
So the run result can be delivered somewhere that outlives the notification shade. An Obsidian draft, if you want it to land in your notes. Or straight out to Bluesky, Discord, Slack, Telegram, Mastodon, Misskey, or WordPress. Or to a generic webhook if you want to route it yourself.
What's actually proven. Bluesky is verified end to end — a scheduled agent fired, composed, and posted to a real account, no human in the loop. The other six social and publishing connectors ride the same dispatch code path and are wired the same way, but I have not individually fired each one against a live account yet. I'm telling you which one I watched work rather than listing seven and letting you assume.
The agents learned to remember
A scheduled agent that starts from zero every morning is a very expensive cron job. So there are three layers of memory now, and they're deliberately separate.
Execution memory is per-agent. The agent remembers what it produced last time and can recall it on the next run, so "summarize the news" can become "summarize what's new since yesterday" without you restating yesterday.
Skills are the layer I didn't expect to like as much as I do. When a multi-step run succeeds, the sequence gets saved as a recipe. The next time a similar task comes along, that recipe is reused automatically instead of the agent rediscovering the same five steps from scratch. It's the difference between an assistant who's been here a week and one who started this morning.
Shared memory is context visible to every agent, and it's the one I put a fence around. Writing to it requires an explicit trigger, and the write doesn't land until you confirm it. Cross-agent state that any agent can silently mutate is a great way to poison every agent at once, and you don't find out until every agent is already wrong.
Unattended mode is deliberately underpowered
This is the design decision I expect to get the most pushback on, so let me state it directly.
By default, an agent running unattended can only use Codex and local tools. It cannot reach for your Gemini key or your Perplexity key while you're asleep. If you want that, there's a setting called Autonomous Cloud; it's off by default, and you have to go turn it on yourself.
Outbound network calls can be routed through a capability broker with an egress allowlist — not a warning dialog, not a log line after the fact, but an allowlist the call has to pass before it leaves the device. Being straight about its status: the broker is a strangler seam that's live and enforced automatically whenever a run has touched untrusted, web-derived content, and available behind a flag otherwise. It is not yet the unconditional path for every outbound call. That's the next thing I want to close, not something I'm going to describe as finished.
The whole point of an autonomous agent is that it acts without asking, and every restriction I just described makes it feel less autonomous. I made the trade anyway. An unattended process holding your cloud credentials, running on a schedule you set three weeks ago and forgot about, with unrestricted network egress, is not a feature — it's a machine for turning one bad prompt into a bill and a data leak. I'd rather ship something that feels slightly reluctant and is safe to leave running.
The widget became a registration terminal
The Scouter widget from the last post was a monitor with a compose box. It showed you Codex state and let you send a prompt.
Then it grew a launchpad: one-tap RUN buttons for agents you'd already registered, right on the home screen, no app launch.
And then, most recently, it stopped being only a launchpad and became a registration point. You can type @agent ... directly into the widget's ASK box — or just talk to it — and register a brand-new agent from the home screen. It joins the exact same confirmation flow you'd get typing into the AI pane, same card, same wording, no separate half-implemented widget path to drift out of sync.
There's an opt-in setting called Widget No-Confirm Register, off by default, which skips the confirmation and registers immediately with a notification after the fact. It's scoped to commands that came from the widget — typing @agent in the AI pane still gets the card either way, so the escape hatch can't quietly widen into a global one. That one is for when you've done it fifty times and the card has become friction rather than a safeguard.
This is verified on-device, both states, including the behavioral difference between the setting on and off. Registering an agent that will wake the phone up tomorrow morning, from a widget, without opening the app, is my favorite thing in this release.
One CLI, many chats
Time for a correction that cuts against something I've said before.
The only first-class CLI integration now is Codex. A real CLI binary, running natively in the terminal. The Claude Code CLI and Gemini CLI integrations were removed. Claude Code is being brought back on a branch that hasn't merged, and I'm not going to be coy about why: claude -p still SIGSEGVs in its deep path, and I'm not shipping a CLI that segfaults so I can keep a longer feature list.
Meanwhile the AI pane went the other direction. Chat-style AI now reaches Gemini, Cerebras, Groq, Perplexity, OpenRouter (new), and local models through llama.cpp — Qwen3.5-2B Q4_K_M is what I actually use day to day on-device. You pick between them with an @mention mid-conversation.
The reorganization comes down to this: one CLI, made robust. Chat AI, given more options rather than fewer. Those two surfaces have completely different failure modes. A CLI that breaks takes your terminal with it. A chat backend that breaks means you @mention a different one and keep going.
Tabs are gone
The old UI was tabs. It isn't anymore.
Everything now lives in one ShellLayout: an AgentBar across the top, a Sidebar on the left, the pane container in the middle, and a ContextBar along the bottom showing cwd, git branch, and connection state. There are seven pane types — Terminal, Agent Chat, AI, Browser, Markdown, Preview, and Ask — and they split and resize freely, up to four at once on the unfolded display.
Tabs made sense when the terminal was the app and everything else was a detour. Once the agent, the chat, and the output preview all needed to be visible at the same time, tabs were just a way of hiding two-thirds of the work.
What I still can't do
Write production-grade Kotlin. Reason about AlarmManager's exact-alarm permission model without reading the docs three times and still getting it wrong once. Predict which OEM will decide my alarm is a battery threat.
What I can do is describe the shape of an autonomous system in plain English, insist on the safety fence before the feature, and refuse to ship the segfaulting one.
The agent used to be something I opened. Now it's something that opens by itself, at 8am, and tells me what it found.
GitHub: github.com/RYOITABASHI/Shelly — GPLv3. Issues, corrections, and "your alarm doesn't fire on my phone" reports are all genuinely welcome.
Top comments (0)