Reference

What is a computer-use agent?

A computer-use agent is a program that operates a real computer the way a person does: it takes a screenshot, decides where to click, moves the pointer, types, and reads what comes back, then repeats. It works against the same screens a person uses rather than against an API, which is why it can use software that has no API, software behind a login, and software whose API leaves out the one thing you need.

Key points

  • A computer-use agent acts on a machine. An assistant produces text you then act on.
  • It needs no integrations, because it drives the interface a person would.
  • It is slower than an API per step, and only pays off when many run in parallel.
  • Running many at once is a different problem from running one: isolation, reclaiming idle browsers, not stealing focus, and verifying their own claims.
  • It cannot pass a deliberate human check, and a well-built one does not try.

How a computer-use agent works

Every computer-use agent runs the same loop. The details differ between implementations; the shape does not.

  1. Observe. Capture the screen, or the browser viewport, as an image.
  2. Decide. Pass that image and the goal to a model, which returns an action: click at a coordinate, type this text, scroll, wait.
  3. Act. Execute the action against the real machine.
  4. Read back. Capture the screen again and check what actually happened, which is frequently not what was intended.
  5. Repeat until the goal is met or the agent decides it cannot be.

The read-back step is what separates a working agent from a demo. A model that acts without checking the result will confidently report having filled a form that never opened.

Why it needs no integrations

An API integration is a contract between two pieces of software. It has to be built, it has to be maintained, and it only exposes what the vendor decided to expose. A computer-use agent needs none of that, because the interface it targets is the one already built for people.

That is a real capability difference, not a convenience. Software with no public API is reachable. So is a page behind a login, a tool your account has access to but no key for, and the ninety percent of an application that its API does not cover.

What breaks when you run a hundred at once

One agent is a demo. The engineering starts at the point where many of them run against one machine, all day, while somebody is using it. These are the failures that show up, in the order they show up.

Every agent needs its own browser, and browsers are expensive

Agents cannot share a browser profile: they would share cookies, sessions and history, and one agent’s login would land in another’s account. So each gets an isolated browser, and a browser is hundreds of megabytes of memory and a measurable share of the battery. Fleet size is bounded by RAM long before it is bounded by anything interesting.

The fix is unglamorous: reclaim idle browsers rather than leaving them running. Lanes closes an agent’s browser after ten minutes of inactivity and reopens it on the next step, which costs a few seconds and returns the memory.

A failed page load is not a refusal

When a navigation fails, Chrome commits a real page atchrome-error://chromewebdata/. An agent that treats an unexpected URL as a policy boundary will read that as “I have been blocked” and stop, when what actually happened is a network blip that a retry would clear. Distinguishing a dead page from a wall is a specific piece of code, and without it a fleet quietly halts on transient failures.

An agent reporting its own success is not evidence

The most expensive failure is the confident one. An agent that believes it booked a meeting will report a booked meeting, and at a hundred agents nobody is checking by hand. The only thing that works is separation: a second agent that opens the evidence itself and either confirms the claim or refutes it, with the refutations counted rather than discarded. In Lanes, a booked call counts only once that second agent has seen it on the calendar.

The machine still belongs to somebody

Agents driving a real browser will pull window focus, raise windows, and take the pointer, which makes a laptop unusable while they work. Background agent work has to be genuinely background: no focus changes, no windows raised, no interference with whoever is at the keyboard.

What computer-use agents cannot do

Worth saying plainly, because the category is over-promised.

  • They cannot pass a deliberate human check.CAPTCHAs, two-factor prompts and identity verification are there on purpose. A well-built agent stops and says so rather than trying to defeat them.
  • They are slower than a person on any one short task.Every step costs a screenshot and a model call. The economics only work when the work is repetitive enough to parallelise.
  • They break when layouts change. A redesign that an API would not have noticed can stop an agent mid-run.
  • They are not deterministic. The same goal run twice takes two different paths, which makes them hard to test by comparing before and after, and means you have to sample behaviour continuously instead.

Frequently asked questions

What is a computer-use agent?
A computer-use agent is a program that operates a real computer the way a person does. It takes a screenshot, decides where to click, moves the pointer, types, and reads what comes back, then repeats. It works against the same screens a person uses rather than against an API, which is why it can use software that has no API at all.
How is a computer-use agent different from a chatbot or an assistant?
A chatbot produces text and hands it back to you. A computer-use agent produces actions on a machine and hands you the result of those actions. The practical difference is who does the work: an assistant drafts the email you then send, while a computer-use agent opens the inbox, sends it, watches for the reply and answers it.
Do computer-use agents need API integrations?
No. A computer-use agent needs no API integration, because it drives the same interface a person would. That is the whole point of the approach: it can work in software with no public API, software behind a login, and software whose API omits the one thing you need. The cost is that it is slower than an API call and it breaks when a layout changes.
Can you run many computer-use agents at once?
Yes, and running many at once is a different engineering problem from running one. Each agent needs its own isolated browser, which costs real memory and battery, so idle browsers have to be reclaimed rather than left running. Agents also have to be prevented from stealing focus from whoever is using the machine, and their self-reported successes have to be checked by something other than themselves.
What can computer-use agents not do?
A computer-use agent cannot get through a deliberate human check, and should not try: CAPTCHAs, two-factor prompts and identity verification are boundaries, not obstacles. It is also slower than a person on any single short task, because every step costs a screenshot and a model call, and it is only economical when the work is repetitive enough that many agents can run in parallel.

Lanes runs them in numbers

Lanes puts teams of computer-use agents on a goal you name, on your computer and in the cloud, and works the number until it is met. Free to start.

Download for Mac