Stagehand vs Notte

Caching

1. developerCache resolved actions or generated code so repeat runs replay deterministically at lower cost and latency than re-prompting the LLM

   weight 2 · round to Stagehand
   Stagehand✓fullclaimed7/10

   Stagehand's docs explicitly state that act(), observe(), and extract() results are cached server-side to reduce LLM costs and speed up automations, directly matching the story's request for cached deterministic replay at lower cost/latency. Additional support for persistent user data (cookies/local storage, Browserbase contexts) reinforces cross-run determinism, though there's no independent/hands-on corroboration of cache-hit behavior or cache invalidation details. Missing for 10: independent verification of caching effectiveness/determinism claims, details on cache invalidation when page structure changes, and quantified latency/cost savings.

   • [claimed-docs] “Stagehand caches `act()`, `observe()`, and `extract()` results server-side to reduce LLM costs and speed up your automations.”
   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”

   proof ↗⚑ flag

   Notte~partialclaimed4/10

   Notte lets you script deterministic parts and generate/edit workflow code (notte-docs-2, notte-docs-26, notte-docs-30, notte-gh-2), which implies some cached/generated code can be replayed without re-prompting the LLM, but there is no explicit documentation of an action/result cache, deterministic replay guarantee, or cost/latency comparison for repeat runs. missing for 10: explicit caching mechanism for resolved actions, documentation of deterministic replay across runs, and cost/latency benchmarks comparing cached vs re-prompted execution.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”
   • [github] “combines AI agents with traditional scripting for maximum efficiency - letting you script deterministic parts and use AI only when needed, c…”

   proof ↗⚑ flag

Dom

1. developerDrive the page through DOM-understanding action primitives (act/click/type on described elements) that survive selector and layout changes

   weight 3 · round to Stagehand
   Stagehand✓fullcommunity8/10

   Docs describe act()/observe()/extract() as natural-language, DOM-understanding primitives with selfHeal to re-infer broken selectors and automatic iframe/shadow-DOM handling, directly matching the story; independent HN commentary corroborates that Stagehand dynamically regenerates Playwright actions making it resilient to DOM changes. Missing for 10: rigorous independent benchmark of resilience across real layout changes and more than a single third-party account.

   • [claimed-docs] “Execute actions using natural language”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Turn on `selfHeal` to re-infer an action when its recorded selector breaks.”
   • [claimed-docs] “Stagehand automatically handles iFrame traversal and shadow DOM elements without requiring additional configuration.”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”

   proof ↗⚑ flag

   Notte~partialcommunity6/10

   Docs describe a genuine action-space abstraction (observe()/act() calls, 'no selectors, no maintenance', natural-language task execution) that maps directly to the described act/click/type primitives, and the CLI/MCP integrations reinforce this as a core product concept. However, there's no first-party benchmark or independent hands-on confirmation that these primitives specifically survive selector/layout changes, and community commentary raises skepticism about action-space reliability versus screenshot+HTML approaches without being a concrete contradiction. Missing for 10: independent reproducibility evidence of resilience across DOM changes, and a documented before/after example showing selector survival.

   • [claimed-docs] “Element IDs, selectors, and field mappings must come from a live `observe()` call, CLI `notte page observe` output, or generated workflow co…”
   • [claimed-docs] “Describe a task. Watch it happen. One prompt. No selectors, no maintenance.”
   • [github] “Give AI agents natural language tasks to complete on websites”
   • [github] “combines AI agents with traditional scripting for maximum efficiency - letting you script deterministic parts and use AI only when needed, c…”
   • [community] “why would an action space be more reliable than screenshots + html, this i don't get. I can think of many use cases it would fail”

   proof ↗⚑ flag

Observe

1. developerPreview candidate actions on the current page (observe/plan) before committing the agent to act

   weight 1 · round to Stagehand
   Stagehand✓fullprobed8/10

   observe() is a first-class primitive documented explicitly for discovering actionable elements and returning structured actions 'you can execute or validate before acting,' directly matching the preview/plan-before-act story, and it composes with act()/extract() as separate committed steps (stagehand-docs-3). Runtime probe confirms the package installs and exposes the Stagehand class in practice. missing for 10: independent hands-on developer confirmation specifically of observe()'s preview behavior (community evidence discusses self-healing/act() but not observe() directly).

   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Execute actions using natural language”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Notte~partialprobed6/10

   Notte's docs explicitly describe an `observe()` call and CLI `notte page observe` command that returns element IDs/selectors before actions are executed, which is direct evidence of a preview/plan-before-act primitive. However, the evidence pack lacks a full worked example showing the observe→plan→act workflow end-to-end, independent confirmation of its reliability, or details on how proposed actions are presented/reviewed by a developer. missing for 10: a complete observe/plan-then-act workflow example, independent/hands-on verification that observe output is accurate and usable for gating actions, and documentation of any 'plan' abstraction distinct from observe.

   • [claimed-docs] “Element IDs, selectors, and field mappings must come from a live `observe()` call, CLI `notte page observe` output, or generated workflow co…”
   • [probe] “official CLI documented at https://docs.notte.cc/quickstart”
   • [claimed-docs] “The Notte CLI lets AI agents control browsers through simple shell commands.”

   proof ↗⚑ flag

Vision

