An agent can find the right website in the wrong account. The page looks familiar, the export button works, and the resulting file belongs to another workspace.
A useful browser description helps route the task before that happens. It cannot establish which account is active right now. I would treat those as two separate checks: candidate selection from recorded context, followed by verification against the current page.
This is a proposed operating procedure from the BrowserAct team. The examples are fictional and do not represent a live customer portal test.
Write descriptions for the next operator
A label such as “work browser” leaves too many questions unanswered. Work for which organization? Which site? Which role? When was the login last checked?
A more useful note could be:
Purpose: monthly supplier document collection for Demo Workshop.
Sites: billing.example.com.
Expected account role: Demo Workshop billing reader.
Last observed: account menu matched the expected organization.
Observed at: 2026-11-07 09:00 UTC.
The note records an observation, not a promise. The login can expire. Someone can switch organizations. The same browser may have access to several workspaces. A successful check last month should not become an indefinite assurance.
Use a stable account reference where possible. Keep passwords, session cookies, recovery codes, and full document contents out of a routing description. A short reference to protected evidence is enough when an observation needs to be audited.
Select a candidate without pretending the choice is certain
Read the task requirements first: target site, intended organization, expected role, and permitted action. Then compare them with the descriptions available in the browser inventory.
A clear match gives you a candidate to inspect. An ambiguous match needs clarification or an authoritative account mapping. Similar names are not enough to resolve two organizations that share the same portal.
Do not pick a different personal account just because it is already logged in. Convenient access and the intended identity are different facts. If the approved account cannot be established, record that boundary before touching the business action.
Check the identity where the task happens
Open the intended site in your own task session. Inspect the current account menu or organization selector. Record the evidence that answers the actual identity question.
For a multi-organization portal, an email address alone may not resolve the active workspace. For a shared team account, the displayed role may matter as well. Choose the smallest reliable check that identifies the task's organization and account context.
The visible identity check should happen before the export or other consequential action. If the workflow changes organizations later, repeat the relevant check at that boundary. Do not assume an earlier observation survived the switch.
An account menu is evidence about identity. It is not, by itself, permission for every action available on the page. Keep the user's authorized task scope alongside the account check.
Record the decision separately from the description
A small task record can preserve what was expected and what was observed. This is a design sketch, not a BrowserAct API schema:
{
"task_ref": "demo-monthly-export-07",
"browser_ref": "approved-demo-browser",
"target_host": "billing.example.com",
"expected_organization": "Demo Workshop",
"observed_organization": "Demo Workshop",
"identity_check": "matched",
"evidence_ref": "internal://demo/account-check-07",
"next_step": "inspect_requested_period"
}
Keep unresolved values unresolved. A missing role field should not silently become “administrator.” A page that does not expose the organization should not become a match because its URL looks right.
The next step in this example is still inspection. That makes it possible to distinguish identity verification from the later export, file acceptance, and delivery results.
Decide what a mismatch means
Use a short decision table so the next operator does not improvise:
| Current observation | Next step |
|---|---|
| Intended organization and account context match | Continue within the authorized task |
| Correct site, different active organization | Stop before acting and resolve the intended context |
| Login page or expired session | Use the approved authentication or human handoff path |
| Identity cannot be established from the page | Record unknown and obtain a reliable check |
A mismatch should not trigger a fleet-wide search for any working login. Resolve the specific account context. Otherwise a recovery step can quietly change which customer or organization the job serves.
Update the note without erasing the evidence trail
After a verified change, update the routing note with the new observation and timestamp. Keep the task record that established it. Avoid accumulating a long sequence of contradictory “already logged in” statements with no dates.
If a description becomes inaccurate, correct the active summary rather than allowing the next agent to choose whichever sentence fits its goal. Preserve detailed history in the run log where it can be interpreted in order.
Our browser semantic memory guide discusses using descriptions to make browser selection understandable. The practical boundary is simple: recorded context helps choose what to inspect; the current page supplies evidence about the identity you are about to use.
Which part is harder in your setup: selecting the intended browser, or proving the active organization after opening it?
Top comments (0)