Assess Cloudflare Computer patterns for OpenAgents cloud computers #34

Outcome

Decide how OpenAgents should provide durable cloud computers to agents by comparing the implemented Cloudflare Computer architecture with our connected-computer, SCV, Forge, and Google Cloud systems. Produce a GCP-native design and a staged proof of concept. Do not treat the Cloudflare preview as a production dependency or copy its platform-specific Durable Object design without evaluation.

Source review

Review the local Cloudflare Computer checkout at ~/work/projects/repos/computer. Separate shipped code from forward-looking documentation. Start with these implemented areas:

• packages/computer/src/workspace.ts and packages/computer/src/backends/: one workspace with replaceable execution backends.
• packages/computerd/: a single injected daemon that owns command execution, a transient filesystem mirror, health checks, and an authenticated RPC surface.
• packages/dofs/ and packages/rpc/: durable filesystem authority, revision watermarks, idempotent synchronization, backpressure, and replay boundaries.
• docs/05_runtime_interface.md, docs/07_injected_service.md, docs/11_lifecycle.md, docs/16_code_execution.md, and docs/19_performance.md: runtime contracts, reverse-dial bootstrap, lifecycle, authorization boundaries, and performance costs.

Cloudflare Computer is a preview. Its docs explicitly contain planned behavior, and its current FUSE mirror has material large-file and package-install overhead. Capture both strengths and unresolved risks.

Compare with OpenAgents

Map the Cloudflare patterns to the systems we already operate:

• Customer-owned computers pair through the controller WebSocket path and run durable work_jobs delegations with streaming, reconnection, machine authority, and scoped working directories.
• SCV deployments now use work_jobs with kind: "scv", immutable authority and budget snapshots, concurrency limits, workspace cleanup, inference metering, and operator approval.
• OpenAgents.SCV.Runner still has only the local provider, so system-owned execution capacity is not a first-class runtime choice.
• Forge already uses GCS for durable repository WAL data and GCE for the rolling production fleet.
• Production already uses PostgreSQL, GCS, Secret Manager, Cloud Run, and GCE. Prefer these existing control, identity, storage, and operations paths unless the assessment proves a reason to add another service.

Decisions to make

• Define one agent-facing computer contract that can target a paired customer machine or OpenAgents cloud capacity without weakening either authority model.
• Decide whether PostgreSQL plus GCS, persistent disks, or another existing GCP primitive should own durable workspace manifests, blobs, snapshots, and revisions.
• Define runtime tiers for fast restricted execution and full Linux execution. Backend selection must be server-authorized capability routing, not caller-selected authority.
• Decide how workers dial back to the Phoenix control plane, authenticate each run, stream sequenced events with backpressure, and recover after transport or node failure.
• Define exact replay boundaries. Filesystem synchronization can be idempotent; an ambiguously dispatched shell command must not run twice.
• Specify cold start, warm reuse, suspension, TTL cleanup, restore, cancellation, and destroy behavior.
• Define tenant isolation, per-run identity, secret injection, path scope, egress policy, quotas, metering, audit receipts, and redaction.
• Decide how repositories, Git metadata, artifacts, and large dependency trees move through a workspace without making FUSE or a database-backed VFS the bottleneck.
• Determine whether to adapt any portable Cloudflare code or reproduce the protocol and lifecycle concepts in Elixir and our worker images.

Deliverables

• A current-state diagram for paired computers, SCV, work_jobs, Forge storage, and GCP runtime capacity.
• A gap matrix that distinguishes reusable OpenAgents machinery, reusable architectural patterns, platform-specific Cloudflare code, and missing controls.
• A recommended GCP-native control-plane and execution-plane design with module, schema, protocol, and infrastructure boundaries.
• A threat model covering tenant escape, credential theft, unauthorized egress, confused-deputy routing, replay, stale workers, and workspace data leakage.
• A proof-of-concept plan that runs one agent task on OpenAgents-owned capacity with a durable workspace and the existing work_jobs lifecycle.
• Benchmarks for cold start, warm start, repository checkout, dependency installation, incremental writes, artifact upload, stream latency, restore, and cleanup.
• A staged rollout and migration plan that preserves the current customer-owned computer and SCV behavior.

Acceptance criteria

• The assessment cites concrete code in both repositories and labels Cloudflare behavior as shipped, planned, or unresolved.
• The recommended design uses our existing Google Cloud setup and identifies every new managed service or privilege it requires.
• A prototype runs an agent task end to end with durable workspace recovery, sequenced output, cancellation, timeout, controlled egress denial, process or worker restart, and terminal cleanup.
• Tests prove that an ambiguous command dispatch is not replayed, stale worker identities cannot mutate a workspace, and unauthorized backends or paths are refused.
• The design links execution, usage, workspace state, and terminal evidence to the existing work_jobs and SCV receipt model.
• The assessment records measured cost and performance before recommending a production rollout.