1. developerSwitch to a vision or computer-use action mode that operates on screenshots for canvases and UIs the DOM path can't handle

   weight 2 · round to Notte
   Stagehand—none0/10

   No documentation describes a vision/computer-use mode operating on screenshots; the only related evidence is a community comment stating the team is 'working on a better computer use integration' — implying it isn't shipped yet.

   • [community] “Our Stagehand MCP server actually won Anthropic's Claude MCP hackathon :) ... We're working on a better computer use integration using Stage…”

   proof ↗⚑ flag

   Notte~partialcommunity5/10

   Notte's core action space is DOM/observe-based, but the docs include a dedicated integration guide for OpenAI's Computer Use Agent (CUA) that operates on screenshots atop Notte's browser infrastructure, showing a vision/computer-use path exists. However this is presented as an external integration rather than a first-class 'switch mode' toggle within Notte's own API, and community commentary explicitly questions the reliability of Notte's action-space approach versus screenshot-based methods. Missing for 10: native documented API/flag to toggle into vision mode, first-party examples of vision-based action execution, and independent hands-on confirmation that the CUA integration works reliably.

   • [claimed-docs] “This guide explains how to integrate OpenAI's Computer Use Agent (CUA) with Notte's browser infrastructure for automated web interactions.”
   • [claimed-docs] “Live View & Replays Screenshare & session playback”
   • [community] “why would an action space be more reliable than screenshots + html, this i don't get. I can think of many use cases it would fail”

   proof ↗⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Notte
   Stagehand✓fullprobed8/10

   The probe confirms Stagehand's docs site serves a valid llms.txt (HTTP 200) with structured links to docs pages, directly enabling an agent to be pointed at agent-oriented documentation. missing for 10: no evidence of independent/community confirmation that agents actually consume this llms.txt successfully in practice, and no detail on completeness/coverage of the llms.txt beyond the introduction page.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stagehand.dev/llms.txt # Stagehand - [Introducing Stagehand](https://docs.stagehand.dev/v4/first-s…”

   proof ↗⚑ flag

   Notte✓fullprobed9/10

   Notte serves a verified llms.txt at docs.notte.cc/llms.txt with explicit 'Critical Instructions For AI Agents' directing agents to further docs, plus extensive agent-oriented docs (MCP server, CLI, integration guides for CrewAI, Vercel AI SDK, Claude Code) confirming a mature agentic-docs ecosystem. Missing for 10: independent third-party confirmation that agents actually consume llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.notte.cc/llms.txt # Notte ## Critical Instructions For AI Agents STOP. Read and follow https://do…”
   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [claimed-docs] “Notte MCP lets it start cloud browser sessions, interact with the pages, fetch data, build scripts, and more.”
   • [claimed-docs] “pointing it at the Notte MCP server hands your crew a real browser.”
   • [claimed-docs] “Point its MCP client at the Notte MCP server and your TypeScript agent gets a browser.”
   • [claimed-docs] “The Notte CLI lets AI agents control browsers through simple shell commands.”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Stagehand✓fullprobed8/10

   Stagehand is a Node/TS library built on Playwright with a scriptable API (act/observe/extract), headless browser support via Browserbase or CDP-attached Chromium, and npm-installable package confirmed via runtime probe, making CI/headless automation straightforward. missing for 10: explicit first-party CI pipeline examples (GitHub Actions/Docker recipes) and independent hands-on confirmation of a full unattended CI run.

   • [claimed-docs] “When you know the selector or want zero inference, use page methods you already know.”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [claimed-docs] “Attach over CDP (localBrowser.connect): Attach to any Chromium browser you are already running, by URL”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [community] “Have been on the Slack for a while and this crew has had an insane product velocity. Excited to see where it goes!”

   proof ↗⚑ flag

   Notte✓fullprobed8/10

   Notte offers cloud/remote browser sessions, an API with Bearer token auth, serverless 'Functions' deployments that can be scheduled, and a CLI/SDK — all designed for headless, programmatic, CI-friendly automation without a local browser or UI. Community evidence corroborates real usage of the API/agent stack though with mixed reliability reports on task success. Missing for 10: no explicit CI pipeline example (e.g., GitHub Actions), no independent benchmark confirming headless stability at scale.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”
   • [probe] “official CLI documented at https://docs.notte.cc/quickstart”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Stagehand—none0/10

   All evidence shows Stagehand exposing its own browser-automation tools via MCP (server role) to other agents like Claude Code, not Stagehand acting as an MCP client that consumes external MCP servers' tools. No evidence describes configuring Stagehand to plug into third-party MCP servers so it can call their tools.

   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Notte—none0/10

   All MCP-related evidence describes Notte exposing its own MCP server for external agents (Claude, CrewAI, Vercel AI SDK) to plug into and control Notte's browser tools — the reverse direction of this story. There is no evidence that Notte's own agents can consume or plug in external MCP servers to gain new tools.

   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [claimed-docs] “Notte MCP lets it start cloud browser sessions, interact with the pages, fetch data, build scripts, and more.”
   • [claimed-docs] “pointing it at the Notte MCP server hands your crew a real browser.”
   • [claimed-docs] “Point its MCP client at the Notte MCP server and your TypeScript agent gets a browser.”
   • [probe] “official MCP server documented at https://docs.notte.cc/mcp-server”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   Stagehand✓fullprobed8/10

   Stagehand ships an official MCP server ('Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio') and a runtime probe confirms `npx -y @browserbasehq/mcp` actually boots and identifies as 'Browserbase MCP Server ... powered by Browserbase and Stagehand', responding to JSON-RPC initialize. Community evidence corroborates real-world use (the Stagehand MCP server won Anthropic's Claude MCP hackathon). Missing for 10: independent third-party review of the full tool surface/robustness of the MCP server beyond the hackathon anecdote and the first-party docs/probe.

   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [community] “Our Stagehand MCP server actually won Anthropic's Claude MCP hackathon :) ... We're working on a better computer use integration using Stage…”

   proof ↗⚑ flag

   Notte✓fullprobed8/10

   Notte publishes a dedicated official MCP server (docs.notte.cc/mcp-server) that gives agents access to cloud browser sessions, page interaction, and data extraction, and this is corroborated across multiple integration guides (CrewAI, Vercel AI SDK) showing agents pointed at the Notte MCP server to get a real browser. Missing for 10: independent/hands-on third-party confirmation that the MCP server works reliably in practice (community evidence only covers the general product, not MCP specifically).

   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [claimed-docs] “Notte MCP lets it start cloud browser sessions, interact with the pages, fetch data, build scripts, and more.”
   • [claimed-docs] “pointing it at the Notte MCP server hands your crew a real browser.”
   • [claimed-docs] “Point its MCP client at the Notte MCP server and your TypeScript agent gets a browser.”
   • [probe] “official MCP server documented at https://docs.notte.cc/mcp-server”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Notte
   Stagehand—none0/10

   Stagehand is distributed as an npm SDK/library plus an MCP server; the evidence pack shows npm install and MCP server invocation via npx, but no dedicated official CLI tool for direct AI-native command-line interaction is documented anywhere.

   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”

   proof ↗⚑ flag

   Notte✓fullprobed8/10

   Notte documents an official CLI used to generate config, drive browsers, and produce observe/page output (notte-docs-30, notte-docs-31, notte-docs-9, notte-docs-8, notte-probe-4), explicitly positioned for AI agents to control browsers via shell commands. missing for 10: no independent/community hands-on validation of the CLI specifically (only vendor docs), and no detailed CLI command reference beyond scattered mentions.

   • [claimed-docs] “The Notte CLI lets AI agents control browsers through simple shell commands.”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”
   • [claimed-docs] “give them the notte CLI and they can drive real browsers”
   • [claimed-docs] “Element IDs, selectors, and field mappings must come from a live `observe()` call, CLI `notte page observe` output, or generated workflow co…”
   • [probe] “official CLI documented at https://docs.notte.cc/quickstart”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Stagehand✓fullprobed8/10

   Stagehand ships a well-documented public SDK API (act(), extract(), observe(), page methods, selfHeal, caching) with a dedicated docs site and llms.txt, and an npm package that a runtime probe confirms actually installs and exports a working class plus a functioning MCP server exposing the same tools. Community posts corroborate real developer usage of this API for browser automation. Missing for 10: an OpenAPI/REST spec (404s) and deeper independent (non-community) validation of API stability/versioning.

   • [claimed-docs] “Execute actions using natural language”
   • [claimed-docs] “extract() grabs structured data from a webpage. Every call takes an instruction and an output shape”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “When you know the selector or want zero inference, use page methods you already know.”
   • [claimed-docs] “Turn on `selfHeal` to re-infer an action when its recorded selector breaks.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stagehand.dev/llms.txt # Stagehand - [Introducing Stagehand](https://docs.stagehand.dev/v4/first-s…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stagehand.dev/openapi.json, https://docs.stagehand.dev/swagger.json, https://docs.stage…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”

   proof ↗⚑ flag

   Notte✓fullprobed8/10

   Notte documents a full public API with Bearer-token authentication, API reference pages (e.g., agent-start endpoint), SDKs, CLI, and MCP server for programmatic/agentic control of sessions, scraping, and functions, matching the ai-native/agenticness story well. missing for 10: no discoverable OpenAPI/swagger spec (404s on probe) and no independent third-party confirmation of API robustness beyond vendor docs.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [probe] “official MCP server documented at https://docs.notte.cc/mcp-server”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Stagehand—none0/10

   Stagehand is a browser-automation library; evidence covers API keys for model/Browserbase access but no scoped/least-privilege credential issuance, role-based permissions, or token-scoping features for agents are documented anywhere in docs, community, or probes. Missing for 10: any mention of scoped API key issuance, permission scoping, or least-privilege credential management for agents.

   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Notte—none0/10

   Evidence shows only a single Bearer-token API authentication scheme (notte-docs-17) and a vault feature that hides stored web credentials from the LLM (notte-docs-14, notte-docs-27), but nothing about issuing scoped, role-limited, or least-privilege API keys specifically for agents. No mention of API key scopes, permission tiers, or per-agent credential restrictions.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “The significant security benefit of this approach is that the LLM never actually sees the actual credentials.”
   • [claimed-docs] “credentials are never exposed to LLMs or third-party services during agent execution”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to Stagehand
   Stagehand✓fullprobed8/10

   Stagehand ships an official TypeScript/JS SDK (@browserbasehq/stagehand npm package) with documented APIs (act, observe, extract) and confirmed runtime install/import success, making it directly usable by AI-native developers building agentic browser automation. missing for 10: no evidence of official SDKs in other languages (e.g., Python) or independent third-party corroboration of SDK API stability beyond docs and one runtime probe.

   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [claimed-docs] “extract() grabs structured data from a webpage. Every call takes an instruction and an output shape”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Execute actions using natural language”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stagehand.dev/llms.txt # Stagehand - [Introducing Stagehand](https://docs.stagehand.dev/v4/first-s…”

   proof ↗⚑ flag

   Notte~partialprobed5/10

   Notte provides a documented REST API with Bearer-token auth, an official CLI, and an MCP server plus integration guides for frameworks like CrewAI, Vercel AI SDK, and OpenAI CUA, all of which support building AI-native automations programmatically. However, no evidence explicitly names or documents a first-party 'SDK' package (e.g., Python/TypeScript client library) and an OpenAPI spec probe returned 404s, suggesting the API surface may not be as formally packaged as a dedicated SDK. missing for 10: explicit official SDK package docs (Python/JS), a working OpenAPI/schema reference, independent developer confirmation of SDK usage.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”
   • [probe] “official CLI documented at https://docs.notte.cc/quickstart”
   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [probe] “official MCP server documented at https://docs.notte.cc/mcp-server”
   • [claimed-docs] “pointing it at the Notte MCP server hands your crew a real browser.”
   • [claimed-docs] “Point its MCP client at the Notte MCP server and your TypeScript agent gets a browser.”
   • [claimed-docs] “This guide explains how to integrate OpenAI's Computer Use Agent (CUA) with Notte's browser infrastructure for automated web interactions.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”

   proof ↗⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Notte
   Stagehand~partialclaimed5/10

   Stagehand supports cloud-hosted Browserbase sessions with persistent user data/contexts, caching to speed repeat runs, and a real-time observability dashboard, all of which enable automations to run without a local machine and be monitored asynchronously. However there's no documented scheduler, trigger system, or explicit 'run unattended over time' capability distinguishing this from any scripted automation run on-demand. missing for 10: explicit scheduling/cron or trigger mechanism, evidence of long-running unattended multi-step autonomous sessions, independent confirmation of background execution reliability.

   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [claimed-docs] “Browserbase provides real-time visibility into your automation sessions: **Session dashboard features** * Real-time browser screen recordi…”
   • [claimed-docs] “Stagehand caches `act()`, `observe()`, and `extract()` results server-side to reduce LLM costs and speed up your automations.”

   proof ↗⚑ flag

   Notte✓fullcommunity7/10

   Notte supports deploying scripts/agents as serverless 'Functions' invocable via API and schedulable, plus persistent sessions, credential vaults, and cloud browser infrastructure that let automations run unattended in the background (notte-docs-2, notte-docs-26, notte-docs-24, notte-docs-4). This directly matches autonomous background automation for an AI-native user. Missing for 10: no independent/hands-on confirmation of scheduling reliability in production, and community feedback includes at least one report of a failed extraction task (notte-comm-1), so real-world robustness is unverified.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “Secure credential storage. Keep passwords, API keys, and sensitive data encrypted.”
   • [claimed-docs] “Persist cookies and login state across sessions.”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”

   proof ↗⚑ flag

2. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Stagehand
   Stagehand✓fullcommunity8/10

   Stagehand's core capability is letting an AI-native user delegate actions to a built-in AI (act/extract/observe) via natural language, with self-healing and DOM handling reducing manual work — this is the product's central value proposition and is corroborated by community praise for its natural-language automation and self-healing behavior. missing for 10: independent quantitative benchmarks of task delegation success/reliability and more explicit UI/chat-assistant framing beyond programmatic act()/extract() calls.

   • [claimed-docs] “Execute actions using natural language”
   • [claimed-docs] “extract() grabs structured data from a webpage. Every call takes an instruction and an output shape”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Turn on `selfHeal` to re-infer an action when its recorded selector breaks.”
   • [claimed-docs] “Stagehand automatically handles iFrame traversal and shadow DOM elements without requiring additional configuration.”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”
   • [community] “I've been playing around with Stagehand for a minute now, actually a useful abstraction here. We build scrapers for websites that are pretty…”

   proof ↗⚑ flag

   Notte!disputedcontradicted5/10

   Notte's core offering is an AI web agent that accepts natural-language task descriptions and executes them autonomously on websites (notte-gh-1, notte-docs-18, notte-docs-37), which functions as a built-in AI assistant a user delegates tasks to. However, a hands-on community report describes a concrete failure ('tried to use it to extract data from hyatt.com completely failed... another hype but actually doesn't work browser agent' — notte-comm-1), and the founder himself admits only ~60% reliability on captcha-gated sites (notte-comm-7), directly contradicting the polished 'describe a task, watch it happen' framing. Missing for 10: independent verification of consistent task success, a true conversational/chat-based assistant UI (rather than API/CLI-driven task submission), and resolution of the documented failure case.

   • [github] “Give AI agents natural language tasks to complete on websites”
   • [claimed-docs] “Describe a task. Watch it happen. One prompt. No selectors, no maintenance.”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”
   • [community] “Founder: 'we can solve ~60% of providers right now (incl reCAPTCHA, Cloudflare, and main ones) and some others are still work in progress' r…”

   proof ↗⚑ flag

