# Agent computer / stateful serverless workforce — context for agents

## Core thesis

An agent should not be represented by a continuously running process or VM. It should be a durable, addressable organisational actor with an identity, role, memory, policy, event mailbox, pending work and World state. It leases a disposable computer only while actively executing.

**Persistent identity. Ephemeral computer.**

```text
Agent seat → World → task lease → Computer
```

The model is not the employee. The governed deployment is:

```text
Digital worker = model + harness + memory + World + computer + organisation identity + bounded authority + role + supervision + audit
```

## Object boundaries

- **Seat:** role, organisational identity, policy, supervisors and long-term continuity.
- **World:** durable files, browser/profile references, task state, event history, checkpoints and lineage.
- **Computer:** replaceable Linux or Windows execution capacity.
- **Organisation Pack:** Microsoft 365, Google Workspace or another provider's identity and application adapters.
- **Capability broker:** host-side authority layer that obtains short-lived scoped tokens; reusable organisation credentials do not enter the guest.

The employee is not the computer. The employee borrows a computer when work arrives.

## Stateful serverless lifecycle

```text
SLEEPING → event received → WAKING → computer leased → WORKING → checkpoint → SLEEPING
```

Microsoft Graph notifications, Gmail push, Teams mentions, SharePoint changes, calendar events, CRM webhooks and schedules wake the worker. Timers and subscriptions live in the control plane, not in an idle VM.

Waiting for approval should also release compute: stage the action, checkpoint the World, send the approval to Teams, release the machine, and wake again when the manager responds.

## Scale model

Concurrency is driven by duty cycle, not provisioned seats.

```text
average active computers = provisioned workers × active minutes per day ÷ 1,440
```

Example: 10,000 workers averaging 10 active minutes/day imply about 69 active computers on average. A 3× peak implies roughly 209. This is arithmetic, not measured product performance.

Always distinguish:

- provisioned seats;
- sleeping Worlds;
- warm snapshots;
- active computers;
- concurrent tasks.

Dormant means zero CPU/RAM, not zero cost. Storage, events, identities, subscriptions, audit and scheduling remain. Density varies greatly between API-only, browser, Windows Office and GPU workloads.

## Organisation access

The computer itself remains provider-neutral. Organisation Packs adapt identity and applications.

### Microsoft 365

Prefer Microsoft Graph for deterministic work; use Entra delegated OBO when acting for a signed-in employee and tenant-approved agent identity/managed identity/FIC/certificate for autonomous work. Use a dedicated agent user only when a mailbox/persona is necessary. Managed Windows or Windows 365 serves Office desktop, legacy UI and compliant-device workflows.

### Google Workspace

Use Gmail, Drive, Docs, Sheets, Calendar and Chat APIs through delegated OAuth, workload identity or explicitly approved domain-wide delegation. Browser automation remains a fallback rather than the primary authority model.

Use common business capabilities for genuine overlap (`mail.read`, `mail.draft`, `files.search`, `calendar.create`) while preserving native provider operations. Do not force every provider into a lowest-common-denominator API.

## Human supervision

Teams or Slack should be the supervisor cockpit. For Teams:

1. Agent pauses and sends a private Adaptive Card: Watch / Take control / Deny / Stop.
2. The action deep-links to a Teams tab/dialog.
3. Teams SSO identifies tenant and operator.
4. Backend issues a one-use short-lived viewer/control token.
5. An embedded WebRTC viewer shows the actual computer.
6. Human acquires an exclusive control lease; agent input stops.
7. Human completes MFA, CAPTCHA or judgement-heavy work and releases control.
8. Agent receives the resulting UI state, never the secret input.

View and control are separate permissions. Messages contain no bearer URLs or sensitive screenshots. All handoff transitions are audited.

## Best possible computer

The ideal computer is a versioned, instrumented execution World—effectively Git for computers:

- one coherent filesystem/process/browser/desktop state;
- API → shell/files → DOM/CDP → accessibility → pixels control hierarchy;
- verified read-only image + role layer + tenant configuration + encrypted World overlay + task branch;
- checkpoint, fork, diff, restore and explicit disk/live semantics;
- low-latency watch, annotate, exclusive takeover and emergency stop;
- default-deny egress, metadata/private-network blocks and bounded resources;
- host-side credential/capability broker;
- append-only causal event history;
- no model/harness dependency in the machine core;
- truthful capability matrix and no silent unconfined fallback.

