Windows supports two reliable methods for giving an AI agent a continuous, interactive desktop session:
- RDP-based persistent sessions, and
- Hypervisor-based persistent sessions (e.g., VMware).
Both rely on the principle that a Windows user session stays alive as long as it is not logged off.
⸻
1. RDP-Based Persistent Session
How it works
- A human logs into the Windows system using RDP.
- They start the agent and prepare the session as needed.
- When finished, the human clicks a “Detach to Console” icon/script on the desktop.
•This transfers the active session from the RDP connection back to the local console session.• The RDP window closes, but the user session remains active and unlocked.
-The AI agent continues running within this persistent console session.
Why this works• Windows distinguishes between disconnecting and logging off:• A disconnect (including detach-to-console) leaves the session running.• A logoff destroys the session and ends all applications.• The detach operation avoids the problems of:• Auto-locking after an RDP window closes• Idle disconnect policies tied specifically to the RDP transport• Accidental user logoff
Internal operational requirement
Your organization maintains an internal policy that:
Any human who must access an instance via RDP must finish by using the “Detach to Console” action.
This ensures:• The agent session remains intact after human intervention.• No one accidentally logs off the agent.• No RDP idle-disconnect cleanup triggers.• The agent always returns to a stable state after a human takes over temporarily.
Agent periodic activity
Your agent periodically performs small GUI actions—such as briefly opening the Start Menu—to register visible activity with Windows.This prevents:• Idle state classification• Screen locking• Disconnect cleanup• Session timeout triggers in environments that treat no input as inactivityThis technique ensures the desktop remains active indefinitely.
⸻
2. Hypervisor-Based Persistent Session (VMware Example)
How it works
- A human opens the VMware console for the Windows VM.
- They log into the Windows desktop and start the agent.
- They then close the VMware console window.
•This only closes the viewer.• The VM continues running, and the desktop session remains active and unlocked.
The AI agent continues operating normally inside the guest OS, which still sees a live virtual monitor.
Why this works• VMware provides the guest with a virtual graphics adapter and virtual display.• The presence of this virtual display is independent of whether anyone is currently viewing the console.• Closing the VM console does not count as a logoff or disconnect event inside the guest.
Required VMware setting
You must disable:
“Lock the guest operating system when the last remote user disconnects.”
When disabled:• Closing the VMware console leaves the Windows desktop fully accessible.• No automatic locking is triggered.• The agent can remain active 24/7 with no viewer attached.
⸻
Summary
To maintain a persistent interactive desktop for an AI agent:
RDP Method
A human logs in with RDP, performs work, and then uses a “Detach to Console” icon to leave the session active and unlocked. An internal organizational policy enforces this as the required way to exit any RDP session. The AI agent maintains activity (e.g., opening the Start Menu periodically) to keep the session alive and prevent timeout or lock events.
Hypervisor Method
A human accesses the Windows VM through the VMware console, starts the agent, and closes the viewer. With the autolock-on-disconnect option disabled, the guest OS remains logged in and active. The VM behaves as if a monitor is always attached, allowing the agent to operate indefinitely.
Both approaches produce a stable, persistent Windows desktop suitable for continuous AI-driven control while allowing occasional human intervention without disrupting the agent.