使用 Anchor Browser 和 AgentCore payments 构建可交易的智能体

AI Agent 日益需要访问按请求计费的网络资源。例如，高级数据集按查询收费，研究 API 按调用次数计量，付费出版商则将内容置于付费墙之后。当 AI Agent 遇到这些资源时，服务器会返回 HTTP 402 Payment Required。Agent 没有内置支付机制，当前会话也没有关联预算，更没有以编程方式满足该请求的能力。任务因此停滞，并需要人工干预。

具备 Agent 支付能力的 Anchor Browser 可代表 Agent 处理机器对机器的支付工作流。该产品与 AWS Generative AI Innovation Center Partner Agent Factory 合作开发，现已在 AWS Marketplace 上线。本文介绍 Anchor Browser 如何集成 Amazon Bedrock AgentCore payments，从而让 AI Agent 能够自主支付受 x402 保护的页面和 API。x402 协议是一项用于基于 HTTP 的机器对机器支付的开放标准。服务器会返回 402 Payment Required，同时提供金额、接受的支付方式以及支付地址，Agent 可据此完成交易。

Anchor Browser 是专为 AI Agent 构建的云端浏览器自动化解决方案。每个 Agent 会话都运行在托管浏览器环境中，该环境可维持认证状态、处理导航、捕获网络请求，并提供页面交互的实时视图。

Amazon Bedrock AgentCore 提供了大规模构建、连接和优化 Agent 的能力。Amazon Bedrock AgentCore payments 是 AgentCore 中一项完全托管的功能，AI Agent 可使用它自主发现、访问和支付 API、模型上下文协议（Model Context Protocol，MCP）服务器及网页内容。AgentCore payments 管理钱包连接，在基础设施层实施可配置的支出限制，并通过 x402 协议处理支付。它还通过 Amazon CloudWatch 提供对支付尝试、批准、拒绝和结算的可观测性。

当运行在 Anchor Browser 中的 Agent 遇到 402 响应时，AgentCore payments 会在已配置预算内授权并完成交易。工作流将不中断地继续执行。

挑战

当自主 Agent 遇到受 x402 保护的资源时，工作流会停滞。Agent 发起请求，例如获取高级研究报告或调用付费数据增强 API，服务器随即返回 HTTP 402 Payment Required。如果没有支付机制，原本应自主执行的任务现在就需要人工干预。

如今，开发者必须自行构建整个支付技术栈。这项工作涉及四类复杂性：

支付协议处理

• 从 HTTP 响应中检测并解析 402 挑战，并将需要付款的响应与其他 4xx 错误区分开来。
• 按商家预期的精确格式，使用加密证明构造正确的支付请求头。
• 支持多种支付方案（exact、upto 及协议变体），而无需将供应商特定逻辑硬编码到 Agent 中。
• 保持与不同 x402 商家实现的兼容性；这些实现可能在挑战格式、支持的稳定币或结算时间上存在差异。

安全与密钥管理

• 存储用于签署支付的私钥，这要求在暴露于不受信任输入的环境中提供安全的密钥存储。
• 管理钱包生命周期操作，包括密钥轮换、凭证刷新和提供商故障转移。

运营韧性

• 在保留会话状态、Cookie 和请求上下文的同时，携带支付请求头重新提交原始请求。
• 提供幂等性，这对钱包操作至关重要。
• 通过跨并发 Agent 执行的实时预算跟踪，实施每会话和每笔交易的支出限额。

可观测性与合规性

• 在审计日志中记录每次支付尝试、批准、拒绝和结算，以满足合规与对账要求。

如果没有托管支付服务，Agent 就必须内化整个支付技术栈。对于每一次返回 402 响应的、受 x402 保护的调用，Agent 都必须在内部编排完整支付流程，包括：

• 签署证明。
• 附加正确的请求头。
• 重试请求。
• 结算交易。
• 记录结果。

这些步骤中的每一项都需要开发者构建、自行保护并维护自定义代码。图 1 展示了这一架构。Agent 包含八个紧密耦合的组件（钱包、私钥、预算控制、签署证明、附加请求头、重试逻辑、结算支付和日志记录）。Agent 连接至一个 x402 API，402 挑战向后返回，重试请求则向前发送。

图 1：Agent 支付技术栈

除工程工作量外，还存在进一步的安全考量。

支出失控。 如果没有在基础设施层强制执行硬性支出限额，错误、重试循环、提示注入或意外访问都可能触发非预期付款。若 Agent 在循环中重试付费端点，它会持续授权付款，直至人工介入。

