How computer-use and browser agents work

Video lecture

How computer-use and browser agents work

11 chapters · about 8 min · full transcript

Coming soon

Chapter 1 of 11

Computer-use and browser agents

What they are
The observe-think-act loop
Where they help and struggle
Choosing the automation layer

The narrated lecture is in production

Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.

Chapters

Transcript of the narration, chapter by chapter.

0:00 Computer-use and browser agents

An operations team updates stock levels on five supplier portals every week. None of them has an API. It takes hours of clicking. A computer-use agent can do the clicking, and stop before the final submit so a person can approve. In this lecture you will learn what computer-use and browser agents are, how their loop works, where they help, why they are harder than API integrations, how to choose the right automation layer, and how to write task instructions an agent can actually complete.

0:37 What they are

Computer-use agents, also called browser agents or GUI agents, operate software through its user interface, the way a person does. They look at the screen, decide what to do, and act by clicking, typing and scrolling. Anthropic, OpenAI and Google all offer computer-use or browser-control capabilities through their APIs, and several consumer assistants include agent modes that browse and act for the user. Tool versions and supported actions change frequently, so pin the version you tested and re-test when you upgrade.

1:12 The loop

The loop has four steps. Observe: take a screenshot, and sometimes read the page structure or accessibility tree. Think: decide the next action toward the goal. Act: click at coordinates or on an element, type text, press keys, scroll or navigate. Then observe the result, and repeat until done or stopped. It is the agent loop, with the screen as the environment. Systems that combine vision with the browser's page structure can identify elements more reliably than screenshots alone.

1:46 Helps vs hard

Where do they help? Filling repetitive forms across portals that lack APIs. Collecting information from several websites into a structured summary. Testing web applications by following user journeys. Operating legacy desktop software for data entry or extraction. And completing multi-step browser tasks on a user's behalf, with oversight. Why are they harder than API tools? Layouts change and pop-ups appear. Each step costs a screenshot and a model call, so tasks are slow and costly. Similar buttons and hidden menus create ambiguity. One mis-click can derail everything. And confirming success visually is unreliable.

2:26 Choose the layer

So choose the right automation layer. If the system has an API or an MCP server, use it: faster, cheaper, more reliable and easier to secure. If it is a stable web app with fixed steps, use scripted browser automation such as Playwright. If the web app changes and the task needs judgement, use a browser agent that reads the page structure plus screenshots. And reserve pixel-level computer use in a virtual machine for desktop or legacy apps with no other access. Increasingly, agents combine these, calling APIs where they exist and falling back to the screen only when needed.

3:09 The loop in code

Every implementation has the same shape, which the lesson shows in a short function. It keeps a history, takes a screenshot, asks the model for the next action, and stops when the model says done. If an action needs approval, it pauses and returns the proposed action. Otherwise it executes the action inside an isolated virtual machine or browser, appends the result with a fresh screenshot, and loops, up to a step limit. Notice that everything important lives outside the model: the isolated environment, the approval function, the step limit and the logging. Provider quickstarts, such as Anthropic's containerised reference implementation, are the safest way to try it.

3:56 Writing task instructions

Instructions for computer-use agents must be more explicit than chat prompts, because the agent cannot ask you mid-task. The lesson's example: goal, update stock levels for twelve listed SKUs. Start, the portal dashboard, already logged in. Steps it may need: search each SKU, open its edit page, set available quantity. Rules: change only that field, not prices or descriptions; if a SKU is not found, record it and continue; if a pop-up asks to accept new terms, stop and report. Finish: open the pending changes page, take a screenshot, and stop without pressing submit. Report: a table of SKU, old quantity, new quantity and status.

4:42 Worked example + measurement

Back to the operations team. The agent gets a goal per portal and a structured list of updates. Login is handled by a secure credential mechanism, never typed from the prompt. It stops before submit, screenshots the summary, and waits. A person reviews five screenshots and approves. After several weeks of clean runs on two stable portals, those two are allowed to submit automatically, with daily screenshot audits. Measure time per run, including human review, against the manual baseline, plus errors caught and interventions. If review takes as long as the manual task, narrow the task or find an integration. And always design verifiable end states, like a confirmation number or a record visible in the system.

