From Intent to Authorized Browser Action

BrowserSkill's architecture, session lifecycle, and borrowing rules form one operating model when a task moves from an agent's intention to a real browser effect. This checkpoint connects those ideas around a practical judgment: is the intended action in scope, authorized, observable, and safely finishable? The answer cannot be read from a tab listing or a successful command alone. It depends on the chain of state that surrounds the action.

A task is a chain of scope decisions

Consider a request such as: “Open the support ticket I already have open, read its latest status, and update the internal note.” The request sounds like one browser task, but BrowserSkill must resolve several different relationships before the note can be changed.

First, the agent's harness turns the goal into a request through the BrowserSkill bridge. The CLI and daemon route that request to a browser connection and a live session. The session supplies an Agent Window and the state that lets the extension interpret later operations. At this point, the agent has an operating context, not permission to change every page in the connected profile.

Next comes target discovery. The user’s ticket tab may appear in a list of user tabs. That tells the agent that a candidate exists, perhaps with a title or URL that helps distinguish it from other tabs. It does not yet tell the session that the tab is controlled. If the task is remote, even reading page content requires an explicit task-created or borrowed target. If the task is local, a passive read may be available under the local policy, but the write still belongs inside the session's Agent Window.

If the agent needs to update the note, the tab must cross the ownership boundary through the borrow process. The user may need to approve the borrow. BrowserSkill records the tab's original window and position, reserves it against competing sessions, and moves it into the Agent Window. Only after that transition does the session have the right kind of target for an input operation. The borrow record is not an administrative detail added after the action; it is the fact that makes the action in scope.

The action itself remains narrower than the business request. BrowserSkill can route a navigation, observation, or input operation to the controlled tab. The page may respond with a changed DOM, an error, a dialog, or no visible change. The agent therefore needs fresh page evidence and a result that fits the specific tool contract. A successful input dispatch is not identical to “the ticket note was saved.” The site may require another confirmation, reject the content, or update asynchronously.

Finally, the session must be cleaned up. The borrowed tab should be returned before the Agent Window is closed. If return succeeds, the session's control over the user tab ends. If the original window has disappeared, a fallback may be reported. If return fails, the session should remain visibly unresolved rather than claiming that the whole task ended cleanly. The external ticket state and the browser-resource state are both relevant, but they are not the same state.

The same task can take different branches without changing this logic.