Skyvern 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 Notte
   Skyvern—none0/10

   No evidence of caching resolved actions or generated code for deterministic, cheaper replay; Skyvern's model is per-run AI-driven navigation via LLM+vision, and community feedback even complains about cost/latency of repeated LLM calls with no mention of a caching mechanism to mitigate this.

   • [community] “I tried it out and it's pretty pricey. My OpenAI API bill is $3.20 after using this on a few different pages to test it out... this is alway…”
   • [community] “This is an impressive tool. I especially like the observability around the workflow and the steps it takes to achieve the outcome. We are po…”
   • [claimed-docs] “It navigates websites it has never seen before, filling forms, extracting data, and completing multi-step tasks via a simple API.”

   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 Notte
   Skyvern!disputedcontradicted5/10

   Skyvern's docs describe exactly this: natural-language act/click/type primitives with vision+DOM understanding that operate on sites 'never seen before' and fall back to selectors only if needed (skyvern-docs-19, skyvern-gh-1, skyvern-docs-17), positioned explicitly as a replacement for brittle Selenium scripts (skyvern-docs-13). However, a hands-on community test found it worked on the happy path but concretely failed to interact with a layout element (a popup) and struggled to hit a tab on a real site (skyvern-comm-2), contradicting the claim that it robustly survives arbitrary layout changes. Missing for 10: independent benchmark data on selector/layout-change robustness, broader corroboration beyond one hands-on report, and resolution of the observed failure mode.

   • [claimed-docs] “Drop-in AI commands on top of Playwright. Use natural language to act, extract, and validate — or fall back to selectors.”
   • [github] “Skyvern can operate on websites it's never seen before, as it's able to map visual elements to actions necessary to complete a workflow, wit…”
   • [claimed-docs] “It navigates websites it has never seen before, filling forms, extracting data, and completing multi-step tasks via a simple API.”
   • [claimed-docs] “You're replacing brittle Selenium scripts, integrating browser automation via API, or building workflows into your product.”
   • [community] “I played with the Geico example, and it seems to do a good job on the happy path. But I tried costcotravel.com... it struggled to hit the 'r…”

   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 Notte
   Skyvern~partialcommunity3/10

   Skyvern's docs mention human-in-the-loop pausing for approval between steps and a VNC stream to watch/take control, which offers some ability to intervene before the agent proceeds, but there is no documented explicit 'plan/preview candidate actions' step (e.g., a dry-run or action list shown before execution). A community comment even notes the absence of assertion/verification-style controls compared to Playwright, suggesting no built-in preview mechanism for validating steps before they run. Missing for 10: an explicit plan/preview UI or API that lists candidate actions before execution, and independent confirmation that the pause-for-approval flow shows planned actions rather than just pausing mid-run.

   • [claimed-docs] “Human-in-the-loop flows: pause for approval between steps without losing browser state. The VNC stream lets you watch or take control at any…”
   • [community] “I can't see that option in Skyvern which would have me worrying that process changes would be overlooked and we would unknowingly start ente…”

   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 Skyvern
   Skyvern✓fullclaimed7/10

   Skyvern's core action loop is vision-based: it maps visual elements to actions on pages it has never seen, without custom DOM-specific code (skyvern-gh-1), and separately uses its vision model to detect and solve CAPTCHAs, which are canvas-like elements the DOM can't parse (skyvern-docs-9, skyvern-docs-27). Docs also mention falling back to selectors when useful (skyvern-docs-19), implying vision-first with DOM as a secondary path rather than a purely DOM-based tool needing a special switch. missing for 10: explicit documentation of a discrete 'vision/computer-use mode' toggle, dedicated canvas/non-DOM UI examples (e.g., canvas-drawn widgets, non-HTML apps), and independent benchmarking confirming success on such UIs.

   • [github] “Skyvern can operate on websites it's never seen before, as it's able to map visual elements to actions necessary to complete a workflow, wit…”
   • [claimed-docs] “Skyvern detects CAPTCHAs using its vision model and solves them automatically. This works for reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstil…”
   • [claimed-docs] “Skyvern detects CAPTCHAs using its vision model and solves them automatically.”
   • [claimed-docs] “Drop-in AI commands on top of Playwright. Use natural language to act, extract, and validate — or fall back to selectors.”

   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
   Skyvern✓fullprobed8/10

   A probe confirms llms.txt is live and returns a structured summary of Skyvern for agent consumption, and skyvern.com/llms provides an agent-oriented docs page listing features in a scannable format. This directly satisfies pointing an agent at llms.txt or agent-oriented docs. Missing for 10: a docs.md/markdown-mirrored docs endpoint (404) and an accessible OpenAPI spec, which would round out machine-readable documentation.

   • [probe] “PROBE llms.txt: HTTP 200 at https://skyvern.com/llms.txt # Skyvern > Skyvern is an open-source, AI-powered browser automation platform. It …”
   • [claimed-docs] “Visual workflow builder for non-developers — drag-and-drop, no code required”
   • [claimed-docs] “Browser recorder that converts manual actions into reusable automations”
   • [claimed-docs] “SOP upload — describe a process in plain English and Skyvern builds the workflow”
   • [claimed-docs] “Copilot chat for building and debugging workflows interactively”
   • [probe] “PROBE docs-md: HTTP 404 at https://skyvern.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://skyvern.com/openapi.json, https://skyvern.com/swagger.json, https://skyvern.com/api/openapi.…”

   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 to Notte
   Skyvern✓fullclaimed7/10

   Skyvern ships a code-first SDK/REST API (Python/TypeScript) that connects to a cloud or self-hosted Chromium instance, explicitly positioned as replacing brittle Selenium scripts and integrating browser automation via API into other products, and can run entirely on your own infrastructure with your own LLM keys, supporting headless/scriptable use suitable for CI. missing for 10: explicit CI/CD pipeline documentation or example (e.g. GitHub Actions integration), and independent confirmation of headless execution in automated environments

   • [claimed-docs] “Integrate browser automation into your product with Python, TypeScript, or REST.”
   • [claimed-docs] “Run Skyvern on your own infrastructure with your own LLM keys.”
   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “Self-hosted Skyvern runs entirely on your infrastructure: your servers, your browsers, your LLM API keys.”
   • [claimed-docs] “You're replacing brittle Selenium scripts, integrating browser automation via API, or building workflows into your product.”

   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
   Skyvern—none0/10

   Evidence only shows Skyvern exposing an MCP *server* so external AI assistants (Claude, Cursor, etc.) can control Skyvern's browser — the reverse of the story, which asks whether Skyvern can consume external MCP servers' tools as a client. No documentation or community evidence shows Skyvern importing or connecting to third-party MCP servers to extend its own toolset.

   • [claimed-docs] “The Skyvern MCP server lets AI assistants like Claude Desktop, Claude Code, Codex, Cursor, and Windsurf control a browser.”
   • [probe] “official MCP server documented at https://skyvern.com/docs/developers/getting-started/mcp”

   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
   Skyvern✓fullprobed8/10

   Skyvern documents an official MCP server (skyvern-docs-7, skyvern-probe-4) that lets AI assistants like Claude Desktop, Claude Code, Codex, Cursor, and Windsurf control a browser via Skyvern, directly matching the story. Missing for 10: independent/hands-on community verification of the MCP server specifically (community evidence covers other features, not MCP usage) and a clear setup/config example beyond the single doc page.

   • [claimed-docs] “The Skyvern MCP server lets AI assistants like Claude Desktop, Claude Code, Codex, Cursor, and Windsurf control a browser.”
   • [probe] “official MCP server documented at https://skyvern.com/docs/developers/getting-started/mcp”

   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
   Skyvern—none0/10

   Evidence covers Skyvern's Python/TypeScript SDKs, REST API, MCP server, and visual dashboard, but nowhere mentions an official CLI tool for AI-native workflows. missing for 10: any documented CLI command, npm/pip CLI package, or terminal-based interface.

   • [claimed-docs] “Integrate browser automation into your product with Python, TypeScript, or REST.”
   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “The Skyvern MCP server lets AI assistants like Claude Desktop, Claude Code, Codex, Cursor, and Windsurf control a browser.”

   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 to Notte
   Skyvern✓fullprobed7/10

   Skyvern documents a public API/SDK surface (Python, TypeScript, REST) for creating tasks, running multi-step browser automations, and extracting structured data via JSON schema, matching the ai-native 'drive via documented API' story; it also ships an MCP server for agent control. Missing for 10: a discoverable OpenAPI/swagger spec (probe found 404s for all candidate paths) and independent/hands-on confirmation of API robustness beyond first-party docs.

   • [claimed-docs] “Integrate browser automation into your product with Python, TypeScript, or REST.”
   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “It navigates websites it has never seen before, filling forms, extracting data, and completing multi-step tasks via a simple API.”
   • [claimed-docs] “You provide a natural-language prompt describing the goal, a starting URL, and optionally a JSON schema for structured output.”
   • [claimed-docs] “you can extract structured data from any page using `page.extract` with a JSON schema, or by passing a `data_extraction_schema` to `page.age…”
   • [claimed-docs] “The Skyvern MCP server lets AI assistants like Claude Desktop, Claude Code, Codex, Cursor, and Windsurf control a browser.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://skyvern.com/openapi.json, https://skyvern.com/swagger.json, https://skyvern.com/api/openapi.…”
   • [probe] “official MCP server documented at https://skyvern.com/docs/developers/getting-started/mcp”

   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
   Skyvern—none0/10

   No evidence of scoped or least-privilege API credential issuance for agents; docs mention API keys and self-hosted LLM keys but nothing about credential scoping, permissions, or restricting agent access levels. Community comments even raise concerns about handling sensitive credentials in plain text with no mitigation shown. Missing for 10: any documentation of scoped API tokens, role-based access control, or least-privilege credential management for agents.

   • [claimed-docs] “Run Skyvern on your own infrastructure with your own LLM keys.”
   • [claimed-docs] “Self-hosted Skyvern runs entirely on your infrastructure: your servers, your browsers, your LLM API keys.”
   • [community] “you are expecting them to pass over their website login credentials and apparently their credit card details too, in plain text. You had bet…”

   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 Skyvern
   Skyvern✓fullprobed7/10

   Skyvern explicitly documents official Python and TypeScript SDKs plus a REST API for integrating browser automation, with SDK-level primitives like page.extract and data_extraction_schema shown in docs (skyvern-docs-1, skyvern-docs-5, skyvern-docs-19, skyvern-docs-4). Missing for 10: independent/hands-on developer corroboration of SDK usage and a public API reference (OpenAPI spec probe returned 404s, skyvern-probe-3), so quality is capped below full confidence in completeness.

   • [claimed-docs] “Integrate browser automation into your product with Python, TypeScript, or REST.”
   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “Drop-in AI commands on top of Playwright. Use natural language to act, extract, and validate — or fall back to selectors.”
   • [claimed-docs] “you can extract structured data from any page using `page.extract` with a JSON schema, or by passing a `data_extraction_schema` to `page.age…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://skyvern.com/openapi.json, https://skyvern.com/swagger.json, https://skyvern.com/api/openapi.…”

   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

9. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Skyvern—none0/10

   No evidence in the pack mentions webhooks or event subscriptions of any kind; Skyvern's documented integration surfaces are REST/SDK APIs, Zapier, and an MCP server, none of which constitute a webhook subscription mechanism.

   ⚑ flag

   Notte—none0/10

   No evidence pack item mentions webhooks or event subscription mechanisms; the product offers sessions, MCP, CLI, and API endpoints but nothing about push notifications or webhook callbacks. Missing for 10: any documentation of webhook subscription, event types, or delivery mechanism.

   ⚑ flag

Agentic features

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

   weight 2 · round to Notte
   Skyvern~partialcommunity7/10

   Skyvern's docs show multi-step, code-first and no-code workflows that run via API or cloud UI, persist browser state, and can pause for human approval while capturing recordings/artifacts — all indicative of autonomous background execution (skyvern-docs-5,6,10,11,21). Zapier integration and API-driven triggering (skyvern-docs-16, skyvern-docs-28) supports running without manual intervention, but there's no explicit documentation of a scheduler, cron-like triggers, or continuous monitoring dashboard for unattended runs. Missing for 10: explicit scheduling/trigger docs, evidence of long-running unattended background jobs, and independent confirmation of reliability at scale (community notes some brittleness, e.g. skyvern-comm-2).

   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “Build multi-step automations visually in the Cloud UI with drag-and-drop blocks. No code required. Share templates across your team.”
   • [claimed-docs] “Human-in-the-loop flows: pause for approval between steps without losing browser state. The VNC stream lets you watch or take control at any…”
   • [claimed-docs] “Every run automatically captures what happened: recordings of the browser session, screenshots at each step, the AI's reasoning, and network…”
   • [claimed-docs] “Cookies, local storage, open tabs, and the current page all persist, so later operations pick up exactly where the previous one stopped.”
   • [claimed-docs] “Connect to Zapier”
   • [claimed-docs] “Skyvern automates browser-based workflows across these platforms — no API keys or custom connectors required.”
   • [community] “I played with the Geico example, and it seems to do a good job on the happy path. But I tried costcotravel.com... it struggled to hit the 'r…”

   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 Skyvern
   Skyvern✓fullclaimed7/10

   Skyvern's core product IS an AI agent you delegate to via natural-language prompts to complete multi-step browser tasks (skyvern-docs-17, skyvern-docs-18), and it also ships a 'Copilot chat for building and debugging workflows interactively' inside the platform (skyvern-docs-25), plus SOP-to-workflow generation from plain English (skyvern-docs-24). This matches an AI-native user delegating tasks to a built-in assistant. Missing for 10: independent/hands-on validation of the copilot chat feature specifically (community evidence focuses on task execution quality, not the assistant/copilot UX), and no detail on assistant's conversational scope beyond workflow authoring.

   • [claimed-docs] “It navigates websites it has never seen before, filling forms, extracting data, and completing multi-step tasks via a simple API.”
   • [claimed-docs] “You provide a natural-language prompt describing the goal, a starting URL, and optionally a JSON schema for structured output.”
   • [claimed-docs] “SOP upload — describe a process in plain English and Skyvern builds the workflow”
   • [claimed-docs] “Copilot chat for building and debugging workflows interactively”
   • [github] “Skyvern can operate on websites it's never seen before, as it's able to map visual elements to actions necessary to complete a workflow, wit…”

   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 Skyvern
   Skyvern✓fullcommunity7/10

   Skyvern's core interaction model is natural-language: users provide a prompt describing the goal (docs-18), SOPs in plain English are converted to workflows (docs-24), and a Copilot chat and MCP server let AI assistants/users direct browser actions in natural language (docs-25, docs-7, docs-19). This is corroborated by community reports of using it via prompts on real sites, though with mixed reliability on complex flows. missing for 10: independent benchmarking or hands-on confirmation that natural-language commands reliably handle complex multi-step tasks, and clearer evidence of NL-driven success rates beyond anecdotal HN reports.

   • [claimed-docs] “You provide a natural-language prompt describing the goal, a starting URL, and optionally a JSON schema for structured output.”
   • [claimed-docs] “SOP upload — describe a process in plain English and Skyvern builds the workflow”
   • [claimed-docs] “Copilot chat for building and debugging workflows interactively”
   • [claimed-docs] “The Skyvern MCP server lets AI assistants like Claude Desktop, Claude Code, Codex, Cursor, and Windsurf control a browser.”
   • [claimed-docs] “Drop-in AI commands on top of Playwright. Use natural language to act, extract, and validate — or fall back to selectors.”
   • [community] “I played with the Geico example, and it seems to do a good job on the happy path. But I tried costcotravel.com... it struggled to hit the 'r…”

   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
   Skyvern—none0/10

   Evidence shows only static docs describing SDKs and REST usage, with no interactive API reference or runnable-example explorer; probes explicitly found no OpenAPI/Swagger spec at any candidate path (404s), indicating no interactive reference exists.

   • [probe] “PROBE openapi: all candidate paths 404 (https://skyvern.com/openapi.json, https://skyvern.com/swagger.json, https://skyvern.com/api/openapi.…”
   • [probe] “PROBE docs-md: HTTP 404 at https://skyvern.com/docs.md”
   • [claimed-docs] “Integrate browser automation into your product with Python, TypeScript, or REST.”

   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
   Skyvern—none0/10

   Skyvern offers a REST API (skyvern-docs-1) but a direct probe for OpenAPI/swagger specs at standard paths returned 404 across all candidates, and no docs mention a downloadable machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://skyvern.com/openapi.json, https://skyvern.com/swagger.json, https://skyvern.com/api/openapi.…”
   • [probe] “PROBE docs-md: HTTP 404 at https://skyvern.com/docs.md”
   • [claimed-docs] “Integrate browser automation into your product with Python, TypeScript, or REST.”

   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
   Skyvern—none0/10

   Skyvern's docs describe cloud or self-hosted execution, credential handling, and observability, but nothing describes a dedicated sandbox/staging mode isolated from production data or systems — missing for 10: any mention of a sandbox environment, test/staging mode, or data isolation guarantees.

   ⚑ 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
   Skyvern—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; OpenAPI/spec probes all returned 404 and no changelog or versioning docs appear in the pack. Missing for 10: versioned API endpoints (e.g., /v1/), a published deprecation/support policy, and changelog documentation.

   • [probe] “PROBE openapi: all candidate paths 404 (https://skyvern.com/openapi.json, https://skyvern.com/swagger.json, https://skyvern.com/api/openapi.…”
   • [probe] “PROBE docs-md: HTTP 404 at https://skyvern.com/docs.md”

   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
   Skyvern~partialclaimed5/10

   Docs show Skyvern's own SDK connects to a cloud Chromium instance over CDP and layers Playwright on top, and describe 'drop-in AI commands on top of Playwright' with fallback to raw selectors, implying some interoperability with existing Playwright code. However there is no explicit guidance or example showing a developer pointing an existing Playwright/Puppeteer/CDP script at Skyvern's managed browser instead of rewriting into Skyvern's task/workflow API, and no independent confirmation of this specific reuse pattern. Missing for 10: explicit BYO-script CDP endpoint docs, Puppeteer-specific support, and hands-on/community verification of dropping in existing automation code unchanged.

   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “Drop-in AI commands on top of Playwright. Use natural language to act, extract, and validate — or fall back to selectors.”
   • [claimed-docs] “you can extract structured data from any page using `page.extract` with a JSON schema, or by passing a `data_extraction_schema` to `page.age…”

   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 Skyvern
   Skyvern✓fullcommunity7/10

   Skyvern's docs explicitly describe storing credentials via password-manager vault integrations (Bitwarden, 1Password, Azure Key Vault) and automatically handling TOTP/2FA, email, and SMS verification during login flows, matching the story closely [skyvern-docs-8][skyvern-docs-26]. However, there's no independent/hands-on verification that secrets are never exposed to the LLM, and a community comment raises concern about credentials being handled in plain text, so missing for 10: independent security audit or hands-on confirmation of secret-masking from the model, and clarification addressing the community's plaintext-handling concern.

   • [claimed-docs] “Skyvern handles logins with stored credentials, TOTP/authenticator codes, email and SMS verification, magic links, and password manager inte…”
   • [claimed-docs] “Skyvern handles authentication end-to-end, from simple passwords to multi-factor flows with TOTP codes, email verification, and magic links.”
   • [community] “you are expecting them to pass over their website login credentials and apparently their credit card details too, in plain text. You had bet…”

   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 Notte
   Skyvern~partialclaimed6/10

   Skyvern's browser-sessions feature explicitly persists cookies, local storage, and open tabs across operations so 'later operations pick up exactly where the previous one stopped,' and pauses preserve browser state — this directly supports skipping repeated logins. However, the docs don't clearly describe a named 'profile' abstraction, how long sessions persist across truly separate future runs, or how these persisted sessions are managed/reused across different agents or teams. missing for 10: explicit reusable-profile management docs, long-term persistence guarantees across independent runs, independent/hands-on confirmation of skip-login behavior.

   • [claimed-docs] “Cookies, local storage, open tabs, and the current page all persist, so later operations pick up exactly where the previous one stopped.”
   • [claimed-docs] “Human-in-the-loop flows: pause for approval between steps without losing browser state. The VNC stream lets you watch or take control at any…”
   • [claimed-docs] “Skyvern handles logins with stored credentials, TOTP/authenticator codes, email and SMS verification, magic links, and password manager inte…”

   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
   Skyvern—none0/10

   No evidence describes a bulk-operation feature (e.g., running the same task across a list/CSV of items, batch triggering, or concurrent multi-item processing) — the docs focus on single-task API calls, visual workflows, and MCP integration rather than batch/bulk execution.

   ⚑ 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 drawn
   Skyvern~partialclaimed3/10

   Skyvern documents a Zapier integration, which could allow external events to trigger Skyvern workflows, but there is no evidence of a native rule/trigger engine, webhooks, or scheduled/event-based automation within Skyvern itself. Missing for 10: documented native event triggers or webhook listeners, schedule-based triggers, and any conditional rule engine inside Skyvern's workflow builder.

   • [claimed-docs] “Connect to Zapier”
   • [claimed-docs] “Build multi-step automations visually in the Cloud UI with drag-and-drop blocks. No code required. Share templates across your team.”

   proof ↗⚑ 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

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Notte
   Skyvern—none0/10

   The evidence pack describes Skyvern's workflow builder, API/SDK, MCP integration, and automation features extensively, but contains no mention of scheduling, cron triggers, or recurring job execution anywhere in the docs, GitHub description, or community discussion. Since Skyvern is a workflow/automation platform, scheduling recurring runs is a fair capability to expect, but it's simply absent from the provided evidence.

   ⚑ flag

   Notte~partialclaimed5/10

   Notte's 'Functions' feature explicitly advertises serverless automations that can be 'invoked and scheduled anywhere' (notte-docs-2, notte-docs-26), directly supporting recurring job scheduling, and workflows can be deployed as API endpoints for automation pipelines. However, there is no documentation of a scheduling UI, cron syntax, or interval/trigger configuration, and no independent confirmation that scheduled jobs work reliably in practice. Missing for 10: concrete scheduling mechanism/API docs (cron expressions, triggers), example of a recurring job configured end-to-end, and independent verification that scheduled runs execute reliably.

   • [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] “Build, debug, and deploy production workflows with cloud browsers, web agents, scraping, serverless functions, credentials, and identities i…”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Skyvern—none0/10

   No evidence in the pack describes version history, change review, or rollback capabilities for Skyvern workflows/automations — only building, running, sharing templates, and artifact capture (recordings/screenshots) are documented. Missing for 10: workflow version history, diff/review UI, rollback-to-previous-version mechanism, any changelog or audit trail for automation edits.

   ⚑ flag

   Notte—none0/10

   No evidence of versioning, review workflows, diffs, or rollback capability for automations/workflows/functions; docs mention deploying, generating and editing scripts but nothing about version history or reverting changes.

   ⚑ flag

Local

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

   weight 2 · round to Skyvern
   Skyvern~partialclaimed6/10

   Skyvern is open-source and its self-hosted docs explicitly state it 'runs entirely on your infrastructure: your servers, your browsers, your LLM API keys' (skyvern-docs-12, skyvern-docs-2), which supports running without a cloud account. However, the core SDK/browser-automation flow described elsewhere connects to a 'cloud Chromium instance over CDP' (skyvern-docs-5), suggesting the default path is cloud-based, and no local-machine dev setup details (docker/local browser config, install steps) are shown. Missing for 10: explicit local-browser dev walkthrough, confirmation that the local-first SDK path bypasses cloud Chromium, and independent hands-on confirmation of local-only operation.

   • [claimed-docs] “Self-hosted Skyvern runs entirely on your infrastructure: your servers, your browsers, your LLM API keys.”
   • [claimed-docs] “Run Skyvern on your own infrastructure with your own LLM keys.”
   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”

   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
   Skyvern—none0/10

   Skyvern documents a Python/TypeScript/REST SDK and an MCP server that plugs into Claude Desktop, Claude Code, Codex, Cursor, and Windsurf, but there is no evidence of documented adapters for Claude Agent SDK, Vercel AI SDK, LangChain, or CrewAI. missing for 10: any documented integration guide or adapter for LangChain, CrewAI, Vercel AI SDK, or Claude Agent SDK specifically.

   • [claimed-docs] “Integrate browser automation into your product with Python, TypeScript, or REST.”
   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “The Skyvern MCP server lets AI assistants like Claude Desktop, Claude Code, Codex, Cursor, and Windsurf control a browser.”

   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 Skyvern
   Skyvern~partialclaimed6/10

   Docs state self-hosted Skyvern runs with 'your own LLM API keys' on your own infrastructure, implying model-agnosticism rather than lock-in to a single vendor, but there is no explicit list of supported providers/models or first-party guide on swapping LLM backends, and no independent confirmation of multi-provider support. Missing for 10: an explicit supported-providers list/config docs, and community/hands-on evidence of using non-default LLMs.

   • [claimed-docs] “Run Skyvern on your own infrastructure with your own LLM keys.”
   • [claimed-docs] “Self-hosted Skyvern runs entirely on your infrastructure: your servers, your browsers, your LLM API keys.”

   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
   Skyvern~partialprobed5/10

   Docs confirm a hosted REST/SDK API where you submit a prompt+URL (optionally a JSON schema) and Skyvern runs the task on cloud Chromium without the caller managing a browser (skyvern-docs-1, skyvern-docs-5, skyvern-docs-18, skyvern-docs-17). However, there is no explicit documentation of a polling endpoint or webhook callback mechanism, and probes found no discoverable OpenAPI spec, so the exact result-retrieval mechanism described in the story is unconfirmed. Missing for 10: explicit webhook/callback docs, explicit polling endpoint docs, and an accessible API reference confirming these mechanics.

   • [claimed-docs] “Integrate browser automation into your product with Python, TypeScript, or REST.”
   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “You provide a natural-language prompt describing the goal, a starting URL, and optionally a JSON schema for structured output.”
   • [claimed-docs] “It navigates websites it has never seen before, filling forms, extracting data, and completing multi-step tasks via a simple API.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://skyvern.com/openapi.json, https://skyvern.com/swagger.json, https://skyvern.com/api/openapi.…”

   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 drawn
   Skyvern!disputedcontradicted5/10

   Skyvern's docs and GitHub strongly claim natural-language goal execution across novel, multi-step web flows (forms, logins, CAPTCHAs) via a single prompt/API (skyvern-docs-17, skyvern-docs-18, skyvern-gh-1), but a hands-on community test found it succeeded only on the 'happy path' and concretely failed on a real multi-step flow (costcotravel.com), struggling to hit a tab and failing to click a popup (skyvern-comm-2). This is a specific documented counter-example contradicting the 'completes multi-step task end to end' claim, not just general skepticism. Missing for 10: independent benchmark results, more hands-on trials showing consistent success on complex/unseen sites, and resolution of the reported failure case.

   • [claimed-docs] “It navigates websites it has never seen before, filling forms, extracting data, and completing multi-step tasks via a simple API.”
   • [claimed-docs] “You provide a natural-language prompt describing the goal, a starting URL, and optionally a JSON schema for structured output.”
   • [github] “Skyvern can operate on websites it's never seen before, as it's able to map visual elements to actions necessary to complete a workflow, wit…”
   • [community] “I played with the Geico example, and it seems to do a good job on the happy path. But I tried costcotravel.com... it struggled to hit the 'r…”

   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
   Skyvern~partialclaimed5/10

   Skyvern clearly supports multi-step, repeatable workflows via both a code-first SDK and a visual no-code drag-and-drop builder (skyvern-docs-5, skyvern-docs-6, skyvern-docs-22), plus SOP-to-workflow generation and a browser recorder for building reusable automations (skyvern-docs-23, skyvern-docs-24). However, the evidence never explicitly documents loop constructs, conditional branching, or parameterized workflow inputs as first-class workflow-builder features. Missing for 10: explicit documentation of loop/iteration blocks, conditional/branching logic, and named/typed workflow parameters in the workflow builder.

   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “Build multi-step automations visually in the Cloud UI with drag-and-drop blocks. No code required. Share templates across your team.”
   • [claimed-docs] “Visual workflow builder for non-developers — drag-and-drop, no code required”
   • [claimed-docs] “Browser recorder that converts manual actions into reusable automations”
   • [claimed-docs] “SOP upload — describe a process in plain English and Skyvern builds the workflow”
   • [github] “a no-code workflow builder to help both technical and non-technical users automate manual workflows on any website, replacing brittle or unr…”

   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 userDo everything through the API that I can do in the UI

   weight 2 · round to Notte
   Skyvern~partialprobed6/10

   Skyvern's docs show a strong code-first path (Python/TS/REST SDKs, page.extract, workflow creation via API) that covers most core automation tasks also available in the dashboard, and MCP/REST access is documented. However, several UI-only tooling features (drag-and-drop visual builder, browser recorder, SOP upload, copilot chat) are described only as dashboard capabilities with no documented API equivalent, and no public OpenAPI/swagger spec was discoverable to confirm full API-UI parity. Missing for 10: documented API equivalents for recorder/SOP-upload/copilot-chat features, and a discoverable OpenAPI reference confirming complete parity.

   • [claimed-docs] “Integrate browser automation into your product with Python, TypeScript, or REST.”
   • [claimed-docs] “Use the dashboard to run tasks and build agents visually.”
   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “Build multi-step automations visually in the Cloud UI with drag-and-drop blocks. No code required. Share templates across your team.”
   • [claimed-docs] “Visual workflow builder for non-developers — drag-and-drop, no code required”
   • [claimed-docs] “Browser recorder that converts manual actions into reusable automations”
   • [claimed-docs] “SOP upload — describe a process in plain English and Skyvern builds the workflow”
   • [claimed-docs] “Copilot chat for building and debugging workflows interactively”
   • [probe] “PROBE openapi: all candidate paths 404 (https://skyvern.com/openapi.json, https://skyvern.com/swagger.json, https://skyvern.com/api/openapi.…”

   proof ↗⚑ flag

   Notte~partialprobed7/10

   Notte is built API/CLI/MCP-first: sessions, scraping, agents, functions, vaults, and even live session viewing are all exposed via API/CLI/MCP endpoints (notte-docs-2, -9, -17, -24, -37, -7/-29), suggesting broad UI/API parity for an API-native product. However there's no explicit vendor statement guaranteeing full feature parity, and a probe found no discoverable OpenAPI/swagger spec (404s across common paths), which weakens confidence that every UI capability (e.g. templates, dashboard-only settings) is fully API-exposed. Missing for 10: explicit parity documentation, a public OpenAPI spec, and independent confirmation that all UI-only features (templates, dashboard views) have API equivalents.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “The Notte CLI lets AI agents control browsers through simple shell commands.”
   • [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] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [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.”
   • [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 userExport all of my data in open formats and leave

   weight 3 · round to Skyvern
   Skyvern~partialclaimed3/10

   Skyvern is open-source and self-hostable, meaning your data (artifacts, recordings, screenshots, network traffic) stays on your own infrastructure rather than being locked in a vendor's cloud, which implicitly supports data portability. However, there is no explicit documentation of a data export feature, standard open-format export (e.g., JSON/CSV bulk export of run history), or a stated 'leave with your data' workflow. Missing for 10: explicit export functionality/documentation, named open data formats, and any independent confirmation of successful data migration out of the platform.

   • [claimed-docs] “Self-hosted Skyvern runs entirely on your infrastructure: your servers, your browsers, your LLM API keys.”
   • [claimed-docs] “Every run automatically captures what happened: recordings of the browser session, screenshots at each step, the AI's reasoning, and network…”
   • [claimed-docs] “Run Skyvern on your own infrastructure with your own LLM keys.”

   proof ↗⚑ 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

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

   weight 2 · round to Notte
   Skyvern!disputedcontradicted4/10

   Skyvern is described as open-source with a GitHub repo, and probe evidence confirms it self-identifies as 'open-source' (skyvern-probe-1), but community evidence directly contradicts full open-license access, noting the project is AGPL3 licensed, which is a legally open license but is called out as a practical non-starter/restrictive for many users (skyvern-comm-3). missing for 10: explicit statement of license terms in docs, confirmation of what percentage of the product (cloud vs self-hosted) is actually open-sourced, and independent corroboration that the full source is readable without restriction.

   • [github] “Skyvern can operate on websites it's never seen before, as it's able to map visual elements to actions necessary to complete a workflow, wit…”
   • [github] “a no-code workflow builder to help both technical and non-technical users automate manual workflows on any website, replacing brittle or unr…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://skyvern.com/llms.txt # Skyvern > Skyvern is an open-source, AI-powered browser automation platform. It …”
   • [community] “Exciting stuff, my employer would be interested but it's AGPL3 licensed so it's a non-starter for them.”

   proof ↗⚑ 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

4. ai-native userSelf-host the core product

   weight 3 · round to Skyvern
   Skyvern✓fullprobed8/10

   Skyvern has a dedicated self-hosted docs page stating it 'runs entirely on your infrastructure: your servers, your browsers, your LLM API keys' (skyvern-docs-12, skyvern-docs-2), and community evidence confirms it is genuinely open-source (AGPL3) rather than just marketing language (skyvern-comm-3). Missing for 10: independent hands-on confirmation of a successful self-host deployment and clarity on how AGPL licensing affects commercial self-hosting use.

   • [claimed-docs] “Self-hosted Skyvern runs entirely on your infrastructure: your servers, your browsers, your LLM API keys.”
   • [claimed-docs] “Run Skyvern on your own infrastructure with your own LLM keys.”
   • [community] “Exciting stuff, my employer would be interested but it's AGPL3 licensed so it's a non-starter for them.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://skyvern.com/llms.txt # Skyvern > Skyvern is an open-source, AI-powered browser automation platform. It …”

   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
   Skyvern—none0/10

   The pricing page is referenced only for its target-audience blurb (skyvern-docs-13); no evidence pack item shows actual per-task or per-browser-hour rates, tiers, or documented rate/concurrency limits. Community comments only express general cost concerns ('pretty pricey', wanting cost down 'at scale') without citing concrete published pricing or limits.

   • [claimed-docs] “You're replacing brittle Selenium scripts, integrating browser automation via API, or building workflows into your product.”
   • [community] “I tried it out and it's pretty pricey. My OpenAI API bill is $3.20 after using this on a few different pages to test it out... this is alway…”
   • [community] “This is an impressive tool. I especially like the observability around the workflow and the steps it takes to achieve the outcome. We are po…”

   proof ↗⚑ 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 Skyvern
   Skyvern~partialclaimed5/10

   Skyvern offers a self-hosted deployment mode where 'your servers, your browsers, your LLM API keys' run entirely on the user's own infrastructure, which lets an AI-native user control where data resides by choosing their hosting region themselves — but this is achieved only by self-hosting, not via an explicit region/residency selector in the managed cloud product. Missing for 10: documented data residency/region options in the hosted Skyvern Cloud offering, compliance certifications, or explicit multi-region storage controls.

   • [claimed-docs] “Run Skyvern on your own infrastructure with your own LLM keys.”
   • [claimed-docs] “Self-hosted Skyvern runs entirely on your infrastructure: your servers, your browsers, your LLM API keys.”

   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 to Skyvern
   Skyvern~partialclaimed4/10

   Skyvern offers self-hosted deployment using your own infrastructure and your own LLM API keys, which implicitly lets users avoid sending data to Skyvern-controlled models/training pipelines, but there is no explicit privacy policy, data-retention statement, or 'we do not train on your data' commitment in the evidence for the hosted/cloud offering. Missing for 10: explicit no-training/data-use policy documentation, opt-out mechanism for the cloud product, and independent confirmation of data handling practices.

   • [claimed-docs] “Run Skyvern on your own infrastructure with your own LLM keys.”
   • [claimed-docs] “Self-hosted Skyvern runs entirely on your infrastructure: your servers, your browsers, your LLM API keys.”

   proof ↗⚑ 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 to Skyvern
   Skyvern~partialcommunity4/10

   Skyvern offers self-hosting (docs-2, docs-12) which gives infrastructure-level control over where data lives, and it captures artifacts (recordings, screenshots, network traffic) per run (docs-11), implying some data exists to manage, but there is no documented retention policy, data deletion API/UI, or export/purge controls for the cloud/hosted product. missing for 10: explicit data retention policy, user-facing deletion/export controls, documentation on how long artifacts/credentials are stored in cloud mode, and independent confirmation that self-hosting actually eliminates vendor-side data retention.

   • [claimed-docs] “Run Skyvern on your own infrastructure with your own LLM keys.”
   • [claimed-docs] “Self-hosted Skyvern runs entirely on your infrastructure: your servers, your browsers, your LLM API keys.”
   • [claimed-docs] “Every run automatically captures what happened: recordings of the browser session, screenshots at each step, the AI's reasoning, and network…”
   • [community] “you are expecting them to pass over their website login credentials and apparently their credit card details too, in plain text. You had bet…”

   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
   Skyvern—none0/10

   No evidence pack item discusses telemetry, usage tracking, or an opt-out mechanism; while self-hosting exists, there is no explicit statement about data collection or opt-out controls for the cloud/hosted product. missing for 10: any mention of telemetry collection, privacy policy on usage data, or an opt-out setting/flag.

   ⚑ 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 Skyvern
   Skyvern✓fullclaimed8/10

   Docs explicitly state a VNC stream lets you watch a live session and take control at any point, plus pause-for-approval human-in-the-loop flows that preserve browser state — directly matching the story. missing for 10: independent/hands-on confirmation of the live takeover UX and details on how control handoff works mid-run beyond the docs description.

   • [claimed-docs] “Human-in-the-loop flows: pause for approval between steps without losing browser state. The VNC stream lets you watch or take control at any…”
   • [claimed-docs] “Cookies, local storage, open tabs, and the current page all persist, so later operations pick up exactly where the previous one stopped.”

   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 to Skyvern
   Skyvern✓fullcommunity8/10

   Skyvern docs explicitly state every run captures session recordings, per-step screenshots, AI reasoning traces, and network traffic for debugging, and community feedback corroborates strong observability into workflow steps. missing for 10: independent hands-on verification of the video/timeline UI itself, and no mention of a true step-by-step interactive timeline scrubber beyond artifact capture.

   • [claimed-docs] “Every run automatically captures what happened: recordings of the browser session, screenshots at each step, the AI's reasoning, and network…”
   • [community] “This is an impressive tool. I especially like the observability around the workflow and the steps it takes to achieve the outcome. We are po…”

   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
   Skyvern—none0/10

   Evidence covers session persistence, VNC control, self-hosting, and SDK/API access, but nowhere documents concurrency limits, fleet-level session orchestration, or programmatic management of multiple simultaneous browser sessions. Missing for 10: documented concurrency limits, APIs for spinning up/managing many parallel sessions, and any scaling/throughput guidance.

   • [claimed-docs] “Human-in-the-loop flows: pause for approval between steps without losing browser state. The VNC stream lets you watch or take control at any…”
   • [claimed-docs] “Cookies, local storage, open tabs, and the current page all persist, so later operations pick up exactly where the previous one stopped.”
   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”
   • [claimed-docs] “Self-hosted Skyvern runs entirely on your infrastructure: your servers, your browsers, your LLM API keys.”

   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
   Skyvern—none0/10

   No evidence pack item mentions webhooks, callback URLs, or push notifications for task/session completion; the docs discuss artifacts, VNC streaming, and human-in-the-loop review but nothing about event-driven notification instead of polling. missing for 10: any documentation of webhook/callback support, event subscription API, or notification configuration.

   ⚑ 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 Skyvern
   Skyvern✓fullclaimed8/10

   Skyvern's docs give an explicit, detailed captcha stance: automatic detection and solving via its vision model for reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile, FunCaptcha, MTCaptcha, and text/image captchas, avoiding silent failure ambiguity. Missing for 10: independent/hands-on confirmation that captcha solving works reliably in practice (community evidence discusses pricing, mobile UX, and credential handling but not captcha outcomes specifically), and no documented fallback/human-in-the-loop behavior specifically tied to captcha failures.

   • [claimed-docs] “Skyvern detects CAPTCHAs using its vision model and solves them automatically. This works for reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstil…”
   • [claimed-docs] “Skyvern detects CAPTCHAs using its vision model and solves them automatically.”

   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
   Skyvern—none0/10

   No evidence in the pack of any published acceptable-use policy, terms of service, or anti-abuse statement covering CAPTCHA-solving/stealth automation features; docs describe capabilities (CAPTCHA bypass, bot bypass) but no governance/AUP language is cited. missing for 10: a published acceptable-use policy, anti-abuse terms, or statement on permitted use of stealth/CAPTCHA-bypass features.

   ⚑ 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
   Skyvern—none0/10

   Evidence covers CAPTCHA solving and authentication/2FA handling, but there is no mention anywhere of stealth fingerprinting, browser fingerprint spoofing, or residential/geo-targeted proxy support. Missing for 10: any documentation of proxy configuration, geo-targeting, or anti-fingerprinting/stealth mode features.

   • [claimed-docs] “Skyvern detects CAPTCHAs using its vision model and solves them automatically. This works for reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstil…”
   • [claimed-docs] “Skyvern detects CAPTCHAs using its vision model and solves them automatically.”

   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 Skyvern
   Skyvern✓fullclaimed7/10

   Skyvern's docs explicitly support structured, schema-based extraction via `page.extract` with a JSON schema or `data_extraction_schema` param, matching the developer's need for typed output rather than raw text (skyvern-docs-4, skyvern-docs-20, skyvern-docs-18). However, evidence only shows JSON-schema validation, not native Zod/Pydantic model binding, and there's no independent/hands-on confirmation of this specific feature. missing for 10: explicit Zod/Pydantic model integration examples, independent verification of extraction accuracy/schema enforcement.

   • [claimed-docs] “you can extract structured data from any page using `page.extract` with a JSON schema, or by passing a `data_extraction_schema` to `page.age…”
   • [claimed-docs] “you can extract structured data from any page using page.extract with a JSON schema”
   • [claimed-docs] “You provide a natural-language prompt describing the goal, a starting URL, and optionally a JSON schema for structured output.”
   • [claimed-docs] “Browser Automation is the code-first way to build multi-step automations. The Skyvern SDK connects to a cloud Chromium instance over CDP, la…”

   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 to Skyvern
   Skyvern~partialclaimed5/10

   Docs show Skyvern can log into vendor portals and download PDFs (skyvern-docs-15) and captures per-run artifacts like recordings, screenshots, and network traffic retrievable afterward (skyvern-docs-11), implying file download support, but there is no explicit documentation of file upload capability to sites, nor of a dedicated API/UI for retrieving downloaded artifacts as opposed to just run/debug artifacts. missing for 10: explicit upload-to-site capability documentation, a documented file-download/artifact storage API distinct from debugging screenshots, and independent/hands-on confirmation of file transfer working in practice.

   • [claimed-docs] “Log into vendor portals, find invoices, download PDFs.”
   • [claimed-docs] “Every run automatically captures what happened: recordings of the browser session, screenshots at each step, the AI's reasoning, and network…”
   • [claimed-docs] “Auto-fill and submit applications on Lever, Greenhouse, and more.”

   proof ↗⚑ 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