Agent session lifecycle

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.

Session duration and timeout

A session has no fixed maximum duration. As long as the agent sends at least one MCP request every 30 minutes, the session remains active and the Cloud PC stays reserved for it. A session that goes 30 minutes without any MCP activity is automatically evicted: channels close, the Cloud PC resets, and capacity returns to the pool.

A few things to know about how session lifetime works in practice:

  • No maximum runtime. There is no hard cap on how long a session can run. Sessions are designed to last as long as the work requires, from seconds to days.
  • Idle timeout at 30 minutes. Any MCP call resets the inactivity clock. There is no separate lease-renewal API — activity is the renewal mechanism. For periods where the agent is waiting on external work rather than issuing tool calls, send a lightweight heartbeat at least once every 30 minutes. The get_screen_size tool is a minimal and reliable option for this purpose.
  • Multi-day workflows are supported. The platform does not enforce a maximum session lifetime or disable workflows that span multiple days. A session that maintains the 30-minute activity cadence will persist for as long as needed.
  • Checkpoint state externally. In-session state does not survive an unexpected session loss. If the session is interrupted, the Cloud PC resets on release and any unsaved work inside the session is lost. Save progress to external storage at regular intervals, and build your agent to handle a 404 Not Found response by re-acquiring a fresh Cloud PC and resuming from the last checkpoint.
  • Manage token lifetimes independently. Authentication tokens expire on their own schedule regardless of session activity. Ensure your application renews credentials transparently for the full duration of the workflow.

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

Related content

  • Last updated on