Agent (Preview)

Agent drives one browser tab towards a goal. There is no mode to switch into: you ask in the chat, and the model decides whether the request needs the browser. When it does, it hands the whole task to Agent, the run appears as a card above the model’s answer, and you supervise it from that card. Routine clicks and typing can run automatically; posting, destructive actions and sensitive steps still require your decision. It is experimental: success depends on the website and the selected model, and every step is checked against the page. Use a model with verified tool calling, and verified vision for visual tasks. No model is currently published as release-qualified on the new workflow suite.

It is off unless you turn it on, from Browser agent (experimental) in the chat’s Context sheet or Settings → Agent; until then the chat model is never offered it. On Chrome it needs two permissions the browser asks for once, at install or on the update that brings the Agent: debugger, to drive the tab it is given, and webNavigation, to tell that tab’s frames apart.

Starting a run

Ask for something that needs a page — “find the pricing page and tell me the cheapest plan”, “fill in this form but don’t submit it”. The model writes the task as one instruction and asks to start it on the tab you are looking at. You see that instruction before anything happens, and you are asked:

• the first time Agent starts on a site in a chat;
• every time the model had read page content earlier in the turn — an attached tab or file, retrieved documents, or an earlier run’s result — because a task written after reading a page may be repeating what the page said;
• every time the task would run on a different tab from the one you are looking at;
• the first time a remote model would be sent page content.

To carry on after a run, use Continue, Retry or Start over on its card, or just ask. Each drafts an ordinary message you still send.

How a step works

Every step is the same six things, in order, and none of them is skipped.

1. Observe — the tab’s own content script reports the page: its URL, title, the text you can see, the rest of the document’s text, open dialogs, and every interactive control with a short reference like e1.
2. Decide — your selected model is asked for exactly one next action, naming a control by its reference. Page content is supplied as data, never as instructions.
3. Ground — the action is resolved against the exact control the observation reported. A reference the page no longer holds, or a command the control cannot accept, is refused and the model is told why.
4. Authorize — policy classifies what the action would actually do and decides whether you are asked.
5. Execute — the resolved action runs against that control and no other.
6. Verify — the page is observed again and compared. A step is confirmed, refused, or unresolved — and an unresolved step pauses the run rather than being retried, because repeating an action that may already have happened is how one click becomes two.

What it asks you about

Action	What happens
Reading, scrolling	Runs without asking
Following a link within a site you already allowed	Runs without asking
Clicking a control, typing into a field	Runs automatically on the starting site when routine actions are enabled
Submitting a form, anything destructive	Asks every time
Payment, sign-in, one-time codes, file pickers	Hands the page to you

Routine actions in Settings is set to Allow on the starting site by default. Each new run gets clicks and typing on the site it starts on for that run only; choose Approve each action to review every change instead. Forms that post or send, destructive actions, new sites, and sensitive steps still require your decision. An empty attachment picker does not force manual takeover; choosing a file does.

When Agent asks about a click or a field, you can also allow that kind of action on that site for the rest of the run. This never carries over to another run.

Anything Agent hands to you is yours to finish. It does not type a password, a card number or a one-time code, and it will not choose a file for you.

What it will not do

• One tab at a time, from a known set. Agent drives the tab it currently controls. The tab you started on and any tab it opened itself are the tabs it may switch between; switching to any other tab — one you were working in — asks you first, whatever site it is on. Every tab it acts on also has to be readable and on a site you allowed.
• Only frames on sites you allowed. Content inside an iframe is observed when the frame is on a site the run may read; a frame on any other site is reported to the model by its origin and left alone.
• Only sites you allowed. A destination on a new site is a new decision.
• Only what the page rendered. Destinations come from links the page actually showed; a URL the model composed carrying data from your page is refused outright when that data is something you typed.
• Nothing it cannot verify. A step whose effect cannot be observed pauses the run and is reported as unresolved, not as done.

What your browser allows

Agent is Chromium only for now; Firefox builds do not include it.

Chromium. Starting a run attaches Chrome’s debugger to its tab. Chrome shows its own banner while that lasts — that banner is this extension, and it is the browser telling you the truth about what is attached. The attachment ends when the run stops, when it hands the tab to you to take over, and when it finishes. With it, the run can send real pointer and keyboard input a page cannot tell from yours, take screenshots for a model that reads them, and see and answer native dialogs.

Where it stops

These are current limits, not design decisions.

