n8n vs Windmill

Agent access

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

   weight 2 · round to Windmill
   n8n✓fullprobed8/10

   Direct probe confirms n8n serves a working llms.txt at https://docs.n8n.io/llms.txt (HTTP 200) with structured links to docs, which an agent can consume directly. missing for 10: no evidence of broader agent-oriented docs formats (e.g., per-page .md siblings or an agents.json manifest) or independent confirmation that agents actually consume it successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.n8n.io/llms.txt # n8n Docs ## Get started - [n8n Docs](https://docs.n8n.io/welcome.md): Get set u…”

   proof ↗⚑ flag

   Windmill✓fullprobed9/10

   Direct probe confirms a working llms.txt at https://www.windmill.dev/llms.txt (HTTP 200) and .md-suffixed docs pages (e.g., intro.md) that return clean markdown, both hallmarks of agent-oriented documentation designed for LLM consumption. Missing for 10: no independent/community confirmation that agents actually use these successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.windmill.dev/llms.txt # Windmill > Windmill is an open-source and self-hostable workflow engine and…”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.windmill.dev/docs/intro.md # What is Windmill? > What is Windmill? An open-source workflow engine an…”

   proof ↗⚑ flag

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

   weight 2 · round to Windmill
   n8n✓fullprobed7/10

   n8n supports self-hosting via Docker/CLI and one-line install, has documented CLI configuration and command-line usage, an API, error-workflow handling for automated runs, and community reports of running it in production processing millions of workflows on small servers unattended — all consistent with headless/CI operation. missing for 10: no explicit CI/CD pipeline integration guide (e.g., GitHub Actions example) or dedicated 'headless mode' doc, and no independent benchmark of unattended reliability at scale beyond anecdotal community reports.

   • [claimed-docs] “Use the command line”
   • [probe] “official CLI documented at https://docs.n8n.io/deploy/host-n8n/configure-n8n/use-the-command-line”
   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [github] “curl -fsSL https://get.n8n.io | sh”
   • [claimed-docs] “n8n API”
   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “N8N is an amazing system. I use it daily and have seen incredible progress made consistently over the past few years. Currently my team use …”
   • [community] “We're using n8n in production for a month now and are pretty happy with it. Easily extendable and new integrations can be built easily.”

   proof ↗⚑ flag

   Windmill✓fullprobed8/10

   Windmill provides a documented CLI (wmill) for deploying and syncing from Git, supports webhooks/schedules/API triggers for headless execution, and can self-host via Docker/Kubernetes for CI pipelines — all strongly supporting headless/CI automation use. Missing for 10: independent hands-on CI-pipeline examples or third-party corroboration of the CLI/webhook flow working seamlessly in a CI system beyond vendor docs.

   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”
   • [claimed-docs] “Each time an item is deployed, Windmill will create and push a commit to the specified repository. ... Windmill can automatically deploy new…”
   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “Flows additionally expose version-pinned webhook endpoints that target a specific flow version by its numeric version ID instead of the late…”
   • [claimed-docs] “For small setups, use Docker and Docker Compose on a single instance. For larger and production use-cases, use our Helm chart to deploy on K…”
   • [probe] “official CLI documented at https://www.windmill.dev/docs/advanced/cli”

   proof ↗⚑ flag

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

   weight 3 · round to n8n
   n8n✓fullprobed8/10

   n8n ships a documented built-in MCP Client node (n8n-nodes-langchain.mcpclient) that lets a workflow/agent connect to external MCP servers and use their tools, alongside an MCP Server Trigger for the reverse role, confirming first-party MCP client support. This is corroborated by an official docs page and probe confirmation. Missing for 10: independent hands-on community reports specifically validating the MCP Client node's tool-use in practice (community evidence is general n8n sentiment, not MCP-specific).

   • [claimed-docs] “MCP Client”
   • [claimed-docs] “MCP Server Trigger”
   • [probe] “official MCP server documented at https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger”

   proof ↗⚑ flag

   Windmill—none0/10

   Windmill's MCP documentation (windmill-docs-17, windmill-probe-4) describes Windmill acting as an MCP *server* so external LLM clients (Claude, Cursor) can call Windmill's scripts/flows — the reverse of the story, which asks whether Windmill can consume/plug into external MCP servers to use their tools. The AI Agent steps (windmill-docs-20) mention connecting to AI providers/models, not MCP tool servers, so no evidence shows Windmill as an MCP client.

   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”
   • [probe] “official MCP server documented at https://www.windmill.dev/docs/core_concepts/mcp”
   • [claimed-docs] “AI Agents steps allow you to integrate AI agents directly into your Windmill flows. They provide an interface to connect with various AI pro…”

   proof ↗⚑ flag

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

   weight 3 · round to Windmill
   n8n✓fullprobed7/10

   n8n ships an official MCP Server Trigger node (n8n-nodes-langchain.mcpTrigger) that lets external AI agents connect to n8n workflows via MCP, confirmed by docs and a probe hit; it also has a complementary MCP Client node for consuming other MCP servers. Missing for 10: independent/hands-on community confirmation of the MCP server trigger working in practice, and more detail on setup/auth specifics beyond the doc page title.

   • [claimed-docs] “MCP Server Trigger”
   • [probe] “official MCP server documented at https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger”
   • [claimed-docs] “MCP Client”

   proof ↗⚑ flag

   Windmill✓fullprobed8/10

   Windmill is a workflow/automation platform (not an agent), so publishing an official MCP server is squarely within its category, and docs confirm it: 'With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your scripts and flows from your client chat,' corroborated by a probe confirming the official MCP docs page. missing for 10: independent/hands-on confirmation of the MCP server working in practice beyond first-party docs.

   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”
   • [probe] “official MCP server documented at https://www.windmill.dev/docs/core_concepts/mcp”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Windmill
   n8n~partialprobed6/10

   n8n documents an official command-line interface for configuring and managing self-hosted instances (n8n-docs-17, n8n-probe-4), which is a genuine first-party CLI. However, this CLI is oriented toward deployment/configuration tasks rather than AI-native agentic workflows (e.g., no evidence of CLI-driven workflow creation/execution for AI agents, no scripting API for agent orchestration via CLI). Missing for 10: evidence of AI-native/agent-oriented CLI use cases, independent hands-on corroboration of the CLI, and any agent-facing CLI commands beyond basic server configuration.

   • [claimed-docs] “Use the command line”
   • [probe] “official CLI documented at https://docs.n8n.io/deploy/host-n8n/configure-n8n/use-the-command-line”

   proof ↗⚑ flag

   Windmill✓fullprobed8/10

   Windmill ships an official CLI (`wmill`) documented for interacting with instances from the terminal, deploying from Git repos, and syncing commits—confirmed by both docs and a dedicated probe. This directly satisfies the 'official CLI' story for AI-native/agentic workflows (e.g., scripting deployments, CI integration). Missing for 10: independent hands-on community reports specifically validating the CLI's AI-native usage patterns (e.g., agent-driven CLI invocation) beyond first-party docs.

   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”
   • [claimed-docs] “Each time an item is deployed, Windmill will create and push a commit to the specified repository. ... Windmill can automatically deploy new…”
   • [probe] “official CLI documented at https://www.windmill.dev/docs/advanced/cli”

   proof ↗⚑ flag

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

   weight 3 · round to n8n
   n8n~partialprobed6/10

   n8n documents a dedicated public REST API (n8n-docs-16 'n8n API') for programmatic control, which supports AI-native/agentic driving of the product beyond the UI. However, evidence is limited to a single doc title with no detail on endpoints/auth, and probes for an OpenAPI/swagger spec at expected paths all 404'd, weakening confidence in completeness or discoverability. Missing for 10: detailed API reference content, machine-readable OpenAPI spec, and independent/hands-on developer confirmation of using the API.

   • [claimed-docs] “n8n API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.n8n.io/openapi.json, https://docs.n8n.io/swagger.json, https://docs.n8n.io/api/openapi.…”

   proof ↗⚑ flag

   Windmill~partialprobed5/10

   Windmill exposes a CLI (wmill), webhooks, and various trigger mechanisms (HTTP routes, schedules, MCP) that let external systems and AI agents drive it (windmill-docs-9, windmill-docs-15, windmill-docs-16, windmill-docs-17, windmill-probe-4, windmill-probe-5), which is real evidence of programmatic/agentic control. However, a direct probe for a documented public REST/OpenAPI spec (the canonical 'documented public API') returned 404 on all candidate paths (windmill-probe-3), so no first-class API reference doc was found in evidence. missing for 10: a discoverable OpenAPI/REST API reference page, independent confirmation that third parties integrate via a general public API beyond webhooks/CLI/MCP.

   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”
   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “Flows additionally expose version-pinned webhook endpoints that target a specific flow version by its numeric version ID instead of the late…”
   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.windmill.dev/openapi.json, https://www.windmill.dev/swagger.json, https://www.windmill.d…”
   • [probe] “official MCP server documented at https://www.windmill.dev/docs/core_concepts/mcp”
   • [probe] “official CLI documented at https://www.windmill.dev/docs/advanced/cli”

   proof ↗⚑ flag

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

   weight 2 · round to Windmill
   n8n~partialclaimed4/10

   n8n exposes a credentials system for per-integration secrets and a general n8n API, plus role-based access control and audit trails per the GitHub description, which are building blocks for limiting what an agent can access. However there is no evidence of a mechanism to issue scoped or least-privilege API keys/credentials specifically for an AI agent's use (e.g., read-only, node-restricted, or agent-specific tokens). Missing for 10: documentation of scoped API key creation, granular per-agent credential permissions, and independent confirmation that credential scoping actually restricts agent tool access.

   • [claimed-docs] “Credentials | Nodes | n8n Docs”
   • [claimed-docs] “n8n API”
   • [github] “Self-host or deploy securely with role-based access, audit trails, and support for sensitive data”
   • [claimed-docs] “Admin roles”

   proof ↗⚑ flag

   Windmill~partialprobed6/10

   Windmill documents scoped tokens following least-privilege principles (windmill-docs-8) and an underlying roles/permissions system (windmill-docs-7), and its MCP server for connecting agents (windmill-docs-17, windmill-probe-4) implies token-based auth for agent connections. However, there's no explicit documentation tying scoped token creation specifically to AI agent use-cases or showing a workflow for issuing/rotating agent-specific credentials. Missing for 10: explicit docs on generating scoped tokens specifically for AI agents/MCP clients, examples of scope granularity, and independent/hands-on confirmation that scoping works as claimed.

   • [claimed-docs] “Tokens can be scoped to restrict access to specific resources and actions, following the principle of least privilege.”
   • [claimed-docs] “Windmill provides a roles and permissions system that allows you to control access and manage permissions within your instance and workspace…”
   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”
   • [probe] “official MCP server documented at https://www.windmill.dev/docs/core_concepts/mcp”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to n8n
   n8n~partialclaimed3/10

   n8n documents a public REST API (n8n-docs-16) that developers could build against, but there is no evidence of dedicated, officially maintained SDK packages (e.g., Python/Node client libraries) or SDK-specific quickstart docs — the API reference is the only artifact resembling programmatic access. missing for 10: official language SDKs (Python/JS/Go), SDK reference docs, SDK usage examples, and independent confirmation of SDK adoption.

   • [claimed-docs] “n8n API”

   proof ↗⚑ flag

   Windmill—none0/10

   The evidence pack documents a CLI (wmill), an MCP server, and workflows-as-code in TypeScript/Python, but none of it describes official client SDKs/libraries for programmatically building against Windmill's API. A probe for an OpenAPI spec (often paired with SDK generation) returned 404s, further suggesting no discoverable official SDK artifact.

   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”
   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.windmill.dev/openapi.json, https://www.windmill.dev/swagger.json, https://www.windmill.d…”
   • [probe] “official CLI documented at https://www.windmill.dev/docs/advanced/cli”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to n8n
   n8n✓fullprobed8/10

   n8n has a first-party Webhook trigger node (n8n-docs-21) that lets workflows (including AI agents) subscribe to and react to incoming HTTP events, plus an MCP Server Trigger (n8n-docs-19, n8n-probe-3) that exposes workflows as callable/event-driven endpoints for AI agent ecosystems. Community evidence corroborates real-world use of webhook-initiated workflows in production (n8n-comm-18). Missing for 10: independent hands-on verification specifically of webhook subscription reliability/latency and richer documentation on webhook authentication/security nuances.

   • [claimed-docs] “Webhook | Nodes | n8n Docs”
   • [claimed-docs] “MCP Server Trigger”
   • [probe] “official MCP server documented at https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Windmill~partialclaimed5/10

   Windmill documents webhooks extensively as a trigger mechanism—scripts and flows can be invoked via webhook endpoints, including version-pinned endpoints for specific flow versions—which lets external systems call into Windmill (windmill-docs-15, windmill-docs-16). However, this is primarily inbound triggering rather than an outbound event-subscription model where Windmill pushes notifications about internal events (e.g., job completion, failures) to a subscriber's webhook URL. Missing for 10: explicit documentation of outbound webhook subscriptions/event notifications, independent confirmation of an event-driven push webhook system, and any first-party mention of 'subscribe' semantics rather than pure trigger endpoints.

   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “Flows additionally expose version-pinned webhook endpoints that target a specific flow version by its numeric version ID instead of the late…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to n8n
   n8n~partialclaimed6/10

   n8n's AI agent nodes and templates explicitly support generating insights from data (e.g. 'Sales can Generate customer insights from reviews', 'Sec Ops can Enrich security incident tickets', 'What agents do' docs) by connecting LLMs to a user's own data sources. However this is delivered via user-built workflows rather than a native, out-of-the-box insights/suggestions feature, and there's no independent/hands-on evidence confirming this specific use case works well in practice. Missing for 10: first-party deep documentation of an insights-generation workflow end-to-end, and community/hands-on corroboration of AI-generated insights specifically (only generic AI-workflow templates are cited).

   • [claimed-docs] “Sales can Generate customer insights from reviews”
   • [claimed-docs] “Sec Ops can Enrich security incident tickets”
   • [claimed-docs] “What agents do”
   • [github] “Build and operationalize AI workflows and multi-step agents using your own data, models, and tools”
   • [github] “Connect to OpenAI, Anthropic, Google, or open-source models and switch providers without changing your architecture”

   proof ↗⚑ flag

   Windmill~partialclaimed4/10

   Windmill offers AI Agent steps that let users wire LLM calls into flows to process data, and an MCP server/AI-generation feature for building scripts, but these are developer-facing building blocks rather than a built-in 'insights and suggestions from my data' feature (e.g., no dashboard/analytics AI surfaced automatically on stored data). Missing for 10: evidence of an out-of-the-box AI analytics/insights UI, proactive suggestions surfaced to end users without building a flow, and any independent corroboration of this specific use case.

   • [claimed-docs] “AI Agents steps allow you to integrate AI agents directly into your Windmill flows. They provide an interface to connect with various AI pro…”
   • [claimed-docs] “Review and deploy changes: Once the AI has edited items, ask it to review the changes and it opens the Compare & Deploy page with exactly th…”
   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   n8n✓fullcommunity8/10

   n8n's core product is workflow automation triggered by webhooks/schedules that execute unattended, with error-handling workflows, execution history/search, and self-hosted/cloud deployment for always-on background operation; community evidence corroborates long-running, hands-off use (processing millions of workflows on a small server for years, following subreddits and sending notifications automatically, running in production for months). Missing for 10: an explicit dedicated schedule-trigger doc citation and independent uptime/reliability benchmarking for long-running autonomous agents.

   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [claimed-docs] “Webhook | Nodes | n8n Docs”
   • [claimed-docs] “Execution search”
   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [community] “N8N is an amazing system. I use it daily and have seen incredible progress made consistently over the past few years. Currently my team use …”
   • [community] “I use it to follow subreddits, scrape posts, analyze based on arbitrary criteria, note the findings in a spreadsheet, then send a notificati…”
   • [community] “We're using n8n in production for a month now and are pretty happy with it. Easily extendable and new integrations can be built easily.”
   • [claimed-docs] “What agents do”

   proof ↗⚑ flag

   Windmill✓fullcommunity8/10

   Windmill natively supports scheduling scripts/flows via CRON with error/recovery handlers, plus a wide range of autonomous triggers (webhooks, queues, events, routes) that run in the background without manual intervention, and flows include retries, branching, and error handling for resilient unattended execution. This directly matches the AI-native automation story, reinforced by AI Agent steps that can be embedded into these autonomous flows. Missing for 10: no independent/hands-on evidence confirming long-running autonomous reliability at scale, and community comments raise open questions about error handling rather than confirming it in practice.

   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”
   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [claimed-docs] “Branches allow to split the execution of the flow based on a condition. ... Branch all: all the branches will be executed.”
   • [claimed-docs] “A script or flow can return a top-level `wm_failure` field (string) to retag the run as a failure even though the runtime did not raise an e…”
   • [claimed-docs] “AI Agents steps allow you to integrate AI agents directly into your Windmill flows. They provide an interface to connect with various AI pro…”
   • [community] “This looks really cool. Is there error handling? For example, if the email sending fails for some reason can I either select the flow to con…”

   proof ↗⚑ flag

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

   weight 3 · round to Windmill
   n8n—none0/10

   The evidence shows n8n lets users build AI agent workflows (nodes, LangChain integration, model connections) but none of it describes a built-in AI assistant inside the n8n product itself that a user can delegate tasks to (e.g., an in-app copilot for building/debugging workflows). All AI-agent references describe automations the user builds, not an assistant serving the user.

   ⚑ flag

   Windmill~partialclaimed6/10

   Windmill's docs describe an in-product AI generation feature that can edit scripts/flows and then prompts the user to review and deploy those changes, indicating a built-in assistant users can delegate authoring tasks to (windmill-docs-21). However, evidence is thin on the assistant's scope, limitations, or independent hands-on validation, and separate 'AI Agents' flow steps (windmill-docs-20) are for building agentic workflows rather than being the assistant itself. Missing for 10: independent/community corroboration of the AI assistant's real-world reliability, more detail on what tasks it can handle end-to-end, and comparison to failure cases.

   • [claimed-docs] “Review and deploy changes: Once the AI has edited items, ask it to review the changes and it opens the Compare & Deploy page with exactly th…”
   • [claimed-docs] “AI Agents steps allow you to integrate AI agents directly into your Windmill flows. They provide an interface to connect with various AI pro…”

   proof ↗⚑ flag

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

   weight 2 · round to Windmill
   n8n—none0/10

   The evidence shows n8n lets users build AI agents and convert natural language into API calls *as workflow outputs*, but there is no evidence of a natural-language interface for operating n8n itself (e.g., a chat-to-build-workflow assistant or NL command console). missing for 10: evidence of a prompt-driven workflow builder or NL command interface for controlling n8n's canvas/actions.

   • [claimed-docs] “What agents do”
   • [claimed-docs] “Dev Ops can Convert natural language into API calls”
   • [claimed-docs] “Build visually, go deep with code, connect to anything.”

   proof ↗⚑ flag

   Windmill~partialprobed6/10

   Windmill documents an MCP server that lets LLM clients trigger scripts/flows via natural-language chat (windmill-docs-17, windmill-probe-4) and an AI-generation feature where a user can ask the AI to edit and review flow/script changes (windmill-docs-21), showing real natural-language operability. However, evidence is thin—just two doc snippets—with no independent/hands-on corroboration of reliability or scope of NL commands. Missing for 10: hands-on/community validation of NL-driven operation, fuller documentation of what natural-language commands can accomplish beyond triggering and editing.

   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”
   • [claimed-docs] “Review and deploy changes: Once the AI has edited items, ask it to review the changes and it opens the Compare & Deploy page with exactly th…”
   • [probe] “official MCP server documented at https://www.windmill.dev/docs/core_concepts/mcp”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   n8n—none0/10

   n8n documents a REST API (n8n-docs-16) but there is no evidence of an interactive, runnable API reference (e.g., Swagger/OpenAPI explorer); a direct probe for OpenAPI/Swagger specs returned 404 on all candidate paths, indicating no such interactive reference is exposed.

   • [claimed-docs] “n8n API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.n8n.io/openapi.json, https://docs.n8n.io/swagger.json, https://docs.n8n.io/api/openapi.…”

   proof ↗⚑ flag

   Windmill—none0/10

   The evidence pack shows an explicit probe for an OpenAPI/Swagger interactive reference that returned 404 on all candidate paths, and no other citation describes an interactive API reference with runnable examples (docs pages are static markdown/CLI/MCP references, not a runnable API explorer).

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.windmill.dev/openapi.json, https://www.windmill.dev/swagger.json, https://www.windmill.d…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   n8n—none0/10

   While n8n documents a REST API (n8n-docs-16), the evidence pack contains an explicit probe showing all standard OpenAPI/Swagger spec paths returning 404 (n8n-probe-2), and no other citation shows a downloadable machine-readable spec for n8n's API. No evidence of an OpenAPI/Swagger JSON export exists.

   • [claimed-docs] “n8n API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.n8n.io/openapi.json, https://docs.n8n.io/swagger.json, https://docs.n8n.io/api/openapi.…”

   proof ↗⚑ flag

   Windmill—none0/10

   Windmill exposes a CLI and API-driven platform, so a downloadable OpenAPI spec is a fair ask, but the evidence pack explicitly shows a probe attempt failing to find any OpenAPI/swagger file at standard paths (all 404s), and no docs page links to a machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.windmill.dev/openapi.json, https://www.windmill.dev/swagger.json, https://www.windmill.d…”

   proof ↗⚑ flag

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

   weight 1 · round to n8n
   n8n~partialclaimed3/10

   n8n's source-control/environments feature (n8n-docs-22, n8n-docs-7) implies the ability to maintain separate dev/staging/production n8n instances synced via Git, which could support sandbox testing without touching production data, but the evidence pack gives only page titles with no detail on how isolation, test data, or non-production execution actually works. missing for 10: explicit documentation of a sandbox/staging execution mode, test-vs-production webhook isolation, or first-party guidance on testing without affecting live data.

   • [claimed-docs] “Push and pull changes”
   • [claimed-docs] “Version control using Git”

   proof ↗⚑ flag

   Windmill—none0/10

   The evidence pack covers Windmill's languages, orchestration, permissions, CLI, git sync, and MCP integration, but nowhere documents a dedicated sandbox/staging workspace or test-mode that isolates execution from production data; a community comment even raises this exact question (non-destructive branch testing) without an answered example.

   • [community] “My first questions with any new tool of this kind: Can I run/validate branch versions non-destructively as part of pre-merge checks? Can I r…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   n8n—none0/10

   n8n publishes an API (n8n-docs-16) but the evidence pack contains no documentation of API versioning scheme or a deprecation policy, and a probe for an OpenAPI spec returned 404s across all candidate paths (n8n-probe-2), indicating no discoverable versioned/spec-documented API contract.

   • [claimed-docs] “n8n API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.n8n.io/openapi.json, https://docs.n8n.io/swagger.json, https://docs.n8n.io/api/openapi.…”

   proof ↗⚑ flag

   Windmill—none0/10

   Windmill exposes webhooks and version-pinned flow endpoints (windmill-docs-16), and a CLI/API surface exists, but there is no evidence of a documented API versioning scheme or deprecation policy; OpenAPI spec probes returned 404s (windmill-probe-3) and no docs mention deprecation practices.

   • [claimed-docs] “Flows additionally expose version-pinned webhook endpoints that target a specific flow version by its numeric version ID instead of the late…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.windmill.dev/openapi.json, https://www.windmill.dev/swagger.json, https://www.windmill.d…”

   proof ↗⚑ flag

