Agent session lifecycle

Important

Windows 365 for Agents is in public preview. The feature is under active development and might change before general availability.

A Windows 365 agent session represents the full lifecycle in which an agentic application requests a Cloud PC, uses it to accomplish a task, and then returns it when done. Sessions are the mechanism by which the platform turns a pool of Cloud PCs for Agents into an on-demand, disposable workspace for AI agents - and, when needed, for the humans who supervise them.

Your first agentic session moves through five conceptual phases: Prepare > Acquire > Connect > Act > Release.

Lifecycle at a glance

Phase Plane What happens
Prepare Computer-Create Pools of Cloud PCs are provisioned, configured, and made available for agent use.
Acquire Computer-Get A Cloud PC is reserved for a specific caller and session.
Connect Computer-Do, Computer-TakeControl Authenticated channels open; capabilities become available.
Act Computer-Do, Computer-TakeControl The agent operates the Cloud PC, with optional human observation.
Release Computer-Get Channels close, the Cloud PC is reset, and capacity returns to the pool.

Prepare

Before any session can exist, you need to create a pool of Cloud PCs for Agents, the Computer-Create plane of the architecture. IT administrators and agent makers define these pools by choosing images, regions, and size, and assign which agents are allowed to access them. Windows 365 then provisions these Cloud PC agent pools.

Acquire

A session begins the moment an agentic application asks for a machine. The request flows into the Computer-Get plane, which selects an available Cloud PC from the right pool, reserves it for the caller, and hands back a session identity that represents that reservation.

At the end of this phase, the caller has a Cloud PC session that they can safely retry against without ever duplicating it.

Connect

With a Cloud PC reserved, the agent opens a working channel to it through the Computer-Do plane. This channel is the conduit through which the agent issues every subsequent instruction. It's authenticated, bound to the session, and terminates at the in-guest component running inside the Cloud PC.

Connecting also surfaces the agent's vocabulary: the set of capabilities the platform exposes through accessibility so the agent knows what it can do on this Cloud PC.

If a human will be watching or helping, a parallel channel through the Computer-Use plane can be opened for real-time screen share and optional shared control. Both channels target the same Cloud PC and the same session.

Act

This phase is the working portion of the session. The agent observes the desktop, decides what to do next, and invokes capabilities on the Cloud PC - clicking, typing, navigating the web, running commands, and inspecting the UI. The platform mediates every action: enforcing the session's identity, applying safety guardrails, and recording what happened.

A few properties define the character of this phase:

  • Turn-based by nature. The agent observes, acts, and observes again. State on the Cloud PC evolves as work proceeds.
  • Safe by construction. Sandboxed execution, allowlisted commands, bounded payloads, and protected system processes keep the session inside a well-defined envelope, secured by Microsoft Entra, Microsoft Intune, Microsoft Defender, and Microsoft Purview.
  • Shared with humans when useful. A human can observe the same session in real time and take over control when appropriate, without disrupting the agent's connection.
  • Kept alive by activity. Sessions that go quiet for too long are reclaimed automatically so capacity isn't wasted.

This phase can last seconds, minutes, or hours, but the Cloud PC is dedicated to the session for its entire duration.

Release

A session ends when the agent declares its work complete, when policy terminates it, or when it goes idle too long. Release is handled by Computer-Get: the channels are torn down, the Cloud PC is reset, billing is finalized, and the Cloud PC returns to its pool, ready to serve another request. Cloud PCs that failed health checks during the session are quarantined and replaced rather than reused, which keeps the pool healthy over time.

Why it's shaped this way

The lifecycle is designed around three ideas:

  • Pools, not Cloud PCs. Agents request capability, not a specific Cloud PC. Pooling is what makes on-demand agent compute economically viable.
  • One session, many surfaces. The same Cloud PC can be driven by an agent and observed or co-driven by a human within a single session - no separate provisioning path for supervised work.
  • Clean boundaries between sessions. Every session ends with reset-and-return to ensure the next session begins with the provisioned state, so isolation, auditability, and reuse all fall out of the same model.

Next steps