密钥暴露。 当私钥驻留在 Agent 运行时中时，它们与不受信任的网页、第三方工具和外部依赖项共享执行环境。这些攻击面可能会意外泄露控制真实资金的凭证。

签名流程暴露。 如果签名基础设施可由运行时访问，威胁行为者便可能尝试访问密钥，或将支付重定向至未经授权控制的地址。有效的缓解措施要求密钥从一开始就不进入运行时。

基于浏览器的 Agent 还带来一项额外约束：支付必须在同一浏览器会话内发生。否则，会话录制和实时视图将不再与实际执行情况一致。

解决方案

Anchor Browser 和 AgentCore payments 通过将整个支付技术栈移入托管基础设施来应对这一复杂性。

与无状态工具调用不同，Anchor Browser 提供真实的云端浏览器，具备持久化身份、可重复且确定性的工作流，以及可靠登录、导航和完成任务所需的会话上下文。认证、导航、网络请求、录制和实时视图均在同一浏览器会话中进行。当需要付款时，交易也在该会话内发生。录制内容会捕获从请求、402、支付到内容交付的完整序列。Anchor Agent 包含内置 x402 工具，可在浏览器上下文中原生处理付费 API 调用。该内置工具无需修改现有基于 Playwright、Puppeteer 或 Chrome DevTools Protocol 的工作流。

AgentCore payments 充当支付层。该服务的核心是 Payment Manager，它是协调 AWS 账户支付操作的顶层资源。创建 Payment Manager 时，需要指定授权者类型和 IAM 角色。随后，AgentCore 会在 Amazon Bedrock AgentCore Identity 中预置相应的工作负载身份。

其余组件将 Payment Manager 与外部钱包基础设施连接起来：

• PaymentConnector 将 Payment Manager 与外部钱包提供商集成，钱包提供商可以是 Coinbase Developer Platform（Coinbase CDP）或 Stripe Privy。
• PaymentCredentialProvider 在 AgentCore Identity 中安全存储钱包提供商凭证。
• PaymentInstrument 标识用于支出资金的具体钱包地址。

Anchor Browser 使用受支持的钱包提供商，通过 AgentCore payments 设置钱包，而不会将钱包机密信息或私钥置于 Agent 运行时中。AgentCore payments 通过已配置的提供商处理钱包操作。对于端点发现，AgentCore 通过 Amazon Bedrock AgentCore Gateway 提供精选的 Coinbase x402 Bazaar MCP 服务器，使 Agent 能够以编程方式发现可用的按使用量付费 x402 端点。

AgentCore payments 重构了支付架构。敏感操作从 Agent 运行时移至托管服务层。Anchor Agent 仅保留两个与支付相关的组件：预算会话和 x402 工具。包括认证、钱包机密信息、支付限额、可观测性和支付证明签名在内的基础设施均位于 AgentCore payments 层。图 2 展示了 Anchor Agent 连接到 AgentCore payments 托管层，后者负责处理与 Coinbase CDP 或 Stripe Privy 的钱包提供商集成。

图 2：Anchor Browser 集成 AgentCore payments

支付流程的工作方式

以下步骤描述了从浏览器会话遇到受 x402 保护的资源，到 Agent 收到响应并继续任务期间的端到端流程。

1. Anchor Browser 为浏览器会话创建专用的 AgentCore PaymentSession。 当会话启动时启用 x402，Anchor Browser 会通过 AgentCore payments 预置一个 PaymentSession，将浏览器会话关联至已配置的支付工具和预算。
2. 浏览器收到 HTTP 402 Payment Required 响应。 Agent 导航至某个 URL，或者发起 fetch 或 XMLHttpRequest（XHR）请求。商家返回 402 挑战，指定金额、接受的支付方式和支付地址。
3. 浏览器选择兼容的支付方式。 Anchor Browser 读取 402 挑战负载，并将所请求的支付方式与关联到 PaymentSession 的支付工具进行匹配。
4. AgentCore 验证会话预算并生成加密支付证明。 AgentCore payments 验证支付金额是否在会话支出限额内。该服务随后使用已配置的钱包提供商（Coinbase CDP 或 Stripe Privy）签署交易，并返回加密证明。浏览器或 Agent 运行时不会接触任何密钥材料。
5. 浏览器携带支付请求头重试原始请求。 浏览器将已签名证明作为 x402 v2 的 PAYMENT-SIGNATURE 或 x402 v1 的 X-PAYMENT 附加，然后恰好重试一次原始请求。
6. 商家验证并结算支付，然后返回受保护资源。 商家验证加密证明，在链上结算交易，并提供内容。Agent 继续执行任务。

