AWS puts a managed browser between your agents and your HTML-only legacy systems

AWS has published a reference implementation for pointing AI agents at legacy web applications using Amazon Bedrock AgentCore Browser Tool and Strands Agents: a managed Chromium instance in the cloud, driven through Playwright over WebSocket-based Chrome DevTools Protocol connections ^[1][2]. For anyone maintaining screen-scraping automation, the consequence is that the runner fleet, the session isolation and the audit trail become a vendor's operational problem, at a price the post does not state ^[3][9].

The compatibility bar is deliberately low. AWS says the target application only needs to be reachable over HTTP or HTTPS, regardless of which browser it was originally designed for ^[4]. The tool connects to Bedrock foundation models through the AgentCore runtime and provides session-isolated security with AWS IAM controls and full audit trails ^[3].

The argument against existing RPA is about failure modes, not throughput. AWS contends that legacy systems built on server-side middleware generating HTML, CSS and JavaScript lack modern REST APIs, and that their multi-step workflows, dynamic form validation and session-dependent state management cannot be reliably navigated by traditional RPA bots ^[5][6]. Authentication gets its own paragraph in the post: some of these applications require multi-factor authentication, some use proprietary single sign-on, and many rely on session tokens with unpredictable expiration rules ^[7]. AWS groups enterprise RPA difficulty into three buckets: integration complexity, regulatory compliance in regulated industries, and scalability limits that prevent production deployment ^[8]. Anyone who has re-recorded a selector after a vendor patch will recognize the list.

The economics, though, are illustrative. The insurance company processing tens of thousands of operational changes a year is introduced as a scenario familiar to enterprises across industries, not a named customer ^[10][11]. The cost is described as significant annual losses from manual errors and tasks that consume thousands of hours, with no dollar figure and no baseline error rate ^[11][12]. The framing claim, that the majority of enterprises still run critical workloads on legacy technology and that most of those systems expose only server-rendered HTML, arrives without a source ^[13].

A companion AWS post on M&A due diligence is more explicit about the fork in the road. It presents two implementation paths, the integrated Amazon Quick suite (Quick Research, Quick Flows, Quick Index) or a custom AgentCore build, and advises choosing Quick if your workflows align with standard business intelligence patterns and you prefer fully managed services over custom development ^[14][15][16]. Quick can also be extended with custom AgentCore agents for requirements such as proprietary valuation models, which makes three procurement shapes rather than two ^[17][1]. The governance detail in that post, a citation-check evaluator, an audit trail per agent invocation and guardrails enforced at runtime, is the part legal will read ^[18]. The speed claim, that work previously requiring weeks of analyst time was completed in hours, is AWS's own testing with no methodology given ^[19].

What actually ships in the Browser Tool post is a blueprint: architecture, design decisions, a Terraform deployment and complete source code on GitHub ^[20]. That is the thing to cost out, because a blueprint you deploy is still a codebase you maintain.

Watch three things: per-session pricing and concurrency limits, neither of which appears in the post ^[9]; whether the Browser Tool handles the MFA, proprietary SSO and token-expiry cases it identifies or leaves them to your agent code ^[7]; and whether the hypothetical insurer is ever replaced by a named customer with a measured error rate before and after ^[10].