Computer is capability, not provider placement
Creating a Computer records provider-neutral intent from an active immutable ComputerProfile revision. The public create operation produces a sleeping Computer. It does not allocate provider capacity, return a provider lease, or contact a provider. The public Computer exposes its stable identity, Workspace scope, lifecycle, generation, pinned profile revision, recovery grade, sharing scope, optimistic resource version, and timestamps. It does not expose provider allocation coordinates, credentials, controller receipts, or private provider routes. Provider selection and allocation remain private control-plane custody. Computer lifecycle is separate from Session truth. A Session may use a Computer, but the Computer does not own the Session transcript, Run settlement, approval state, or Usage ledger. Paid Computer activity is attributed through authoritative Usage, not tracing.Screen is the public observation authority
A Screen is a stable public resource nested under one Computer. It gives observers one durable identity for the current visual surface even when the underlying provider allocation, desktop display, or browser target changes. The public Screen carries provider-neutral facts:
The Screen’s identity and geometry come from durable initialization authority. Recovery may advance the Computer generation, control state, observation generation, attachment, active target, and clocks. It cannot reinterpret the Screen identity, width, height, or observed scale.
A mismatched Computer and Screen pair is not addressable.
A Screen is not a raw provider screenshot API
A Screen is the durable public observation head. A caller may request bounded accessibility-tree and screenshot capture modes, but the settled public Browser observation remains sanitized. Raw screenshot bytes do not fit the public response, and capture does not turn Screen into a provider screenshot endpoint. The public contract excludes provider allocations, browser-debugging target IDs, desktop display IDs, unrelated targets, hidden sensitive fields, form values, browser chrome, and raw provider APIs. The server derives provider contact and target coordinates from private custody. When geometry is needed, public callers reason in logical Screen pixels. Browser targets use stable labels. Public examples must not ask users to supply provider allocation coordinates, provider target coordinates, or vendor-specific display coordinates.Actions are fenced to current observation authority
Structural Browser actions include click, keypress, scroll, target switch, and target close. The caller supplies only the bounded structural intent, a short deadline, and a source observation where stale DOM matters. The owning Session and server derive the current Computer, Screen, attachment, RunAttempt, actor, policy, approval when required, Budget, generation, control epoch, observation epoch, and provider target before provider contact. A stale observer cannot act on a newer Screen. Provider target resolution happens only after the public request passes governance and freshness checks. Mutating actions remain subject to Checkfu policy. When policy requires approval, the first request creates an exact durable ActionApproval and admits no provider action. After a human decision, an identical retry with the same idempotency key re-evaluates current authority and rejoins only the matching decision. The provider adapter cannot approve its own action, and a screenshot cannot carry approval authority.Provider-neutral does not mean universally supported
The public Computer, ComputerProfile, Screen, bounded Browser observation, and structural Browser action contracts are landed. Current support is narrower:- Computer creation returns a sleeping resource and allocates no provider.
- Public wake and provider-dispatch operations remain unavailable.
- Archival refuses active provider cleanup rather than pretending it occurred.
- Provider conformance and managed placement remain incomplete.
- No managed provider is the public default.
Security and retention
Provider credentials and sealed provider coordinates remain outside Computer, Screen, Session events, Harness input, model context, and the sandbox filesystem. Public observations are bounded and screened before they cross the provider port. A durable Screen contains structural observation authority, not a second transcript and not raw provider custody. Observation content that crosses the public boundary follows the applicable Workspace retention posture. Under ZDR, content that cannot enter a durable sink cannot be reconstructed after the live observation is gone.Next steps
Action approvals
Govern Computer actions before the provider effect occurs.
Sessions and runs
Keep Agent execution and event truth in the Session.