Define the UX, DX, and AX for deploying and managing compute workloads

[scotwells]

Parent Issue

Tracked by datum-cloud/enhancements#682 (Launch Workload Compute Service — "UFOs")

Summary

There is no defined experience for compute across any consumer surface — the Cloud Portal, CLI, or agent tooling. This work defines the end-to-end experience for three distinct personas: the human user managing workloads through a portal, the developer building and operating workloads via the CLI and API, and the AI agent using compute as an execution environment.

User Experience (UX)

Goals for human users interacting through the Cloud Portal:

• Design and implement Cloud Portal surfaces: workload deployment flow, instance list, instance detail view (status, conditions, logs, network info)
• Define the empty state / onboarding flow for a user who navigates to Compute for the first time
• Design error state UX for common failure modes: quota exceeded, image pull failure, placement failure
• Expose quota utilization so users can see remaining headroom before hitting a limit

Developer Experience (DX)

Goals for developers building and operating via CLI and API:

• Implement datumctl commands for compute resource types (deploy, list, describe, logs, delete)
• Document how to build Unikraft-compatible images, including the differences from standard OCI containers that developers will encounter
• Define the local development workflow — how to build and test a workload locally before deploying to Datum
• Provide at least one reference workload / sample application demonstrating a realistic use case

Agent Experience (AX)

Goals for AI agents using compute as an execution environment:

• Define the agentic workload pattern — how an AI agent uses a compute instance as a sandboxed execution or inference environment
• Define the MCP / tool interface for compute so agent platforms can manage instance lifecycle programmatically (create, query status, stream logs, terminate)
• Clarify the credential model for agent-to-platform authentication when a workload is itself an agent (relates to enhancements#708 for service account auto-attachment)

Non-Goals

• Backend API changes — this tracks the experience layer only
• Billing/invoicing UI (tracked under enhancements#681)
• Consumer-facing documentation (tracked in compute#97)

Open Questions

• Which surface ships first — Cloud Portal, CLI, or MCP tooling?
• What is the minimum portal surface needed for GA vs. what can follow?
• Is the MCP interface to compute owned by datum-mcp or by the compute service itself?
• Can an existing Service Account be attached to multiple workloads, or is it 1:1?

[scotwells]

Created an initial enhancement PR to capture the expected experience of the compute CLI. Also considering exposing this eventually as a datumctl plugin so we can easily ship service-specific CLIs in the future without updating datumctl core.