3. ai-native userOperate the product with natural-language commands

   weight 2 · round to Stagehand
   Stagehand✓fullcommunity9/10

   Stagehand's core API (act/extract/observe) is explicitly designed around natural-language instructions instead of hardcoded selectors, with docs describing instruction-driven execution and self-healing when selectors break. Community commentary independently corroborates that this NL-driven approach dynamically generates Playwright actions and is more resilient than traditional automation frameworks. Missing for 10: independent quantitative benchmarks on NL command accuracy/reliability across diverse sites.

   • [claimed-docs] “Execute actions using natural language”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Turn on `selfHeal` to re-infer an action when its recorded selector breaks.”
   • [claimed-docs] “Traditional selectors break when websites change”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”

   proof ↗⚑ flag

   Notte!disputedcontradicted5/10

   Notte's core value prop is natural-language task execution ('Describe a task. Watch it happen. One prompt', 'Give AI agents natural language tasks to complete on websites') backed by agent-start API and CLI/MCP integrations, so the capability is clearly built and documented. However, a hands-on community report describes a complete failure when trying to extract data from hyatt.com via the agent, and the founder himself admits captcha/anti-bot handling only works ~60% of the time, concretely undercutting reliability of the NL-driven approach. Missing for 10: independent reproducible success cases beyond vendor demos, and resolution of the documented hyatt.com failure.

   • [claimed-docs] “Describe a task. Watch it happen. One prompt. No selectors, no maintenance.”
   • [github] “Give AI agents natural language tasks to complete on websites”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”
   • [community] “Founder: 'we can solve ~60% of providers right now (incl reCAPTCHA, Cloudflare, and main ones) and some others are still work in progress' r…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Stagehand—none0/10

   The evidence pack shows standard prose documentation pages (docs.stagehand.dev) and confirms no OpenAPI/swagger spec exists (404s on all candidate paths), with no mention anywhere of an interactive, runnable-example API reference (e.g., live code sandbox or Swagger-style explorer). The llms.txt probe only shows a docs index for LLM ingestion, not an interactive reference.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stagehand.dev/openapi.json, https://docs.stagehand.dev/swagger.json, https://docs.stage…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stagehand.dev/llms.txt # Stagehand - [Introducing Stagehand](https://docs.stagehand.dev/v4/first-s…”
   • [claimed-docs] “Execute actions using natural language”

   proof ↗⚑ flag

   Notte—none0/10

   Evidence shows only static API-reference pages (authentication, agent-start) and no OpenAPI/Swagger spec was found at any candidate path (probe-2 returned 404s), and nothing in the pack describes an interactive console or runnable code examples in the API docs.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Stagehand—none0/10

   Direct probes for OpenAPI/swagger specs at all standard paths returned 404, and no documentation mentions a downloadable machine-readable API spec; only an llms.txt exists which is not an API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stagehand.dev/openapi.json, https://docs.stagehand.dev/swagger.json, https://docs.stage…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stagehand.dev/llms.txt # Stagehand - [Introducing Stagehand](https://docs.stagehand.dev/v4/first-s…”

   proof ↗⚑ flag

   Notte—none0/10

   The evidence shows Notte has human-readable API reference docs (auth, agent-start) but a direct probe for machine-readable spec files (openapi.json, swagger.json, etc.) returned 404 on all candidate paths, indicating no downloadable OpenAPI or equivalent spec is published.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Notte
   Stagehand—none0/10

   Stagehand's docs cover browser session persistence, regions, and observability but nothing about a dedicated sandbox/staging mode or safeguards to prevent hitting production data; the evidence pack shows only live browser automation against real or Browserbase-hosted sites.

   ⚑ flag

   Notte~partialclaimed3/10

   Notte documents 'isolated browser instances running in the cloud' for each session and a free trial ('Try the full platform without a card'), which implies some session-level isolation from a user's own systems, but there is no explicit sandbox/production-data separation mode, staging environment, or test-data guarantee described anywhere in the docs. missing for 10: explicit sandbox vs production distinction, test-data isolation guarantees, hands-on confirmation that sandbox sessions never touch real production data.

   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “Try the full platform without a card.”
   • [claimed-docs] “Build, debug, and deploy production workflows with cloud browsers, web agents, scraping, serverless functions, credentials, and identities i…”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Stagehand—none0/10

   Docs reference a 'v4' version path, but there is no evidence of a documented API versioning scheme or deprecation policy for Stagehand's SDK/API; no openapi spec or changelog/deprecation docs were found (openapi probe 404s).

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stagehand.dev/openapi.json, https://docs.stagehand.dev/swagger.json, https://docs.stage…”

   proof ↗⚑ flag

   Notte—none0/10

   There is evidence of an API with bearer token auth, but nothing about API versioning or a documented deprecation policy; OpenAPI probes even 404, suggesting no formal spec surfaced. missing for 10: versioning scheme, deprecation policy documentation, changelog entries about breaking changes.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”

   proof ↗⚑ flag

