使用 Amazon Nova Act 实现合成监控

合成监控通过自动化交易来模拟真实用户旅程。团队无需等到客户遇到问题后才采取行动，而是持续按计划验证关键工作流（登录、购买、表单提交）。通过这种方式，当性能下降或 UI 交互失效时，团队可以更快发现问题。

对于面向客户的企业，尤其是电商企业，合成监控能够保障最重要的交互正常运行。组织可以验证产品搜索是否正确工作、价格和库存是否按预期显示、购物车操作是否成功，以及结账确认是否无错误完成。持续测试能够在客户遇到问题之前识别故障。

同样的方法适用于各个行业。金融服务机构可以确保账户访问和交易流程保持可用。旅游和酒店服务提供商可以监控预订和预约旅程。软件即服务（SaaS）公司可以验证注册和订阅升级路径。医疗机构可以监控预约门户，其中可用性和交易健康状况至关重要。

本文将介绍一种使用 Amazon Nova Act 和 Amazon Bedrock AgentCore 的智能体驱动合成监控方法。结合这些服务，你可以超越脆弱的 UI 脚本，转向更具韧性、托管式的用户旅程验证。本文描述了智能体驱动合成监控的架构和模式，并提供包含完整实现的示例仓库。

传统合成监控的挑战

大多数组织通过指标、日志、追踪和 API 级检查来监控基础设施健康状况。然而，高影响力故障通常发生在用户旅程层面，后端信号可能无法立即揭示问题。常见示例包括：前端部署导致结账按钮失效、第三方登录页面意外变更，或 UI 回归使关键元素无法响应。

Selenium 和 Playwright 等传统浏览器自动化框架依赖显式的文档对象模型（DOM）定位器和选择器，因此较为脆弱。即使是微小的 UI 变更也可能导致测试失败，并需要持续维护。团队需要投入大量持续性工作来管理选择器、处理与时序相关的不稳定性，并随着应用演进更新脚本；通常花在维护上的时间比构建新自动化流程的时间更多。

传统方法

# CSS 类变更时会失效
driver.find_element(By.CLASS_NAME, "checkout-button").click()
driver.find_element(By.ID, "payment-form").submit()
driver.find_element(By.XPATH, "//button[@data-test='complete-order']").click()
# 每个工作流需要 10 行以上的显式选择器

Nova Act 方法

# 在大多数情况下可适应 UI 变更
nova_act.act("Click the checkout button")
nova_act.act("Complete the payment form")
nova_act.act("Confirm the order")
# 仅 3 行，无需维护选择器

Amazon Nova Act 使用多模态大语言模型（LLM）处理 UI 截图，而不是 DOM 选择器，因此对 UI 变化具有显著更强的韧性。由于模型基于屏幕上所见内容进行推理（而不是 CSS 类或元素 ID），即使样式发生变化，也能适应而无需更新脚本。在早期企业客户用例中，Amazon Nova Act 已在浏览器工作流上展示出超过 90% 的准确率。相较于元素发生任何变化便立即失败的基于选择器的方法，这是一项有意义的改进。团队应在自身网站上进行测试，并为适应未成功的情况设计包含重试逻辑的监控器。

企业监控平台通过将浏览器检查作为高级附加功能定价，进一步加剧了维护挑战。这迫使团队在监控覆盖范围与预算之间做出选择，而这与验证关键客户旅程这一真正目标是分离的。

解决方案概览

该解决方案结合以下 AWS 服务，每项服务负责不同职责：

• Amazon Nova Act 通过结合自然语言操作与编排逻辑来定义和执行 UI 工作流。它以视觉和语言推理替代基于选择器的脚本。
• Amazon Bedrock AgentCore Runtime 提供具备会话隔离和稳定调用端点的无服务器执行环境。它托管监控智能体，无需团队管理服务器或容器。
• AgentCore Browser tool 是 Amazon Bedrock AgentCore 的一项能力，为每次测试运行提供安全、隔离的远程浏览器环境。它消除了运营浏览器集群的开销。
• Amazon EventBridge Scheduler 和 Amazon Simple Notification Service（Amazon SNS） 分别负责调度和告警，按设定频率触发测试，并将故障通知发送至订阅端点。

架构

该架构遵循以下流程：

