“Organize my photos when I have time” does not need an exact appointment. An instruction sent to a coding agent, however, has to arrive when the agent is ready to receive it. Some steps can be removed; others need to stay.
DottieNote, Tactic Remote, and MadoHub each contain choices of this kind. Here are three examples, covering the problem, the implementation, and its effect on how the product is used.
DottieNote: capture a task before choosing a time
Finishing a book or sorting old photos may already be something you want to do, even if you have not chosen a day. A required date field can encourage you to pick an arbitrary date, turning an unscheduled intention into an apparently definite calendar entry.
DottieNote 2.0 added Anytime plans for tasks without a fixed time. You can capture the intention first and arrange a focus session when you are ready. Tasks with a specific time can still be scheduled; the two kinds of plans do not need the same form.
The release also grouped task type, duration, and reminders in a quick-add panel, while smart voice input recognized dates, times, and recurrence rules. These reduce input in different ways: leave undecided information open, and organize information the person has already expressed.
“Read for half an hour tomorrow evening” includes timing information to review and correct. “Organize my photos when I have time” has no deadline to extract. Distinguishing those intentions is more useful than simply removing buttons.
Tactic Remote: a paused terminal may not be ready for a task
Integrating Factory Droid in Tactic Remote 1.9 involved several startup screens: update prompts, sign-in, directory-trust questions, and mode selection. Each can pause on screen while expecting a different kind of input.
Sending a queued task immediately could type it into a sign-in prompt or startup menu. Seeing terminal output on the phone confirms that text arrived, not that the session is ready for the task.
The integration identifies startup states and waits for a task-ready interactive state before sending queued instructions. Session identifiers are retained so project switching and reconnection can return to the same work.
The mobile scope is specific, too. Droid uses the repository, dependencies, and sign-in state on the development machine; the phone provides viewing and interaction. In 1.9, Droid uses terminal mode. Claude Code's structured chat and dedicated approval cards are not Droid features, and initial sign-in may still require the development computer.
Supporting another agent therefore involves startup detection, input timing, session recovery, and a clear account of which steps the original tool still handles. Those details determine whether a familiar mobile workflow carries across.
MadoHub: a new desktop shell, a separate native runtime
MadoHub's macOS desktop app has migrated to Electron. React renders the canvas and sessions; an isolated Rust Host handles capabilities such as terminals, files, and persistence. The migration retains that division instead of rewriting the Rust core inside the interface process.
A native request from the interface passes through a restricted bridge to Electron's main process. Main checks the sending window and page, then validates the arguments. Requests requiring lower-level capabilities go to the Rust Host. The renderer has no direct Node.js integration or generic messaging interface.
That carries a development cost. Adding a capability means updating the agreement between the interface, bridge, main process, and Host. Connecting a button is only part of the work. In return, native operations have defined entry points, and failures can be traced to arguments, calling permissions, or execution.
The Host protocol also checks version and capability information. When the interface and native components do not match, it rejects requests. These checks belong in package validation; a browser demonstration alone cannot exercise them.
Electron and Rust are not features in themselves. The practical questions are which working directory the app accesses, which native operations the interface can call, and what happens when versions disagree. Process and interface boundaries provide more useful answers than broad claims about being native, safe, or reliable.