Compat

1. developerConnect my existing Playwright, Puppeteer, or CDP automation code to the product's browsers instead of rewriting it

   weight 2 · round to Notte
   Stagehand~partialcommunity6/10

   Stagehand explicitly supports attaching over CDP to any existing Chromium browser and lets you keep using familiar page-level (Playwright) methods when you don't need AI inference, which lets developers reuse existing Playwright/CDP automation rather than rewriting from scratch. However there is no evidence of native Puppeteer script compatibility, and community comments note Stagehand is positioned as a replacement/wrapper rather than a drop-in for arbitrary existing Playwright suites. Missing for 10: explicit Puppeteer interop, first-party guide on migrating existing Playwright test suites unmodified, and independent confirmation that CDP-attach preserves auth/session state seamlessly.

   • [claimed-docs] “Attach over CDP (localBrowser.connect): Attach to any Chromium browser you are already running, by URL”
   • [claimed-docs] “When you know the selector or want zero inference, use page methods you already know.”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”
   • [community] “This looks very cool and makes a lot of sense, except for the idea that it should take the place of Playwright et al. Personally I'd love to…”

   proof ↗⚑ flag

   Notte✓fullclaimed7/10

   Notte sessions explicitly expose a CDP endpoint documented to work with Playwright (notte-docs-11), which directly supports connecting existing Playwright/CDP automation code to Notte's cloud browsers rather than rewriting it. Puppeteer isn't explicitly named but CDP is the shared protocol underlying it, and sessions are described as programmatically controllable cloud instances (notte-docs-24). missing for 10: explicit Puppeteer example/docs, independent hands-on confirmation of the CDP/Playwright connection working at scale.

   • [claimed-docs] “Notte sessions expose a Chrome DevTools Protocol (CDP) endpoint that you can connect to with Playwright.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “Viewing sessions: When you start a session, the output includes a `ViewerUrl` - open it to watch your browser live”

   proof ↗⚑ flag

Credentials

1. automation-engineerStore credentials in a vault and have the agent complete logins including TOTP/2FA challenges without exposing secrets to the model

   weight 2 · round to Notte
   Stagehand—none0/10

   Evidence covers session/state persistence (cookies, local storage, Browserbase contexts) but there is no mention of vault-based credential storage, secret injection to avoid model exposure, or TOTP/2FA handling anywhere in the docs or community evidence.

   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”

   proof ↗⚑ flag

   Notte~partialclaimed7/10

   Notte's docs describe a credential vault where secrets are injected into the browser session but never exposed to the LLM, plus persistent cookies/login state and 'verified identities' (emails/phones) for sign-up and 2FA flows, directly matching the core of the story. However, there's no explicit walkthrough of a TOTP code being generated/entered by the agent, and no independent/hands-on confirmation that 2FA login flows work end-to-end in practice. Missing for 10: concrete TOTP-specific workflow documentation, independent verification of vault+2FA login success.

   • [claimed-docs] “Secure credential storage. Keep passwords, API keys, and sensitive data encrypted.”
   • [claimed-docs] “The significant security benefit of this approach is that the LLM never actually sees the actual credentials.”
   • [claimed-docs] “credentials are never exposed to LLMs or third-party services during agent execution”
   • [claimed-docs] “Persist cookies and login state across sessions.”
   • [claimed-docs] “Emails and phone numbers for sign-up and 2FA. Verified identities to interact across platforms.”
   • [claimed-docs] “Authenticated Profiles Browser profiles for each agent”

   proof ↗⚑ flag

Profiles