• Closed shadow roots. Open shadow roots are observed like any other content, including the text they slot in. A closed one reads as nothing and stays unread rather than guessed at.
• Frame limits. A page with more than eleven child frames has the rest counted but not read, and a very large page can leave a frame no room to report its controls; both are reported to the model as such. Inherited srcdoc and about:blank frames can be read when their creator origin is allowed and the current document identity is known, with at most three such frames per observation. Opaque sandboxed frames remain unread.
• Native dialogs need Chromium. A click that opens alert, confirm or prompt is handed from the input executor to the debugger’s dialog state. Agent can then answer the dialog, with approval before accepting a confirmation. An interrupted edit whose value cannot be verified still pauses; the input is never replayed automatically.
• Document editing is bounded. Text fields and rich-text documents support up to 20,000 characters. Appending or replacing text beyond that bound is refused because the full resulting value cannot be verified. A model’s output budget can require a long insertion to be split into smaller edits. Composer lookup recognizes both its accessibility label and the placeholder shown inside an empty rich-text editor.
• Long documents are read in pages. extract_text returns up to 12,000 characters and a continuation offset. Agent can keep reading past the initial 30,000-character overview, including inside an authorized frame. Each page reads the current document; content changing between reads can change its offsets. A scan that runs out of time reports that explicitly.
• Scroll inside a pane. Scrollable regions have their own references and scroll positions. Agent can scroll a selected pane without moving the rest of the page.
• Vision needs a model that reads images. A screenshot travels only to a model whose provider reports it can read one; a text-only model is sent no picture and is offered no visual action, so a canvas or an image region is out of reach for it.
• Large pages cost tokens. A page with a thousand controls is a large prompt. The page is projected to fit a budget and the model can ask to expand a region, but a small local model may still run out of room.
• Fifty steps, forty minutes. A run that passes either stops.
• A restart pauses the run. If the browser stops the extension’s worker mid-step, the run comes back paused, with the interrupted step marked unresolved, and waits for you. This one is verified against a real terminated worker rather than assumed.

What has actually been measured

The repository contains a thirty-task scripted capability benchmark and a sixty-task controlled workflow suite: forty development tasks and twenty held-out tasks. The workflow suite uses real models and independent final-state predicates; its fixture/scorer unit tests are separate evidence. Three attempts per task with two capable models at the exact candidate are still pending. These suites do not establish reliability on every live website.

Research comparisons, multi-page forms, draft editing, allowed embedded widgets, multiple tabs and exact-row changes are preview workflows, not a qualified production promise. Reports retain failures, required approvals and unexpected interventions separately. No qualified-model list or success rate is published until the repeated live results meet the release criteria.

Choosing a model

Agent needs a model that supports tool calling, and a small one will struggle regardless — hosted models are the target. Tool calling is checked before a run starts, and the model tells you when it is missing. A model whose tool calling you switched on yourself can still start a run; the start prompt says so. A model that answers but cannot follow the one-action-at-a-time contract will exhaust its retries and stop visibly rather than act on a half-understood answer.

If a run stops

The panel keeps the reason, and says what you can do about it: narrow the goal, reload the page, pick a model that can call tools, or take the tab over and finish the step yourself. A paused run tells you why it paused; a failed run leads with the recovery and keeps the underlying message beneath it, so the words the run used are still there if you report the problem. Both stay on screen after the run ends, because the record is the only account of what happened.

Correcting a run and exporting its record

Pause a run between actions to give it a correction, then submit the correction and continue. Answers to Agent’s questions also travel to the next decision, with the question they answer. These instructions do not change permission or approval rules. Time spent answering or correcting a paused run does not count against its active-time budget.

Repeated decisions and grounding refusals trigger bounded recovery: fresh observations, targeted reads, waits or a different grounded route. Exhaustion asks for your guidance; recovery never refunds the run budgets. A premature completion gives a delayed save a bounded chance to produce evidence; it still cannot be accepted without that evidence. An unresolved side effect remains paused and cannot be resumed through the correction field.

Use Export run report to download the current run and its redacted step records as JSON. The report includes your goal, clarifications and page-derived text. It is saved locally only when you click the export button; nothing is sent to a feedback service automatically.

Disable and report a problem

Stop the active run from its card first, then turn off Settings → Agent → Browser agent (experimental) to prevent new runs. Disabling the setting is not a substitute for stopping an active run. Keep the durable record when an effect is uncertain; inspect the page before starting another run.

Preview testing is voluntary. Start with disposable pages and share a report only when you choose to. Review an exported run report before sharing: it can contain your goal and page text. Benchmark summaries omit raw page content; private debug evidence should stay local. There is no automatic feedback upload.

Use the disable path if a preview update misbehaves. Preserve local data and install a forward-compatible fix; do not clear storage or downgrade across a forward-only migration to roll back runtime behavior. Closing the side panel pauses supervised work unless this task has explicit panel-close consent. Disabling Agent also prevents automatic worker recovery. Browser shutdown clears that consent’s session identity; machine sleep interrupts execution. On a worker wake, opted-in safe checkpoints can resume after permission, tab, origin and provider/model checks. Interrupted effects require reconciliation and are never replayed automatically.

With the optional alarms permission already granted, active panel-free tasks keep a one-minute browser wake alarm. Recovery still rechecks consent and the Agent switch. If notification permission is already granted, completion and human boundaries produce a content-free desktop notification. Neither control requests permissions from a background event.

Current qualification fixtures are generated variants from ten workflow families, not sixty independent real-world workflows. Live-model reports, measured prices and comparable manual-intervention baselines are separate release evidence.