Comparison · Wrench 0.16.1
Browser-using personal agents still need named web operations.
Anish Acharya's notes on Instinct, Grok Bots, and ChatGPT Work describe persistent personal agents with cloud(ish) computers, browser access, cached credentials, and recurring loops. Wrench is not that agent. It is a local capability and custody layer that exposes named operations and keeps general browser control behind the contract.
This comparison uses only Acharya's published notes and the public v0.16.1 pages for Wrench home, provider support, and security.
Persistent personal agents treat the browser as the work surface
Acharya names three products: Instinct, Grok Bots, and ChatGPT Work. He reads them as a distillation of earlier OpenClaw patterns: persistent agents with cloud(ish) computers, browser access, cached credentials, recurring loops, and a top-level orchestrator that can see other agents and dispatch work.
He writes that browser use is now good enough for most web-based work, with CAPTCHAs, 2FA, and occasional brittle flows as the remaining friction. The product variable he watches is presumptuousness and resourcefulness: how much permission the agent assumes, and how it recovers when a flow breaks.
Instinct and Grok Bots are the aggressive pair in those notes. Acharya had both shop and purchase overnight. When Instinct could not reach one website, it reset the password and finished the task. ChatGPT Work is the least aggressive of the three. He records reluctance around credentials, payments, and consequential actions, and treats that as a compliance choice rather than a missing browser.
The question he leaves open is product design and distribution: which first loop earns enough trust, context, and permission to expand into the rest of a life. This page does not answer that product question. It asks a narrower one that Wrench can answer from its public contract: which web operations are supported, and what happens when they are not.
Wrench exposes a finite supported set
The current release offers 135 supported provider actions. The provider support directory groups those actions by service and access method. This page does not add a provider or invent an extra operation.
An action that is missing, blocked, or no longer matches its reviewed contract stays unavailable. Telegram is not supported in this release, and Wrench does not install a Telegram Bot API substitute or claim Telegram contact access.
The Wrench home states the same boundary in product terms. Wrench lets an agent capture pages, preserve media, read supported connected services, and invoke reviewed account operations. Each authenticated operation is typed, bounded, and tied to one account and transport. The caller brings the model and interface. Wrench supplies the local capability and custody layer. It is not an AI agent, planner, or approval shell.
General browser use is a different contract
Acharya's agents keep a live browser, cached credentials, and a recurring loop. Wrench begins with the exact outcome an agent may request. It exposes a small semantic operation such as messaging.list and keeps the browser, provider plumbing, account session, and credentials inside a local kernel. The security guide states that credentials stay opaque to the caller, and that Wrench does not silently move between an official API, browser session, linked-device store, or portable plugin.
| Decision | Persistent personal agent with browser use | Wrench named operation |
|---|---|---|
| What the caller asks for | A loop that can drive the live web, including recovery when a flow breaks | A named outcome such as messaging.list, not cookies, selectors, scripts, arbitrary HTTP, or every signed-in tab |
| Credentials | Cached credentials on a cloud computer that the agent can keep using | Opaque to the caller and bound to one account realm, provider target, and transport |
| Missing or drifted capability | Recover in the browser. Acharya records a password reset that completed the original task | Stop and report that the action is unavailable. Wrench never switches to a browser fallback silently |
| Consequential write | Product-dependent presumptuousness, including overnight purchase in the Instinct and Grok notes | R2 and R3 writes need an exact short-lived preview and confirmation. An indeterminate dispatch is not retried |
| Completeness | Browser use is good enough for most web work, modulo CAPTCHAs, 2FA, and brittle flows | Incomplete reads stay incomplete. An unavailable action cannot run until a newly reviewed contract exists |
The home page already places browser automation in that split. Browser tools remain useful for visual workflows, UI testing, and exploratory interaction. What Wrench adds is a reviewed semantic operation with no hidden DOM-action fallback.
Unavailable actions fail closed
When an origin, account proof, request, status, field, or response shape changes, the affected operation stops. That is the fail-closed rule documented on the security page. The action cannot run until authorized evidence establishes a newly reviewed contract.
The same rule keeps neighboring surfaces from inheriting authority. LinkedIn's official contact adapter does not grant authority to its separate consumer-web inbox adapter. An Instagram inbox summary does not authorize an individual thread read. Those examples are published on the security page so a gap stays visible instead of being filled by the next available tab.
Acharya's password-reset recovery is the opposite move: the agent used the live site to create a new path to the original job. Wrench refuses that substitution. A missing, blocked, or drifted contract stays unavailable. It does not become general browser control, caller-selected HTTP, or another transport.