1. developerPersist logged-in browser state in reusable profiles so agents skip the login wall on every subsequent run

   weight 3 · round to Stagehand
   Stagehand✓fullclaimed8/10

   Docs explicitly describe persisting local browser user-data directories (cookies/local storage survive across runs) and Browserbase contexts for persisting session/browser data across cloud runs, directly matching the reusable-profile/login-skip story. Missing for 10: independent hands-on confirmation that a persisted profile actually skips a real login wall, and more detail on context lifecycle/expiry limits.

   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”

   proof ↗⚑ flag

   Notte✓fullclaimed7/10

   Notte docs explicitly document persisting cookies/login state across sessions and 'Authenticated Profiles' as browser profiles per agent, alongside secure credential vaults so agents can skip re-authentication on subsequent runs. missing for 10: no independent/hands-on confirmation that persisted profiles actually skip login walls in practice, and no detail on profile reuse limits/expiry.

   • [claimed-docs] “Persist cookies and login state across sessions.”
   • [claimed-docs] “Authenticated Profiles Browser profiles for each agent”
   • [claimed-docs] “Secure credential storage. Keep passwords, API keys, and sensitive data encrypted.”
   • [claimed-docs] “The significant security benefit of this approach is that the LLM never actually sees the actual credentials.”
   • [claimed-docs] “credentials are never exposed to LLMs or third-party services during agent execution”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Notte
   Stagehand—none0/10

   The evidence pack covers single-page act/extract/observe primitives, caching, and session persistence, but nothing describes batch/bulk operations across many items or parallelized runs at once. A browser-automation framework could plausibly support this (e.g., running many sessions in parallel), so the axis applies, but no such capability is documented.

   ⚑ flag

   Notte~partialclaimed4/10

   Notte offers scalable cloud browser sessions and serverless 'functions'/API endpoints that can be invoked and scheduled programmatically, which could in principle be used to run automation across many items, but there is no explicit documentation of a batch/bulk-processing feature (e.g., iterating over a list of URLs/records, parallel job queues, or bulk extraction outputs). missing for 10: explicit bulk/batch API or CLI examples, evidence of parallel multi-item execution, and any hands-on confirmation of running the same task across many inputs.

   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”
   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Extract structured data with AI. Turn any website into structured data.”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Notte
   Stagehand—none0/10

   The evidence describes Stagehand's act/observe/extract primitives for executing AI-driven browser actions, caching, and self-healing selectors, but nothing about defining persistent rules that automatically trigger on events (e.g., webhooks, schedules, DOM-change listeners) outside of an explicit script invocation.

   ⚑ flag

   Notte~partialclaimed3/10

   Notte supports scheduling serverless 'functions' (deploy scripts as API endpoints and 'schedule anywhere'), which gives some automation-trigger capability, but there is no evidence of a rules engine, webhooks, or event-based triggers (e.g., 'on page change, do X') as opposed to simple time-based scheduling/API invocation. Missing for 10: explicit event-trigger/webhook support, conditional rule definitions, and any UI/API for defining 'if event then action' automations.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”

   proof ↗⚑ flag

Local

1. developerRun the agent against a local browser on my own machine for development, without any cloud account

   weight 2 · round to Stagehand
   Stagehand✓fullclaimed7/10

   Docs confirm Stagehand can attach to a local Chromium browser over CDP (localBrowser.connect) and persist local user data on disk, meaning it can run fully locally without Browserbase/cloud accounts; Browserbase is presented as optional rather than required. missing for 10: independent hands-on confirmation of a pure-local run with no cloud account, and clearer docs distinguishing local-only setup from Browserbase defaults.

   • [claimed-docs] “Attach over CDP (localBrowser.connect): Attach to any Chromium browser you are already running, by URL”
   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “When you know the selector or want zero inference, use page methods you already know.”

   proof ↗⚑ flag

   Notte—none0/10

   All evidence describes Notte as a cloud-hosted service — sessions are explicitly 'isolated browser instances running in the cloud,' access requires a Bearer API token, and pricing/credits are core to usage — with no documented option to run the agent against a local browser without a cloud account.

   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “Try the full platform without a card.”
   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”

   proof ↗⚑ flag

Frameworks

1. developerPlug the browser layer into agent frameworks (Claude Agent SDK, Vercel AI SDK, LangChain, CrewAI) through documented adapters

   weight 2 · round to Notte
   Stagehand~partialprobed4/10

   Docs and community evidence confirm a documented MCP/stdio integration for Claude Code agents (and a Browserbase MCP server actually powered by Stagehand), but there is no evidence of documented adapters for Vercel AI SDK, LangChain, or CrewAI as the story specifically requires. missing for 10: Vercel AI SDK adapter docs, LangChain adapter docs, CrewAI adapter docs, and any first-party guide unifying these framework integrations.

   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”
   • [community] “Our Stagehand MCP server actually won Anthropic's Claude MCP hackathon :) ... We're working on a better computer use integration using Stage…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Notte~partialprobed7/10

   Notte documents explicit integration guides for CrewAI (notte-docs-32), Vercel AI SDK (notte-docs-33), OpenAI CUA (notte-docs-34), and Claude-based agents via CLI/MCP (notte-docs-9, notte-docs-31), all pointing at its MCP server or CLI as the browser layer plug-in point. However, there is no documented LangChain adapter and no mention of 'Claude Agent SDK' specifically (only Claude Code/managed agents), so the story's exact framework list is only partially covered. Missing for 10: a LangChain-specific integration doc, explicit Claude Agent SDK adapter naming, and independent confirmation these adapters work hands-on.

   • [claimed-docs] “pointing it at the Notte MCP server hands your crew a real browser.”
   • [claimed-docs] “Point its MCP client at the Notte MCP server and your TypeScript agent gets a browser.”
   • [claimed-docs] “This guide explains how to integrate OpenAI's Computer Use Agent (CUA) with Notte's browser infrastructure for automated web interactions.”
   • [claimed-docs] “The Notte CLI lets AI agents control browsers through simple shell commands.”
   • [claimed-docs] “give them the notte CLI and they can drive real browsers”
   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [probe] “official MCP server documented at https://docs.notte.cc/mcp-server”

   proof ↗⚑ flag

Models

1. developerBring my own LLM provider — the framework is model-agnostic rather than locked to one vendor's models

   weight 2 · round to Notte
   Stagehand—none0/10

   The evidence pack never documents which LLM providers Stagehand supports or describes any provider-swapping configuration; it only notes that a 'model key' is required to run (stagehand-probe-rt-1), without specifying that multiple vendors' models are interchangeable. Missing for 10: any docs or examples showing configuration for OpenAI/Anthropic/other providers, a provider-agnostic API surface, or community confirmation of using non-default models.

   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Notte~partialclaimed5/10

   The pricing page lists 'Bring your own keys' as a feature (Yes for higher tiers), indicating some BYO-LLM-key support, and OpenAI CUA integration doc shows a specific model provider integration, but there is no documentation of broad model-agnostic architecture, no list of supported providers, and no explicit statement that any LLM can be swapped in across the framework. missing for 10: explicit multi-provider support documentation, list of supported LLM vendors, guidance on configuring custom/local models, independent confirmation of model-agnosticism.

   • [claimed-docs] “Bring your own keys No No Yes Yes”
   • [claimed-docs] “This guide explains how to integrate OpenAI's Computer Use Agent (CUA) with Notte's browser infrastructure for automated web interactions.”

   proof ↗⚑ flag

Tasks

1. ai agentSubmit a browser task over a hosted HTTP API and receive the result by polling or webhook, without managing any browser myself

   weight 2 · round to Notte
   Stagehand—none0/10

   Stagehand is presented as an SDK/library (with an MCP server for agent tool-use) rather than a hosted HTTP task-submission API; the probe explicitly found no OpenAPI/REST endpoint (openapi paths all 404), and no docs describe submitting a task and polling or receiving a webhook result. Evidence shows Browserbase-hosted browser sessions and MCP/stdio integration, but nothing matching the described async HTTP task API.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stagehand.dev/openapi.json, https://docs.stagehand.dev/swagger.json, https://docs.stage…”
   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Notte~partialprobed6/10

   Notte offers a hosted HTTP API (Bearer-token auth, agent-start endpoint, cloud sessions, serverless 'functions' you can invoke and schedule) that let an agent submit a task without managing a browser itself, and sessions expose CDP/live-view for status. However there is no direct documentation of a polling endpoint or webhook callback mechanism for retrieving results, and no OpenAPI/swagger spec was found (404s), so completion-notification patterns are unclear. Missing for 10: explicit polling/webhook result-retrieval documentation, published OpenAPI schema, independent confirmation of end-to-end async task completion.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”

   proof ↗⚑ flag

