Amazon Nova Act Ships Faster With New Reliability Fixes

AWS didn't hold a keynote for this one. Nova Act, Amazon's open source SDK for browser automation agents, has quietly shipped nine releases in the past four and a half months, and the pattern behind them is a real lesson in Amazon Nova Act reliability: fix small things constantly instead of saving them for a big annual version bump.

If you haven't touched it yet, Nova Act is an Apache 2.0 licensed SDK that AWS opened up in preview in April 2025. It wraps Playwright and pairs it with a Nova model custom trained for web actions, so you write nova.act("find flights from Boston to Wolf on Feb 22nd") instead of hand-rolling selectors, and it can pull structured data out of a page with a Pydantic schema.

The release cadence behind Amazon Nova Act reliability

Check the GitHub releases page and you'll see a steady drumbeat: v3.0.67.0 in mid-December, v3.0.157.0 in early January, then v3.1.18.0, v3.1.89.0, v3.1.263.0, v3.3.35.0, v3.3.96.0, v3.3.316.0, and the current latest, v3.4.187.0, on April 30. That's roughly one release every two weeks.

Two threads run through those changelogs. One is diagnostics. Back in v3.1.89.0, AWS added ActInvalidToolError and ActInvalidToolSchemaError exceptions specifically so a bad tool call fails with a message that tells you what went wrong instead of a generic stack trace. The same release fixed headless launch failures on Linux boxes with no display server, auto-detecting the missing display and switching to headless mode instead of just dying. That one matters if you've ever run a browser agent in a container and watched it fall over because there was no X server to talk to.

The other thread is the kind of grinding compatibility work that never makes a launch slide. The latest release, v3.4.187.0, took Async Nova Act to general availability, added localStorage session persistence, and fixed three separate bugs: text input silently failing inside cross-origin iframes, Unicode and signal-handling issues on Windows, and navigation timeouts being ignored on non-Chromium browsers.

Why this matters for browser automation agents in production

None of this is glamorous, and that's the point. If you're building an agent tooling stack on AWS and betting on browser automation agents to click through an internal claims system or a vendor portal that only speaks iframes, these are exactly the failure modes that take down a demo in front of a customer: a headless container that won't start, a login form inside a cross-origin iframe that silently eats keystrokes, a Windows jump box that chokes on Unicode. Amazon fixing them in two-week increments means you're not stuck waiting for a yearly major version to get a patch that unblocks your pilot.

It's also a pattern worth stealing for your own agent products. Nova Act's team isn't treating an agent SDK as a one-shot release with a roadmap deck. They're treating it like any other piece of production software: ship, watch for breakage, patch, repeat. That's the agile lesson here as much as the AWS one.

What to do with it this week

First, stop pinning an old version out of habit and check what you're actually running:

pip show nova-act | grep -i version
pip install --upgrade nova-act

Second, if you're running agents inside containers or CI, use headless mode explicitly and catch the newer tool-call exceptions so failures show up in your logs instead of your ticket queue:

from nova_act import NovaAct, ActInvalidToolError, ActInvalidToolSchemaError

with NovaAct(starting_page="https://your-internal-app.example.com", headless=True) as nova:
    try:
        nova.act("open the claims queue and approve the top ticket")
    except ActInvalidToolError as e:
        logger.error("agent picked a tool nova act doesn't support: %s", e)
    except ActInvalidToolSchemaError as e:
        logger.error("tool call didn't match the expected schema: %s", e)

That gives you a specific exception to alert on instead of a bare except Exception swallowing whatever went wrong.

If you're shipping any browser automation agent into a customer's environment, this is why it matters: reliability doesn't arrive in one big release, it arrives two weeks at a time, and you want to be pulling those updates in as fast as AWS is pushing them out.