Desktop AI Agent Pilot: Cost and Rollout Worksheet

Jump to the cost worksheet if the workflow is already clear. This resource is for a CTO, platform engineering leader or operations owner scoping a computer-use pilot. It is an internal reference model, not a client result, vendor quote, market benchmark or promise that desktop automation will save money.

Choose one legacy task, not one legacy estate

The first pilot should operate one defined task class inside one legacy application. A support case closure, an order-status lookup or a back-office record reconciliation can qualify when the input, allowed screen path, business owner and authoritative outcome are explicit. "Operate the ERP" is not a task boundary.

Use this starting contract:

• Input: one eligible work queue with stable task identifiers.
• Application: one named legacy application, environment and screen path.
• Identity: one dedicated agent identity, never a reused employee account.
• Authority: exact visual modes, exact forwarded tools and one short expiry.
• Output: one intended business result under a stable effect key.
• Owners: one workflow owner and one systems owner for the desktop and destination.
• Acceptance: authoritative business read-back matches the intent, and the desktop session is inactive.
• Stop rule: a human stop, unexpected modal, visual divergence or out-of-scope screen ends the lease and routes the task to a person.

Amazon WorkSpaces for Agents is billed by active session time and exposes managed desktops, an MCP endpoint and real-time session control. Windows 365 for Agents documents pooled stateless desktops and dedicated Entra agent identities distinct from human identities. Those platforms make legacy applications reachable. They do not decide which business task deserves authority.

Keep five routes separate

One confidence score cannot explain whether the problem is missing evidence, business authority or an application exception. Give every task one terminal route:

1. Act: the bounded read, navigation or approved write fits the admitted task and its evidence plan.
2. Approval: a material write is supportable, but the exact task, effect key, duplicate-safe write or read-back plan is not fully approved.
3. Handoff: a person stopped the run, the application diverged from the expected path or the task left the contract.
4. Hold: ownership, task identity, agent identity, policy digest, stop control or expiry evidence is missing.
5. Refuse: the request needs a human credential, identity-policy change, privileged-access approval, security-control change or payment authority.

The distinction protects recovery. Approval may resume after a person authorizes the exact proposal. Handoff requires a person to own the exception and a new session admission. Hold preserves an evidence gap. Refusal says the requested authority does not belong in this pilot.

The desktop session lease implementation supplies the corresponding runtime control. Its reference gate binds task, owner, identity, policy, allowed interaction modes, stop control and expiry before access is issued. This worksheet uses that lease as one input to a commercial rollout decision.

Bind pixels and tools independently

Computer use and forwarded tools are two authority paths, even when both live inside one desktop session. Allow each separately.

AWS documents visual interaction for screenshots, clicks and typing plus forwarded tools exposed through the session. Forwarded tools require IAM permission and the service setting, inherit the session-user environment and receive prefixed names. Current agent-access setup supports one agent per session and requires computer vision for computer input.

For a case-closure pilot, the lease might allow screenshot, click and type inside the support application plus crm.lookup. It should deny an unlisted crm.write until the write has its own effect key, target-bound approval and source-system read-back. A screen path is not safer merely because the same update could have been expressed as an API call.

Record the chosen modes and tools in the same versioned admission record as the task and policy digest. If either set widens at runtime, the result is divergent rather than successful.

Make stop and cleanup part of acceptance

A task is incomplete while its authority remains live. Close the session as part of the outcome, not as infrastructure housekeeping.

AWS exposes VIEW_ONLY, VIEW_STOP and DISABLED human-control modes. Its setup guidance says a stopped agent needs a new session to continue. That is the right first-pilot behavior: stop revokes the lease rather than pausing it in a reusable shell.

The AWS MCP documentation also defines X-Amzn-AgentAccess-Expire-Streaming-Session-On-Delete: true. The documented default is false, which can leave the streaming session alive until its disconnect timeout. Set the equivalent cleanup behavior explicitly and verify inactivity after deletion.

The close receipt should join:

{
  "taskId": "case:177:close",
  "sessionId": "session-17",
  "deleteAcknowledged": true,
  "sessionActive": false,
  "effectIntent": {
    "effectKey": "case:177:close",
    "acceptanceId": "accept-17"
  },
  "businessReadback": {
    "effectKey": "case:177:close",
    "acceptanceId": "accept-17"
  }
}

Missing session read-back is uncertain. An active or mismatched session is divergent. Missing business read-back is uncertain. Contradictory business state is divergent. Only matching source-system state plus a proved inactive session counts as an accepted task. The receipt and outcome verification method explains why neither an accepted request nor a session log proves the business effect.

You can inspect the five checkpoints in the Session Lease DVNC experiment. It uses a synthetic fixture, stores nothing, calls no model and is not a deployed customer system.

Price the complete desktop workflow

Measure one operating window. Join the desktop, model, tools, integration, observability, security review, remaining human work and amortized setup before dividing by accepted outcomes.

