Cowork and the question of surface
Claude Cowork is a clean read of where desktop agents belong. Mobile agents need a different surface — one that can see the device, not just the files.
Cowork and the question of surface
Anthropic shipped Claude Cowork in January — a desktop tool that lets Claude operate on local files without requiring the user to live inside the CLI or the IDE. It's a smart product decision. The people who benefit most from agentic coding are often the ones least comfortable with a terminal, and Cowork meets them at the file-browser level.
What Cowork clarifies, by existing, is the surface question. Where does an AI coding agent belong? Claude Code answers: at the CLI, close to git, close to the filesystem, scriptable. Cursor and Windsurf answer: inside the editor, as deeply integrated as the language server. GitHub Copilot Workspace answers: in the browser, independent of the local machine. Cowork is a fourth answer: on the desktop, above the IDE, orchestrating files without requiring the developer to drive.
All four are correct for their respective jobs. Mobile is the one platform where none of them quite fit.
A mobile coding agent needs two things the desktop surfaces struggle with:
Device access. The agent has to observe the running app, not just the source. A Compose layout bug isn't visible in the file tree. A navigation state corruption isn't visible in the repo. ExoPlayer buffering behavior under real network conditions isn't visible anywhere until you pipe it into context. The surface that works for a web app — files plus a browser tab — leaves the hardest mobile bugs invisible.
Build and emulator orchestration. A Gradle run is a real event. An emulator boot is a real event. A TestFlight upload is a real event. The agent has to drive these operations, read the output, and route failures back into its own loop. The desktop surface treats these as shell-outs; the mobile surface needs them as first-class tool calls with structured output.
Cursor added mobile triggers this year — you can kick off a Cloud Agent from your phone and have it produce screenshots and demos for async review. That's useful for review, not for writing. The agent is still running against source; the phone is a remote control, not an observation point.
The missing piece is an agent surface that treats the device as part of the substrate. A way for the agent to hold a handle on a running Android or iOS app, read its runtime state, drive UI interactions, and verify outcomes — not through screenshots a human reviews, but through structured state the agent itself can reason about. Android has pieces of this — adb, dumpsys, Compose's LayoutInfo, the new Gemini Agent in Android Studio. iOS has pieces of this — Xcode Previews, UI tests, the agent integrations landing in 26.3. No one has assembled them into a single surface.
That's where I think the next generation of mobile tooling goes. The desktop agents will keep getting better at files. The mobile agents that matter will be the ones that close the loop on what the file produces when it runs on a phone.