2. developerHand the product a natural-language goal and it completes a multi-step web task end to end — navigating, filling forms, and clicking through flows

   weight 3 · round to Stagehand
   Stagehand~partialcommunity5/10

   Stagehand's docs confirm natural-language act()/observe()/extract() primitives that can navigate, click, and fill forms, plus self-healing and iframe/shadow-DOM handling that support robustness across steps, and community posts confirm real-world scraping/automation use (stagehand-comm-1, stagehand-comm-9). However, the evidence shows these as composable single-action primitives rather than a documented single-call 'give it a goal and it autonomously completes a multi-step flow' agent mode — multi-step chains appear to require the developer to sequence act/observe/extract calls or wire it via MCP into another agent (stagehand-docs-11). Missing for 10: first-party or hands-on evidence of a single natural-language goal driving full end-to-end multi-step task completion without developer-orchestrated step chaining.

   • [claimed-docs] “Execute actions using natural language”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Turn on `selfHeal` to re-infer an action when its recorded selector breaks.”
   • [claimed-docs] “Stagehand automatically handles iFrame traversal and shadow DOM elements without requiring additional configuration.”
   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”
   • [community] “I've been playing around with Stagehand for a minute now, actually a useful abstraction here. We build scrapers for websites that are pretty…”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”

   proof ↗⚑ flag

   Notte!disputedcontradicted5/10

   Notte's docs and README explicitly market natural-language, multi-step web task execution (e.g. 'Give AI agents natural language tasks to complete on websites', 'Describe a task. Watch it happen. One prompt', and a worked example of logging into LinkedIn and extracting messages), backed by session/vault/proxy infrastructure. However, a hands-on community report describes a real attempt to use the agent to extract data from hyatt.com that 'completely failed,' directly contradicting the end-to-end reliability claim, and the founder himself admits captcha/anti-bot handling only works for ~60% of providers. Missing for 10: independent successful third-party demonstrations of complex multi-step flows, and resolution of the reported failure case.

   • [github] “Give AI agents natural language tasks to complete on websites”
   • [claimed-docs] “Describe a task. Watch it happen. One prompt. No selectors, no maintenance.”
   • [claimed-docs] “Got to linkedin.com, login with the credentials and extract the last 10 messages from my most recent conversation”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”
   • [community] “Founder: 'we can solve ~60% of providers right now (incl reCAPTCHA, Cloudflare, and main ones) and some others are still work in progress' r…”

   proof ↗⚑ flag

Workflows

1. automation-engineerCompose repeatable multi-step workflows with loops, conditionals, and parameters instead of one-shot prompts

   weight 2 · round drawn
   Stagehand~partialclaimed5/10

   Stagehand is a code-first SDK (act/observe/extract primitives) that developers embed in regular TypeScript/Python code, which implicitly allows loops, conditionals, and parameters since it's just function calls in a host language — but no docs explicitly describe workflow composition, control-flow patterns, or parameterized repeatable workflows as a first-class feature. missing for 10: explicit workflow/orchestration documentation, examples of loops or conditionals chaining act/observe/extract calls, parameterized workflow templates, and any community evidence of engineers building such multi-step conditional workflows.

   • [claimed-docs] “extract() grabs structured data from a webpage. Every call takes an instruction and an output shape”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “When you know the selector or want zero inference, use page methods you already know.”
   • [claimed-docs] “Stagehand caches `act()`, `observe()`, and `extract()` results server-side to reduce LLM costs and speed up your automations.”

   proof ↗⚑ flag

   Notte~partialclaimed5/10

   Notte supports scripting deterministic automations and deploying them as serverless 'Functions'/API endpoints, and lets users generate workflow code via CLI then edit it, going beyond a single one-shot prompt (notte-docs-26, notte-docs-2, notte-docs-30, notte-gh-2). However there is no explicit documentation of workflow-level constructs like loops, conditionals, or parameterized templates. missing for 10: explicit docs on loop/conditional syntax in workflows, parameter binding across runs, independent confirmation of repeatable multi-step workflow composition.

   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”
   • [github] “combines AI agents with traditional scripting for maximum efficiency - letting you script deterministic parts and use AI only when needed, c…”
   • [claimed-docs] “Start from ready-made browser automation templates for common workflo”

   proof ↗⚑ flag

1. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Stagehand—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Notte—none0/10

   No evidence of data export/portability features, open-format export of user data, or account deletion/data takeout mechanisms; the docs focus on browser automation, scraping outputs, and credential storage but nothing about exporting one's own account data in open formats. missing for 10: data export feature docs, open-format (e.g. JSON/CSV) account export, data portability/account deletion process, any independent confirmation of exportability.

   ⚑ flag

2. ai-native userRead the product's source under an open license

   weight 2 · round to Notte
   Stagehand—none0/10

   The evidence pack contains only docs, community discussion, and runtime probes about Stagehand's automation features; none of it references a public source repository, license, or open-source status. Missing for 10: any mention of a GitHub repo, license file, or open-source claim.

   ⚑ flag

   Notte~partialcommunity3/10

   A public GitHub repository (nottelabs/notte) exists and is referenced in evidence, indicating the source code is at least publicly readable, but no evidence pack item specifies a license type (e.g., MIT/Apache) or confirms open-source licensing terms. A community comment even questions whether Notte is open source at all, suggesting ambiguity rather than confirmed openness. Missing for 10: explicit license file/badge evidence, confirmation of license terms, independent verification that the full product (not just parts) is open-licensed.

   • [github] “Give AI agents natural language tasks to complete on websites”
   • [github] “combines AI agents with traditional scripting for maximum efficiency - letting you script deterministic parts and use AI only when needed, c…”
   • [community] “Interesting but are there any open source products which can do the same too? This does feel something that I can trust more if it was open …”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Stagehand
   Stagehand~partialprobed6/10

   Stagehand is installable via npm and can run against a locally-controlled Chromium instance via CDP (localBrowser.connect), and the runtime probe confirms local install/execution without requiring Browserbase credentials, indicating the core library can be self-hosted. However, several advanced features (proxies, captcha handling, session recording, multi-region hosting) are documented as Browserbase-cloud-only, and there is no explicit self-hosting/Docker deployment guide or licensing statement. Missing for 10: dedicated self-host deployment docs, confirmation that captcha/proxy features work without Browserbase, and independent hands-on confirmation of a fully self-hosted setup.

   • [claimed-docs] “Attach over CDP (localBrowser.connect): Attach to any Chromium browser you are already running, by URL”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”

   proof ↗⚑ flag

   Notte—none0/10

   All evidence describes Notte as a cloud/SaaS platform (remote browsers, cloud sessions, serverless functions, hosted API with Bearer auth) with no documented self-hosting or on-prem deployment path; a community comment even asks whether an open-source alternative exists, implying Notte itself isn't self-hostable.

   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [community] “Interesting but are there any open source products which can do the same too? This does feel something that I can trust more if it was open …”

   proof ↗⚑ flag

Pricing