Use:

joined monthly cost = remaining human labor + desktop sessions + model and tools + integration and observability + security review + amortized setup

The denominator is reconciled accepted tasks plus acknowledged handoffs. A handoff counts only when a named person accepts control. Do not count sessions opened, clicks performed, fields touched or model messages as outcomes.

Blank worksheet

Synthetic arithmetic check

This fixture tests the worksheet. It is not a platform price, client result, industry benchmark or savings forecast.

• 480 eligible tasks in one month
• 12 baseline human minutes and 5 remaining human minutes per task
• $85 synthetic loaded hourly cost
• $640 desktop sessions, $210 model and tools, $450 integration and observability, and $700 security review
• $15,000 setup amortized over 12 months, or $1,250 for the month
• 360 reconciled accepted tasks and 60 acknowledged handoffs

Baseline labor is $8,160. Remaining labor is $3,400. Recurring technology and review cost is $2,000. Joined monthly cost, including amortized setup, is $6,650. Across 420 accepted outcomes, synthetic unit cost is $15.83. The synthetic difference from baseline labor is $1,510.

Raise remaining human time from 5 to 8 minutes and the same fixture becomes $8,690, which is $530 above the baseline labor model. Review and correction time can reverse the direction even when the agent completes many sessions.

If accepted outcomes are zero, unit cost is unavailable. Keep failed, held, refused and divergent work in the numerator. A weak pilot cannot improve its unit economics by excluding its exceptions.

Run the reference artifact

The retained dependency-free artifact joins the cost and classifies the task route before admission. The core decision is intentionally small:

export function routeDesktopTask(input) {
  if (input.useHumanCredential || input.approvePrivilegedAccess ||
      input.disableSecurityControl || input.initiatePayment) {
    return { route: "refuse" };
  }

  if (!input.workflowOwnerNamed || !input.systemsOwnerNamed ||
      !input.taskId || !input.agentIdentity || !input.policyDigest ||
      !input.stopControlNamed || !input.expiresAt) {
    return { route: "hold" };
  }

  if (input.humanStopped || input.visualDivergence ||
      input.unexpectedModal || input.outsideTaskClass) {
    return { route: "handoff" };
  }

  if (input.materialWrite) {
    const approved = input.approvalStatus === "approved" &&
      input.approvalBoundToTask && input.effectKey &&
      input.duplicateSafeWrite && input.readbackPlanNamed;
    return { route: approved ? "act" : "approval" };
  }

  return { route: "act" };
}

The complete reference passes 22 of 22 local cases. They cover cost joining, human-time sensitivity, an empty denominator, invalid counts, prohibited authority, missing ownership and policy, human stop, visual divergence, material-write approval, the eighteen-part release gate, session cleanup and observed, uncertain and divergent business read-back. These cases prove local classifier behavior only. They do not prove desktop accuracy, latency, application compatibility, security posture or business results.

Release only after eighteen pieces of evidence

The first release should remain held until every item is true:

1. Name the workflow owner.
2. Name the systems owner.
3. Bind one legacy application and environment.
4. Bind one task class and eligible queue.
5. Issue a dedicated agent identity.
6. Pin the desktop stack and evaluated policy digest.
7. Allowlist visual interaction modes.
8. Allowlist exact forwarded tools.
9. Test a visible human stop control.
10. Prove human credentials are denied.
11. Pass representative normal and exception cases.
12. Pass denied-action cases.
13. Join session lifecycle telemetry to the task.
14. Join forwarded-tool telemetry to the task.
15. Make every material write duplicate-safe.
16. Pass authoritative business read-back.
17. Prove deletion and session inactivity.
18. Join the cost ledger for the same task cohort.

Microsoft's governance and auditability guidance emphasizes designated ownership, lifecycle management, least privilege and correlation across prompts, tool use and outcomes. The specific gate above is DVNC's implementation recommendation. It is designed to remain portable when the desktop provider changes.

The first lease should be short. AWS uses a 30-minute expiration in its getting-started test flow. Use that as a conservative DVNC pilot cap, not a universal limit. Tighten or widen it later from accepted-task duration evidence.

Keep these decisions outside the pilot

The smallest credible desktop-agent pilot excludes:

• a shared or reused human credential;
• identity or conditional-access policy changes;
• privileged-access approval;
• security-control disablement;
• payments or financial authorization;
• unbounded navigation across applications;
• silent continuation after a human stop;
• blind replay after an uncertain write;
• completion while the desktop remains active;
• rollout based on sessions opened or clicks completed.

Expand only one boundary at a time. A wider task class needs new representative cases. A new tool needs an updated policy digest. A material write needs exact approval, a stable effect key, duplicate-safe execution and authoritative read-back. A longer lease needs retained evidence that the shorter cap prevented accepted work rather than merely inconvenienced the agent.

Frequently asked questions