Nova Act SDK: browser agents that hand off to a human when the page fights back
Amazon Nova Act is an AWS service for building and deploying highly reliable AI agents that automate UI-based workflows at scale.
At a glance
- What is it?
- Amazon's Nova Act SDK drives Chrome through natural-language prompts wrapped in Python, with an escalation path to a human supervisor. It is a managed AWS service with a thin open client, and the README is honest that it supports English only.
- Who is it for?
- Adopt Nova Act if your workflow already lives in a browser, you can run Python 3.10 or newer, and you accept that the reasoning happens in an AWS service reached with an API key or IAM credentials. Do not adopt it if you need non-English prompts, an offline or air-gapped agent, or permissive licensing around the service itself, since the SDK is Apache-2.0 but the service terms are separate.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 116 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Nova Act targets: UI workflows that never got an API
A large share of internal work happens inside a browser against software that exposes no usable API. Someone opens a portal, fills the same fields, clicks through the same three screens, and copies a confirmation number into a spreadsheet. Scripting that with Selenium or Playwright works until the page changes a button label, and then the script fails silently or loudly depending on how much error handling was written.
Nova Act's answer is to describe the step in English and let a model find the control. The README frames the target as automating "production UI workflows at scale" and completing "repetitive UI workflows in the browser," with escalation to a human supervisor "when appropriate." The audience is therefore teams with browser-bound processes plus enough Python capacity to wrap them, not end users clicking a no-code button. The README also points at a web playground at nova.amazon.com/act for exploration before any code is written.
How a NovaAct session actually runs: context manager, act(), Chrome
The core object is NovaAct, used as a Python context manager. The README's script-mode example opens a session against a starting_page URL, calls nova.act() with a natural-language instruction, and lets the with block close the browser. The documented sequence is explicit: the SDK opens Chrome, performs the task described in the prompt, then closes Chrome, printing run details as console log messages.
Interactive mode splits that apart. You construct NovaAct with a starting_page, call nova.start() yourself, then issue act() calls one at a time. The README warns against touching the browser while an act() is running, because the underlying model will not know what you changed. It also notes that ctrl+x exits an agent action while leaving the browser intact for a later act() call, whereas ctrl+c exits the browser. That distinction matters when you are iterating on a prompt against a half-filled form.
The SDK drives Chrome through Playwright. First run of NovaAct can take one to two minutes because Playwright browser modules are installed at that point; later runs start in seconds. Setting NOVA_ACT_SKIP_PLAYWRIGHT_INSTALL turns that install step off. Chrome itself is optional but preferred: the README says Nova Act works best with Google Chrome, that it cannot install the browser for you, and that you can run playwright install chrome in the same environment, or accept Chromium.
Install, authenticate, and the two credential paths
Installation is a single command, pip install nova-act, or pip install . from a clone of the repository. Python 3.10 or above is required, on macOS Sierra or later, Ubuntu 22.04 or later, WSL2, or Windows 10 or later. The README states plainly that Nova Act supports English.
There are two authentication routes and they carry different terms. API key authentication means generating a key at nova.amazon.com/act and exporting it as NOVA_ACT_API_KEY. The README notes that playground use and developer tools under API key authentication fall under the nova.amazon.com Terms of Use. IAM-based authentication instead relies on AWS credentials already configured in your environment; the SDK instantiates a default boto session. The README directs you to the Amazon Nova Act User Guide for details and says IAM credentials are used via the Workflow constructs. Deploying workflows to the Nova Act AWS service falls under AWS Service Terms or your Customer Agreement.
That split is the most consequential thing in the README. The same Python package behaves as a standalone tool in one configuration and as a client for a managed AWS service in the other, and the governing terms change with it.
Escalation to a human is the feature most competitors do not have
The README lists Human-in-the-loop (HITL) as a first-class topic alongside workflows, extraction, and parallel sessions. The framing is that Nova Act escalates to a human supervisor when appropriate. This is a different posture from a pure automation library, where an unmatched selector is simply an exception your code must catch.
It also implies a deployment shape: someone has to be available to receive the escalation, and the workflow has to tolerate a pause. Nothing in the supplied material describes the escalation transport, the timeout behaviour, or what state the browser is in when a supervisor takes over. Those are the questions to answer from the AWS user guide before designing a process around HITL, because an escalation path with an undefined timeout is not a reliability feature, it is an unbounded wait.
The README also documents a time worked tracking utility, which suggests the intended use includes workflows where human minutes are the unit being measured. Again, the mechanism is not described in the material available here.
Parallel sessions, persisted browsers, and where sensitive input goes
The table of contents covers running multiple sessions in parallel and persisting browser sessions. Parallelism is the obvious lever for throughput on a fleet of similar tasks, and persistence matters for anything behind a login, where re-authenticating per task would dominate runtime. Neither mechanism is spelled out in the excerpt, so treat the section headings as pointers rather than specifications.
Handling sensitive data gets its own section, and the README's phrasing is "entering sensitive information," which suggests the SDK offers a route for credentials that keeps them out of the prompt text. That is the right instinct. A natural-language instruction like "log in as the admin user" puts a secret into a model call; a dedicated sensitive-input path presumably does not. Verify which one your code actually does before pointing it at a production account.
There are sections for captchas, file upload and download, browser dialogs, date pickers, user agent strings, and proxies. The presence of a captcha section is worth pausing on: it tells you the SDK encounters them, not that it defeats them. Nothing in the material claims captcha solving.
The managed-service dependency is the real limitation
The SDK is Apache-2.0, but the reasoning behind act() is not in the repository. It runs in an AWS service reached with an API key or IAM credentials. That is the boundary to plan around: no offline mode is described, no local model option appears in the README, and the preview integration with external tools through API calls, remote MCP, or frameworks such as Strands Agents is labelled preview, which means the interface can move.
English-only support is the second hard edge, stated without qualification. A workflow that touches a non-English portal is out of scope as documented.
The upgrade policy is the third. The README carries a warning that SDK versions older than 3.0 are no longer supported and that users must upgrade to receive security updates and new features, with pip install --upgrade nova-act and pip show nova-act as the commands. For a library whose behaviour depends on a remote model, pinning an old version is not a safe long-term strategy; the client and the service are expected to move together.
Finally, the README lists a Known limitations section but does not enumerate it in the excerpt. Read that section before committing, because it is where the project itself draws the line.
Where Playwright alone is the better choice
If your target page is stable and you control it, plain Playwright is the more predictable tool. You write a selector, the selector either matches or raises, and the failure is deterministic and debuggable. Nova Act replaces that determinism with a model that interprets your sentence, which is exactly what you want when the page is a third-party portal you cannot change, and exactly what you do not want when a CSS selector would have been sufficient and free.
The cost difference is structural, not incremental. A Playwright script runs locally against a browser you already have. A Nova Act act() call reaches a managed service, which means network latency, service availability, and the terms attached to whichever credential type you chose. The README's own note that the first run takes one to two minutes to install Playwright modules is a small reminder that the SDK sits on top of the same browser automation stack, not in place of it. You are paying for the interpretation layer, and you should only pay for it on the steps that need interpreting.
Who should adopt it, and what to check before the first workflow
The project fits teams automating browser workflows they do not own, where the alternative is brittle selector maintenance or manual labour, and where a human escalation path is acceptable rather than a failure. It fits AWS shops that already have IAM credentials configured, since the SDK will pick up a default boto session without extra plumbing.
It does not fit anyone who needs non-English prompts, anyone who cannot send page context to a managed service, or anyone who wants a self-contained library with no service dependency. The Apache-2.0 licence on the SDK does not extend to the service, and the README is explicit that API key use is governed by the nova.amazon.com Terms of Use while IAM and deployment use is governed by AWS terms. Read both before a pilot, and get your own legal read rather than inferring from the licence file.
Concretely, before writing workflows: confirm your version with pip show nova-act and upgrade if it is below 3.0, decide between NOVA_ACT_API_KEY and IAM credentials because the choice determines which terms apply, and open the Known limitations section. Then run one act() against the playground URL from the README to see the console log format you will be debugging against, because that log is the only observability the quick start describes.
Editorial conclusion
Adopt Nova Act if your workflow already lives in a browser, you can run Python 3.10 or newer, and you accept that the reasoning happens in an AWS service reached with an API key or IAM credentials. Do not adopt it if you need non-English prompts, an offline or air-gapped agent, or permissive licensing around the service itself, since the SDK is Apache-2.0 but the service terms are separate. Before writing a single workflow, verify three things from the README and the linked AWS user guide: that your target sites behave under a headless Chrome session, that your organisation can provision either a NOVA_ACT_API_KEY or IAM credentials, and that your current nova-act version is 3.0 or later, because the README states older versions are no longer supported.
Community notes