在整个流程中，钱包凭证始终保留在 AgentCore 和已配置的钱包提供商处。

前提条件

开始前，请确保你拥有有效的 Anchor Browser API 密钥（ANCHOR_API_KEY）。如需创建密钥，请参阅 Anchor Browser Quick Start 指南。

设置自动 x402 支付

为 Anchor Browser 设置 Agent 支付只需要一个会话属性：将 session.x402 设为 true。该属性默认值为 false。启用后，浏览器会话可以自动访问受 x402 保护的网站，支付由 AgentCore payments 签名，并在同一浏览器会话内重试。启用 session.x402 即授权浏览器从已配置的支付工具中进行真实付款。

以下示例展示如何使用 cURL 和 JavaScript 为 Anchor Browser 创建支持支付的会话：

cURL

curl --request POST
--url https://api.anchorbrowser.io/v1/sessions
--header "anchor-api-key: $ANCHOR_API_KEY"
--header "content-type: application/json"
--data '{"session":{"x402":true}}'

JavaScript

const response = await fetch('https://api.anchorbrowser.io/v1/sessions', {
  method: 'POST',
  headers: {
    'anchor-api-key': process.env.ANCHOR_API_KEY,
    'content-type': 'application/json',
  },
  body: JSON.stringify({ session: { x402: true } }),
});
const { data: session } = await response.json();
console.log(session.cdp_url);

通过 Chrome DevTools Protocol 连接后，Agent 可按常规方式进行导航。你无需在自动化代码中包含钱包密钥或支付请求头。浏览器会针对文档导航、fetch 和 XHR 请求，透明地处理 402 挑战、支付签名和重试。

支付会话限额与行为

Anchor Browser 通过与 AgentCore payments 的集成，在会话层面实施以下防护措施。每个准备就绪、可进行支付的浏览器会话均在已配置的支出和时间约束内运行。有关具体限额，请参阅 Anchor Browser 技术文档。

如果商家响应格式不正确、未提供兼容网络、预算已耗尽，或 AgentCore payments 拒绝……

AI agents increasingly need to access web resources that are priced per request. For example, premium datasets charge by the query, research APIs meter by the call, and paywalled publishers gate content behind payment. When an AI agent encounters one of these resources, the server returns HTTP 402 Payment Required. The agent has no built-in payment mechanism, no budget attached to the session, and no programmatic way to satisfy the request. The task stalls and requires manual intervention.

Anchor Browser with Agentic Payments handles machine-to-machine payment workflows on behalf of the agent. Developed in collaboration with the AWS Generative AI Innovation Center Partner Agent Factory, it’s now available on AWS Marketplace. This post covers how Anchor Browser integrates with Amazon Bedrock AgentCore payments so that AI agents can pay for x402-protected pages and APIs autonomously. The x402 protocol is an open standard for HTTP-based machine-to-machine payments. A server responds with 402 Payment Required along with the amount, accepted payment methods, and payment address that the agent uses to complete the transaction.

Anchor Browser is a cloud-based browser automation solution purpose-built for AI agents. Each agent session runs inside a managed browser environment that maintains authentication state, handles navigation, captures network requests, and provides a live view of page interactions.

Amazon Bedrock AgentCore provides capabilities to build, connect, and optimize agents at scale. Amazon Bedrock AgentCore payments is a fully managed capability within AgentCore that AI agents can use to discover, access, and pay for APIs, Model Context Protocol (MCP) servers, and web content autonomously. AgentCore payments manages wallet connectivity, enforces configurable spending limits at the infrastructure layer, and processes payments through the x402 protocol. It also provides observability into payment attempts, approvals, denials, and settlements through Amazon CloudWatch.

When an agent running in Anchor Browser encounters a 402 response, AgentCore payments authorizes and completes the transaction within the configured budget. The workflow continues without interruption.

Challenges

When an autonomous agent encounters an x402-protected resource, the workflow stalls. The agent makes a request, such as fetching a premium research report or calling a paid data enrichment API, and the server responds with HTTP 402 Payment Required. Without a mechanism to pay, the task that was supposed to run autonomously now requires human intervention.

Today, developers must build the entire payment stack. This effort spans four categories of complexity:

Payment protocol handling

