# Agents and Computer Use - Vendor Capability Matrix | Loop Engineering [← All matrices](/matrices/) # Agents and Computer Use - Vendor Capability Matrix Chapter 9 of Loop Engineering argues the motor / sensory layer is where autonomous-agency surfaces live, and that the architecturally-relevant deltas across vendors are not raw capability but the guardrail shape: how confirmations are gated, whether a monitor model watches the agent, how the side-effect surface is bounded. Refreshed quarterly; next review 2026-09. Verified 2026-06. The agent surface is one of the fastest-changing surfaces in the field; treat any row older than six months as a snapshot. ### The matrix Surface Confirmation gates Monitor model Sandboxing Side-effect controls Availability Verified Anthropic Computer Use Claude 3.5 Sonnet (Oct 2024) Configurable; operator-controlled at the harness level (no default UI gate in the raw API). Not built-in; harnesses commonly run a separate monitor. Recommended pattern: containerised VM; vendor docs explicitly recommend isolation. Operator-controlled; the API does not enforce side-effect class restrictions. Public beta; via Anthropic API. 2026-06 OpenAI Operator / CUA Computer-Using Agent Built-in user-facing confirmation gates for sensitive actions (payments, account changes); always-on for the consumer Operator product. Built-in safety monitor; vendor describes guardrails layered above the action model. OpenAI-hosted browser; user does not run the sandbox. Vendor-controlled categorical refusals plus user-side confirmations. Operator: ChatGPT Pro (US); CUA API: limited preview. 2026-06 Google Project Mariner browser agent research preview Built-in user-facing confirmation gates for purchase-class actions; research-preview defaults. Vendor-described safety layer; specifics not fully published. Google-hosted Chrome surface. Categorical refusals + per-action confirmations. Research preview; limited Labs availability. 2026-06 Devin (Cognition Labs) autonomous software engineer Configurable; user-facing review on PR creation by default. Internal evaluation layer. Cognition-hosted Linux sandbox per session. Code review and PR-based approval are the dominant control. Generally available; commercial product. 2026-06 AutoGPT (historical, 2023) proof-of-concept None by default; the breakthrough was removing them, which is also the failure mode. None. Operator-installed; runs wherever the user runs it. None at framework level. Open source; community-maintained. 2026-06 Open-source agent frameworks LangChain, LangGraph, AutoGen, CrewAI Framework-provided primitives (human-in-the-loop hooks, interrupt nodes); the discipline is operator-implemented. Pattern-supported but not default; the operator wires the monitor. Operator-controlled. Operator-implemented via tool-allow-lists and pre-call validators. Open source; framework + operator deployment. 2026-06 ### What the columns mean - Confirmation gates - does a human have to approve an action before the agent takes it, and is that gate built into the product or operator-implemented? Architectural relevance: the materiality dial (Chapter 13) requires gates that scale with stakes. - Monitor model - is there a separate model watching the agent's actions and intervening on policy violations? Critical for autonomous deployments where the action loop runs faster than human review can keep up. - Sandboxing - what bounds the agent's side-effect surface? A vendor-hosted browser sandbox is a different security posture than the operator's own machine. - Side-effect controls - categorical refusals (the vendor refuses a class of actions outright) vs. per-action confirmations (the user approves each one) vs. operator-implemented validation. Most architectures compose all three. - Availability - public beta vs. research preview vs. generally available vs. open source; informs which products can be deployed in production today. ### Architectural takeaway The vendors that ship strong defaults (Operator's built-in confirmation gates, Mariner's purchase-action approvals) put a floor under what the operator has to implement. The vendors that ship raw capability (Computer Use, the open frameworks) push that floor onto the operator. Neither is wrong; they target different deployment contexts. The architecture's discipline is to name the floor - and if the vendor does not provide it, the operator must. This matrix maps the floor; it does not score it. Picking the right surface depends on the deployment context (materiality, regulatory posture, operator capability), not on which row scores highest in the abstract. ### What this matrix does not cover - Accuracy benchmarks - agent benchmarks (OSWorld, WebArena, SWE-bench Verified) shift faster than this matrix can; consult the live leaderboards. - Cost per task - varies enormously by task length and tool calls; not stable enough for a column. - Compliance certifications - SOC 2, ISO 27001, HIPAA BAAs, etc.; consult vendor trust pages. - Roadmap claims - only shipped capability is in this matrix; announced-but-unshipped features are explicitly excluded. ### Correction policy If a vendor surface changes materially before the next quarterly refresh, please flag it via [the errata page](/errata/). Substantive corrections to any column will be reflected here within two weeks.