# AWS previews the Amazon Nova Act SDK > AWS announced a preview of the Amazon Nova Act SDK for building browser automation agents. The company said the SDK used a Nova Act model fine-tuned for browser execution and included integration with IAM credential management, Amazon S3 data controls, and a browser tool. AWS positioned the release around multi-step browser workflows, Python scripting, and testing or debugging agent behavior before deployment. Canonical: https://hypler.com/ai-news/aws-nova-act-sdk-preview-2025 Hypler publication: 2026-10-06 Hypler updated: 2026-10-06 Original source date: 2025-07-16 Byline: Hypler editorial team Source publisher: AWS Editorial standard: https://hypler.com/ai-news#editorial-standard Article kind: source-briefing Category: Agents Tags: AWS, Nova Act, browser automation, agents ## Engineering relevance Browser automation increases the chance that an AI workflow crosses from reading to acting in a third-party system. The release makes identity, storage, browser state, and human intervention first-class design concerns. A browser agent can be useful without being autonomous: each workflow needs explicit permitted actions, test coverage, error handling, and an accountable owner for its effects. ## Source record: Nova Act SDK preview for browser work On July 16, 2025, AWS announced the preview release of the Amazon Nova Act SDK for building browser automation agents. AWS described the SDK as powered by a Nova Act model fine-tuned for agentic AI and browser execution. The announcement named IAM credential management, Amazon S3 data controls, and the Genesis Browser Tool, and positioned the SDK around Python-based, multi-step browser workflows that developers could test and debug before deployment. AWS said the preview was available in US East (N. Virginia) at the time of the announcement. Preview status and a named regional launch are part of the historical release record. The engineering question begins after that record: a browser automation system needs a precise definition of its permitted pages, user identity, session state, data handling, and the effects it is permitted to create in a third-party interface. ## Browser automation turns interface state into system state A browser agent operates through pages designed for people, so its state includes navigation history, cookies, redirects, form fields, downloads, dialogs, and page content that changes while the workflow runs. A resilient implementation records the task identity, selected account, allowed domains, current step, expected page condition, and terminal outcome. These details matter when a page reloads, a session expires, or a workflow reaches a confirmation screen. Treat every page as untrusted input, including text that looks like instructions. The workflow should derive its action plan from the approved task contract and validate page state before entering data or submitting a form. Stable selectors, assertions, and screenshots can provide execution evidence, but they should be paired with structured state such as target record identifiers and approved parameters. This makes browser interaction inspectable rather than dependent on an opaque sequence of clicks. ## Hypothetical example: prepare a portal update for review Imagine a hypothetical operations workflow that opens a vendor portal, reads the status of a named order, and prepares a draft update for a responsible employee. The task contains the order identifier, an approved portal domain, a read-only account, and a maximum number of pages it may inspect. The browser agent captures the displayed status, the retrieval time, and the page identifier, then returns a structured draft that the employee can review outside the portal. The workflow stops before any form submission. If the portal presents a different account, a missing order, a changed confirmation dialog, or a request for additional credentials, it records the mismatch. The employee can then resolve the issue with the appropriate authority. This hypothetical design creates practical value from browser access while keeping the system's effect limited to evidence collection and draft preparation. ## Architecture: use checkpoints around consequential steps Break a browser workflow into explicit checkpoints: authenticate, locate the target, validate the target state, prepare input, request approval where needed, submit, and verify the resulting state. Each checkpoint should have a success condition and a terminal reason. Store enough evidence to explain the transition, such as a page URL pattern, target identifier, visible confirmation text, or receipt identifier, while avoiding broad capture of unrelated personal or account data. For an action that changes another system, create an exact execution request before the submit step. Include the target, parameters, actor, policy result, and idempotency strategy. After submission, verify the external outcome through a separate observation when possible. A page timeout or disconnected browser session should leave the outcome in an explicit reconciliation state. This preserves the distinction between a request that was prepared, one that was submitted, and one that was observed as complete. ## Failure modes: retries can duplicate external effects Browser workflows fail in ways API clients often avoid: a button can be clicked while the page is stale, a response can arrive after the browser disconnects, a modal can obscure a required field, or a site can apply a change before it renders a confirmation. Retrying the entire script after any of these events can duplicate a submission. The design needs a safe lookup or receipt check before it decides whether another attempt is appropriate. Test login expiry, account switching, page-layout changes, slow network responses, duplicate submits, unexpected downloads, and a page that contains adversarial instructions. Include a test that loses the browser connection immediately after a submit action. The expected result is a reconciled outcome with an evidence trail, not an optimistic assumption. These cases reveal whether a browser agent can operate predictably in the interfaces it is intended to assist. ## Evaluation checklist: prove the workflow before broadening it Use a test environment or controlled account with synthetic records where possible. Define normal paths, known exceptions, expired sessions, permission failures, changed page states, and interrupted submissions. Measure task completion, intervention rate, false completion rate, duplicate effects, and recovery time. Preserve the script version, browser configuration, allowed-domain list, and assertions with every run so a later regression can be compared with a known baseline. A first release should have a named owner, a scoped account, an audit trail, a kill switch, and a clear escalation path for ambiguous outcomes. Review storage retention for screenshots and browser artifacts, especially where pages contain sensitive data. Expand to new domains, actions, or accounts one approval at a time. The resulting system is easier to operate because its browser capabilities are tied to specific workflows, evidence, and recovery procedures. ## Original source - [AWS](https://aws.amazon.com/about-aws/whats-new/2025/07/build-browser-agents-amazon-nova-act-sdk-preview/) ## Related links - [AWS: Nova Act SDK preview announcement](https://aws.amazon.com/about-aws/whats-new/2025/07/build-browser-agents-amazon-nova-act-sdk-preview/) - [AWS documentation: Nova Act interfaces](https://docs.aws.amazon.com/nova-act/latest/userguide/interfaces.html) - [Hypler technical library: capability and authority](/technical-library/capability-and-authority) - [SI infrastructure development](https://hypler.com/ai-infrastructure-development) ## Image provenance ### Primary image ![Generated editorial illustration: browser forms and saved snapshots inspected before submission.](https://hypler.com/assets/news/browser-review-print.webp) generated illustration. Credit: Hypler / AI-generated editorial illustration. Hypler editorial asset. - [Image source](https://hypler.com/ai-news/media.md) ### Supporting image ![Generated illustration of isolated tool-execution fixtures and a controlled test gate; not deployed software.](https://hypler.com/assets/news/tool-execution.webp) generated illustration. Credit: Hypler / AI-generated editorial illustration. Hypler editorial asset; not vendor or event photography. - [Image source](https://hypler.com/ai-news/media.md) ## Reading boundary Historical source briefing with Hypler engineering analysis. Source details reflect the original publication date; implementation examples are hypothetical. Public reading grants no private access or execution authority.