Browser mode
The work behind a login is still work.
Vendor portals, admin consoles, government forms, back offices with no API — Browser mode operates the real website in a real browser, visibly. Your credentials stay in a vault the agent can use but never read, and every use is written to a ledger.
The vault boundary
It can use your password. It can never read it.
How a session runs
Granted once. Worked visibly. Handed over when a human is required.
A browser session is not a script. It observes the page, decides, and acts — under the same plan, budgets, and approvals as every other Aghata session.
Grant the credential once
Save a login to the vault and scope it — this time, this task, or this site. It's encrypted, substituted outside the model, and never appears in prompts or logs.
It operates the site, on the record
Real clicks in a real browser, with a live view you can watch and take over. Each step keeps evidence — except credential screens, which are never photographed.
It hands over when a human is required
A login wall or 2FA prompt pauses the run and makes the live view interactive. You sign in; the session resumes its plan. Your logins persist for next time.
Trust, mechanically
Not promises. Mechanisms.
Every claim on this page corresponds to a structure in the product — a ledger row, a scope, a pause state — not a policy document.
Every use is written down
Each time a credential is used, a ledger entry records which run, which site, and when. You review usage after the fact instead of guessing.
Grants, not blank checks
Approve a credential for this time, this task, or this site. High-risk origins — banking, payments, SSO — always step up and re-ask, regardless of scope.
Redaction by construction
Steps keep screenshots of what happened — but credential-bearing screens are skipped entirely. Auth pages are never photographed, so they can never leak.
Watch, or take the wheel
The session streams the actual browser. You can watch every click, and take over at any moment — it's your browser session, driven for you.
Logged in stays logged in
A persistent browser profile keeps your sessions between tasks, so routine work doesn't restart from a login page every morning.
A rejected click cancels the run
Rejecting a risky browser action cancels the session rather than improvising around your no — because a refused step usually invalidates the plan.
The category
Where a chatbot stops and a script breaks.
Three ways to get software to work a website for you — and what each one actually does at the moments that matter.
| Chatbot with browsing | RPA scripts | Browser mode | |
|---|---|---|---|
| Sites without an API | Reads public pages; can't act behind a login | Works until the selector changes | Operates the real site, logged in, adaptively |
| Who holds the password | You paste it into the chat — now it's in a prompt | Stored in the script or a config file | A vault the agent can use but never read |
| At a login wall or 2FA | Gives up | Fails the job | Pauses, hands you the keyboard, resumes |
| When something risky comes up | No concept of risk | Executes whatever was scripted | Stops at an approval you can inspect |
| What's on the record | A transcript | A log file, if you built one | Per-step evidence + a credential-use ledger |
Questions
Questions about letting it log in.
Can the agent see my password?+
No — structurally, not by policy. Credentials are encrypted in the vault and substituted at the point of use, outside the model. Your password never enters a prompt, a step record, or a log. What the agent gets is a logged-in page; what you get is a ledger entry saying the credential was used.
What happens at a login wall or a 2FA prompt?+
The session pauses for authentication and the live view flips from watch-only to interactive. You log in — password manager, hardware key, whatever you use — and the run picks its plan back up. Aghata never tries to social-engineer its way past a second factor.
Can I watch it work?+
Yes — the live view shows the actual browser, click by click, and you can take over at any time. After the fact, every step keeps evidence: what it saw, what it did, and screenshots — except on credential screens, which are never photographed.
Does it log in fresh every time?+
No. Sessions keep a persistent browser profile per user, so a login granted on Monday still holds on Thursday's task. Grants are scoped — this time, this task, or this site — and high-risk sites like banking or payments always re-ask.
What if the site changed and it gets stuck?+
It stops and tells you where. Browser sessions run under an action budget; a run that can't make progress parks with its evidence trail intact instead of clicking in circles. Rejecting a risky browser step cancels the run — a rejected click usually invalidates the plan, and Aghata treats it that way.
Chapters of one system
Give it the outcome. Keep the control.
Start free in the product, or talk to us about how your team would use it.