• Detecting and parsing the 402 challenge from the HTTP response, and distinguishing payment-required responses from other 4xx errors.
• Constructing the correct payment header with the cryptographic proof in the exact format the merchant expects.
• Supporting multiple payment schemes (exact, upto, and protocol variants) without hardcoding vendor-specific logic into the agent.
• Maintaining compatibility across x402 merchant implementations that might vary in challenge format, supported stablecoins, or settlement timing.

Security and key management

• Storing a private key to sign payments, requiring secure key storage within an environment exposed to untrusted inputs.
• Managing wallet lifecycle operations, including key rotation, credential refresh, and provider failover.

Operational resilience

• Resubmitting the original request with the payment header while preserving session state, cookies, and request context.
• Providing idempotency, which is essential for wallet operations.
• Enforcing per-session and per-transaction spend limits with real-time budget tracking across concurrent agent executions.

Observability and compliance

• Capturing every payment attempt, approval, denial, and settlement in audit logs for compliance and reconciliation.

Without a managed payment service, the agent must internalize the entire payment stack. On every x402-protected call that returns a 402 response, the agent must orchestrate the full payment flow internally, including:

• Signing the proof.
• Attaching the correct header.
• Retrying the request.
• Settling the transaction.
• Logging the result.

Each of these steps requires custom code that developers must build, secure, and maintain. Figure 1 illustrates this architecture. The agent contains eight tightly coupled components (Wallet, Private Keys, Budget Controls, Sign Proof, Attach Header, Retry Logic, Settle Payment, and Logging). The agent connects to an x402 API with a 402 challenge flowing back and a retry flowing forward.

Figure 1: Agent payment stack

The security considerations extend beyond the engineering effort.

Uncontrolled spending. Without hard spending limits enforced at the infrastructure level, a bug, retry loop, prompt injection, or inadvertent access can trigger unintended payments. An agent retrying a paid endpoint in a loop continues to authorize payments until manual intervention occurs.

Key exposure. When private keys reside inside the agent runtime, they share an execution environment with untrusted web pages, third-party tools, and external dependencies. These vectors might inadvertently disclose the credentials that control real funds.

Signing flow exposure. If the signing infrastructure is accessible from the runtime, a threat actor can attempt to access the key or redirect payments to an address under unauthorized control. Effective mitigation requires that the key doesn’t enter the runtime in the first place.

Browser-based agents introduce an additional constraint: the payment must occur within the same browser session. Otherwise, session recordings and live view no longer match what actually executed.

Solution

Anchor Browser and AgentCore payments address this complexity by moving the entire payment stack into managed infrastructure.

Unlike a stateless tool call, Anchor Browser provides a real cloud browser with persistent identity, repeatable and deterministic workflows, and the session context needed to log in, navigate, and finish tasks reliably. Authentication, navigation, network requests, recordings, and live view happen inside the same browser session. When a payment is required, the transaction happens within that session. The recording captures the full sequence from request to 402 to payment to content delivery. Anchor agents include a built-in x402 tool that handles paid API calls natively within the browser context. The built-in tool requires no changes to existing Playwright, Puppeteer, or Chrome DevTools Protocol-based workflows.

AgentCore payments serves as the payment layer. At the center of the service is the Payment Manager, the top-level resource that coordinates payment operations for the AWS account. Creating a Payment Manager requires specifying an authorizer type and an IAM role. AgentCore then provisions a corresponding workload identity in Amazon Bedrock AgentCore Identity.

The remaining components connect the Payment Manager to external wallet infrastructure:

• A PaymentConnector integrates the Payment Manager with an external wallet provider, either Coinbase Developer Platform (Coinbase CDP) or Stripe Privy.
• A PaymentCredentialProvider stores wallet provider credentials securely in AgentCore Identity.
• A PaymentInstrument identifies the specific wallet address from which funds are drawn.

Anchor Browser sets up wallets through AgentCore payments using a supported wallet provider, without placing wallet secrets or private keys inside the agent runtime. AgentCore payments handles wallet operations through the configured provider. For endpoint discovery, AgentCore provides a curated Coinbase x402 Bazaar MCP server through Amazon Bedrock AgentCore Gateway, so agents can discover available pay-per-use x402 endpoints programmatically.

AgentCore payments restructures the payment architecture. Sensitive operations move out of the agent runtime and into a managed service layer. The Anchor Agent holds only two payment-related components: a budget session and the x402 tool. The infrastructure, including authentication, wallet secrets, payment limits, observability, and payment proof signing, resides in the AgentCore payments layer. Figure 2 shows the Anchor Agent connecting to the AgentCore payments managed layer, which handles wallet provider integration with Coinbase CDP or Stripe Privy.