5:33 Example 1: downloading utility invoices

A simple worked example. You need to download last month's invoices from a utility company's website that has no API: log in, go to billing, filter by month, download each PDF. A computer-use agent can do this. Your instructions: start logged in on the dashboard; go to billing history; filter to last month; download each invoice PDF; do not change any settings or payment details; if a pop-up asks to accept new terms, stop and report; finish by listing the file names downloaded. The agent completes the job in about twenty steps, and you verify the files. Explicit scope and a clear finish line make it a checkable errand.

6:20 Example 2: port and customs portals (illustrative)

Now a business scenario, with illustrative numbers. A freight forwarder in Karachi must submit shipment details to four different government and port portals, about four hundred submissions a month, none with an API. Staff spend around five minutes per submission copying data. They pilot a browser agent that reads structured shipment data from their system, fills each portal's form, and stops on the final review page with a screenshot. A clerk approves each one. Early runs fail about one time in six, mostly because of slow page loads and one portal's session timeouts; adding waits and a re-login routine, handled by a secure credential service, brings failures below one in twenty. With approval included, time per submission falls to about ninety seconds. They keep approvals on all four portals, because a wrong submission has regulatory consequences. Illustrative figures.

7:20 Recap

To recap. Computer-use agents observe screens and act through clicks and typing in a loop. They help where no API exists, but they are slower, costlier and more brittle than API or scripted integrations, so choose the lowest layer that works. Keep the environment, approvals, limits and logs outside the model, and write explicit instructions with scope, obstacles, a stopping point and a report. Try this now: identify one repetitive browser task, and write its goal, verifiable end state, approval point, and whether an API or scripted alternative exists. Next: deploying computer-use agents safely.

What they are

Computer-use agents (sometimes called browser agents or GUI agents) operate software through its user interface, the way a person does: they look at the screen, decide what to do, and act by clicking, typing and scrolling. Several AI providers and platforms offer such capabilities, and browser automation products increasingly build them in.

They matter because much business work happens in interfaces without convenient APIs: legacy systems, supplier portals, government websites and internal tools.

The loop

1. Observe: take a screenshot (and sometimes read the page structure or accessibility tree)
2. Think: decide the next action toward the goal
3. Act: click at coordinates or on an element, type text, press keys, scroll, navigate
4. Observe the result, and repeat until done or stopped

This is the agent loop from our agents course, with the screen as the environment. Some systems combine vision with the browser's page structure (the document object model or accessibility tree), which can make element identification more reliable than pure screenshots.

Where they help

Filling repetitive forms across portals that lack APIs.
Collecting information from multiple websites into a structured summary.
Testing web applications by following user journeys.
Operating legacy desktop software for data entry or extraction.
Assisting users by completing multi-step tasks in a browser on their behalf, with oversight.

Why they are harder than API-based tools

Brittleness: layouts change, pop-ups appear, pages load slowly, elements move.
Speed and cost: each step involves a screenshot and model call; tasks can take many steps.
Ambiguity: similar-looking buttons, hidden menus, dynamic content.
Error compounding: one mis-click can derail the rest of the task.
Verification: confirming success visually can be unreliable ("Did the form actually submit?").

Capabilities and reliability are improving rapidly, and published benchmark results for these agents change frequently. For any serious deployment, measure on your own tasks.

When to prefer other approaches

Use an API or structured integration (including MCP servers) when one exists: it is faster, cheaper, more reliable and easier to secure. Use traditional scripted automation (such as robotic process automation or browser testing frameworks) when the steps are fixed and the interface is stable. Computer-use agents fit best when the interface varies, the task needs judgement, or no integration exists.

Worked example: supplier portal updates

An e-commerce operations team must update stock availability on five supplier portals weekly, none with an API. A browser agent is given:

