It also cleaned up the UX around interruption
The nice side effect is that the assistant becomes easier to talk to during long tasks.
While a desktop job is running, I can still ask:
- what happened to the last run?
- how much is left?
- can you also write a script in the repo?
Those should not all be treated as reasons to interrupt the desktop flow.
The assistant can answer status questions from run state, do non-desktop work in parallel, and only queue the things that truly need the same physical controls.
That made the product feel less like a brittle automation demo and more like an actual operator with limited hands.
The rule I am keeping
If an agent can touch the real desktop, it needs to understand the difference between:
- parallel work
- exclusive resources
- explicit cancellation
- simple status follow-ups
Without that split, concurrency just becomes another word for collision.
That is now part of how I am shaping CliGate, the local control plane I use for Claude Code, Codex CLI, Gemini CLI, channels, desktop automation, and a resident assistant layer on top.
The project is open source here: CliGate.
If you are building local agents, are you treating the desktop as just another tool call, or as a resource that needs scheduling?