Figure 2: Anchor Browser integrates with AgentCore payments

How the payment flow works

The following steps describe what happens end to end, from the moment a browser session encounters an x402-protected resource to the moment the agent receives the response and continues the task.

1. Anchor Browser creates a dedicated AgentCore PaymentSession for the browser session. When the session starts with x402 turned on, Anchor Browser provisions a PaymentSession through AgentCore payments, linking the browser session to a configured payment instrument and budget.
2. The browser receives an HTTP 402 Payment Required response. The agent navigates to a URL or makes a fetch or XMLHttpRequest (XHR) request. The merchant responds with a 402 challenge specifying the amount, accepted payment methods, and payment address.
3. The browser selects a compatible payment method. Anchor Browser reads the 402 challenge payload and matches the requested payment method against the instrument linked to the PaymentSession.
4. AgentCore verifies the session budget and generates the cryptographic payment proof. AgentCore payments validates that the payment amount falls within the session spending limit. The service then signs the transaction using the configured wallet provider (Coinbase CDP or Stripe Privy) and returns the cryptographic proof. No key material enters the browser or agent runtime.
5. The browser retries the original request with the payment header. The browser attaches the signed proof as PAYMENT-SIGNATURE for x402 v2 or X-PAYMENT for x402 v1, then retries the original request exactly once.
6. The merchant verifies and settles the payment, then returns the protected resource. The merchant validates the cryptographic proof, settles the transaction on-chain, and serves the content. The agent continues the task.

Wallet credentials remain with AgentCore and the configured wallet provider throughout this flow.

Prerequisites

Before you begin, make sure that you have a valid Anchor Browser API key (ANCHOR_API_KEY). To create one, see the Anchor Browser Quick Start guide.

Setting up automatic x402 payments

Setting up agentic payments for Anchor Browser requires one session property. Set session.x402 to true. The property defaults to false. When enabled, the browser session can automatically access x402-protected websites with payments signed by AgentCore payments and retried inside the same browser session. Enabling session.x402 authorizes the browser to make real payments from the configured payment instrument.

The following examples show how to create a payment-enabled session for Anchor Browser using cURL and JavaScript:

cURL

curl --request POST
--url https://api.anchorbrowser.io/v1/sessions
--header "anchor-api-key: $ANCHOR_API_KEY"
--header "content-type: application/json"
--data '{"session":{"x402":true}}'

JavaScript

const response = await fetch('https://api.anchorbrowser.io/v1/sessions', {
  method: 'POST',
  headers: {
    'anchor-api-key': process.env.ANCHOR_API_KEY,
    'content-type': 'application/json',
  },
  body: JSON.stringify({ session: { x402: true } }),
});
const { data: session } = await response.json();
console.log(session.cdp_url);

After connected through Chrome DevTools Protocol, the agent navigates normally. You don’t need to include a wallet key or payment header in your automation code. The browser handles 402 challenges, payment signing, and retries transparently for document navigation, fetch, and XHR requests.

Payment session limits and behavior

Anchor Browser enforces the following guardrails at the session level through AgentCore payments integration. Each payment-ready browser session operates within configured spending and time constraints. For specific limits, refer to the Anchor Browser technical documentation.

If the merchant response is malformed, no compatible network is offered, the budget is exhausted, or AgentCore payments rejects the payment, the browser returns the original 402 response to the page unchanged. Your automation code can then handle the 402 as a standard HTTP error.

The x402 session property controls payments to third-party resources only. The property doesn’t replace Anchor credits and doesn’t pay for the browser session.

Automation code for Anchor Browser

Your automation code for Anchor Browser remains unchanged. The following example demonstrates that no payment-specific code is required:

const { chromium } = require('playwright');
// Connect to the x402-enabled session via CDP
const browser = await chromium.connectOverCDP(session.cdp_url);
const page = await browser.newPage();
// Navigate to an x402-protected resource exactly as with a free page
await page.goto('https://premium-research.example.com/market-report');
// The page loaded, the payment was handled automatically
// Extract content as normal
const content = await page.textContent('article');

No wallet logic, no payment header construction, and no retry code. The agent navigates to the URL. If the server returns 402, Anchor Browser coordinates with AgentCore payments to sign the payment proof, retries the request with the appropriate payment header, and delivers the content to the page. Your automation code receives the final rendered page with no indication that a payment occurred.