## Existing landscape — research snapshot 17 Aug 2026

- **Grok Bot:** best consumer interaction reference: persistent cloud computer, shared browser sessions, watch and takeover. Its account-level computer shares files, cookies and CLI credentials across bots; separate screens are not security boundaries.
- **Windows 365 for Agents:** strongest Microsoft-native enterprise substrate: agent computer pools, session checkout/checkin, computer operation, WebRTC observation/takeover, Intune/Defender/Purview/Conditional Access. Sessions reset on release, so durable World continuity remains external.
- **DeepSeek Harness:** strongest append-only event truth, coherent capability seams, per-call policy and fail-closed enforcement. It is a harness, not a microVM platform.
- **E2B:** strong hosted sandbox API, templates and integration ecosystem; hosted-first and substantial to self-host.
- **CubeSandbox:** strong production-shaped microVM fleet, default-deny egress, credential injection, snapshots and future cluster architecture.
- **Microsandbox / BoxLite:** strongest local embeddable microVM candidates; benchmark rather than choosing from README claims.
- **AIO Sandbox / SmolVM:** useful coherent browser + shell + files + desktop UX references; not the primary isolation boundary.
- **Kubernetes Agent Sandbox:** useful Template → WarmPool → Claim model once fleet scale is justified; it orchestrates rather than supplies isolation.
- **Nehemiah:** clearest abstraction: Sandbox = Machine; Computer = Machine + display.

## Differentiation

The underlying pieces are inspired by existing systems. The proposed product's differentiation is their composition:

```text
Grok interaction
+ Microsoft governance
+ Cube security
+ DeepSeek truth
+ Git state
+ Sym continuity
= provider-neutral agent seat
```

The moat is not VM creation, desktop streaming, MCP, Graph wrapping or disk snapshots. It is cross-provider organisational identity/access, persistent World semantics, human-agent supervision, governed external consequences, reusable company-specific behaviour and portable memory.

## Non-negotiables

1. No raw long-lived organisation credentials in guests.
2. No silent unconfined fallback.
3. No default metadata/private-network access.
4. No split local-file/remote-shell execution world.
5. No unbounded process, output, disk, time or connection growth.
6. No public viewer without current machine/lease authorisation.
7. No model or harness dependency in the machine core.
8. CLI/SDK first; MCP optional.
9. No fleet control plane before one-host lifecycle, cleanup and recovery are reliable.
10. Every irreversible external effect must be policy-checked and receipted.

## Open questions

- Which local backend wins a real Microsandbox vs BoxLite benchmark on Apple Silicon and Linux?
- What are honest active-browser and Windows-worker density numbers by workload profile?
- Which World state can move portably across runtime/OS boundaries without overstating live migration?
- Should the tenant capability broker run in customer cloud by default or remain an enterprise option?
- What is the smallest useful provider-neutral capability vocabulary without erasing native M365/Google features?
- What should be the first paid SMB role and workflow wedge?

## Primary references

- DeepSeek Harness: https://github.com/deepseek-ai/deepseek-harness
- E2B: https://github.com/e2b-dev/E2B
- CubeSandbox: https://github.com/TencentCloud/CubeSandbox
- Microsandbox: https://github.com/superradcompany/microsandbox
- BoxLite: https://github.com/boxlite-ai/boxlite
- AIO Sandbox: https://github.com/agent-infra/sandbox
- Kubernetes Agent Sandbox: https://github.com/kubernetes-sigs/agent-sandbox
- SmolVM: https://github.com/CelestoAI/SmolVM
- Nehemiah: https://github.com/boringcomputers/nehemiah
- Grok Bot computer: https://docs.x.ai/grok-bot/computer-and-apps
- Grok Bot security: https://docs.x.ai/grok-bot/approvals-security-and-privacy
- Windows 365 for Agents: https://learn.microsoft.com/en-us/windows-365/agents/mcp-tool-overview
- Windows 365 lifecycle: https://learn.microsoft.com/en-us/windows-365/agents/agent-session-lifecycle
- Entra Agent ID OBO: https://learn.microsoft.com/en-us/entra/agent-id/agent-on-behalf-of-oauth-flow