Every morning, an operations coordinator opens a supplier portal, checks delivery changes and copies the relevant updates into an internal planning tool. The supplier offers no suitable API. A replacement programme would be disproportionate, and the coordinator has better work to do. This is the kind of narrow gap where a browser agent deserves a serious pilot.
Browser automation becomes a business product when it can explain where a task stopped and let a person continue without starting again. A convincing video of clicks is only the beginning. For a European company buying this capability, the central deliverable is a completed, traceable workflow across systems it is authorised to use.
What has changed in the technology
Anthropic's browser use documentation describes a model-and-executor loop that can read and act within webpages. Its separate computer use documentation covers screenshot, keyboard and mouse interaction, along with isolation and human confirmation precautions. The choice matters: a webpage task need not inherit access to an entire employee desktop.
These capabilities make it possible to interpret pages rather than depend solely on a rigid sequence of coordinates. They do not remove the need for an application around the model. Someone still has to manage credentials, task state, approvals, evidence, retries and the integration with your internal system.
First check whether a supported API, file export or ordinary deterministic browser script can solve the job. An agent is useful where page interpretation or variable layouts create genuine complexity. Paying for model decisions on a stable download button may add cost without helping the user.
Pick a workflow with a visible finish line
A useful pilot might collect delivery status for a defined list of purchase orders and prepare updates for a planner. Its finish line is precise: every requested order has a retrieved status or a named exception, and each proposed update identifies the source observation.
“Manage our supplier portals” is too broad. Separate reading, drafting and submission. The first release might read status and prepare internal changes while a coordinator approves them. A later release can automate an agreed subset after the team understands the exceptions.
Choose a process you have permission to automate and check the portal provider's access terms. Agree how to handle login challenges and changes to access policy. The application should pause for the authorised person when necessary. Bypassing a restriction is not an acceptance criterion.
The screen changes while the business task continues
A portal may add a banner, rename a field or move a button. The agent needs enough context to recognise the task, but it should not improvise a new commercial action because the expected control disappeared. Store the requested business outcome independently of the current browser page.
For each task, retain the input reference, completed observations, proposed changes and last confirmed external result. If the browser closes, the application should know what remains. After reconnecting, it should inspect the actual state before repeating an action. A click followed by silence is an uncertain outcome, not proof that nothing happened.
This distinction is especially important for submissions. If a supplier portal provides a receipt or reference number, capture it. If it provides only a changed screen, agree what evidence is sufficient and which outcomes require human review. Avoid making the model's own statement of success the only completion record.
Give the operator a small control room
The operator needs a queue organised around business work, with clear states such as ready, running, needs attention and completed. Each attention item should explain what the agent was trying to do and what blocked it. A screenshot may help, but a screenshot without the order reference leaves staff doing detective work.
An effective handoff allows a person to take control, resolve the issue and return the task to the automation at a known point. The person should be able to reject a proposed change. The system should then remember that decision rather than ask the same question on the next run.
Keep credentials outside prompts and ordinary logs. Use a dedicated service identity where the portal supports one, with access limited to the pilot's work. Restrict the destinations the browser may visit. Content retrieved from a page is task data; it must not become a new instruction to email records or change permissions.
The test that separates a demo from a useful tool
During evaluation, change something the developer has not rehearsed. Add a harmless page banner, remove one expected field or expire the session halfway through. Ask the team to explain the resulting state from the operator screen alone.
Also interrupt the flow after a submission but before its confirmation is recorded. A strong implementation checks for the prior result and resolves uncertainty. A weak one simply repeats the submission. Test two tasks against the same underlying record to reveal races and conflicting updates.
Keep the trial proportionate. Record completion rate, operator minutes per exception, erroneous updates and average cost per finished task. Count manual recovery effort and the time required to adapt after a portal change. A low model bill is irrelevant if an employee must supervise every action.
Put maintenance in the commercial proposal
Browser-driven integration depends on an interface your supplier may not control. Ask who notices when it changes, who suspends affected tasks and what happens to the queue during repair. Agree a supported set of portal journeys and an explicit process for adding new ones.
Require ownership of the source code, task data and deployment accounts. A maintained test set should describe the business results, so a future provider can reproduce the workflow. Your existing team should be able to disable the agent while continuing the underlying manual process.
For a first engagement, buy a bounded workflow assessment and a pilot with real exceptions. Our articles on software support and restoration ownership and software vendor scorecards can help structure the purchasing decision. You can also explore Anis Khalef's selected software work for an introduction to the founder's portfolio before discussing your workflow.
TuniCyberLabs builds custom software that connects operational systems. Bring us the repetitive portal workflow, the actions you authorise and the result your team needs. We can scope the smallest useful automation and its recovery process before you commit to a wider rollout.