This pattern applies uniformly to paywalled journalism, licensed financial data, gated API documentation, metered research databases, and other resources that gate content behind a 402 challenge.

Paid resources aren’t limited to web pages. Many are APIs that expect POST, PUT, or other HTTP methods. Common examples include data enrichment services, premium inference endpoints, and licensed content APIs. For these use cases, Anchor Browser agents include a built-in x402 tool that you call like a standard HTTPS API within the browser context.

Your agent makes the API call through fetch or XHR. If the server returns a 402 challenge, the browser coordinates payment signing through AgentCore payments and retries the request with the signed payment header. Your code receives the response as though the endpoint were free. The tool isn’t tied to a specific vendor, model, or framework. Payment operates as a session-level capability beneath your existing tooling, and no changes to agent code are required.

// Fetch call to a paid API endpoint within the x402-enabled session
const response = await page.evaluate(async () => {
  const res = await fetch('https://data-enrichment.example.com/api/v1/enrich', {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ company_domain: 'example.com' }),
  });
  return res.json();
});
// If the API returned 402, AgentCore handled payment automatically
// The response contains the enriched data
console.log(response);

Your automation code doesn’t receive wallet credentials. Automatic payments are available only when session.x402 is set to true and remain subject to the spending and expiration limits described in the previous section.

Key benefits

This integration moves payment from application code to the infrastructure layer:

No payment infrastructure to build. No wallet SDK to integrate, no 402 response parser to write, no retry loop to implement, no header construction logic to maintain, and no custom audit logging to build. AgentCore payments manages the entire payment stack.

No changes to existing tooling. Playwright scripts, Puppeteer automations, Chrome DevTools Protocol commands, and agent flows in Anchor Browser continue to function exactly as before. Payment is a session capability attached to the browser, not a modification to agent logic, prompts, or tool definitions.

Private keys don’t enter the runtime. Signing and settlement happen inside AgentCore payments. The service communicates with Coinbase CDP or Stripe Privy through secure credential storage in AgentCore Identity. The agent runtime doesn’t have access to key material that can move funds.

Budgets are enforced at the infrastructure level. Every session operates within defined spend limits that AgentCore enforces before authorizing a payment. Amazon Bedrock AgentCore Observability provides full payment audit trails through Amazon CloudWatch. When a session reaches the spending limit, AgentCore payments denies the payment.

Paid tasks complete successfully. Paid GET pages load. Paid API calls return responses. The agent completes the workflow rather than stopping at a 402 response and requiring manual intervention.

Billing is consolidated. Anchor Browser settles third-party x402 charges in credits on the same invoice as browser session time. There’s no separate crypto custody to manage, no USDC balance to monitor, and no on-chain settlement for the finance team to reconcile.

Conclusion

Anchor Browser, integrated with AgentCore payments, equips AI agents to handle x402 payment challenges autonomously for paywalled web pages and paid API endpoints. Wallet credentials stay out of agent code, and no custom payment infrastructure is required.

As more of the web moves to per-request pricing, agents that lack a payment mechanism can’t complete tasks involving paid resources. This integration addresses that gap: agents complete paid workflows end to end, operating within defined budgets, with full observability through AgentCore Observability, and without cryptographic key material in the runtime.

To get started, explore the following resources:

---

About the authors

Cher Simon

Cher is a Principal Deep Learning Architect at AWS, where she helps customers, startups, and AWS Partners build large-scale, high-performance AI/ML solutions. A published author, she specializes in translating AI research into production-ready solutions.

Guy Ben Simhon

Guy is a Co-Founder and CPO at Anchor Browser, leading product and strategy. He focuses on building infrastructure that enables AI agents to reliably interact with the web and operate real computer environments at scale.

Elay Gelbart

Elay is a Founding and Lead Engineer at Anchor Browser, pioneering its browser infrastructure and core engineering. He specializes in large-scale browser infrastructure, distributed systems, and building reliable execution environments for AI agents.

Chethan Shriyan

Chethan is a Principal Product Manager – Technical at AWS. He has more than 12 years of experience in product and business management. Chethan is passionate about building and delivering technology products that create meaningful impact in customers’ lives.

Peter Jiang

Peter is a Senior Software Developer at AWS, based in Seattle, WA. He is a core member of the engineering team behind the Amazon Bedrock AgentCore payments initiative, which enables payment capabilities for AI agents. With over 8 years of experience in the financial and payments industry, Peter has launched multiple greenfield projects spanning banking, crypto, and agentic systems.