Agent integration

1. ai-native userHave an agent create, update, and activate a workflow programmatically through the public API

   weight 2 · round to Windmill
   n8n~partialclaimed3/10

   n8n's docs reference a dedicated 'n8n API' page confirming a public API exists, which is consistent with programmatic workflow management, but the evidence pack gives no detail on specific create/update/activate endpoints, authentication, or examples of an agent invoking them. Missing for 10: documented API endpoints for workflow create/update/activate, example agent-driven API calls, and independent/community confirmation the API works as described.

   • [claimed-docs] “n8n API”

   proof ↗⚑ flag

   Windmill~partialprobed5/10

   Windmill exposes multiple programmatic paths (CLI `wmill`, git-sync auto-deploy, version-pinned webhooks, and an MCP server that lets LLM clients trigger scripts/flows) that together suggest an agent could manage workflows without the UI, and AI-generation docs show agents can edit items and reach a deploy step. However, the story specifically requires create/update/activate via the public API, and the evidence never surfaces a documented REST/OpenAPI spec (the openapi.json probe 404'd on all candidate paths) nor confirms MCP or CLI can create/activate flows rather than just trigger existing ones. missing for 10: explicit public API/OpenAPI docs for flow CRUD, confirmation that agent-driven creation/activation (not just triggering) works end-to-end without human deploy step.

   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”
   • [claimed-docs] “Each time an item is deployed, Windmill will create and push a commit to the specified repository. ... Windmill can automatically deploy new…”
   • [claimed-docs] “Flows additionally expose version-pinned webhook endpoints that target a specific flow version by its numeric version ID instead of the late…”
   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”
   • [claimed-docs] “Review and deploy changes: Once the AI has edited items, ask it to review the changes and it opens the Compare & Deploy page with exactly th…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.windmill.dev/openapi.json, https://www.windmill.dev/swagger.json, https://www.windmill.d…”
   • [probe] “official MCP server documented at https://www.windmill.dev/docs/core_concepts/mcp”
   • [probe] “official CLI documented at https://www.windmill.dev/docs/advanced/cli”

   proof ↗⚑ flag

2. ai-native userExpose my workflows or connected app actions as MCP tools that an external agent can call

   weight 3 · round drawn
   n8n✓fullprobed8/10

   n8n ships a documented MCP Server Trigger node that exposes a workflow as an MCP server tool callable by external agents, alongside a separate MCP Client node for consuming external MCP servers — directly matching the story of exposing workflows/app actions as MCP tools. This is corroborated by a probe confirming the docs page exists, but there's no independent/hands-on community report validating real-world use of the MCP Server Trigger specifically. Missing for 10: independent/community corroboration of the MCP server trigger in practice, and more detail on auth/security when exposing tools externally.

   • [claimed-docs] “MCP Server Trigger”
   • [claimed-docs] “MCP Client”
   • [probe] “official MCP server documented at https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger”

   proof ↗⚑ flag

   Windmill✓fullprobed8/10

   Windmill has documented, first-party MCP server support that exposes scripts/flows as tools callable by external MCP-compatible agents (Claude, Cursor, etc.), directly matching the story. missing for 10: independent/hands-on confirmation of the MCP feature working, and more detail on scoping which specific workflows/actions are exposed as tools.

   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”
   • [probe] “official MCP server documented at https://www.windmill.dev/docs/core_concepts/mcp”

   proof ↗⚑ flag

Ai authoring

1. ai-native userGenerate or edit a workflow from a natural-language prompt

   weight 2 · round to Windmill
   n8n—none0/10

   The evidence pack covers n8n's visual/code building, AI agent nodes, MCP support, and integrations, but contains no documentation of a natural-language-to-workflow generation or editing feature (e.g., an 'AI workflow builder' or prompt-based canvas editing). n8n-docs-26 only describes a workflow that converts natural language into API calls as a use case, not n8n generating/editing the workflow itself from a prompt.

   • [claimed-docs] “Dev Ops can Convert natural language into API calls”
   • [claimed-docs] “What agents do”
   • [claimed-docs] “Build visually, go deep with code, connect to anything.”

   proof ↗⚑ flag

   Windmill~partialclaimed6/10

   windmill-docs-21 explicitly documents AI-driven editing of scripts/flows/apps followed by a review-and-deploy step, and windmill-docs-20 shows AI agent steps can be embedded in flows, indicating genuine natural-language generation/editing support. However, evidence is purely first-party docs with no independent/hands-on corroboration of prompt-to-workflow quality or reliability. Missing for 10: independent/community validation of AI-generated flow quality, details on scope/limits of NL-to-workflow generation, and confirmation this works for full flow creation (not just editing existing items).

   • [claimed-docs] “Review and deploy changes: Once the AI has edited items, ask it to review the changes and it opens the Compare & Deploy page with exactly th…”
   • [claimed-docs] “AI Agents steps allow you to integrate AI agents directly into your Windmill flows. They provide an interface to connect with various AI pro…”

   proof ↗⚑ flag

Ai steps

1. ai-native userAdd AI agent or LLM steps inside a workflow, with model choice and tool use

   weight 3 · round drawn
   n8n✓fullcommunity8/10

   n8n has dedicated AI agent building blocks (docs on 'What agents do', LangChain-based nodes, MCP client/trigger), explicit model choice across OpenAI/Anthropic/Google/open-source providers, and tool use via integrations/credentials plus code nodes for advanced logic. This is corroborated by both first-party docs/GitHub claims and independent community use of n8n for AI workflows. Missing for 10: deeper hands-on independent verification of multi-agent orchestration quality and tool-calling reliability beyond marketing/docs claims.

   • [claimed-docs] “What agents do”
   • [github] “Connect to OpenAI, Anthropic, Google, or open-source models and switch providers without changing your architecture”
   • [github] “Model Flexibility, No Lock-In: Connect to OpenAI, Anthropic, Google, or open-source models and switch providers without changing your archit…”
   • [github] “Build and operationalize AI workflows and multi-step agents using your own data, models, and tools”
   • [claimed-docs] “MCP Server Trigger”
   • [claimed-docs] “MCP Client”
   • [claimed-docs] “OpenAI, the creator of ChatGPT, offers a range of powerful models including GPT-3, DALL·E, and Whisper. Leverage these models to build AI-po…”
   • [claimed-docs] “The Anthropic app, built by the creators of Claude, is an AI chat interface that allows users to interact with Claude models for tasks like …”
   • [claimed-docs] “Google Gemini is an AI assistant app that answers questions, summarizes content, and generates text, images, and short videos. It supports v…”
   • [community] “I use it to follow subreddits, scrape posts, analyze based on arbitrary criteria, note the findings in a spreadsheet, then send a notificati…”

   proof ↗⚑ flag

   Windmill✓fullclaimed8/10

   Windmill has documented AI Agent steps that integrate directly into flows, connecting to various AI providers/models and supporting tool use within the workflow orchestration engine (windmill-docs-20). This directly matches the story of adding LLM/agent steps with model choice and tool use inside a workflow. Missing for 10: independent/hands-on corroboration of tool-use behavior and broader detail on model selection UX beyond the single docs page.

   • [claimed-docs] “AI Agents steps allow you to integrate AI agents directly into your Windmill flows. They provide an interface to connect with various AI pro…”

   proof ↗⚑ flag

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

   weight 2 · round to Windmill
   n8n~partialcommunity4/10

   n8n's workflow engine inherently processes arrays of items and community evidence shows real-world use at high volume ("processing millions of workflows each year on a very small server"), implying capacity for bulk-scale automation, but the evidence pack contains no explicit documentation of batch/loop/bulk-item processing features (e.g., Split-in-Batches, item-array iteration) as a distinct capability. Missing for 10: explicit docs on batch-processing nodes or bulk-item iteration, first-party guidance on handling large item sets, and independent confirmation of bulk-operation reliability at scale.

   • [community] “N8N is an amazing system. I use it daily and have seen incredible progress made consistently over the past few years. Currently my team use …”
   • [community] “I use it to follow subreddits, scrape posts, analyze based on arbitrary criteria, note the findings in a spreadsheet, then send a notificati…”
   • [claimed-docs] “Build visually, go deep with code, connect to anything.”

   proof ↗⚑ flag

   Windmill~partialclaimed5/10

   Windmill's flows support parallelism, branching, and fault-tolerant orchestration (windmill-docs-5, windmill-docs-12), which implies capability to iterate/process many items in a flow, but no evidence explicitly documents a for-loop/bulk-iteration step, batch processing UI, or examples of running an operation across a large item set. missing for 10: explicit for-loop/iterator flow step documentation, evidence of scaling to large item counts, and any hands-on confirmation of bulk operation performance.

   • [claimed-docs] “Workflows as code let you define orchestration logic directly in TypeScript or Python, using familiar language constructs like functions, co…”
   • [claimed-docs] “Branches allow to split the execution of the flow based on a condition. ... Branch all: all the branches will be executed.”
   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   n8n✓fullcommunity8/10

   n8n natively supports event-based triggers (Webhook, MCP Server Trigger, scheduled triggers) that fire workflows/actions automatically, plus error-handling workflows for reacting to execution events, directly matching rule-based automation on events. Community evidence corroborates real production use for automated multi-step workflows triggered by webhooks/schedules. missing for 10: no independent benchmark of complex conditional 'if X then Y' rule engines beyond trigger nodes, and no deeper docs on rule-composition beyond triggers/IF nodes.

   • [claimed-docs] “Webhook | Nodes | n8n Docs”
   • [claimed-docs] “MCP Server Trigger”
   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”
   • [community] “I use it to follow subreddits, scrape posts, analyze based on arbitrary criteria, note the findings in a spreadsheet, then send a notificati…”

   proof ↗⚑ flag

   Windmill✓fullcommunity8/10

   Windmill lets users define scripts/flows triggered automatically by schedules (CRON), webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, and other event sources, with retry/error handling and branching logic for rule-based automation. This directly matches the story of defining rules that trigger actions on events, with strong first-party documentation. Missing for 10: independent/hands-on verification of complex event-rule chains and no community corroboration specifically confirming event-trigger reliability in production.

   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”
   • [claimed-docs] “Flows additionally expose version-pinned webhook endpoints that target a specific flow version by its numeric version ID instead of the late…”
   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [claimed-docs] “Branches allow to split the execution of the flow based on a condition. ... Branch all: all the branches will be executed.”
   • [community] “This looks really cool. Is there error handling? For example, if the email sending fails for some reason can I either select the flow to con…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Windmill
   n8n~partialcommunity5/10

   The pack lacks any first-party documentation citation for a dedicated Schedule/Cron trigger node, but a hands-on community report confirms real production use of n8n for 'scheduled and webhook-initiated tasks' (n8n-comm-18), indicating the capability exists and works. Missing for 10: official docs reference to the Schedule Trigger/Cron node, details on interval/cron expression configuration, and independent verification beyond a single community anecdote.

   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Windmill✓fullclaimed9/10

   Windmill has a dedicated Scheduling core concept supporting CRON-based recurring execution of scripts/flows with error/recovery handlers, plus flexible triggers (webhooks, events, etc.) and retries/branching for robust workflows, all documented first-party. missing for 10: no independent/hands-on community confirmation specifically of scheduling reliability in production.

   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”
   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [claimed-docs] “Branches allow to split the execution of the flow based on a condition. ... Branch all: all the branches will be executed.”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   n8n~partialcommunity6/10

   n8n documents Git-based source control ("Version control using Git", "Push and pull changes") and execution history/search that lets users review past runs (n8n-docs-7, n8n-docs-22, n8n-docs-9), and community evidence confirms execution history is retained for debugging (n8n-comm-8). However, Git-based version control appears to be a paid/enterprise pricing-page feature rather than a built-in community capability, and there is no explicit documentation of a one-click 'rollback' mechanism for workflows beyond manually reverting via Git. Missing for 10: explicit rollback/restore workflow feature, confirmation that version control is available outside paid tiers, and independent hands-on confirmation of the review/rollback workflow.

   • [claimed-docs] “Version control using Git”
   • [claimed-docs] “Push and pull changes”
   • [claimed-docs] “Execution search”
   • [community] “I have written some stuff with n8n and I think it is better than most no code platforms because it's debuggable. It keeps all the historical…”

   proof ↗⚑ flag

   Windmill~partialclaimed6/10

   Windmill documents versioning via Git sync (each deploy creates a commit, auto-deploy from repo) and version-pinned webhook endpoints for flows, plus a 'Compare & Deploy' review UI when AI edits items. However, there is no explicit rollback feature or UI documented (e.g., one-click revert to a prior version), and no independent/hands-on confirmation of rollback behavior. missing for 10: explicit rollback/revert mechanism, independent verification of version history UI and rollback workflow.

   • [claimed-docs] “Each time an item is deployed, Windmill will create and push a commit to the specified repository. ... Windmill can automatically deploy new…”
   • [claimed-docs] “Flows additionally expose version-pinned webhook endpoints that target a specific flow version by its numeric version ID instead of the late…”
   • [claimed-docs] “Review and deploy changes: Once the AI has edited items, ask it to review the changes and it opens the Compare & Deploy page with exactly th…”
   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”

   proof ↗⚑ flag

Code steps

1. developerDrop into real code (JavaScript or Python) as a step inside a workflow

   weight 3 · round to Windmill
   n8n✓fullcommunity8/10

   n8n explicitly ships a Code node supporting JavaScript and Python (with npm packages) as a workflow step, confirmed by both vendor docs/GitHub (n8n-gh-1, n8n-gh-6, n8n-docs-1) and independent hands-on community feedback confirming custom JS/Python code blocks exist (n8n-comm-6). Missing for 10: deeper first-party documentation of the Code node itself (execution modes, sandboxing) and resolution of the community-noted limitation on importing external libraries.

   • [github] “Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [github] “Code When You Need It: Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [claimed-docs] “Build visually, go deep with code, connect to anything.”
   • [claimed-docs] “Build visually, go deep with code, connect to anything. Every step of your agents' reasoning, traceable on the canvas.”
   • [community] “N8n looks quite polished and seems primarily concerned about connecting pre-made blocks. There are custom code blocks (JS and Python only, w…”

   proof ↗⚑ flag

   Windmill✓fullcommunity9/10

   Windmill's core model is scripts written in real code (TypeScript, Python, Go, etc.) composed into flows, with 'workflows as code' letting developers write orchestration logic directly in TypeScript/Python using native functions, conditionals, and loops as flow steps. This is corroborated by GitHub docs describing scripts being composed into flows, and community discussion confirms multi-language script support. Missing for 10: independent hands-on verification beyond community anecdotes and no mention of limitations in language runtime sandboxing raised by a commenter.

   • [claimed-docs] “It supports coding in TypeScript, Python, Go, PHP, Bash, C#, SQL, Rust, Ruby and R, or any Docker image”
   • [claimed-docs] “Workflows as code let you define orchestration logic directly in TypeScript or Python, using familiar language constructs like functions, co…”
   • [claimed-docs] “An orchestrator for assembling these functions into efficient, low-latency flows, using either a low-code builder or YAML”
   • [github] “Scripts are turned into sharable UIs automatically, and can be composed together into flows or used into richer apps built with low-code.”
   • [community] “Was hoping it allowed my runtime. I have a bunch of scripts in NodeJS, Python 2, C#, etc. I don't care to rewrite them and/or write scripts …”

   proof ↗⚑ flag

Connector dev

1. developerBuild a custom connector or private integration with a documented developer platform, SDK, or CLI

   weight 2 · round to Windmill
   n8n~partialprobed6/10

   n8n documents a developer platform for extensibility: an n8n API (n8n-docs-16), a CLI (n8n-docs-17, n8n-probe-4), and code nodes supporting JavaScript/Python/npm packages for custom logic (n8n-gh-1, n8n-gh-6), plus self-hosting/OEM options for building private integrations (n8n-docs-3, n8n-docs-6). However, community feedback specifically flags that documentation for building custom nodes is weak ('leaves a lot to be desired... especially regarding custom node development' n8n-comm-12), and code blocks have 'limited ability to import libraries' (n8n-comm-6), indicating real gaps versus a mature SDK experience. Missing for 10: a dedicated custom-node SDK/scaffolding tool with strong docs, and independent confirmation that custom connector development is smooth rather than reported as under-documented.

   • [claimed-docs] “n8n API”
   • [claimed-docs] “Use the command line”
   • [probe] “official CLI documented at https://docs.n8n.io/deploy/host-n8n/configure-n8n/use-the-command-line”
   • [github] “Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [github] “Code When You Need It: Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [community] “The documentation leaves a lot to be desired. Especially regarding custom node development. But also on the user side, for example the kafka…”
   • [community] “N8n looks quite polished and seems primarily concerned about connecting pre-made blocks. There are custom code blocks (JS and Python only, w…”

   proof ↗⚑ flag

   Windmill✓fullprobed8/10

   Windmill offers a documented CLI (wmill) for interacting with instances and deploying from Git, multi-language scripting (TypeScript, Python, Go, etc. or custom Docker images), a flows/apps builder, webhooks, triggers, and an MCP server for connecting external clients, all backed by extensive first-party docs. This directly supports building custom integrations/connectors via a developer platform. missing for 10: no public OpenAPI/REST API spec found (probe returned 404s), and no independent third-party SDK usage reports corroborating the CLI/platform beyond vendor docs.

   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”
   • [claimed-docs] “It supports coding in TypeScript, Python, Go, PHP, Bash, C#, SQL, Rust, Ruby and R, or any Docker image”
   • [claimed-docs] “Windmill supports both UI-based operations via its webIDE and low-code builders, as well as CLI deployments from a Git repository”
   • [claimed-docs] “Each time an item is deployed, Windmill will create and push a commit to the specified repository. ... Windmill can automatically deploy new…”
   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”
   • [probe] “official MCP server documented at https://www.windmill.dev/docs/core_concepts/mcp”
   • [probe] “official CLI documented at https://www.windmill.dev/docs/advanced/cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.windmill.dev/openapi.json, https://www.windmill.dev/swagger.json, https://www.windmill.d…”

   proof ↗⚑ flag

Data mapping

1. ops userMap and transform data between steps with expressions, functions, or formulas

   weight 2 · round to Windmill
   n8n✓fullcommunity7/10

   n8n explicitly supports combining visual workflow steps with JavaScript/Python code and npm packages for custom data manipulation, and community users confirm using code nodes, SQL, JSON/XML parsing, and debugging data in/out between steps. Missing for 10: explicit first-party documentation of the dedicated Expression/Function editor syntax and independent verification of complex multi-step transform reliability (community notes it 'looks weird' and requires programming knowledge for hard data-mapping cases).

   • [github] “Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [github] “Code When You Need It: Combine visual building with JavaScript, Python, and npm packages for advanced AI workflows”
   • [claimed-docs] “Build visually, go deep with code, connect to anything.”
   • [community] “N8n looks quite polished and seems primarily concerned about connecting pre-made blocks. There are custom code blocks (JS and Python only, w…”
   • [community] “n8n is low code platform to build various applications... You need to write SQL, extract data from XML or JSON, describe HTTP queries and pa…”
   • [community] “I have written some stuff with n8n and I think it is better than most no code platforms because it's debuggable. It keeps all the historical…”
   • [community] “I think using this without programming knowledge is hard, you'll hit a lot of errors and data transformation issues that are hard to solve w…”

   proof ↗⚑ flag

   Windmill✓fullclaimed8/10

   Windmill lets ops users write full scripts in TypeScript, Python, Go, SQL, Bash, etc. to transform data, and 'workflows as code' explicitly supports functions, conditionals, and loops between flow steps, plus branch logic for conditional data flow; the low-code flow builder also composes these steps together for mapping/transformation between steps. Missing for 10: no dedicated documentation on a lightweight expression/formula language for simple inline mappings (e.g., JS expression fields) distinct from full scripts, and no independent/hands-on corroboration of transformation ergonomics.

   • [claimed-docs] “It supports coding in TypeScript, Python, Go, PHP, Bash, C#, SQL, Rust, Ruby and R, or any Docker image”
   • [claimed-docs] “An orchestrator for assembling these functions into efficient, low-latency flows, using either a low-code builder or YAML”
   • [claimed-docs] “Workflows as code let you define orchestration logic directly in TypeScript or Python, using familiar language constructs like functions, co…”
   • [claimed-docs] “Branches allow to split the execution of the flow based on a condition. ... Branch all: all the branches will be executed.”
   • [github] “Scripts are turned into sharable UIs automatically, and can be composed together into flows or used into richer apps built with low-code.”

   proof ↗⚑ flag

Credentials

1. ops userStore connection credentials centrally, share them with my team, and control who can use which credential

   weight 3 · round drawn
   n8n~partialclaimed6/10

   n8n has a dedicated Credentials system for centrally storing connection secrets across hundreds of integrations (n8n-docs-23, n8n-intdir-12..30), and enterprise-tier docs reference role-based access control, admin roles, and SSO/SAML/LDAP for governing team access (n8n-gh-5, n8n-docs-28, n8n-docs-8). However, the evidence never explicitly documents a 'share credential with specific users/roles' workflow or granular per-credential permission model, so team sharing and fine-grained control are only implied via general RBAC/admin claims. Missing for 10: explicit documentation of credential-sharing UI/permissions, independent/hands-on confirmation that per-credential access control works as described.

   • [claimed-docs] “Credentials | Nodes | n8n Docs”
   • [github] “Self-host or deploy securely with role-based access, audit trails, and support for sensitive data”
   • [claimed-docs] “Admin roles”
   • [claimed-docs] “SSO, SAML and LDAP”
   • [claimed-docs] “APITemplate.io credentials Asana credentials”

   proof ↗⚑ flag

   Windmill~partialclaimed6/10

   Windmill documents centrally encrypted Variables/Secrets at the workspace level plus a broader roles/permissions system and scoped tokens for least-privilege access, which together support storing and sharing credentials with some access control. However, the evidence doesn't show fine-grained per-credential ACLs (e.g., which specific users/groups can use a specific secret) beyond general workspace/role permissions. Missing for 10: explicit per-resource/credential-level permission granularity, audit logging of credential usage, and independent/hands-on confirmation of this governance in practice.

   • [claimed-docs] “All Variables (not just secrets) are encrypted with a workspace specific symmetric key to avoid leakage.”
   • [claimed-docs] “Windmill provides a roles and permissions system that allows you to control access and manage permissions within your instance and workspace…”
   • [claimed-docs] “Tokens can be scoped to restrict access to specific resources and actions, following the principle of least privilege.”

   proof ↗⚑ flag

Human in the loop

1. ops userPause a workflow to wait for human approval or input before it continues

   weight 2 · round drawn
   n8n—none0/10

   The evidence pack contains no mention of a wait/pause node, human-in-the-loop approval step, or any mechanism for pausing execution pending human input — only unrelated items like error workflows, webhooks, and MCP nodes are cited. This is a fair capability to expect from a workflow automation tool, but no evidence in the pack demonstrates it.

   ⚑ flag

   Windmill—none0/10

   The evidence pack covers flow branching, retries, error handling, and scheduling, but contains no mention of a suspend/approval step, human-in-the-loop gate, or 'wait for input' mechanism in Windmill flows. This is a fair axis for a workflow orchestration product, but no evidence in the pack demonstrates it.

   • [claimed-docs] “Branches allow to split the execution of the flow based on a condition. ... Branch all: all the branches will be executed.”
   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [claimed-docs] “A script or flow can return a top-level `wm_failure` field (string) to retag the run as a failure even though the runtime did not raise an e…”

   proof ↗⚑ flag

Versioning

1. developerVersion workflows through source control or environments and promote changes from dev to production

   weight 2 · round to Windmill
   n8n✓fullclaimed7/10

   n8n has dedicated docs on 'Push and pull changes' via source control and environments, plus a pricing-listed 'Version control using Git' enterprise feature, directly supporting versioning workflows and promoting them across environments. Missing for 10: independent/hands-on verification of the dev-to-prod promotion workflow, and details on CI/CD pipeline integration beyond Git push/pull.

   • [claimed-docs] “Push and pull changes”
   • [claimed-docs] “Version control using Git”
   • [claimed-docs] “Admin roles”

   proof ↗⚑ flag

   Windmill✓fullcommunity8/10

   Windmill documents Git sync where deployments push commits to a repo and can auto-deploy new commits back into workspaces, plus a dedicated CLI (`wmill`) for deploying from a Git repository, enabling version control and promotion across workspaces/environments (dev/staging/prod). This covers source-control-backed versioning and promotion workflows fairly thoroughly, though community feedback questions non-destructive branch validation and local script running pre-merge, indicating some workflow gaps. Missing for 10: independent/hands-on confirmation of a full dev-to-prod promotion pipeline and clearer support for pre-merge branch validation raised by users.

   • [claimed-docs] “Each time an item is deployed, Windmill will create and push a commit to the specified repository. ... Windmill can automatically deploy new…”
   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”
   • [claimed-docs] “Windmill supports both UI-based operations via its webIDE and low-code builders, as well as CLI deployments from a Git repository”
   • [community] “My first questions with any new tool of this kind: Can I run/validate branch versions non-destructively as part of pre-merge checks? Can I r…”

   proof ↗⚑ flag

Community

1. developerInstall community-built nodes, components, or integrations contributed outside the vendor

   weight 1 · round drawn
   n8n—none0/10

   Evidence covers n8n's vendor-built integrations directory, npm packages usable inside code nodes, and API access, but nothing documents an official community-nodes marketplace or process for installing third-party-built nodes/components contributed outside n8n itself.

   ⚑ flag

   Windmill—none0/10

   There is no evidence of a marketplace, registry, or community-contributed nodes/integrations/components ecosystem outside the vendor for Windmill—docs describe language support, flows, CLI, git sync, and MCP but nothing about installing third-party/community-built connectors or components. The hub/scripts sharing feature, if any, isn't mentioned in the evidence pack.

   ⚑ flag

Connectors

1. ops userConnect to thousands of apps through prebuilt, vendor-maintained integrations

   weight 3 · round to n8n
   n8n✓fullcommunity8/10

   n8n's GitHub README and docs consistently tout '1500+ integrations' and thousands of templates, backed by an integrations directory covering major SaaS apps (Slack, Notion, GitHub, HubSpot, Jira, etc.) and a long list of built-in credential types, and community users corroborate ease of extending/using integrations in production. Missing for 10: explicit confirmation that all listed integrations are vendor-maintained (vs. community-contributed nodes) and independent benchmarking of integration reliability/coverage depth.

   • [github] “Combine a visual canvas with custom code, run it self-hosted or in the cloud, and connect to 1500+ integrations.”
   • [github] “1500+ integrations and 9,000+ workflow templates to connect AI with your existing systems”
   • [github] “connect to 1500+ integrations”
   • [claimed-docs] “12116 Workflow Automation Templates”
   • [claimed-docs] “Discover 12326 Automation Workflows from the n8n's Community”
   • [claimed-docs] “OpenAI, the creator of ChatGPT, offers a range of powerful models including GPT-3, DALL·E, and Whisper. Leverage these models to build AI-po…”
   • [claimed-docs] “Slack is a powerful collaboration tool for businesses of all sizes. It brings team communication and collaboration into one place so you can…”
   • [claimed-docs] “Notion is an all-in-one workspace for you and your team. It helps team members create tasks, wikis, and databases all at one place.”
   • [claimed-docs] “GitHub is the number one platform for developers. It boosts their software development and enhances their collaboration options. The tools o…”
   • [claimed-docs] “HubSpot is a leading all-in-one marketing and sales software that is tailored for content marketing, SEO, landing pages, lead management, ma…”
   • [community] “We're using n8n in production for a month now and are pretty happy with it. Easily extendable and new integrations can be built easily.”
   • [community] “I'm a developer but use N8N. One reason is not having to build and maintain integrations with lots of APIs for workflows that are just run o…”

   proof ↗⚑ flag

   Windmill—none0/10

   Evidence shows Windmill offers code-based scripts, flows, and triggers (webhooks, Kafka, Postgres, etc.) but no mention of a prebuilt, vendor-maintained connector/app library comparable to Zapier-style integrations; a community comment even contrasts it with Zapier as a code-first alternative rather than a connector marketplace.

   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [community] “This is brilliant. The world has been needing something like Zapier, but not opaque and locked down. Everything Zapier does is a good idea, …”
   • [community] “Was hoping it allowed my runtime. I have a bunch of scripts in NodeJS, Python 2, C#, etc. I don't care to rewrite them and/or write scripts …”

   proof ↗⚑ flag

Templates

1. ops userStart from a public library of workflow templates instead of building from scratch

   weight 2 · round to n8n
   n8n✓fullclaimed8/10

   n8n publishes a public, searchable library of 12,000+ community workflow templates (n8n.io/workflows) that ops users can browse and start from instead of building from scratch, corroborated across multiple docs and GitHub mentions of '9,000+/12,000+ workflow templates.' Missing for 10: independent hands-on account specifically describing starting from a template (vs building from scratch) and details on template customization/import friction.

   • [claimed-docs] “12116 Workflow Automation Templates”
   • [claimed-docs] “Discover 12116 Automation Workflows from the n8n's Community”
   • [claimed-docs] “Discover 12326 Automation Workflows from the n8n's Community”
   • [github] “1500+ integrations and 9,000+ workflow templates to connect AI with your existing systems”

   proof ↗⚑ flag

   Windmill—none0/10

   No evidence of a public template library or gallery of pre-built workflows for ops users to start from; docs focus on scripting languages, orchestration, CLI, and roles/permissions but never mention a template marketplace or starter workflow gallery.

   ⚑ flag

Embedding

1. developerEmbed the automation platform white-label inside my own product for my customers

   weight 1 · round to n8n
   n8n✓fullclaimed7/10

   n8n explicitly documents an OEM deployment option that lets developers embed and surface n8n's interface inside their own product's UI, confirming white-label embedding is a supported first-party capability (though it requires a separate commercial agreement). Missing for 10: independent/hands-on developer accounts of actually shipping an OEM-embedded product, and details on branding/customization depth.

   • [claimed-docs] “n8n's OEM deployment option lets you embed and surface n8n's interface inside your own product's UI.”
   • [claimed-docs] “OEM deployment of n8n requires a separate commercial agreement with n8n.”

   proof ↗⚑ flag

   Windmill—none0/10

   No evidence of white-labeling capability (custom branding, theming, hiding Windmill identity, or embeddable SDK/iframe for reselling under the developer's own brand) — only self-hosting, app builder, and guest-user features are documented, none of which address white-label embedding for customers.

   ⚑ flag

Local dev

1. developerRun workflows locally or against a dev instance for development and CI testing

   weight 2 · round to n8n
   n8n~partialcommunity7/10

   n8n can be self-hosted locally (Docker Compose, one-line curl install) or run on a dev instance, configured via CLI, and supports pushing/pulling workflows between environments via source control integration, which enables dev/test workflows; community confirms long-term self-hosting in production. However, there is no explicit documentation or evidence of a CI-testing framework, automated test runner, or headless workflow execution for CI pipelines specifically. Missing for 10: dedicated CI/testing tooling or docs (e.g. workflow unit tests, CLI-based automated test execution in CI), and independent hands-on confirmation of dev/CI usage.

   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [claimed-docs] “Use the command line”
   • [claimed-docs] “Push and pull changes”
   • [github] “curl -fsSL https://get.n8n.io | sh”
   • [community] “N8N is great. Been self-hosting for years.”
   • [community] “We're using n8n in production for a month now and are pretty happy with it. Easily extendable and new integrations can be built easily.”

   proof ↗⚑ flag

   Windmill~partialcommunity5/10

   Windmill supports self-hosting a dev instance via Docker Compose (windmill-docs-10) and provides a CLI (`wmill`) for interacting with instances and deploying from Git repos (windmill-docs-9, windmill-docs-4, windmill-docs-11), which could support CI workflows against a dev instance. However, there is no explicit documentation of a local/offline execution mode for scripts/flows independent of a running instance, and a community question directly asking 'Can I run my scripts locally without a lot of drama?' (windmill-comm-5) goes unanswered in the evidence, suggesting friction. Missing for 10: explicit docs on local script execution without an instance, CI-specific testing guides, and a direct answer to the community's local-run concern.

   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”
   • [claimed-docs] “For small setups, use Docker and Docker Compose on a single instance. For larger and production use-cases, use our Helm chart to deploy on K…”
   • [claimed-docs] “Windmill supports both UI-based operations via its webIDE and low-code builders, as well as CLI deployments from a Git repository”
   • [claimed-docs] “Each time an item is deployed, Windmill will create and push a commit to the specified repository. ... Windmill can automatically deploy new…”
   • [community] “My first questions with any new tool of this kind: Can I run/validate branch versions non-destructively as part of pre-merge checks? Can I r…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Windmill
   n8n~partialprobed2/10

   The evidence pack confirms n8n has a documented REST API (n8n-docs-16) and a CLI (n8n-docs-17), but there's no evidence establishing that this API achieves full feature parity with the UI (e.g., building/editing every workflow node type, credentials, AI agent config, etc.), and a probe for a discoverable OpenAPI spec at standard paths returned 404s. Missing for 10: explicit documentation or independent testing confirming API/UI parity, a published OpenAPI spec, and evidence AI-native users can fully replicate complex canvas actions (agent config, node wiring) purely via API.

   • [claimed-docs] “n8n API”
   • [claimed-docs] “Use the command line”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.n8n.io/openapi.json, https://docs.n8n.io/swagger.json, https://docs.n8n.io/api/openapi.…”

   proof ↗⚑ flag

   Windmill~partialprobed6/10

   Windmill exposes a CLI (`wmill`) for deployments, webhooks/triggers for running scripts and flows, git-sync for pushing changes, and an MCP server for AI agents to trigger scripts/flows, showing broad programmatic access to core operations. However, there's no explicit documentation or evidence of a comprehensive REST/OpenAPI spec covering all UI actions (e.g., app-builder UI creation, permissions management, variable/secret management) via API, and the openapi probe returned 404s at standard locations. missing for 10: explicit OpenAPI/API reference confirming full UI-API parity, evidence that app-building, permissions, and admin UI actions are all scriptable via API/CLI, independent confirmation of parity.

   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”
   • [claimed-docs] “Each time an item is deployed, Windmill will create and push a commit to the specified repository. ... Windmill can automatically deploy new…”
   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “Flows additionally expose version-pinned webhook endpoints that target a specific flow version by its numeric version ID instead of the late…”
   • [claimed-docs] “With MCP, you can connect your favorite LLMs (like Claude, Cursor, or any MCP compatible client) to Windmill, allowing you to trigger your s…”
   • [probe] “official MCP server documented at https://www.windmill.dev/docs/core_concepts/mcp”
   • [probe] “official CLI documented at https://www.windmill.dev/docs/advanced/cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.windmill.dev/openapi.json, https://www.windmill.dev/swagger.json, https://www.windmill.d…”

   proof ↗⚑ flag

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

   weight 3 · round to n8n
   n8n✓fullcommunity7/10

   n8n workflows are stored as portable JSON and can be pushed/pulled via Git-based source control (n8n-docs-22), plus a documented REST API (n8n-docs-16) and full self-hosting (n8n-docs-3, n8n-comm-1/16/17) give users real control to extract and leave with their data. Missing for 10: explicit documentation of a bulk 'export all data' feature, independent confirmation of complete data portability (credentials, execution history), and clarity on the fair-code (not fully OSS) license implications for openness (n8n-comm-19).

   • [claimed-docs] “Push and pull changes”
   • [claimed-docs] “n8n API”
   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [claimed-docs] “Without a license key, n8n runs as the free Community edition.”
   • [community] “N8N is great. Been self-hosting for years.”
   • [community] “I have been using n8n for over a year. I prefer it over popular Zapier as it gives me more flexibility and I am able to self host. It has it…”
   • [community] “As per its description on github: N8n is a Free and source-available fair-code licensed workflow automation tool. Not really OSS.”

   proof ↗⚑ flag

   Windmill~partialprobed6/10

   Windmill's CLI (`wmill`) and Git Sync feature let users pull/push all scripts, flows, and apps as plain code (TypeScript/Python/YAML) into a Git repository, giving a genuinely open, portable format for the core workflow logic, and the whole platform is open-source and self-hostable so users are never locked to a vendor. However the evidence pack shows no explicit mechanism for exporting the rest of the instance state — variables, secrets, execution history/logs, users/permissions — as an open-format bundle, only code artifacts. missing for 10: documented full-instance export/backup covering secrets, variables, run history, and permissions, plus independent confirmation that a git-synced workspace can be fully reconstituted elsewhere.

   • [claimed-docs] “The Windmill CLI, `wmill` allows you to interact with Windmill instances right from your terminal.”
   • [claimed-docs] “Each time an item is deployed, Windmill will create and push a commit to the specified repository. ... Windmill can automatically deploy new…”
   • [claimed-docs] “Workflows as code let you define orchestration logic directly in TypeScript or Python, using familiar language constructs like functions, co…”
   • [probe] “official CLI documented at https://www.windmill.dev/docs/advanced/cli”
   • [claimed-docs] “For small setups, use Docker and Docker Compose on a single instance. For larger and production use-cases, use our Helm chart to deploy on K…”

   proof ↗⚑ flag

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

   weight 2 · round to Windmill
   n8n!disputedcontradicted4/10

   n8n's source code is publicly readable on GitHub and docs describe it as 'fair-code licensed' with a Sustainable Use License/Community edition, but this is explicitly not an OSI-approved open source license, and community evidence directly disputes the openness framing ('Not really OSS'). Missing for 10: an actual OSI-approved open license, and vendor acknowledgment that fair-code differs from open source rather than implying openness via branding.

   • [claimed-docs] “A standard, self-hosted version of n8n is available on GitHub.”
   • [claimed-docs] “n8n's Sustainable Use License and n8n Enterprise License are based on the fair-code model.”
   • [claimed-docs] “n8n is a fair-code licensed workflow automation tool that combines AI features with business process automation.”
   • [community] “As per its description on github: N8n is a Free and source-available fair-code licensed workflow automation tool. Not really OSS.”

   proof ↗⚑ flag

   Windmill✓fullprobed7/10

   Windmill is explicitly described as 'open-source and self-hostable' in its own docs/llms.txt, and its source is publicly available on GitHub (windmill-labs/windmill), satisfying the story that an AI-native user can read the source under an open license. missing for 10: no explicit license name (e.g., AGPL/MIT) is cited in the evidence, and no independent confirmation of license terms is provided.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.windmill.dev/llms.txt # Windmill > Windmill is an open-source and self-hostable workflow engine and…”
   • [probe] “PROBE docs-md: HTTP 200 at https://www.windmill.dev/docs/intro.md # What is Windmill? > What is Windmill? An open-source workflow engine an…”
   • [github] “Scripts are turned into sharable UIs automatically, and can be composed together into flows or used into richer apps built with low-code.”
   • [community] “This looks pretty neat! Once the FOSS self-hostable version is out I might try it out for my local hackerspace, it seems like it might be us…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   n8n✓fullcommunity9/10

   n8n provides clear first-party documentation for self-hosting via Docker Compose, one-line install script, or other methods, and confirms a free Community edition runs without a license key; this is corroborated by extensive community testimonials of long-term self-hosting in production. Missing for 10: independent hands-on verification of the self-hosting setup process itself beyond community mentions of using it.

   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [claimed-docs] “Without a license key, n8n runs as the free Community edition.”
   • [claimed-docs] “A standard, self-hosted version of n8n is available on GitHub.”
   • [github] “curl -fsSL https://get.n8n.io | sh”
   • [community] “N8N is great. Been self-hosting for years.”
   • [community] “This is really neat! I'm generally prohibited from using stuff like Zapier at work, since we handle a lot of client data... The self-hosted …”
   • [community] “I have been using n8n for over a year. I prefer it over popular Zapier as it gives me more flexibility and I am able to self host. It has it…”

   proof ↗⚑ flag

   Windmill✓fullprobed9/10

   Windmill provides official self-hosting docs with Docker Compose for small setups and Helm/Kubernetes for production, corroborated by independent community reports of successful self-hosting via Caprover and Podman+Docker Compose. Missing for 10: more recent/large-scale production self-host case studies beyond community hobbyist reports.

   • [claimed-docs] “For small setups, use Docker and Docker Compose on a single instance. For larger and production use-cases, use our Helm chart to deploy on K…”
   • [community] “Yesterday I submitted a one-click install to Caprover, never been so easy to self host. It's really fast on Oracle's free 4vCPU, 24GB RAM ma…”
   • [community] “Pretty easy to selfhost as I deployed it on a Alpine Linux server using Podman + Docker Compose binary. Really nice piece of software.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.windmill.dev/llms.txt # Windmill > Windmill is an open-source and self-hostable workflow engine and…”

   proof ↗⚑ flag

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

   weight 2 · round to n8n
   n8n~partialclaimed6/10

   n8n's self-hosting model (Docker Compose, own infrastructure, on-premises, or private cloud) lets a user fully control where data physically resides, and docs explicitly offer 'Deploy on your infrastructure or ours.' However, this is an indirect residency mechanism (achieved via self-hosting) rather than a first-class region-selection setting, and there is no evidence of specific region options for n8n Cloud. Missing for 10: explicit n8n Cloud region-selection UI/feature, documented data-residency guarantees or compliance certifications tied to region choice.

   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [claimed-docs] “Deploy on your infrastructure or ours.”
   • [claimed-docs] “A standard, self-hosted version of n8n is available on GitHub.”
   • [github] “Self-host or deploy securely with role-based access, audit trails, and support for sensitive data”

   proof ↗⚑ flag

   Windmill~partialcommunity4/10

   Windmill is self-hostable via Docker/Docker Compose or Kubernetes Helm chart, which implicitly lets a user control where their data resides by deploying in any region/infrastructure of their choosing. However, there is no explicit documentation of a region-selection feature for Windmill's hosted/cloud offering or any formal data-residency guarantee. Missing for 10: explicit cloud region selection options, formal data residency/compliance statements, and independent confirmation of self-hosted deployments meeting residency requirements.

   • [claimed-docs] “For small setups, use Docker and Docker Compose on a single instance. For larger and production use-cases, use our Helm chart to deploy on K…”
   • [community] “Yesterday I submitted a one-click install to Caprover, never been so easy to self host. It's really fast on Oracle's free 4vCPU, 24GB RAM ma…”
   • [community] “Pretty easy to selfhost as I deployed it on a Alpine Linux server using Podman + Docker Compose binary. Really nice piece of software.”

   proof ↗⚑ flag

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

   weight 3 · round to n8n
   n8n~partialcommunity4/10

   n8n offers self-hosting on your own infrastructure (n8n-docs-3, n8n-gh-8, n8n-comm-16), which gives users full control over where their data lives and implicitly prevents it from being sent to n8n's cloud or used by n8n for any AI training. However, there is no explicit policy statement, opt-out setting, or documentation addressing AI-training data usage specifically. Missing for 10: an explicit data-usage/AI-training policy or opt-out toggle, independent confirmation that self-hosted data is never used for model training, and clarity on cloud-plan data handling for AI training purposes.

   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [github] “curl -fsSL https://get.n8n.io | sh”
   • [community] “This is really neat! I'm generally prohibited from using stuff like Zapier at work, since we handle a lot of client data... The self-hosted …”
   • [claimed-docs] “Without a license key, n8n runs as the free Community edition.”

   proof ↗⚑ flag

   Windmill—none0/10

   No evidence in the pack addresses AI-training data usage or opt-out policies for Windmill; the product is a workflow/automation engine and could plausibly publish a data-usage/privacy policy, but none is documented here.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to n8n
   n8n~partialclaimed4/10

   n8n's self-hosting option (n8n-docs-3, n8n-docs-14, n8n-gh-5) gives users full control over where data lives and implicitly the ability to delete or retain it as they see fit, and n8n-gh-5 mentions support for 'sensitive data' with audit trails. However, there is no explicit documentation in the pack of configurable execution-data retention/pruning settings, deletion APIs, or GDPR-style data-deletion controls within the product itself. missing for 10: explicit execution-data retention/pruning configuration, documented data-deletion workflow or API, independent confirmation of retention controls working as described.

   • [claimed-docs] “You can self-host n8n on your own infrastructure, on-premises, or in a private cloud, using Docker Compose, one-line setup, or other deploym…”
   • [claimed-docs] “Deploy on your infrastructure or ours.”
   • [github] “Self-host or deploy securely with role-based access, audit trails, and support for sensitive data”

   proof ↗⚑ flag

   Windmill—none0/10

   The evidence pack covers encryption of variables, roles/permissions, and token scoping, but there is no mention of data retention policies, data deletion controls, or export/purge capabilities for an AI-native user's data. No documentation or community evidence addresses this axis.

   ⚑ flag

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

   weight 2 · round drawn
   n8n—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or opt-out settings for n8n; self-hosting is documented but that alone doesn't confirm telemetry can be disabled or clarify what data is collected in cloud/community editions.

   ⚑ flag

   Windmill—none0/10

   No evidence in the pack mentions telemetry, usage tracking, or an opt-out mechanism for Windmill; the docs focus on features, self-hosting, and permissions but never address telemetry data collection. Since Windmill is self-hostable software where telemetry opt-out is a plausible and fair question, absence of evidence yields 'none' rather than 'na'. missing for 10: any mention of telemetry collection, opt-out settings/env vars, or privacy documentation addressing usage tracking.

   ⚑ flag

Durability

1. developerThrottle or queue workflow executions to respect downstream rate limits

   weight 1 · round drawn
   n8n—none0/10

   The evidence pack shows error-workflow handling and community mentions of using 'retries' for sporadic errors, but there is no documentation or evidence of features like rate-limit throttling, request queuing, batching/wait nodes, or execution concurrency controls to respect downstream rate limits.

   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Windmill—none0/10

   The evidence pack shows retries, scheduling, and branching (windmill-docs-13, windmill-docs-18, windmill-docs-12) but contains no mention of concurrency limits, execution throttling, or queuing mechanisms to respect downstream rate limits. Missing for 10: any documentation of concurrency-limit settings, rate-limit-aware queuing, or throttling controls on flows/scripts.

   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”

   proof ↗⚑ flag

2. developerRun long-lived workflows that wait for days and survive worker or platform restarts without losing state

   weight 2 · round to Windmill
   n8n—none0/10

   The evidence pack contains no mention of n8n's wait/pause mechanism, execution state persistence across worker or platform restarts, or queue-mode durability for long-running workflows. Error-workflow handling (n8n-docs-5) and execution history search (n8n-docs-9, n8n-comm-8) address failure notification and debugging, not surviving restarts during multi-day waits, so this applicable reliability axis is unevidenced.

   ⚑ flag

   Windmill~partialclaimed5/10

   Windmill's docs describe 'workflows as code' with built-in checkpointing, parallelism, and fault tolerance, plus retry/error-handling mechanisms (windmill-docs-5, windmill-docs-13, windmill-docs-19), which imply support for durable, resumable flows. However, there is no explicit documentation or independent confirmation of long-duration (multi-day) sleeps/waits or of state surviving worker/platform restarts specifically. Missing for 10: explicit docs on sleep/suspend semantics for days-long waits, and hands-on/community evidence confirming state survives worker or platform restarts.

   • [claimed-docs] “Workflows as code let you define orchestration logic directly in TypeScript or Python, using familiar language constructs like functions, co…”
   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [claimed-docs] “A script or flow can return a top-level `wm_failure` field (string) to retag the run as a failure even though the runtime did not raise an e…”
   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”

   proof ↗⚑ flag

Error handling

1. developerConfigure automatic retries with backoff for failed steps or activities

   weight 3 · round to Windmill
   n8n~partialcommunity4/10

   n8n provides an error-workflow mechanism to react to failed executions (n8n-docs-5) and community usage confirms retries are commonly relied upon in production (n8n-comm-18), but the evidence pack contains no explicit documentation of a configurable retry-with-backoff setting (e.g., delay/backoff intervals) for individual steps. Missing for 10: documentation of per-node 'retry on fail' with configurable backoff/delay, independent confirmation of backoff behavior, and any activity-level retry policy details.

   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Windmill✓fullclaimed9/10

   Windmill's docs explicitly document a retries feature for flow steps with configurable delay and maximum attempts on error, directly matching the story, and error/recovery handlers extend this to scheduled flows. Missing for 10: independent hands-on confirmation of retry/backoff behavior in production use beyond docs.

   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”

   proof ↗⚑ flag

2. ops userDefine dedicated error-handling paths or error workflows and get notified when a run fails

   weight 2 · round to Windmill
   n8n~partialcommunity6/10

   n8n has a documented first-party 'error workflow' feature letting users control how workflow execution failures are handled [n8n-docs-5], and community evidence confirms n8n keeps historical execution logs so failures are debuggable [n8n-comm-8]. However, the evidence pack doesn't detail specific notification channels (e.g., Slack/email alerting nodes) tied to error workflows or dedicated 'get notified on failure' setup steps, and one community comment notes users 'just live with' sporadic errors using retries rather than dedicated alerting [n8n-comm-18]. Missing for 10: explicit documentation of notification/alerting integration within error workflows, and independent hands-on confirmation that error-workflow notifications work reliably in production.

   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “I have written some stuff with n8n and I think it is better than most no code platforms because it's debuggable. It keeps all the historical…”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Windmill~partialcommunity7/10

   Windmill docs describe dedicated failure-handling mechanisms: retries with configurable delay/attempts (windmill-docs-13), conditional branch execution (windmill-docs-12), custom failure tagging via wm_failure (windmill-docs-19), and explicit 'Error and Recovery Handlers to deal with failed scheduled executions' (windmill-docs-18), which together support building dedicated error paths and being alerted on failure. However, the evidence doesn't detail concrete notification channels (email/Slack/webhook alerts) beyond the handler concept, and error-handler support is documented mainly in the scheduling context rather than as a general flow-level feature; a community question (windmill-comm-8) about error handling/branching is asked but not answered by the evidence pack. missing for 10: explicit documentation of flow-level (not just schedule-level) dedicated error workflows, and concrete notification-channel integration for failure alerts.

   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [claimed-docs] “Branches allow to split the execution of the flow based on a condition. ... Branch all: all the branches will be executed.”
   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”
   • [claimed-docs] “A script or flow can return a top-level `wm_failure` field (string) to retag the run as a failure even though the runtime did not raise an e…”
   • [community] “This looks really cool. Is there error handling? For example, if the email sending fails for some reason can I either select the flow to con…”

   proof ↗⚑ flag

Observability

1. ops userInspect past execution logs and re-run a failed execution, resuming from the failing step

   weight 2 · round to n8n
   n8n~partialcommunity5/10

   n8n clearly supports inspecting past execution logs (execution search feature, and community reports that 'it keeps all the historical executions so you can see what happened when workflows failed and what data was going in/out of each component') plus error-workflow handling for failures. However, there is no concrete documentation or evidence describing a re-run/retry that resumes specifically from the failing step rather than restarting the whole execution; only a vague community mention of 'retries' as a workaround for sporadic errors. missing for 10: explicit docs/feature describing resume-from-failing-node re-execution, and independent confirmation that this resume behavior works as intended.

   • [claimed-docs] “Execution search”
   • [claimed-docs] “With an error workflow, you can control how n8n responds to a workflow execution failure.”
   • [community] “I have written some stuff with n8n and I think it is better than most no code platforms because it's debuggable. It keeps all the historical…”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Windmill~partialclaimed3/10

   Windmill's docs describe automatic per-step retries, error handling (wm_failure tagging), and schedule error/recovery handlers, which support reliability around failures, but no evidence explicitly describes an ops user inspecting past execution logs and manually re-running a failed execution resuming from the specific failing step. missing for 10: explicit documentation of log-based re-run/resume-from-step UI or API, and confirmation this is a distinct manual operation rather than automated retry.

   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”
   • [claimed-docs] “A script or flow can return a top-level `wm_failure` field (string) to retag the run as a failure even though the runtime did not raise an e…”

   proof ↗⚑ flag

Schedules

1. ops userRun workflows on cron-style schedules with timezone control

   weight 2 · round to Windmill
   n8n—none0/10

   The evidence pack lists numerous n8n trigger/node docs (Webhook, MCP Trigger/Client, credentials) but never mentions a Cron/Schedule Trigger node or timezone configuration options, so there is no direct evidence this specific capability is documented or delivered.

   ⚑ flag

   Windmill✓fullclaimed8/10

   Windmill's docs explicitly describe Schedules as a CRON expression tied to a Script or Flow with error/recovery handlers, and schedules are listed among supported trigger types alongside webhooks, HTTP routes, etc. Timezone control is a standard part of Windmill's schedule UI per its core concept documentation, though the evidence pack doesn't explicitly quote a timezone field or independent hands-on confirmation. Missing for 10: explicit citation confirming timezone selector UI, independent/community verification of scheduling reliability.

   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”
   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “A script or flow can return a top-level `wm_failure` field (string) to retag the run as a failure even though the runtime did not raise an e…”

   proof ↗⚑ flag

Triggers

1. ops userTrigger workflows from events in connected apps (new record, message, email, form submission)

   weight 3 · round to n8n
   n8n✓fullcommunity8/10

   n8n has documented trigger-based nodes (Webhook, MCP Server Trigger) and 1500+ app integrations that fire workflows off events like new records, messages, emails, or form submissions, backed by extensive integration docs and community reports of production use (webhook-initiated tasks, Slack/email/form-style automations). missing for 10: no explicit first-party doc snippet listing app-specific triggers (e.g., 'new email received', 'new form submission') by name, and no independent benchmark of trigger reliability/latency across many apps.

   • [claimed-docs] “Webhook | Nodes | n8n Docs”
   • [claimed-docs] “MCP Server Trigger”
   • [github] “Combine a visual canvas with custom code, run it self-hosted or in the cloud, and connect to 1500+ integrations.”
   • [github] “connect to 1500+ integrations”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”
   • [community] “We're using n8n in production for a month now and are pretty happy with it. Easily extendable and new integrations can be built easily.”
   • [claimed-docs] “Slack is a powerful collaboration tool for businesses of all sizes. It brings team communication and collaboration into one place so you can…”

   proof ↗⚑ flag

   Windmill~partialclaimed6/10

   Windmill documents generic trigger mechanisms (webhooks, email, HTTP routes, Postgres, Kafka, MQTT, etc.) that can be wired to fire on external events like new records, emails, or form submissions [windmill-docs-15][windmill-docs-16]. However, there's no evidence of pre-built native connectors for specific SaaS apps (e.g., Salesforce, Gmail, Slack) that an ops user could configure without engineering setup — these are generic infra-level hooks requiring technical wiring, not app-specific integrations. missing for 10: native app connector library/marketplace, no-code trigger setup UI for specific third-party apps, evidence of non-technical ops users successfully configuring these triggers.

   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “Flows additionally expose version-pinned webhook endpoints that target a specific flow version by its numeric version ID instead of the late…”
   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”

   proof ↗⚑ flag

2. developerExpose a custom webhook URL that receives external HTTP requests and starts a workflow run with the payload

   weight 3 · round drawn
   n8n✓fullcommunity8/10

   n8n has a dedicated Webhook node documented in official docs, which lets developers expose a custom URL that receives external HTTP requests and triggers a workflow run with the incoming payload; community reports (n8n-comm-18) confirm real-world use of webhook-initiated tasks in production. missing for 10: independent hands-on verification of advanced webhook configuration (e.g., custom auth, response modes) and no dedicated deep-dive doc excerpt beyond the node reference page.

   • [claimed-docs] “Webhook | Nodes | n8n Docs”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”

   proof ↗⚑ flag

   Windmill✓fullclaimed8/10

   Windmill's docs explicitly list webhooks as a trigger type that starts scripts/flows with the request payload, and even describe version-pinned webhook endpoints for flows, confirming custom webhook URLs can kick off workflow runs. missing for 10: no independent/hands-on confirmation of webhook payload handling or setup walkthrough beyond docs references.

   • [claimed-docs] “How do I trigger scripts and flows in Windmill? Use schedules, webhooks, emails, HTTP routes, websockets, Kafka, Postgres, NATS, SQS, MQTT, …”
   • [claimed-docs] “Flows additionally expose version-pinned webhook endpoints that target a specific flow version by its numeric version ID instead of the late…”

   proof ↗⚑ flag

Builder

1. ops userBranch a workflow with conditions, filters, and parallel paths that merge back together

   weight 2 · round to Windmill
   n8n—none0/10

   The evidence pack contains only generic marketing language about visual building, code extensibility, and error-workflow handling, but no documentation of IF/Switch/Filter nodes or a Merge node that would let branches recombine. Community and docs items never describe conditional branching or parallel-path merging explicitly, so the specific branch-and-merge capability is unevidenced. Missing for 10: docs/evidence on conditional (IF/Switch) nodes, filter nodes, and a Merge node for recombining parallel paths.

   ⚑ flag

   Windmill✓fullcommunity7/10

   Windmill's docs explicitly describe flow Branches that split execution based on conditions and a 'branch all' mode that runs all branches in parallel, directly matching conditional and parallel-path branching in a low-code flow builder. Merging paths back together is implied by the flow's linear continuation after a branch block but is not explicitly documented, and 'filters' as a distinct branching primitive isn't named. missing for 10: explicit doc/example of branches merging back into a single downstream step, and confirmation of filter-based branching syntax.

   • [claimed-docs] “Branches allow to split the execution of the flow based on a condition. ... Branch all: all the branches will be executed.”
   • [claimed-docs] “An orchestrator for assembling these functions into efficient, low-latency flows, using either a low-code builder or YAML”
   • [community] “This looks really cool. Is there error handling? For example, if the email sending fails for some reason can I either select the flow to con…”

   proof ↗⚑ flag

2. ops userBuild multi-step workflows in a visual editor without writing code

   weight 3 · round to n8n
   n8n~partialcommunity7/10

   n8n's docs and GitHub materials describe a drag-and-drop visual canvas for multi-step workflows ('Build visually, go deep with code'), with 1500+ integrations and 12000+ templates, and community reports (n8n-comm-18) confirm a non-technical manager built a complex backend visually. However, other hands-on community feedback (n8n-comm-3, n8n-comm-13) says users without programming knowledge hit frequent errors on data transformation/JSON/SQL tasks, meaning pure no-code use has real friction for non-trivial workflows. missing for 10: independent benchmark of non-coder success rate, clearer docs-side guarantee that no-code path avoids expression/code steps for common ops-ops workflows.

   • [claimed-docs] “Build visually, go deep with code, connect to anything.”
   • [github] “Combine a visual canvas with custom code, run it self-hosted or in the cloud, and connect to 1500+ integrations.”
   • [claimed-docs] “12116 Workflow Automation Templates”
   • [community] “We're using this tool for some of our project. Our manager with zero programming skills was able to build a quite complex backend using post…”
   • [community] “N8n looks quite polished and seems primarily concerned about connecting pre-made blocks. There are custom code blocks (JS and Python only, w…”
   • [community] “I think using this without programming knowledge is hard, you'll hit a lot of errors and data transformation issues that are hard to solve w…”
   • [community] “n8n is low code platform to build various applications... You need to write SQL, extract data from XML or JSON, describe HTTP queries and pa…”

   proof ↗⚑ flag

   Windmill~partialcommunity6/10

   Windmill's docs confirm a visual/low-code flow builder (drag-and-drop orchestration, branches, retries, scheduling) that lets users assemble flows without writing orchestration logic (windmill-docs-2, windmill-docs-12, windmill-docs-13, windmill-docs-18, windmill-comm-8). However, Windmill is fundamentally code-centric — individual flow steps are typically scripts in TypeScript/Python/etc, and the docs repeatedly describe it as 'low-code' rather than no-code, with community feedback confirming it's aimed at developers writing scripts (windmill-docs-1, windmill-comm-3). Missing for 10: evidence of pure no-code step types (e.g. built-in connectors/actions requiring zero code), and hands-on testimony from a non-technical ops user successfully building a flow without touching code.

   • [claimed-docs] “An orchestrator for assembling these functions into efficient, low-latency flows, using either a low-code builder or YAML”
   • [claimed-docs] “Branches allow to split the execution of the flow based on a condition. ... Branch all: all the branches will be executed.”
   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [claimed-docs] “A Schedule consists of a Script or Flow, its arguments, a CRON expression that controls the execution frequency and optional Error and Recov…”
   • [claimed-docs] “It supports coding in TypeScript, Python, Go, PHP, Bash, C#, SQL, Rust, Ruby and R, or any Docker image”
   • [community] “Was hoping it allowed my runtime. I have a bunch of scripts in NodeJS, Python 2, C#, etc. I don't care to rewrite them and/or write scripts …”
   • [community] “This looks really cool. Is there error handling? For example, if the email sending fails for some reason can I either select the flow to con…”

   proof ↗⚑ flag

Composition

1. developerCompose reusable sub-workflows or modules that other workflows call

   weight 2 · round to Windmill
   n8n—none0/10

   The evidence pack covers n8n's general visual-building, AI/agent, integration, and deployment capabilities but contains no citation referencing sub-workflows, an 'Execute Workflow' node, or any modular workflow-calling-workflow mechanism, which is the specific capability this story asks about.

   ⚑ flag

   Windmill~partialclaimed6/10

   Windmill's docs and README confirm scripts/functions can be composed together into flows (windmill-gh-1, windmill-docs-2) and workflows-as-code lets you call functions/loops within flows (windmill-docs-5), implying reusable modules, but there is no explicit documentation shown for one flow invoking another flow as a sub-workflow/module across multiple parent workflows. missing for 10: explicit doc/example of a flow calling another flow as a reusable subflow, and independent confirmation of this pattern working in practice.

   • [github] “Scripts are turned into sharable UIs automatically, and can be composed together into flows or used into richer apps built with low-code.”
   • [claimed-docs] “An orchestrator for assembling these functions into efficient, low-latency flows, using either a low-code builder or YAML”
   • [claimed-docs] “Workflows as code let you define orchestration logic directly in TypeScript or Python, using familiar language constructs like functions, co…”

   proof ↗⚑ flag

Testing

1. developerTest a workflow with sample or pinned data and inspect each step's input and output before going live

   weight 2 · round to n8n
   n8n~partialcommunity5/10

   n8n's canvas-based execution tracing is referenced in marketing docs ('Every step of your agents' reasoning, traceable on the canvas') and independently corroborated by a hands-on user noting it keeps historical executions so you can see data going in/out of each node when debugging. However, there is no explicit documentation or mention of the 'pin data' / sample-data testing feature described in the story, and no walkthrough of pre-production testing workflow. Missing for 10: explicit docs on pinning sample data for test runs, and a clear developer workflow showing pre-go-live inspection rather than just post-hoc execution history.

   • [claimed-docs] “Every step of your agents' reasoning, traceable on the canvas.”
   • [claimed-docs] “Build visually, go deep with code, connect to anything. Every step of your agents' reasoning, traceable on the canvas.”
   • [community] “I have written some stuff with n8n and I think it is better than most no code platforms because it's debuggable. It keeps all the historical…”

   proof ↗⚑ flag

   Windmill—none0/10

   The evidence describes Windmill's flow builder, branching, retries, and error handling, but nothing in the pack documents a test-run mode with sample/pinned data or step-by-step input/output inspection before deployment. A community question (windmill-comm-5) about non-destructive testing/local runs goes unanswered in the evidence. Missing for 10: documentation of a 'test flow' or step-by-step debug/preview feature, evidence of pinning/sample input data per step, and confirmation that outputs of each step can be inspected pre-deployment.

   • [claimed-docs] “An orchestrator for assembling these functions into efficient, low-latency flows, using either a low-code builder or YAML”
   • [claimed-docs] “Branches allow to split the execution of the flow based on a condition. ... Branch all: all the branches will be executed.”
   • [claimed-docs] “If defined, upon error this step will be retried with a delay and a maximum number of attempts as defined below.”
   • [community] “My first questions with any new tool of this kind: Can I run/validate branch versions non-destructively as part of pre-merge checks? Can I r…”

   proof ↗⚑ flag