1. developerSee transparent per-task or per-browser-hour pricing and documented rate/concurrency limits before committing

   weight 2 · round to Notte
   Stagehand—none0/10

   No evidence pack items mention pricing tiers, per-task/per-browser-hour costs, or documented rate/concurrency limits — docs cover only technical features (caching, contexts, regions) and community comments are unrelated to pricing transparency.

   ⚑ flag

   Notte!disputedcontradicted3/10

   Notte does have a public pricing page and free-trial claim (notte-docs-22, notte-docs-23), but there is no documentation of concrete per-task/per-browser-hour rates or rate/concurrency limits, and community feedback directly contradicts the transparency claim: users on HN explicitly ask what a 'credit' actually buys and report the pricing page doesn't explain it, calling the credit-based scheme 'broken' and unpredictable (notte-comm-2, notte-comm-3, notte-comm-4). missing for 10: explicit per-task/per-hour rate tables, documented concurrency/rate limits, and resolution of the community complaints about opaque credit meaning.

   • [claimed-docs] “Try the full platform without a card.”
   • [claimed-docs] “Bring your own keys No No Yes Yes”
   • [community] “The pricing page mentions how many credits you get but not what a credit does or gets you. Could you elaborate on that?”
   • [community] “Credit based pricing is broken. No way u produce shiy then user get out of credit to get nothing done.”
   • [community] “You missed the point. What i mean, is your pricing scheme is a scam because u never know if your bot response would solve customer issue. St…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Stagehand
   Stagehand~partialclaimed6/10

   Docs state Browserbase-hosted sessions can be started in one of four regions and that this can keep session data in a required jurisdiction, giving some data-residency control (stagehand-docs-9). However this only covers Browserbase-run browser sessions, not other data flows like server-side act/observe/extract caching (stagehand-docs-6) or local user-data directories (stagehand-docs-7), and there is no independent/hands-on confirmation of residency guarantees. Missing for 10: region control over cached LLM/action results and other stored artifacts, explicit compliance/residency guarantees, and third-party verification.

   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [claimed-docs] “Stagehand caches `act()`, `observe()`, and `extract()` results server-side to reduce LLM costs and speed up your automations.”
   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”

   proof ↗⚑ flag

   Notte—none0/10

   No evidence in the pack mentions data residency, region selection, or storage location choices for Notte's cloud infrastructure; only general security/credential features are documented.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Stagehand—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Notte—none0/10

   No evidence in the pack addresses opting out of AI training data usage, data retention policies for model training, or any privacy commitment regarding customer data not being used to train models. Notte's docs cover security of credentials, sessions, stealth mode, and infrastructure, but nothing about AI-training data usage policy.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stagehand—none0/10

   Docs describe persisting user data (cookies/local storage, Browserbase contexts) and choosing a data region for jurisdiction, but there is no evidence of any deletion controls, retention limits, or user-facing settings to purge stored session/browser data. missing for 10: explicit retention policy, deletion/purge mechanism, and user controls over how long session data or extracted data is kept.

   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”

   proof ↗⚑ flag

   Notte—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or user-facing options to purge stored data/sessions/credentials; docs mention credential encryption and cookie persistence but nothing about retention windows or deletion mechanisms.

   ⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Stagehand—none0/10

   No evidence pack item discusses telemetry, usage tracking, or opt-out settings for Stagehand; documentation covers automation features, caching, and Browserbase infrastructure but is silent on telemetry practices.

   ⚑ flag

   Notte—none0/10

   No evidence pack item mentions telemetry, analytics opt-out, or usage-tracking controls for Notte; missing for 10: any privacy policy or docs section on telemetry collection, opt-out mechanism/flag, or data retention settings.

   ⚑ flag

Live

1. automation-engineerWatch a session live and take human control mid-run when the agent gets stuck

   weight 2 · round to Notte
   Stagehand~partialclaimed4/10

   Stagehand's docs mention Browserbase's session dashboard offering real-time browser screen recording and replay, which covers 'watching a session live,' but there is no evidence of a mechanism to hand control back to a human mid-run when the agent stalls. missing for 10: explicit live take-over/human-in-the-loop control feature, evidence of pausing agent execution for manual intervention, and independent confirmation of this workflow.

   • [claimed-docs] “Browserbase provides real-time visibility into your automation sessions: **Session dashboard features** * Real-time browser screen recordi…”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”

   proof ↗⚑ flag

   Notte~partialclaimed5/10

   Notte clearly supports live session viewing via ViewerUrl and a 'Live View & Replays' screenshare feature, and sessions expose a CDP endpoint connectable via Playwright which could in principle allow manual intervention. However, there is no explicit documentation of a human-takeover/pause-and-control workflow mid-run when an agent gets stuck. Missing for 10: explicit human-in-the-loop takeover mechanism, documentation of pausing agent execution to hand control to a human, and independent confirmation this works in practice.

   • [claimed-docs] “Viewing sessions: When you start a session, the output includes a `ViewerUrl` - open it to watch your browser live”
   • [claimed-docs] “Live View & Replays Screenshare & session playback”
   • [claimed-docs] “Notte sessions expose a Chrome DevTools Protocol (CDP) endpoint that you can connect to with Playwright.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”

   proof ↗⚑ flag

Replay

1. automation-engineerDebug a failed agent run from recorded replays — video, screenshots, step-by-step action timelines

   weight 2 · round drawn
   Stagehand~partialclaimed5/10

   Stagehand relies on Browserbase's session dashboard for real-time screen recording and replay, giving some visibility into runs, but there is no documented step-by-step action timeline correlated with agent decisions, no screenshot-per-step artifact, and no dedicated debugging/replay tooling built into Stagehand itself. missing for 10: native step-by-step action timeline tied to LLM decisions, per-step screenshots, first-party replay/debug UI (beyond Browserbase's generic session recording), independent hands-on confirmation of replay-based debugging workflows.

   • [claimed-docs] “Browserbase provides real-time visibility into your automation sessions: **Session dashboard features** * Real-time browser screen recordi…”

   proof ↗⚑ flag

   Notte~partialclaimed5/10

   Notte docs confirm 'Live View & Replays' with screenshare and session playback, plus a live ViewerUrl to watch sessions and CDP/Playwright hooks for programmatic inspection, giving some replay-debugging capability. However, there is no explicit documentation of step-by-step action timelines or a dedicated debugging UI for failed runs, and no independent/hands-on confirmation this replay feature works reliably. missing for 10: documented step-by-step action timeline/debugging tool, independent verification of replay/video debugging in practice.

   • [claimed-docs] “Live View & Replays Screenshare & session playback”
   • [claimed-docs] “Viewing sessions: When you start a session, the output includes a `ViewerUrl` - open it to watch your browser live”
   • [claimed-docs] “Notte sessions expose a Chrome DevTools Protocol (CDP) endpoint that you can connect to with Playwright.”
   • [claimed-docs] “Build, debug, and deploy production workflows with cloud browsers, web agents, scraping, serverless functions, credentials, and identities i…”

   proof ↗⚑ flag

Fleets

1. automation-engineerRun a fleet of concurrent browser sessions with documented concurrency limits and programmatic session management

   weight 2 · round to Notte
   Stagehand—none0/10

   The evidence shows Stagehand/Browserbase supports single-session configuration (regions, contexts, persistence, observability) but nowhere documents fleet-level concurrency limits or APIs for managing many concurrent sessions programmatically. Missing for 10: documented concurrency caps, fleet/session-pool management API, and any evidence of running many sessions in parallel.

   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [claimed-docs] “Browserbase provides real-time visibility into your automation sessions: **Session dashboard features** * Real-time browser screen recordi…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”

   proof ↗⚑ flag

   Notte~partialcommunity4/10

   Notte documents cloud-based, isolated, programmatically controllable sessions (notte-docs-24), API/CLI/SDK control (notte-docs-17, notte-docs-37, notte-probe-4), and serverless scaling claims (notte-docs-1, notte-docs-26), supporting the 'programmatic session management' half of the story. However, no evidence anywhere specifies actual concurrency limits, quotas, or fleet-scale numbers for running many sessions in parallel — pricing/credit pages are mentioned only vaguely by community members (notte-comm-2) without concurrency specifics. missing for 10: documented concurrency/rate limits per plan, explicit multi-session fleet management API/dashboard evidence, independent benchmarks of parallel session throughput.

   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [community] “The pricing page mentions how many credits you get but not what a credit does or gets you. Could you elaborate on that?”

   proof ↗⚑ flag

