A user opens your product, finds a record, changes a field and submits a form. Except the user did none of that. An AI agent used their authenticated browser session and operated the interface on their behalf.
That is no longer an edge case reserved for products with a bespoke API. Anthropic says Claude in Chrome can read pages, type, click, navigate and fill forms using a person’s existing logins. Its separate browser inside Claude Cowork can work through dashboards and vendor portals without a connector. The strategic shift is simple: agents can reach software through the same front door as people.
The next product requirement is therefore not merely “add an MCP server”. It is to make the product safe and intelligible when intent comes from a human but execution comes from a machine.
What has actually changed
Vendor-observed: On 26 August 2026, Anthropic announced general availability of Claude in Chrome for paid plans and a built-in browser for Cowork. The Chrome product can take some actions without asking for approval each time, with classifiers intended to check proposed actions against the original request. Anthropic also explicitly says prompt injection remains a moving target and recommends starting with trusted sites. Enterprise administrators can manage browser access, including approved domains for the Chrome extension.
The Cowork browser is separate from the user’s personal browser and excludes banking, email and single sign-on credentials from login import unless the user chooses otherwise. That separation is a useful product decision, not proof that browser automation is risk-free.
My analysis: Browser agents turn every reasonably structured web product into a potential agent surface, whether its team planned one or not. APIs and MCP can provide a cleaner route, but the visible interface remains the fallback. Products will be judged on how reliably an agent can understand state, choose an action and recover from a mistake.
This does not mean optimising the experience for bots at the expense of people. Most of the improvements agents need are also marks of good human-facing software: explicit labels, stable states, clear consequences and reversible actions.
The L-C-U-T framework
Use four tests when reviewing an important workflow: legibility, confirmation, undo and telemetry.
1. Legibility: can an agent understand the current state?
An agent should not have to infer that a grey icon means “invoice already sent” or that a row disappeared because a filter changed. Give controls accessible names. Put status and validation messages in text, not colour alone. Use stable headings, meaningful field labels and predictable focus order. Make loading, empty, partial and error states distinct.
This is not a request to expose hidden chain-of-thought or to fill screens with machine-oriented clutter. It is a request to make product state explicit in the interface and, where appropriate, in structured responses. If an action is unavailable, state why. If a price or permission changed since the page loaded, surface the new value before commitment.
For PMs, add agent-assisted completion to usability testing. Give an agent a goal, not click-by-click instructions, and watch where it misreads state. The failure is often a product ambiguity that also costs human users time.
2. Confirmation: does friction match the consequence?
Approving every click makes agents tedious. Approving nothing makes them dangerous. The answer is risk-tiered confirmation.
Low-consequence actions, such as opening a report or changing a view, can usually proceed. Medium-consequence actions, such as editing a draft or assigning an internal task, should show a compact preview and affected objects. High-consequence actions, such as publishing, paying, deleting or changing access, should require explicit confirmation at the point of commitment.
The confirmation must describe the effect, not merely ask “Are you sure?”. “Remove access for 84 contractors immediately” gives a human reviewer something meaningful to assess. Include changed values, scope, timing and whether the action can be reversed.
Do not rely on the browser agent’s safety layer to supply all of this. The product owns the domain consequence. Only your product knows that changing a tax setting, cancelling a shipment or merging two customer records is unusually sensitive.
3. Undo: can a bad action be contained?
Agents will make mistakes, users will give incomplete instructions and pages may contain hostile content. Design for recovery before celebrating automation.
Prefer soft deletion, drafts and staged publication. Offer a meaningful undo window for reversible changes. For bulk operations, show the proposed set before execution and produce a result set afterwards. For irreversible operations, consider a two-person approval or a delayed queue with cancellation.
An audit log is necessary but not sufficient. A perfect record of an unrecoverable mistake is still an unrecoverable mistake. PMs should specify recovery time and recovery scope alongside the happy path: how long does the user have, who can reverse it, and what dependent changes will also be restored?
4. Telemetry: can you distinguish delegation from direct use?
If agents operate through the ordinary UI, conventional analytics may report healthy engagement while concealing a new behaviour. A ten-second agent session and a ten-minute human session are not equivalent, yet both may emit the same clicks.
Instrument outcomes rather than celebrating activity. Track attempted, confirmed, completed, blocked, failed, undone and escalated actions. Record the relevant actor type when it is reliably available, the authorising human or service identity, the client or integration, and a correlation ID across a multi-step task. Never pretend you can identify an agent perfectly from behavioural guesses.
Review failure clusters: repeated retries, abandoned confirmation screens, validation loops and rapid undo. These are signals that the workflow is ambiguous or brittle. Preserve privacy by collecting the minimum context needed to debug, with clear retention and access rules.
A workflow review checklist
Choose one valuable, consequential journey and ask:
- Is every control and status understandable without visual guesswork?
- Can the user or agent tell which account, workspace and objects are in scope?
- Does the final step preview the exact consequence?
- Is confirmation proportional to risk rather than applied everywhere?
- Can the action be undone, cancelled or restored?
- Are bulk changes bounded and reviewable?
- Does the audit trail connect the request, authorisation and result?
- Do metrics capture outcomes, retries, blocks and reversals?
- Have we tested malicious page content and stale state?
- Is there a reliable route to a human when confidence is low?
The caveat: do not build for an imaginary majority
Agent traffic may remain small in your category. Some environments will prohibit browser agents, and accessibility semantics alone will not make a complex workflow reliable. Browser automation is also exposed to prompt injection, changing layouts and ambiguous instructions. Anthropic’s own release notes acknowledge that safeguards reduce rather than eliminate risk.
So avoid a speculative redesign. Start with workflows already used for repetitive, cross-system work. Improve their semantics and recovery mechanisms, then measure whether delegated use appears. If demand becomes material, add a supported API or MCP interface with narrower permissions and stronger contracts.
The PM implication is not “agents replace users”. It is that one human may increasingly arrive through several machine executors. Your product still owes that human understandable consequences and control.
Pick the highest-value workflow in your product this week. Run the L-C-U-T review, attempt it with a browser agent in a test account, and turn the first three failures into backlog items. The agent-ready product will usually become a better human product too.