1. Amazon EventBridge Scheduler 按定义的计划触发合成监控运行（根据工作流关键程度，每 5 分钟至每小时一次）。
2. 每次计划调用都会通过 Amazon EventBridge Scheduler 的通用目标功能，直接调用 InvokeAgentRuntime。
3. 智能体在 AgentCore Runtime 中执行，在 AgentCore Browser 会话内调用 Amazon Nova Act，通过自然语言操作驱动 UI 工作流。
4. 如果旅程在任一步骤失败，智能体会通过 Amazon SNS 发布通知。
5. 故障会立即路由至订阅端点（电子邮件、聊天集成、事件响应工具）。

下图展示了该架构。

图 1：采用 Amazon Nova Act 和 Amazon Bedrock AgentCore 的合成监控架构

该架构提供全托管的合成监控。团队无需维护脆弱的脚本或浏览器基础设施。

实现

以下各节将介绍设置要求、用户旅程定义、智能体部署和调度基础设施。

前提条件

实施前，请确认具备以下条件：

• 拥有一个 AWS 账户，并可访问 Amazon Nova Act、Amazon Bedrock AgentCore（Runtime 和 Browser tool）、Amazon Elastic Container Registry（Amazon ECR）、IAM、Amazon EventBridge Scheduler 和 Amazon SNS。
• 已配置凭证的 Python 3.11 或更高版本、Docker 和 AWS Command Line Interface（AWS CLI）v2。
• 用于生产基础设施部署路径的 Node.js 18 或更高版本及 AWS Cloud Development Kit（AWS CDK）（同时也提供独立的 deploy.py 脚本）。
• 如果希望让 deploy.py 或 CDK 为告警创建 SNS 电子邮件订阅，需要一个电子邮件地址。

定义用户旅程

实现工作首先需要定义最重要、需要验证的客户旅程。对于电商应用，这通常包括主页加载、产品搜索、产品详情页导航、加入购物车验证和结账准备状态。

不要仅关注工作流是否完成，而应显式验证结果。监控器应确认搜索结果正确显示、购物车包含商品，且没有显示错误横幅。显式的结果验证可减少因检查不完整造成的误报，以及因断言过于宽松造成的漏报。

智能体定义

智能体将自然语言操作归类为逻辑用户旅程步骤，并在关键检查点使用断言。操作通过 act() 使用自然语言驱动 UI。断言使用带有布尔模式的 act_get() 来验证结果。当用户旅程失败时，智能体会发布旅程类型、目标 URL、耗时、已完成步骤和失败步骤。详细的异常信息保留在运行时日志中。

代码直接使用 Nova Act SDK。部署到 AgentCore Runtime 后，执行环境会通过 Browser tool 管理浏览器会话生命周期。在测试中，典型的六步用户旅程会根据页面加载时间在 2 至 4 分钟内完成。有关当前方法签名和 SDK 版本，请参阅 Nova Act User Guide。示例仓库包含完整的智能体定义，其中包含错误处理和单次尝试的步骤执行。

将智能体部署到 AgentCore Runtime

在 Amazon EventBridge 调度任务能够调用智能体之前，需要使用 Nova Act CLI 将其部署到 AgentCore Runtime。act workflow 命令会打包智能体代码、将容器镜像推送至 Amazon ECR，并预置运行时环境。部署完成后，端点 Amazon Resource Name（ARN）保持不变。更新会创建新的运行时版本，而无需更新 Scheduler 目标。

act workflow create --name synthetic-monitoring-workflow
act workflow deploy --name synthetic-monitoring-workflow --source-dir . --entry-point workflow.py
act workflow show --name synthetic-monitoring-workflow

act workflow show 命令会返回 AgentCore Runtime ARN，你需要将其作为 Scheduler 目标引用。示例仓库中的 deploy.py 脚本通过前提条件检查（Docker、AWS 凭证）封装了这些命令，创建 SNS 告警主题，并连接 Amazon EventBridge 调度任务，因此执行一次 python deploy.py 即可完成端到端部署。（AgentCore 也为智能体开发提供了自己的 agentcore CLI。本示例统一使用 Nova Act 的 act workflow 命令。）

使用 CDK 部署

对于生产级、可重复的部署，示例提供了一个 CDK stack，作为 deploy.py 的独立替代方案。它会预置具有最小权限 IAM 授权的 Amazon EventBridge 调度任务、SNS 告警主题，以及用于捕获 Scheduler 失败 InvokeAgentRuntime 调用的 SQS 死信队列。

