Two releases in the last nine days quietly changed what "agent workflow" means for engineers.
On August 26, 2026, VS Code introduced the Agent Host and the open Agent Host Protocol (AHP). On September 2, 2026, Cursor launched Self-Hosted Machines and expanded its push to run Cloud Agents on hardware you control.
They sound similar because both target the same pain: agent work should survive longer than one editor tab. But they solve different boundaries.
VS Code is fixing session durability and portability. Cursor is fixing execution locality and infrastructure control.
Round 1: Where the agent actually runs
Cursor is the clearer answer if your real problem is, "I need the tools to run on my machine, not yours."
Its Self-Hosted Machines docs are explicit: the worker runs file edits, terminal commands, local MCP servers, and optional computer use on a machine you manage, while Cursor keeps the agent loop, inference, and planning in its cloud. The September 2 launch also says teams can place those workers on their own servers or partner sandboxes such as AWS Lambda, Cloudflare, Modal, Namespace, E2B, Daytona, Coder, and Vercel.
VS Code's Agent Host is different. It is a dedicated process that owns sessions, locally or on a remote machine next to the workspace. That is a strong architecture change, but it is not a hosted worker fleet product.
Winner: Cursor, if the first requirement is execution on your hardware.
Round 2: What happens at the network boundary
Cursor's docs are blunt about the tradeoff: it is not on-prem. The checkout, build cache, and machine-local credentials stay on your machine, but tool outputs, diffs, screenshots, local MCP results, and routing metadata can flow back to Cursor so the cloud agent loop can continue. The worker opens an outbound HTTPS connection; Cursor does not initiate an inbound connection into your network.
That model is practical for teams that need private registries, Macs for iOS, GPUs, or internal services without opening inbound ports. It is less attractive if planning and inference must also stay fully inside your boundary.
VS Code's Agent Host story is narrower but cleaner. The host runs next to the workspace, and the docs describe clients connecting over a message port locally or JSON-RPC over WebSocket remotely. If you run code agent host --tunnel, you are exposing a session host, not outsourcing execution to a vendor-managed worker fleet.
Winner: VS Code for architectural clarity. Cursor for real enterprise network placement.
Round 3: Persistence and multi-client sessions
This is where VS Code lands the sharper product idea.
The August 26 announcement makes the Agent Host the authority for a live session, so the same run can continue after you close the folder, reappear in the Agents window, and even be checked from the browser or another machine. The protocol is state-first and built for multiple clients to observe, approve, cancel, and reconcile the same long-running session.
Cursor's September 2 launch is more about worker placement and scaling than shared session semantics. It mentions reconnect windows and hibernation for pooled workers so follow-up requests can resume faster, but the core design center is capacity management, not an open multi-client session model.
Winner: VS Code.
Round 4: Setup friction and scale path
Cursor gives you two paths.
For one engineer, agent worker start --name "my-devbox" gets a personal machine online. For teams, agent worker --pool start plus a service account key and admin settings gives you Team Pools, one agent per machine, with controllers that can scale capacity up and down. The docs also note that Team Pools require a Cursor Enterprise plan.
VS Code's Agent Host has a lighter local story. The blog and docs show a standalone host you can run with code agent host, then connect through SSH, dev tunnels, or the web.
Winner: Tie, depending on whether you need fleet orchestration or just durable sessions.
Round 5: Extensibility
VS Code scores the cleanest technical point here.
AHP is open, and the Agent Host blog already points developers to client libraries for Rust, TypeScript, Kotlin, Go, and Swift. That matters because it frames the host as infrastructure other tools can connect to, not only a built-in UI feature.
Cursor is extensible in a different way. Self-Hosted Machines can run local MCP servers and execute on custom machines, but the September 2 materials are about operational flexibility rather than an open session protocol other clients can implement.
Winner: VS Code.
The practical pick
Pick Cursor Self-Hosted Machines if your blocker is infrastructure reality: private repos, internal services, Macs for Apple-platform builds, GPUs, or existing sandbox platforms that must stay in your control.
Pick VS Code Agent Host if your blocker is workflow reality: you want an agent session to survive window changes, stay synchronized across surfaces, and expose a protocol that other clients can speak.
The better read is that these are not the same launch wearing different branding. Cursor answers, "Where may the agent execute?" VS Code answers, "Who owns the session while clients come and go?"