A goal per portal and a structured list of updates.
Login handled by a secure credential mechanism, not typed from the prompt.
An instruction to stop before the final submit, take a screenshot of the summary page, and wait for approval.

A team member reviews five summary screenshots and approves. Time saved is substantial, and errors are caught at the review step. After several weeks of clean runs on two stable portals, the team allows those to submit automatically, with daily screenshot audits.

Writing good task instructions for a computer-use agent

Instructions for these agents benefit from being more explicit than for chat tasks, because the agent cannot ask you mid-task:

Goal: update stock levels on the supplier portal for the 12 SKUs listed below.
Start: the portal dashboard (already logged in).
Steps you may need: search each SKU, open its edit page, set "Available qty".
Rules:
- Only change the "Available qty" field. Do not edit prices or descriptions.
- If a SKU is not found, record it and continue.
- If a pop-up asks you to accept new terms, stop and report.
Finish: open the "Pending changes" page, take a screenshot, and stop
without pressing "Submit".
Report: a table of SKU, old qty, new qty, status.

Notice the explicit scope limits, the handling of expected obstacles, the stopping point and the structured report. These turn a vague errand into a checkable job.

Measuring whether it is worth it

Track time per run (agent plus human review) against the manual baseline, error rate caught at review, and how often runs need intervention. If review takes nearly as long as doing the task manually, the design needs rethinking, perhaps by narrowing the task or finding an integration.

Computer use in 2026

Anthropic, OpenAI and Google all offer computer-use or browser-control capabilities through their APIs, and several consumer assistants include agent modes that browse and act on the user's behalf. Tool versions and supported actions change frequently (new tool types, higher-resolution screenshots, zoom actions), so pin the tool version you tested and re-test when upgrading.

Increasingly, agents combine approaches: they call APIs or MCP tools when available, use a browser automation layer (DOM or accessibility tree) for web apps, and fall back to pixel-level computer use only for interfaces with no better option.

Hands-on: the shape of a computer-use loop

The exact tool definitions differ by provider, but every implementation has this shape:

def run_computer_task(goal, model_call, execute_action, take_screenshot,
                      needs_approval, max_steps=50):
    history = [{"role": "user", "content": goal}]
    for step in range(max_steps):
        reply = model_call(history, screenshot=take_screenshot())
        history.append(reply.as_message())
        action = reply.next_action()          # e.g. click(x, y), type(text), key("Enter"), done
        if action is None or action.kind == "done":
            return {"status": "done", "steps": step + 1, "report": reply.text}
        if needs_approval(action):
            return {"status": "paused_for_approval", "action": action.describe()}
        result = execute_action(action)       # runs inside an isolated VM or browser
        history.append(result.as_message())   # includes a fresh screenshot or error
    return {"status": "stopped", "reason": "step limit"}

Everything important lives outside the model: the isolated environment, the approval function, the step limit and the logging. Provider quickstarts (for example Anthropic's computer-use reference implementation, which runs in a container) are the fastest way to try this safely.

Choosing the right automation layer

Situation	Best layer
The system has an API or MCP server	API or MCP tool calls
Stable web app, fixed steps	Scripted browser automation (e.g. Playwright)
Web app that changes, needs judgement	Browser agent using DOM or accessibility tree plus screenshots
Desktop or legacy app, no other access	Pixel-level computer use in a VM

Going further

When building or evaluating such agents, design tasks with verifiable end states: a confirmation number captured, a record visible in the system of record, a downloaded file with expected contents. Visual "looks done" is not proof. Log every action with screenshots for audit and debugging.

Computer-use agents observe screens and act via clicks and typing in a loop.
They help where no API exists: portals, legacy systems, cross-site research and UI testing.
They are slower, costlier and more brittle than API integrations; prefer APIs or scripted automation when available.
Design verifiable end states and approval points; log actions with screenshots.

Identify one repetitive browser task in your work. Write the goal, the verifiable end state, the approval point, and whether an API or scripted alternative exists.

Enrol for free to save your progress

Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.

How computer-use and browser agents work