# Browser control or named actions: choosing an agent tool

A browser-driving agent chooses its next click from what the page shows. A tool with named actions accepts a specific request and returns a result. Choose between them by how much of the task is known before the agent starts.

![An ivory paper fan sits beside a single amber tab fitted into a matching recess.](https://ghostget.com/images/editorial/personal-agents-browser-use-paper.webp)

Generated with [SlopCamera](https://slopcamera.com/).

Drafted with AI and reviewed by Codex editorial review (AI).

## Use browser control when the path is part of the problem

Suppose an agent needs to find a setting in an unfamiliar application. The menu labels, page layout, and available controls determine the next step. Browser automation lets it inspect those details, navigate, and respond to what it finds.

This flexibility is useful for visual checks, unfamiliar forms, and tasks that span several pages. It also means the agent must interpret intermediate page state. The result depends on the page, the available browser controls, and the agent’s decisions at each step.

[browser-use](https://github.com/browser-use/browser-use) supplies a browser-driving agent library. [Playwright MCP](https://github.com/microsoft/playwright-mcp) exposes browser controls to an agent you already use. Their interfaces suit different setups, but both allow the agent to steer.

## Use a named action when the request is already clear

Finding recent messages in a known conversation does not necessarily require deciding which screen to open. A tool can accept the conversation identifier and return the messages directly. The agent then works with the result instead of the navigation around it.

GhostGet exposes this kind of interface for the actions in its [service directory](https://ghostget.com/docs/reference/provider-capabilities/). Account selection and credentials stay inside the connection. The agent supplies the documented inputs and receives the action’s output.

A supported action can use a browser internally without exposing browser control to the caller. That is how some GhostGet page captures render content: the agent requests the page, while the tool controls the rendering steps.

## Compare the work the agent must do

| Task | Browser control | Named action |
| --- | --- | --- |
| Find an unfamiliar setting | Explore menus and inspect the page. | Needs an action that already covers the setting. |
| Read a known conversation | Navigate to it and extract the messages. | Pass its identifier to a supported read action. |
| Publish a prepared post | Fill and submit the site’s form through the browser tool. | Prepare the exact account and content, then confirm the write. |
| The site changes | The agent may find another path through the interface. | Affected GhostGet actions stop when the response no longer matches what they expect. |

## Give each tool a defined role

An agent setup can use both approaches. Browser control handles exploration; a named action handles a repeatable task once the required input is known. Make the handoff explicit so a failed read does not become an unexpected write in another tool.

GhostGet does not silently replace an unavailable action with browser control. Check the [supported actions](https://ghostget.com/docs/reference/provider-capabilities/) before connecting an account, then use the [security guide](https://ghostget.com/docs/explanation/security-model/) to understand confirmation and recovery.