AGI browser agent: the web, with your permission.

The web is where a lot of work actually lives: supplier portals, admin dashboards, booking systems, ticketing tools, reporting consoles, registration pages. They are rarely connected by an API you can call. They are a page with fields, buttons and a login. A browser agent works at that level: it opens the browser, reads the interface, acts on it and confirms the outcome.

The important word is real. This is not a scraper that reads a page and stops at the edge of the HTML. It operates the interface: types into fields, selects options, confirms dialogues, downloads the file, uploads the replacement, moves through a multi-step flow. When a step is ambiguous, it reads the page again and decides the next action from what is visible rather than from a script written for one layout.

That makes it useful for the long tail of web work that no integration covers. Refreshing prices in a supplier portal. Pulling a monthly report from a dashboard that has no export button. Registering a batch of attendees. Checking a booking flow after a theme update. Reading six sources and putting the findings where the next step can use them. The work is ordinary and time-consuming, which is exactly the work that should be handed over.

It is also where a general intelligence earns its keep. The browser is one tool among several, so the agent can leave it and come back: pull the data from the portal, compare it in a file, update the site through CMS, then reopen the browser to confirm the page. The thread survives the transitions because the same intelligence holds the goal.

All of it runs under your permissions. The agent uses the access you grant, on the machine you choose, and it stops for approval where an action cannot be undone. A browser session is your session; the agent is the worker using it, not a separate identity acting in your name.

There is a second gain beyond the time saved: consistency. A person doing the same portal routine on a busy Friday will skip a check, misread a column or forget to download the evidence. The agent runs the same steps, in the same order, with the same verification, every time. Consistency is not glamorous, but in reporting and admin work it is the difference between a record you can trust and one you have to audit twice.

Browser work is powerful precisely because it acts inside your accounts, so the permissions model matters more here than anywhere else. The agent uses the access you grant and nothing beyond it. Irreversible actions, such as submitting an order, sending a message, deleting a record or changing a live setting, wait for your approval. The log records what was read, what was changed and what was left alone.

Some things it will not do. It does not solve CAPTCHAs to get around an access control, does not bypass a site’s authentication or anti-automation measures, and does not pretend a blocked action succeeded. Where a site actively refuses automation, that is reported as a limit of the site rather than a failure to disguise. Two-factor prompts and identity checks that need a human are yours to complete.

The practical limit is the same as a person’s: a page you cannot see, an account you cannot access, a decision that needs authority. The difference is that the agent will tell you which of those it hit. A run that stops for approval is a working run. A run that claims success without evidence is the thing this design exists to avoid.

Local-first matters here too. The browser session, the files it reads and the output it produces stay on your machine by default. You choose which model providers are used and which sites are in reach. That is a different privacy posture from a cloud bot that needs your credentials and your data in someone else’s environment.

The pattern that makes this safe is small permissions and clear stops. A task that reads a dashboard is different from a task that submits a form, and a task that submits a form is different from one that changes a setting other people depend on. Each gets its own scope and its own gate. The agent does not need more access than the job, and the approval rule can be as specific as a single button on a single page.