Integrate cloud computers with Work, chat, text, voice, and API #37

Project

Cloud computer platform

Source: Cloud computer scale architecture audit

Dependencies

• OpenAgentsInc/openagents#3 - cloud computer contract
• OpenAgentsInc/openagents#4 - capacity and quota broker
• OpenAgentsInc/openagents#5 - workspace checkpointing
• OpenAgentsInc/openagents#6 - replay-safe commands
• OpenAgentsInc/openagents#9 - runtime class routing
• OpenAgentsInc/openagents#10 - cross-provider isolation

Outcome

Make OpenAgents-managed cloud computers a first-class Work target. Text, voice, model tools, and authenticated API routes must call one backend entry point, apply the same authority and budget rules, and produce the same durable job, placement, usage, event, and terminal evidence.

Scope

• Add a cloud-computer target concept to the existing Work path instead of creating another job system.
• Persist the logical computer identity, owner, conversation, profile, generation, checkpoint reference, and current runtime lease reference or immutable control-plane reference without duplicating provider authority.
• Extend work_jobs or its target association so a job records the requested class, logical computer, control-plane operation, authority snapshot, budget snapshot, requesting surface, and effective placement receipt.
• Implement one Req client for the private managed-sandbox control service with bounded timeouts, typed errors, authentication, idempotency, generation fences, and response redaction.
• Expose create, list, inspect, run, attach, cancel, stop, checkpoint, restore, fork, and destroy through owner-scoped service functions.
• Add the model tool and authenticated API surface through the same service functions.
• Keep customer-connected computers as an explicit target. Never infer customer-owned versus OpenAgents-managed placement from text versus voice or from the route that received the request.
• Project bounded live events through the existing conversation activity path while keeping the control-plane journal and work_jobs terminal report durable.
• Meter provider usage into the existing inference and work usage model.
• Reconcile active jobs after Phoenix node loss without replaying commands that may have started.
• Gate cloud computers independently by environment, runtime class, and qualification receipt. Never fall back to local Phoenix execution.

Deliverables

• Ecto migrations and schemas for the minimum Phoenix-owned cloud-computer metadata.
• Control-plane Req client and owner-scoped service module.
• Work target integration, recovery, usage, and incident handling.
• Cloud computer model tools and authenticated API routes.
• Text, voice, tool, API, ownership, failure, and recovery tests.
• Operator configuration and documentation.

Acceptance criteria

• Equivalent text and voice requests produce the same target, authority, budget, provider admission, runtime class, usage, and terminal state.
• Tool and API callers enter the same owner-scoped service and cannot bypass conversation, workspace, capability, or budget checks.
• Another owner cannot list, inspect, execute, attach, checkpoint, restore, stop, fork, or destroy the computer.
• A Phoenix restart reattaches to the same command and generation or reports may_have_started or lost; it never duplicates the command.
• Provider, quota, capacity, egress, checkpoint, and cleanup failures remain typed and visible.
• No runtime runs on a Phoenix application node, under /tmp, or through an implicit customer-machine fallback.
• Terminal reports remain bounded and durable after the live event stream disappears.

Project linkage

The Projects API currently enforces repository-local project items. This openagents.com issue links the OpenAgentsInc/openagents project here and must appear in the dependency section of the project qualification issue.