Vyre / Computer
Vyre Computer.
Agents that work on real computers.
Some work has no API: a portal, a government site, a back-office page, a desktop app. Vyre Computer is how an agent does that work. It tries the site’s own interface first, uses the screen last, signs in without seeing a password, and stops at anything that sends, posts or pays until a person approves it.
One front door.
Three places to work, named the way you would say them.
An agent asks for a computer by name: “on my Mac”, “on the office computer”. With no name it uses its own. If a name fits two computers or none, it asks you, with the real names as choices. It never guesses.
Your Chrome
The Chrome you already have open, signed in as you. Vyre for Chrome reads a page in one call, fills forms, runs a whole workflow build as one batch and reads DevTools. It works in Chrome, Brave, Edge, Chromium, Arc and Dia.
Your Mac
Computer use on macOS reads and presses controls in any app through the accessibility tree. An agent on your server works on your Mac only for the kinds of work you allow there: look, act and files. Each is off until you turn it on and one command takes it back.
An agent’s own computer
A container on your server with a desktop, Chrome and a terminal. Each agent has its own, with its own home folder and Chrome profile. A few screens are shared: a computer runs only while someone is looking at it, and is frozen when idle.
Interface first, screen last.
Five ways to do a thing, cheapest and surest first.
Clicking pixels is slow and breaks when a page changes. Vyre Computer climbs down a ladder instead. A failure on one rung names the next. When the same target fails twice on the page rungs, the error comes back with a fresh screenshot and the next step already named.
- 1The site’s own API callLearned from the page’s traffic and called from inside the page with your login. A read tries this first.
- 2The page’s controlsFound by role, name and identifier on a fresh look at the page, in every frame.
- 3DevToolsDOM, console, network and scripts, to see why a control did not answer.
- 4The accessibility treeThe control by its role and name, where the page markup is unhelpful.
- 5The screenA screenshot and a point in it. The last rung, for a canvas or a frame it cannot read.
Before any of this, computer.use checks for a Connection you made or an operation Vyre learned from the site. If one covers the job, the screen is not touched. Say “do it on screen” and it goes straight there.
Part of Vyre, not beside it.
It plugs into the Vault, Agents, Flows, Needs you and the Gate.
Vault
Logins are filled without the model seeing them. Tag a login with #Name and the Vault types the username, password and one-time code into the agent’s computer. While it does, the agent’s hands refuse every read and input, and the fill ends on its own within a minute. Your own Chrome is never typed into by Vyre: you type, or the Vault’s fill extension does, with Touch ID.
Agents
Each agent has its own computer and can start, stop and read only that one. A named agent holds a grant from you. In Chrome it posts its plan before its first action, and you can interject, edit a step that has not started, or stop it.
Flows
Teach Vyre a site once and make it a Connection. A Flow’s “Call a service” step then runs the site’s operations with no model in the loop, and anything that is not a read is held. A public-records search can run on a schedule this way.
Needs you
A held act is a card with the site, the control and the field values it would send. When a site’s login runs out, one quiet card says “Sign in to the site again” and closes itself when the site answers.
The Gate
A send, a post, a payment or a delete made through a computer waits at the Gate. An agent can ask and cannot approve. If the page changed since the act was held, the release is refused and nothing happens.
What is built.
Today, in code and under test.
- Vyre for Chrome, two ways to run itStandalone for Claude Code, and native inside Vyre. CI drives a real Chrome on macOS, Windows and Linux. Install steps and capabilities. The architecture.
- Computer use on a MacAccessibility-tree control of any app. A visible indicator shows while it acts and no setting removes it. An agent’s send is held for your yes.
- A computer for each agentA container with a desktop, Chrome and a terminal. Its home folder and Chrome profile survive a restart. Limits are set per agent:
vyre agents computer kit limits --cpus 2 --memory 4. - Take-overA person takes the keyboard and the agent’s hands refuse input until the person gives it back. A person signing in privately also blinds the agent: its reads are refused too.
- Lending a computer to a SpaceA member lends a Mac or Linux computer. The Space’s sessions run there inside a sandbox (macOS seatbelt, Linux bubblewrap) whose network reaches only the AI provider and the Space, in an encrypted workspace that opens while the Space leases its key (one hour, renewed while access holds). Either side takes it back in one tap. A session moves to the server when the lid closes.
- Sign-in handed to the VaultThe agent says
computer.use { do: "signin", login }and never receives the login. When you turn egress on, chosen sites (a bank, a tax authority) leave through your own Mac so they see your address, and fail closed if the Mac is away.
Where it goes.
Drive any connected computer, from wherever you are.
The pieces for this are already in place: a Space’s server that holds the Gate and the Vault, computers that join it, a phone that approves with Face ID or a fingerprint, and a placement step that decides where work runs. The next steps extend that picture. They are direction, not dates.
Where you ask from
Your Space’s server
Computers that do the work
Solid boxes are built. Dashed boxes are coming next.
- Coming in 0.5.2One Chrome extensionThe password and passkey extension, the Chrome control extension and the standalone server become one. It signs in like a device of yours: its own key, listed in Devices, removable there, with no typed address.
- Coming in 0.5.2Chrome control for chatsA chat asks to use this Chrome. You allow it once and it is hands-free on that browser until you take it back. Esc or the toolbar stops everything, and sends, posts and payments stay held. No native host and no local port.
- Coming in 0.5.2A chat in the browser side panelEvery chat there is an ordinary Vyre thread saved in the Space, openable from the app and the phone. The agent sees the current tab only when you turn sharing on.
- Coming nextScreen ShareWatch and take over your agents’ computers and Chrome on every device. The take-over rules it needs (keyboard ownership, a shield for private sign-in) are already built in the computers module.
- Coming nextDrive your computer from your phoneThe phone is already a paired device that approves with Face ID. The direction is a request from it to a connected computer that is awake, under the same grants as an agent’s.
- Coming nextAgents borrow a computer from the Space’s poolPlacement already decides where a Space’s sessions run: on a computer lent to it, on the server, or wait. The direction is the same decision for an agent’s computer use.
- Coming nextA Chrome profile for each agentEach agent’s own computer already has its own Chrome profile. The direction is the same inside one person’s Chrome: a tab group and profile per agent, so several agents work there at once.
Connects to
- Vyre for ChromeInstall it and see what each way can do.
- Chrome control, architectureThe control loop, the hold-and-approve path and the Esc stop.
- Vyre architectureThe Gate, the Vault and the layers Vyre Computer plugs into.
- Vyre Computer, in the docsThe tool, the Mac classes and Vault sign-in.
- Lend a computer to a SpaceThe sandbox, the encrypted workspace and the leased key.
- Map your business onto VyreWhere computer work fits in a firm’s Flows and agents.