该 stack 还会创建两个 Amazon CloudWatch 告警：一个针对死信队列深度（Scheduler 调用失败），另一个针对缺失的计划运行（使用 AWS/Scheduler InvocationAttemptCount 指标，并将缺失数据视为越过阈值）。请注意，这些告警用于检测基础设施故障，例如向智能体投递失败或调度任务未触发。功能上已损坏、但在 HTTP 层面仍可返回响应的客户旅程，会通过智能体的 SNS 发布暴露，而不会通过这些 CloudWatch 告警暴露。

避免告警疲劳

应将合成监控聚焦于高价值客户旅程，而非穷尽覆盖所有页面。过度监控会制造噪声，使团队对真实故障失去敏感度。从 3 至 5 个关键工作流（登录、结账、账户访问）开始，并根据实际故障模式和业务影响扩展。监控直接影响收入或客户信任的用户旅程，而不是每一条可能的用户路径。

同样，避免对每一个页面元素进行过度断言。应验证有意义的结果（搜索结果是否出现、购物车是否包含商品），而不是检查页面上的每一个 DOM 元素。过于细粒度的断言会增加误报，却无法提升故障检测能力。

示例智能体代码对每个步骤使用单次尝试执行，从而最大限度降低 Browser 会话成本。由于 Nova Act 的自然语言适应能力在约 90% 的情况下能够成功，单次尝试的方法偶尔可能在 Nova Act 未能定位实际存在的 UI 元素时产生误报。需要更低误报率的团队可以增加步骤级重试机制（在宣布失败前重新运行一次失败步骤），代价是更长的会话持续时间。

运营注意事项

部署完成后，有两项运营问题需要关注：观察监控系统本身，以及管理成本。

监控监控系统

AgentCore Runtime 会将智能体调用指标发布至 Amazon CloudWatch，因此你可以跟踪执行频率和持续时间。成功时，智能体会完成执行而不向 SNS 发布消息。用户旅程故障会通过智能体的 SNS 发布呈现。请为 SNS 主题配置死信队列，以检测失败的智能体调用。

成本注意事项

成本由五个组成部分构成：AgentCore Runtime 调用、Browser tool 会话、Nova Act 推理、Amazon EventBridge Scheduler 调用和 SNS 通知。主要成本驱动因素是 Browser 会话持续时间，以及每个用户旅程步骤的 Nova Act 推理调用次数。

下表为每 5 分钟运行一次的示例六步电商用户旅程提供成本估算（每月约 8,640 次调用）：

组件	每月使用量	预估成本
AgentCore Runtime 调用	8,640 个会话，每个约 2-4 分钟	参见定价页面
Browser tool 会话	8,640 个会话，每个约 2-4 分钟	参见定价页面
Nova Act 操作	约 207,360 次操作和断言调用（每个用户旅程 24 次）	参见定价页面
Amazon EventBridge Scheduler	8,640 次调用	约 $0.009
参见定价页面
SNS 通知	仅故障告警（配置时）	可忽略不计
参见定价页面

解决方案优势

采用基于 Nova Act 和 AgentCore 的智能体驱动合成监控的组织，可以期待在关键运营维度上获得可衡量的改进：

• 降低脚本维护成本 ：自然语言操作取代了更新选择器的循环。团队不再需要

Synthetic monitoring emulates real user journeys through automated transactions. Rather than waiting for customers to encounter problems, teams continuously validate critical workflows (logins, purchases, form submissions) on a scheduled basis. With this approach, you detect problems faster when performance degrades or UI interactions break.

For customer-facing businesses, especially in ecommerce, synthetic monitoring safeguards interactions that matter most. Organizations validate that product search works correctly, pricing and inventory display as expected, cart operations succeed, and checkout confirmations complete without error. Continuous testing identifies problems before customers encounter them.

The same approach applies across industries. Financial services organizations make sure account access and transaction flows remain functional. Travel and hospitality providers monitor booking and reservation journeys. Software as a service (SaaS) companies validate signup and subscription upgrade paths. Healthcare organizations monitor appointment scheduling portals where availability and transaction health are essential.

This post walks through an agent-driven approach to synthetic monitoring using Amazon Nova Act and Amazon Bedrock AgentCore. Together, with these services you can move beyond brittle UI scripts toward resilient, managed journey validation. The post describes the architecture and patterns for agent-driven synthetic monitoring, with a sample repository containing the complete implementation.

The challenge with traditional synthetic monitoring

Most organizations monitor infrastructure health through metrics, logs, traces, and API-level checks. However, high-impact failures often occur at the user journey level, where backend signals may not immediately reveal the problem. Common examples: a frontend deployment breaks a checkout button, a third-party login page changes unexpectedly, or a UI regression makes critical elements unresponsive.

