Client-side browser control versus server RPA
AshnaAI controls the user’s own browser through an extension or desktop broker. It is not a hosted RPA farm. Actions are a closed list, every run needs an idempotency key, and secrets go to requestUserInput instead of the page.
Method: Reading the browser-control tool contract: implemented actions, idempotency, extension-or-desktop execution, and the handoff to requestUserInput for secrets.
Key findings
- Browser control is a client tool. The extension or desktop broker executes actions on the user’s machine, not on an Ashna-hosted browser farm.
- Implemented actions are a closed set: observe, extract, scroll, screenshot, navigate, search, click, fill, select, upload, and submit.
- Every run requires an idempotencyKey so a retry continues the same tab session instead of opening a new one.
Client execution is the architecture
A hosted RPA bot sees a vendor browser. That is useful for unattended back-office jobs and dangerous for personal sessions, SSO cookies, and files on disk. AshnaAI takes the other side: the agent proposes actions, the user’s browser performs them.
The tool is schema-only in the cloud. The extension or desktop broker is the executor. That is the same pattern as Tally, applied to the web.
A closed action list
The implemented list is finite. The agent can observe, extract, scroll, screenshot, navigate, search, click, fill, select, upload, and submit. It cannot invent a new primitive such as “download the whole CRM.”
FILL_FIELD supports plain text or a file upload source. Uploads still happen on the client. The agent does not receive the file bytes into the cloud tool call as a substitute for local access.
Retries and human gates
idempotencyKey is mandatory. The client, not the model, owns tab continuity. Secrets, missing local files, and irreversible confirmations must use requestUserInput after the agent has tried observation and compact target resolution.
This is why browser control is an alternative to Copilot-style “do it in the cloud” automation, not a clone of it. The compare page covers product packaging; this note covers the execution boundary.
Limitations
If the extension or desktop broker is not installed, browser control cannot run. AshnaAI also does not build or host the target website. It operates pages the user can already open.
Unattended 24/7 RPA on a vendor VM is not this product. Firms that need that pattern should not read this article as a promise of it.
Frequently asked questions
- Is AshnaAI browser control the same as server RPA?
- No. Server RPA logs into a remote browser that the vendor hosts. AshnaAI drives the browser already running on the user’s computer through the extension or desktop broker.
- Which browser actions exist today?
- OBSERVE_PAGE, EXTRACT_PAGE, SCROLL_PAGE, CAPTURE_SCREENSHOT, NAVIGATE, SEARCH_WEB, CLICK, FILL_FIELD, SELECT_OPTION, UPLOAD_FILE, and SUBMIT.
- Why is an idempotency key required?
- Retries should continue the same browser-control task. The client keeps tab continuity. Without a stable key, a retry looks like a new job and can lose the page.
- Does the agent ask me to grant browser permissions in chat?
- No. The installed extension handles local execution. The tool contract says not to ask the user for browser-control grants in conversation.
- Where do passwords and irreversible confirms go?
- To requestUserInput, not into a fill action. Browser control is for page observation and ordinary form work, not secret capture.
- Do I need the desktop app?
- Use the extension or the desktop broker. Local files and some desktop-only connectors still need the desktop app. See the desktop files how-to.
Related
Try this in AshnaAI. Create a free account and install the desktop app when the workflow needs local access.