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. Substantive corrections to any column will be reflected here within two weeks.