Traditional browser automation frameworks like Selenium and Playwright rely on explicit Document Object Model (DOM) locators and selectors, which creates brittleness. Even small UI changes can break tests and require constant maintenance. Teams invest significant ongoing effort managing selectors, handling timing-related instability, and updating scripts as applications evolve, often spending more time on maintenance than on building new automations.

Traditional approach

# Breaks when CSS class changes
driver.find_element(By.CLASS_NAME, "checkout-button").click()
driver.find_element(By.ID, "payment-form").submit()
driver.find_element(By.XPATH, "//button[@data-test='complete-order']").click()
# Requires 10+ lines of explicit selectors per workflow

Nova Act approach

# Adapts to UI changes in most cases
nova_act.act("Click the checkout button")
nova_act.act("Complete the payment form")
nova_act.act("Confirm the order")
# 3 lines, no selectors to maintain

Amazon Nova Act uses a multimodal large language model (LLM) that processes UI screenshots rather than DOM selectors, making it significantly more resilient to UI changes. Because the model reasons from what it sees on screen (not from CSS classes or element IDs), it adapts when styling changes without requiring script updates. In early enterprise customer use cases, Amazon Nova Act has demonstrated over 90% accuracy on browser workflows. This is a meaningful improvement over selector-based approaches that fail immediately on any element change. Teams should test on their own sites and design monitors with retry logic for cases where adaptation does not succeed.

Enterprise monitoring platforms compound the maintenance challenge by pricing browser checks as premium add-ons. This forces teams to choose between monitoring breadth and budget, all separate from the real goal of validating critical customer journeys.

Solution overview

This solution combines the following AWS services, each handling a distinct responsibility:

• Amazon Nova Act defines and executes UI workflows through natural-language actions combined with orchestration logic. It replaces selector-based scripts with vision and language reasoning.
• Amazon Bedrock AgentCore Runtime provides serverless execution with session isolation and stable invocation endpoints. It hosts the monitoring agent without requiring teams to manage servers or containers.
• AgentCore Browser tool , a capability of Amazon Bedrock AgentCore, provides a secure, isolated remote browser environment for each test run. It eliminates the overhead of operating browser farms.
• Amazon EventBridge Scheduler and Amazon Simple Notification Service (Amazon SNS) handle scheduling and alerting respectively, triggering tests on cadence and delivering failure notifications to subscribed endpoints.

Architecture

The architecture follows this flow:

1. Amazon EventBridge Scheduler triggers synthetic monitoring runs on a defined schedule (every 5 minutes to hourly, depending on workflow criticality).
2. Each scheduled invocation calls InvokeAgentRuntime directly through the universal target capability of Amazon EventBridge Scheduler.
3. The agent executes within AgentCore Runtime, invoking Amazon Nova Act to drive the UI workflow using natural-language actions inside an AgentCore Browser session.
4. If the journey fails at any step, the agent publishes a notification through Amazon SNS.
5. Failures route immediately to subscribed endpoints (email, chat integrations, incident response tooling).

The following diagram illustrates the architecture.

Figure 1: Synthetic monitoring architecture with Amazon Nova Act and Amazon Bedrock AgentCore

This architecture provides fully managed synthetic monitoring. Teams avoid maintaining brittle scripts or browser infrastructure.

Implementation

The following sections walk through setup requirements, journey definition, agent deployment, and scheduling infrastructure.

Prerequisites

Before implementing, confirm the following:

• An AWS account with access to Amazon Nova Act, Amazon Bedrock AgentCore (Runtime and Browser tool), Amazon Elastic Container Registry (Amazon ECR), IAM, Amazon EventBridge Scheduler, and Amazon SNS.
• Python 3.11 or later, Docker, and AWS Command Line Interface (AWS CLI) v2 configured with credentials.
• Node.js 18 or later and AWS Cloud Development Kit (AWS CDK) for the production infrastructure path (the standalone deploy.py script is also provided).
• An email address if you want deploy.py or CDK to create an SNS email subscription for alerts.

Defining a journey

Implementation begins by defining the most important customer journeys to validate. For ecommerce applications, these typically include homepage load, product search, product detail navigation, add-to-cart validation, and checkout readiness.

Rather than focusing only on workflow completion, validate outcomes explicitly. The monitor should confirm that search results appear correctly, the cart contains items, and no error banners display. Explicit outcome validation reduces false positives from incomplete checks and false negatives from overly permissive assertions.

Agent definition