Lifecycle

1. developerGet webhook notifications when tasks and sessions finish instead of polling for status

   weight 1 · round drawn
   Stagehand—none0/10

   No evidence of any webhook/callback mechanism for task or session completion; Stagehand's docs focus on act/observe/extract, caching, and session dashboards but nothing about push notifications replacing polling.

   ⚑ flag

   Notte—none0/10

   No evidence pack item mentions webhooks, callback URLs, or event-driven notifications for task/session completion; the docs describe sessions, viewer URLs, CDP endpoints and API auth but nothing about push notifications, forcing polling-based status checks instead.

   ⚑ flag

Captcha

1. automation-engineerRely on a documented captcha stance — automatic solving, human fallback, or explicit non-support — instead of silent task failures

   weight 2 · round to Stagehand
   Stagehand~partialcommunity3/10

   Only a single community anecdote claims Stagehand/Browserbase have 'built in proxies and captcha' handling, but no first-party documentation in the pack states an explicit captcha policy (auto-solve, human fallback, or non-support). missing for 10: official docs describing captcha handling behavior, guidance on fallback/human-in-the-loop when captchas are hit, and independent verification beyond one forum comment.

   • [community] “I've been playing around with Stagehand for a minute now, actually a useful abstraction here. We build scrapers for websites that are pretty…”
   • [community] “I recently tried to implement a workflow automation using similar frameworks that were playwright or puppeteer based... What stopped me enti…”

   proof ↗⚑ flag

   Notte!disputedcontradicted4/10

   Notte's docs advertise 'captcha solving' as a built-in feature of its browser infrastructure (notte-docs-1), suggesting automatic handling, but there is no documented policy for what happens when solving fails (no human fallback or explicit non-support statement). Concrete contradicting evidence comes from the founder himself in community discussion, admitting captcha solving only works for ~60% of providers and some are 'still work in progress' (notte-comm-7), directly undercutting the blanket 'captcha solving' claim and leaving automation engineers without clarity on failure behavior. missing for 10: documented success-rate/coverage table, explicit fallback or escalation behavior on captcha failure, and independent verification of solve rates beyond the founder's informal comment.

   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”
   • [community] “Founder: 'we can solve ~60% of providers right now (incl reCAPTCHA, Cloudflare, and main ones) and some others are still work in progress' r…”

   proof ↗⚑ flag

Posture

1. automation-engineerPoint to the vendor's published acceptable-use and anti-abuse posture governing what its stealth and automation features may be used for

   weight 1 · round drawn
   Stagehand—none0/10

   No evidence pack item references a published acceptable-use policy, anti-abuse terms, or governance statement about how Stagehand's automation/anti-detection features may or may not be used; docs focus entirely on features (act/observe/extract, caching, proxies) with no mention of usage policy or abuse prevention stance.

   ⚑ flag

   Notte—none0/10

   No evidence pack item shows Notte publishing an acceptable-use policy, terms governing stealth/captcha-bypass usage, or an anti-abuse stance; docs only describe stealth/proxy/captcha features themselves. A community comment even accuses Notte of 'disrespecting robots.txt' and enabling spam, but this is criticism, not a vendor-published policy to compare against.

   • [claimed-docs] “All Notte sessions automatically include: **Clean browser fingerprints** - Realistic browser signatures”
   • [claimed-docs] “Combine stealth mode with residential proxies for maximum anonymity”
   • [claimed-docs] “Notte sessions include built-in stealth features to help your automations avoid detection by anti-bot systems.”
   • [community] “Avoiding captchas and disrespecting robots.txt. How does it feel to advertise your spam service? Are you proud?”

   proof ↗⚑ flag

Stealth

1. automation-engineerEnable stealth fingerprinting and residential or geo-targeted proxies so legitimate automations aren't blocked as bots

   weight 2 · round to Notte
   Stagehand~partialcommunity5/10

   A community hands-on comment praises Stagehand/Browserbase's 'built in proxies and captcha' handling for adversarial sites, and docs confirm Browserbase supports multi-region session placement (geo-targeting) — but there is no first-party documentation of stealth fingerprinting configuration or explicit residential-proxy selection controls. missing for 10: dedicated docs on fingerprint spoofing/stealth mode, explicit residential proxy configuration options, and independent verification that bot-block evasion works reliably.

   • [community] “I've been playing around with Stagehand for a minute now, actually a useful abstraction here. We build scrapers for websites that are pretty…”
   • [community] “I recently tried to implement a workflow automation using similar frameworks that were playwright or puppeteer based... What stopped me enti…”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”

   proof ↗⚑ flag

   Notte✓fullclaimed7/10

   Notte's docs explicitly describe stealth mode with clean/realistic browser fingerprints, built-in anti-bot detection avoidance, and residential proxies with a global network including fixed IPs and BYO options, directly matching the story's ask for fingerprinting and geo/residential proxy control. missing for 10: independent hands-on verification that stealth+proxy combo actually evades sophisticated bot detection in practice, and finer detail on geo-targeting granularity beyond 'global network'.

   • [claimed-docs] “All Notte sessions automatically include: **Clean browser fingerprints** - Realistic browser signatures”
   • [claimed-docs] “Combine stealth mode with residential proxies for maximum anonymity”
   • [claimed-docs] “Residential Proxies Global network, fixed IPs & BYO”
   • [claimed-docs] “Notte sessions include built-in stealth features to help your automations avoid detection by anti-bot systems.”
   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”

   proof ↗⚑ flag

Extraction

1. developerExtract typed, schema-validated data (Zod/Pydantic-style) from pages the agent visits, not just raw text

   weight 3 · round to Stagehand
   Stagehand✓fullclaimed7/10

   Stagehand's documented extract() API takes an instruction plus an output shape (schema), directly matching typed/schema-validated extraction rather than raw text scraping. Missing for 10: explicit mention of Zod/Pydantic naming in the evidence pack, independent/hands-on confirmation of schema validation behavior beyond docs.

   • [claimed-docs] “extract() grabs structured data from a webpage. Every call takes an instruction and an output shape”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”

   proof ↗⚑ flag

   Notte!disputedcontradicted5/10

   Docs show Pydantic-style schema extraction (BaseModel classes) and structured/markdown output via 'fetch' and scraping concepts (notte-docs-15, notte-docs-3, notte-docs-25), which directly matches the story. However, a hands-on community report states extraction 'completely failed' on a real site (hyatt.com), directly contradicting the reliability of the extraction pipeline in practice. Missing for 10: Zod/TypeScript schema examples (only Python/Pydantic shown), independent corroboration of successful schema-validated extraction, and resolution of the reported failure case.

   • [claimed-docs] “Extract structured data from a page: ... class HackerNewsFeed(BaseModel):”
   • [claimed-docs] “Extract structured data with AI. Turn any website into structured data.”
   • [claimed-docs] “Fetch extracts web page content as markdown or structured data using LLM-powered extraction.”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”

   proof ↗⚑ flag

Files

1. developerMy agent can download files from and upload files to the sites it operates, with the artifacts retrievable afterwards

   weight 1 · round drawn
   Stagehand—none0/10

   The evidence pack covers Stagehand's act/observe/extract primitives, session persistence, and MCP integration, but nowhere mentions file download/upload handling or artifact retrieval after a session ends. Since browser automation tools plausibly support file transfer, this is an applicable axis with no supporting evidence.

   ⚑ flag

   Notte—none0/10

   The evidence pack covers browser sessions, scraping/extraction, credentials, and CDP/Playwright access, but no documentation mentions file upload/download handling or artifact retrieval from agent-operated sites. This is a plausible capability for a browser-automation platform, so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag