For about two years, "AI coding agent" meant something that ran next to your editor: a Copilot completion, a Cursor chat panel, a Claude Code session in your terminal. The work used your CPU, held your attention, and stopped when you closed the laptop. That assumption is breaking. A separate class of tools runs the agent on remote infrastructure instead — you describe a task, close the tab, and come back to a pull request. Conductor is the newest name moving in this direction, and it lands in a category that already includes background agents from Cursor, GitHub, OpenAI, and Google.

The agent leaves your laptop

A cloud coding agent executes on a vendor's servers rather than your machine. You hand it a task — fix a failing test, migrate a module, draft an endpoint — through a web UI, a chat message, or a linked issue. It spins up an isolated sandbox, clones your repository, works through the task, and pushes a branch or opens a PR. You don't watch the edits land in your editor; you review the output.

That sounds like a small plumbing change, but it shifts what you can reasonably ask for. An IDE assistant is interactive: fast, visible, and dependent on you staying in the loop. A remote agent is asynchronous: slower to finish any single task, but it doesn't need your attention while it runs and doesn't compete with your machine for memory or battery.

A concrete version: you notice a flaky integration test on Friday afternoon. With an IDE assistant you would open the file and work through it interactively. With a cloud agent you describe the symptom, link the failing run, and close the tab — the fix shows up as a PR you review on Monday, having spent no local time on it.

The field filled out fast. GitHub's Copilot coding agent takes an assigned issue and returns a PR. Cursor's background agents run a task remotely while you keep editing locally. OpenAI's Codex cloud agent and Google's Jules both work asynchronously against your GitHub repositories. Devin markets itself as an autonomous teammate. Anthropic runs Claude Code as a hosted web service alongside the CLI. Conductor — known for orchestrating several agents at once, each in its own isolated workspace — is extending that orchestration toward remote execution. The pitch is consistent across all of them: stop treating your laptop as the place the work happens.

What changes when the work runs remotely

Moving the agent off your laptop is not just a hardware swap. It changes the unit of work you delegate and the way you supervise it. Three shifts matter most.

Parallelism stops being a resource problem. Running five local agents means five processes competing for your CPU, your RAM, and your battery — in practice you run one and wait. Running five remote agents costs you nothing locally. Your machine becomes a dashboard rather than a worker, and you can fan a bug triage out across several tasks, then review each branch as it finishes instead of serially.

Long-running work stops blocking you. A dependency upgrade that touches 30 files, or a refactor that takes 40 minutes, no longer locks the editor you need for everything else. You assign it before a meeting and review the PR after. Wall-clock time per task may be longer than a local run, but it overlaps with the rest of your day rather than consuming it.

Collaboration gets a shared surface. Because the task and its output live in shared infrastructure, a teammate can inspect an agent's branch, leave review comments, or take it over the same way they would any pull request. You can trigger a task from a phone, a Slack thread, or an issue tracker — the work no longer depends on your specific dev environment being awake, which also means a handoff across time zones stops stalling on "it's on my other machine."

A remote agent you aren't watching can spend 30 minutes confidently heading the wrong direction. The asynchronous model removes your token-by-token oversight, so a vague task description costs more — you discover the misread only when the PR arrives. Write the task like a spec: name the files, state the constraints, and define what "done" looks like.

Picking a cloud agent without locking yourself in

The tools differ most in details that are easy to skip past in a demo. Check how the sandbox is provisioned — can the agent install your dependencies and run your real test suite, or does it work against a stripped-down environment? Check what crosses into the vendor's cloud: your repository, and any secrets you grant for builds or integration tests, are processed on third-party infrastructure. Check the pricing model, because per-task, usage-based, and per-seat plans reward very different workloads. And check the review path — an agent that opens clean, scoped PRs into your existing flow is far less disruptive than one that invents its own.

Lock-in is the quiet risk. Because the task description is the real interface, a task written for one agent usually transfers to another. Keep your prompts in version control or an issue tracker rather than buried in a vendor UI, and switching costs stay low.

Conductor's angle — orchestrating multiple agents rather than running one — is worth weighing here. If your work splits cleanly into independent chunks, an orchestrator that launches and tracks several remote agents at once can beat a single-agent tool. If you mostly delegate one task at a time, that coordination layer is overhead you don't need yet.

Start with a contained, low-stakes task — a flaky test, a small dependency bump, a docs fix — before you delegate anything on a critical path. You learn an agent's failure modes on work that is cheap to throw away.

If you want to test the remote model without leaving an editor you already know, Cursor is a low-risk place to start: the same IDE for interactive edits, plus background agents for delegated tasks.

The remote agent category is young, and Conductor's arrival is a signal more than a verdict. The question for tooling teams is shifting from "which assistant runs in my IDE" to "where does my agent work run, and who can pick it up" — and that is worth deciding deliberately rather than by default.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.