The agent groups natural-language actions into logical journey steps and uses assertions at key checkpoints. Actions use act() to drive the UI through natural language. Assertions use act_get() with a boolean schema to validate outcomes. When a journey fails, the agent publishes the journey type, target URL, duration, completed steps, and failed steps. Detailed exception information remains in the runtime logs.

The code uses the Nova Act SDK directly. When deployed to AgentCore Runtime, the execution environment manages browser session lifecycle through the Browser tool. In testing, a typical six-step journey completes in 2 to 4 minutes depending on page load times. Refer to the Nova Act User Guide for current method signatures and SDK version. The sample repository includes the complete agent definition with error handling and single-attempt step execution.

Deploying the agent to AgentCore Runtime

Before the Amazon EventBridge schedule can invoke the agent, deploy it to AgentCore Runtime using the Nova Act CLI. The act workflow commands package the agent code, push the container image to Amazon ECR, and provision the runtime. Once deployed, the endpoint Amazon Resource Name (ARN) remains constant. Updates create new runtime versions without requiring you to update your Scheduler target.

act workflow create --name synthetic-monitoring-workflow
act workflow deploy --name synthetic-monitoring-workflow --source-dir . --entry-point workflow.py
act workflow show --name synthetic-monitoring-workflow

The act workflow show command returns the AgentCore Runtime ARN that you reference as the Scheduler target. The sample repository’s deploy.py script wraps these commands with prerequisite checks (Docker, AWS credentials), creates the SNS alert topic, and wires the Amazon EventBridge schedule, so a single python deploy.py performs an end-to-end deployment. (AgentCore also provides its own agentcore CLI for agent development. This sample standardizes on the Nova Act act workflow commands.)

Deploying with CDK

For a production-grade, repeatable deployment, the sample includes a CDK stack as a standalone alternative to deploy.py. It provisions the Amazon EventBridge schedule with least-privilege IAM permission, the SNS alert topic, and an SQS dead-letter queue that captures failed InvokeAgentRuntime calls from the Scheduler.

The stack also creates two Amazon CloudWatch alarms: one on dead-letter-queue depth (failed Scheduler invocations), and one on missing scheduled runs (using the AWS/Scheduler InvocationAttemptCount metric, treating missing data as breaching). Note that these alarms detect infrastructure failures, such as a delivery failure to the agent or the schedule not firing. A functionally broken customer journey that still returns at the HTTP level surfaces through the agent’s SNS publish, not through these CloudWatch alarms.

Avoiding alert fatigue

Focus synthetic monitors on high-value customer journeys rather than exhaustive page coverage. Over-monitoring creates noise that desensitizes teams to real failures. Start with 3-5 critical workflows (login, checkout, account access) and expand based on actual failure patterns and business impact. Monitor journeys that directly affect revenue or customer trust, not every possible user path.

Similarly, avoid over-asserting on every page element. Validate meaningful outcomes (whether search results appear, whether the cart contains items) rather than checking every DOM element on the page. Overly granular assertions increase false positives without improving failure detection.

The sample agent code uses single-attempt execution per step, which minimizes Browser session cost. Since the natural language adaptation of Nova Act succeeds in approximately 90% of cases, a single-attempt approach may occasionally produce false alerts when Nova Act fails to locate a UI element that is actually present. Teams requiring lower false-positive rates can add step-level retry (re-run a failed step once before declaring failure) at the cost of longer session durations.

Operational considerations

Once deployed, two operational concerns require attention: observing the monitoring system itself and managing cost.

Monitoring the monitoring system

AgentCore Runtime publishes agent invocation metrics to Amazon CloudWatch, so you can track execution frequency and duration. On success, the agent completes without publishing to SNS. Journey failures surface through the agent’s SNS publish. Configure SNS topics with dead-letter queues to detect failed agent invocations.

Cost considerations

Costs come from five components: AgentCore Runtime invocations, Browser tool sessions, Nova Act inference, Amazon EventBridge Scheduler invocations, and SNS notifications. The primary cost drivers are Browser session duration and Nova Act inference calls per journey step.

The following table provides a cost approximation for the sample’s six-step ecommerce journey running every 5 minutes (approximately 8,640 invocations per month):

Component	Usage per month	Estimated cost
AgentCore Runtime invocations	8,640 sessions, approximately 2-4 minutes each	See pricing page
Browser tool sessions	8,640 sessions, approximately 2-4 minutes each	See pricing page
Nova Act operations	~207,360 action and assertion calls (24 per journey)	See pricing page
Amazon EventBridge Scheduler	8,640 invocations	~$0.009
See pricing page
SNS notifications	Failure alerts only (when configured)	Negligible
See pricing page

Solution benefits

Organizations adopting agent-driven synthetic monitoring with Nova Act and AgentCore can expect measurable improvements across key operational dimensions:

• Reduced script maintenance : Natural language actions replace the selector-update cycle. Teams no longer need to rebuild monitors after routine UI deployments.
• Faster mean-time-to-detect (MTTD) : Continuous 5-minute cadence validation catches failures within minutes of deployment rather than after customer reports surface.
• Lower false-positive rates : Session isolation through Firecracker microVMs helps prevent state-leakage-induced false positives that plague shared-browser monitoring setups.
• Broader coverage at lower cost : Fully managed infrastructure (no browser farms, no server maintenance) allows teams to monitor more journeys without proportional increases in ongoing costs.

Security and compliance

Synthetic monitoring must produce reliable results without introducing false positives or masking real failures. AgentCore Runtime provides session isolation for each test execution using a strict one-session-one-microVM model built on Firecracker microVMs. By default, each session terminates with full memory sanitization, preventing cookies, browser cache, and LocalStorage from persisting between runs. This helps prevent false positives caused by state leakage across tests. For synthetic monitoring, ephemeral sessions are the recommended pattern to maintain test independence. AgentCore does offer persistent browser profiles through the SaveBrowserSessionProfile API for other use cases, but synthetic monitors should always use ephemeral sessions.

For network access, the Browser tool operates in public network mode by default, providing internet access appropriate for synthetic monitors that validate customer-facing websites. For environments requiring egress control, AgentCore supports Browser with Amazon Virtual Private Cloud (Amazon VPC) configuration, allowing teams to restrict network access to specific domains when monitoring internal applications.

Teams integrate synthetic monitoring with AWS Identity and Access Management (IAM) to enforce least-privilege permissions. IAM roles define which resources the agent can access, including SNS publishing permissions and Browser tool invocation.

When synthetic tests require authentication, teams should store credentials in AWS Secrets Manager, which keeps sensitive information encrypted and access is auditable through AWS CloudTrail.

Multi-Region deployment with infrastructure as code

Organizations with users around the world can deploy Nova Act synthetic monitoring in multiple AWS Regions to test user experiences from different geographic locations. This helps validate user experiences and identify issues across multiple Regions.

Use infrastructure as code (IaC) to deploy the solution consistently and repeatably across supported Regions. For current Region availability, see the Amazon Bedrock AgentCore and Amazon Nova Act product pages.

Clean up

To avoid ongoing charges from the resources created in this post, remove them when they are no longer needed:

• For the deploy.py path, run python deploy.py --cleanup to stop scheduled invocations and remove the workflow and related sample resources.
• For the CDK path, run cdk destroy to remove the CDK-managed schedule, SQS dead-letter queue, CloudWatch alarms, SNS topic, and IAM role.
• The CDK stack does not own the AgentCore Runtime. Delete the separately deployed workflow with act workflow delete --name synthetic-monitoring-workflow.

Conclusion

Synthetic monitoring has traditionally required a tradeoff between brittle scripts and the ongoing effort needed to maintain them as applications change. Amazon Nova Act and Amazon Bedrock AgentCore reduce this burden. Nova Act uses natural-language actions that are more resilient to routine UI changes, while AgentCore Runtime provides the infrastructure to run workflows at scale.

For the complete working implementation, see the sample repository: github.com/aws-samples/sample-nova-act-synthetic-monitoring

Additional resources

---

About the authors

Sarath Krishnan

Sarath is a Senior Gen AI/ML Specialist Solutions Architect at Amazon Web Services, where he helps enterprise customers design and deploy generative AI and machine learning solutions that deliver measurable business outcomes. He brings deep expertise in Agentic AI, machine learning, and MLOps to build scalable, secure, and production-ready AI systems.

Matthew Jorat

Matthew is a Customer Solutions Manager at AWS focused on Retail and Consumer Goods enterprises. He works with engineering leaders and their teams to adopt AI-native development practices and helps organizations close the gap between AI investment and end-to-end delivery improvement. He partners with executive stakeholders to connect modernization outcomes to business priorities. Prior to AWS, he led global enterprise teams across Services, Support, and Customer Success.

Karen Huttsell

Karen is an AI/ML Specialist at Amazon Web Services with a background in engineering, IoT, and AI/ML. She partners with enterprise customers to turn AI ambition into measurable business outcomes — working at the intersection of bold ideas and real-world impact.