[Epic] Support computer-use agents as a first-class agent type

[abhipi]

Decision

#9649 and merged PR #9657 replace the original CUA candidate and qualification design.

The current implementation is one experimental, default-off terminal agent. This epic tracks that foundation and any later first-class CUA capabilities that maintainers accept.

Candidate status, qualification gates, release manifests, readiness records, component receipts, and CUA-specific target or task state are not current requirements.

Current foundation

• NEMOCLAW_CUA_ENABLED=1 is the only value that exposes nemocua.
• NEMOCLAW_CUA_SANDBOX_IMAGE_REF selects the caller-prepared sandbox image.
• NemoClaw validates the image-reference syntax and uses the image as the sandbox base image.
• The agents/nemocua agent manifest defines terminal commands, configuration paths, smoke checks, and baseline policy additions.
• nemoclaw launch <sandbox> uses the existing interactive terminal path.
• nemoclaw <sandbox> agent runs the NemoCUA harness through the existing agent path.
• Existing onboarding, status, doctor, managed inference, policy, recovery, rebuild, and destroy behavior remains authoritative.
• NemoClaw does not select a NemoCUA release, resolve private artifacts, or attest the supplied image contents.
• This path is experimental. It does not establish product support or a compatibility promise.

Ownership

NemoClaw owns:

• the exact default-off feature gate;
• agent discovery and selection;
• image-reference validation and sandbox handoff;
• one OpenShell-managed sandbox;
• the baseline filesystem, process, and network policy;
• managed inference;
• the existing sandbox lifecycle.

The active scenario or caller owns:

• image preparation, distribution, contents, and version selection;
• compatibility between the image, harness, and desktop target;
• desktop-target provisioning, transport, reset, and removal;
• target credentials, task input, task orchestration, and private artifacts;
• independent result verification and scenario-resource cleanup.

NemoClaw core remains environment-agnostic. It creates no nested NemoCUA sandbox and stores no CUA-specific target, security, task, or evidence state.

Current demo path

The private browser demo can proceed on the merged foundation:

1. The scenario prepares the NemoCUA sandbox image.
2. The caller sets the feature gate and image reference.
3. The caller onboards nemocua through the standard agent path.
4. The scenario invokes the harness through nemoclaw <sandbox> agent.
5. The scenario owns the desktop target, task flow, independent verification, and cleanup.

The scenario repository owns its Brev run and browser-task acceptance. The demo does not depend on a first-class NemoClaw target or task API.

Deferred first-class work

Do not implement the deferred issues from their historical bodies. Re-refine each issue against the standard terminal-agent foundation before implementation.

1. [Deferred] CUA: Connect one disposable target through existing policy controls #8450: First determine whether the standard agent and policy commands can connect one caller-managed disposable target. Add no CUA target subsystem unless a current requirement proves that these commands are insufficient.
2. A future first-class browser-task boundary requires a new accepted issue after [Deferred] CUA: Connect one disposable target through existing policy controls #8450 establishes the required target boundary.
3. [Deferred] CUA: Run a terminal task and recover lifecycle state #7751: Define terminal-task recovery only after an accepted shared task boundary exists.
4. [Deferred] CUA: Run a computer task and the integrated journey #7752: Define the computer and integrated journeys only after the earlier lifecycle work exists.
5. [Deferred] Verify the cumulative CUA release gate on Brev #7753: Re-scope only if maintainers resume a product release-qualification decision. It is not a feature slice.

Related records:

• Define the CUA architecture and trust boundaries #7750 preserves the environment-agnostic architecture constraint. Its larger design is historical context.
• [Deferred] Preserve CUA security, authority, and recovery invariants #7754 is historical security input. Map only applicable safeguards into each accepted capability.
• CUA vertical slice 1: Install and inspect a candidate worker #7755 is superseded and is not a dependency for current or future work.

Refinement requirements

Before implementation starts on a deferred capability, its issue must:

• identify one current consumer and one independently useful outcome;
• establish product ownership, lifecycle, compatibility, security, and validation;
• reuse the standard agent, policy, and sandbox paths unless a current requirement prevents it;
• define credential custody, failure, interruption, recovery, and cleanup behavior;
• select deterministic tests and the minimum required live boundary;
• remove CUA vertical slice 1: Install and inspect a candidate worker #7755 and all candidate, qualification, readiness, digest, and receipt assumptions.

Do not add a second CUA feature gate, a parallel agent lifecycle, duplicated sandbox state, or a general target or task framework.

Completion criteria

• Simplify experimental CUA to the standard terminal-agent path #9649 defines the experimental terminal-agent foundation.
• refactor(cua): use the standard terminal-agent path #9657 implements that foundation on main.
• The private demo has no dependency on the deferred first-class issues.
• After the private demo, maintainers decide whether NemoClaw stops at the experimental foundation or resumes first-class product work.
• If product work resumes, maintainers accept a refined [Deferred] CUA: Connect one disposable target through existing policy controls #8450 before implementation.
• Maintainers record any final enablement and product-support decision.
• If product work does not resume, close the deferred issues without describing the experimental foundation as supported.

Non-goals

• General remote-desktop or target-fleet management.
• Brev control-plane behavior in NemoClaw core.
• Employee desktops, production accounts, or shared mutable desktop targets.
• A universal CUA abstraction.
• Cross-agent delegation, messaging, or dashboard work.
• Public storage of task content, screenshots, documents, browser state, credentials, or transport data.
• New CUA-specific state or APIs without an accepted capability that consumes them.

[wscurran]

✨ Thanks for the design proposal. This is a significant new integration surface spanning sandbox, skills, and external desktop automation. Maintainers will need to review the architecture before implementation can proceed.