Pylon vs Parahelp

Actions

1. developerThe agent takes real actions through my APIs — refunds, order changes, subscription updates — with scoped auth per action

   weight 3 · round to Parahelp
   Pylon~partialprobed5/10

   Pylon documents that AI agents can 'take action' and that admins can define Custom API tools so agents can hit internal or third-party API endpoints (e.g., a company's own refund/order APIs), and that Pylon's own API/MCP integration uses OAuth authentication for issues/accounts/contacts. However, there's no concrete example or documentation of granular, action-level scoped auth (e.g., distinct permission scopes for 'refund' vs 'subscription update') — the OAuth scoping described applies to Pylon's own data objects, not to arbitrary external business APIs the agent might call. Missing for 10: explicit examples of refunds/order/subscription actions being executed, and documentation of per-action auth scoping for custom API tools beyond general OAuth.

   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “Using a combination of Webhooks, API, and/or Pylon MCP, you can connect your agent to ticketing workflows in Pylon.”
   • [claimed-docs] “If a system does not provide an MCP server, an administrator can define a Custom API tool that agents can use to hit internal or third party…”
   • [claimed-docs] “AI tools authenticate with your Pylon account via OAuth and can read and update issues, accounts, and contacts within the data you can see i…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public REST API at api.usepylon.com is live and cleanly auth-gated — a keyless GET returned HTTP 40…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the first-party MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.usepylon.com ans…”

   proof ↗⚑ flag

   Parahelp✓fullclaimed7/10

   Docs show the agent executes real API actions (Stripe or internal endpoints) like refunds, with per-tool guardrails (e.g., Slack approval above $100), tool-level auto-approve settings, and role-based access control across the product. This covers real-action execution with approval/authorization gating per action, though evidence doesn't detail fine-grained per-action auth scoping (e.g., API-key/permission scoping distinct from approval workflows) beyond general RBAC mentions. Missing for 10: explicit documentation of per-action credential/auth scoping mechanics (vs. approval gates), and independent/hands-on verification of action execution in production.

   • [claimed-docs] “Require Slack approval before the refund tool runs on amounts above $100.”
   • [claimed-docs] “By default, every action requires manual approval. You can set specific tools to auto-approve per task or automation”
   • [claimed-docs] “Enable auto-approve for a task or automation, and the Internal Agent can perform any action through the connection without asking for approv…”
   • [claimed-docs] “Tools can use any service with an API: public integrations like Stripe, or your own internal endpoints.”
   • [claimed-docs] “Role-based access across the product.”
   • [claimed-docs] “let the Internal Agent act without waiting for approval, and run it from your own tools via the API.”

   proof ↗⚑ flag

Procedures

1. support ops leadI encode standard operating procedures the agent follows step-by-step for known issue types, with deterministic branching

   weight 2 · round drawn
   Pylon~partialclaimed6/10

   Pylon's Runbooks feature lets ops leads write natural-language, step-by-step instructions for the AI Support Agent to follow for specific scenarios, and Skills provide reusable instructions for consistent handling of known workflows — directly matching the SOP-encoding need. However, the docs describe these as natural-language guidance rather than an explicit deterministic branching/decision-tree engine, and Triggers/automations are a separate rule system not tied to agent SOPs. Missing for 10: explicit conditional/branching logic constructs within runbooks, and evidence of deterministic (non-LLM-interpreted) path selection.

   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”
   • [claimed-docs] “Build your swarm of AI Agents to help augment your team.”
   • [claimed-docs] “Set up complex workflows and automations to execute your business processes”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

   Parahelp lets ops encode conditional rules (e.g. 'if enterprise account, transfer with summary', 'if refund >$100, require Slack approval') and lets the Internal Agent configure task flows from natural-language descriptions of policies/tools, which supports rule-based branching for known issue types. However, there's no evidence of an explicit step-by-step SOP builder or visual decision-tree/flowchart for deterministic multi-step branching beyond simple guardrail conditions. Missing for 10: explicit multi-step SOP/workflow authoring UI, evidence of complex nested/deterministic branching logic beyond single-condition guardrails, and independent validation of branching behavior in production.

   • [claimed-docs] “Describe the flow you want in natural language - the policies, knowledge, and tool connections it combines - and the Internal Agent configur…”
   • [claimed-docs] “Require Slack approval before the refund tool runs on amounts above $100.”
   • [claimed-docs] “When a ticket is about an enterprise account, transfer it to the enterprise team with a summary note.”
   • [claimed-docs] “See your live knowledge and its version history - who published what and when, with a diff for every change”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round to Parahelp
   Pylon✓fullprobed8/10

   Probes confirm a live llms.txt index at docs.usepylon.com/llms.txt and working per-page .md mirrors (e.g. pylon-mcp.md), so an agent can be pointed at agent-oriented docs and consume them directly. missing for 10: independent third-party confirmation beyond the vendor's own probe, and some per-page md endpoints (e.g. pylon-docs.md) 404 showing coverage is inconsistent.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.usepylon.com/llms.txt # Pylon ## Pylon - [Introduction](https://docs.usepylon.com/pylon-docs/gett…”
   • [probe] “PROBE runtime (recorded 2026-09-10): Pylon's docs are agent-legible — https://docs.usepylon.com/pylon-docs/llms.txt serves a live '# Pylon' …”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.usepylon.com/pylon-docs.md # Page Not Found The URL `pylon-docs` does not exist. This page may have…”

   proof ↗⚑ flag

   Parahelp✓fullprobed9/10

   Direct probe evidence confirms Parahelp's docs serve a working llms.txt (HTTP 200) and per-page .md mirrors via Mintlify, making the docs agent-legible and directly consumable by an AI agent. Missing for 10: no independent third-party report of an agent actually consuming this llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.parahelp.com/llms.txt # Parahelp docs - [Introduction](https://docs.parahelp.com/get-started/intro…”
   • [probe] “PROBE runtime (recorded 2026-09-10): Parahelp's docs are agent-legible (Mintlify) — https://docs.parahelp.com/llms.txt serves '# Parahelp do…”

   proof ↗⚑ flag

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

   weight 2 · round to Parahelp
   Pylon~partialprobed5/10

   Pylon exposes a REST API, webhooks, and triggers that allow programmatic, non-UI interaction with the platform, which supports automation-style usage outside the web UI (pylon-docs-31, pylon-docs-32, pylon-docs-30, pylon-probe-rt-2). However there is no evidence of a CLI, headless mode, or explicit CI/CD integration story — the product is a SaaS support platform accessed via API/OAuth, not something designed to be invoked in a CI pipeline. Missing for 10: explicit CLI/headless execution mode, CI/CD pipeline examples or docs, evidence of automated/scripted runs outside a live SaaS API context.

   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [claimed-docs] “Receive webhooks for various events happening in Pylon.”
   • [claimed-docs] “Set up complex workflows and automations to execute your business processes”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public REST API at api.usepylon.com is live and cleanly auth-gated — a keyless GET returned HTTP 40…”

   proof ↗⚑ flag

   Parahelp~partialprobed7/10

   Parahelp exposes a documented API for triggering agent actions programmatically, supports auto-approve mode to bypass manual gating, and automations can run on schedules or triggers like a GitHub PR merge — all consistent with headless/CI-style automation. However, there's no explicit CLI, CI-pipeline example, or SDK documentation, and no independent/hands-on confirmation of running it in a real CI environment. Missing for 10: dedicated CLI or CI-integration docs, and third-party confirmation of headless automation in production.

   • [claimed-docs] “An automation is an Internal Agent task that runs on a schedule, like every weekday at 9am, or a trigger, like a GitHub PR merging”
   • [claimed-docs] “Enable auto-approve for a task or automation, and the Internal Agent can perform any action through the connection without asking for approv…”
   • [claimed-docs] “let the Internal Agent act without waiting for approval, and run it from your own tools via the API.”
   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system. Your Customer Agent handles them with the same configurations, tool…”
   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system.”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public API reference at https://app.parahelp.com/api/docs is reachable keylessly — no login wall in…”

   proof ↗⚑ flag

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

   weight 3 · round to Pylon
   Pylon~partialclaimed5/10

   Pylon's agent 'connectors' documentation states that if a third-party system provides an MCP server, agents can use it directly (falling back to a Custom API tool only when none exists), indicating Pylon can consume external MCP servers as tool sources for its AI agents. However, this is a single thin doc line with no setup walkthrough, supported-server list, or hands-on/runtime confirmation of actually connecting to a third-party MCP server. missing for 10: a dedicated 'add MCP server' configuration flow/UI, documentation of supported transports/auth for third-party servers, and independent or runtime evidence of a working third-party MCP connection.

   • [claimed-docs] “If a system does not provide an MCP server, an administrator can define a Custom API tool that agents can use to hit internal or third party…”

   proof ↗⚑ flag

   Parahelp—none0/10

   Parahelp's tools connect via its own APIs and integrations (Stripe, internal endpoints, ticketing systems) but there is no mention of MCP server support or the ability to plug in MCP servers so the agent can use their tools. Missing for 10: any reference to MCP protocol, MCP server connection, or standardized tool-plugin interface.

   ⚑ flag

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

   weight 3 · round to Pylon
   Pylon✓fullprobed8/10

   Pylon documents a public REST API (docs-31) and webhooks (docs-32), and runtime probes confirm the API is live and properly auth-gated (probe-rt-2). Docs also describe programmatic/agentic access patterns (Custom API tools, OAuth-based AI tool access via docs-34) reinforcing that the API is designed for agentic/programmatic drivers. missing for 10: no discoverable OpenAPI/swagger spec (probe-3 shows 404s across candidate paths) and no independent third-party corroboration of API robustness beyond Pylon's own docs.

   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [claimed-docs] “Receive webhooks for various events happening in Pylon.”
   • [claimed-docs] “AI tools authenticate with your Pylon account via OAuth and can read and update issues, accounts, and contacts within the data you can see i…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public REST API at api.usepylon.com is live and cleanly auth-gated — a keyless GET returned HTTP 40…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.usepylon.com/openapi.json, https://docs.usepylon.com/swagger.json, https://docs.usepylo…”

   proof ↗⚑ flag

   Parahelp~partialprobed7/10

   Docs explicitly describe driving both the Internal Agent and Customer Agent via API (ticket-free API intake, automation triggers, run-without-approval via API), and a runtime probe confirms a public API reference is reachable keylessly at app.parahelp.com/api/docs. However, standard OpenAPI/swagger spec endpoints all 404, so there's no machine-readable spec confirmed, only prose docs and a reference UI. Missing for 10: a confirmed OpenAPI/swagger spec, and independent hands-on confirmation of actually calling the API successfully.

   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system. Your Customer Agent handles them with the same configurations, tool…”
   • [claimed-docs] “let the Internal Agent act without waiting for approval, and run it from your own tools via the API.”
   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system.”
   • [claimed-docs] “run it from your own tools via the API”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public API reference at https://app.parahelp.com/api/docs is reachable keylessly — no login wall in…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.parahelp.com/openapi.json, https://docs.parahelp.com/swagger.json, https://docs.parahel…”

   proof ↗⚑ flag

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

   weight 2 · round to Pylon
   Pylon~partialprobed4/10

   Pylon's MCP integration uses OAuth 2.0 (via AuthKit) and the REST API requires Bearer tokens, so credentials are authenticated and gated (pylon-docs-34, pylon-probe-rt-1/2/3), and access is limited to 'the data you can see in Pylon,' giving a coarse form of least-privilege tied to the issuing user's own permissions. However there is no evidence of a dedicated mechanism to mint distinct, granularly-scoped API keys or OAuth scopes specifically for an agent (e.g., read-only vs write, per-object scoping) separate from a full user account's access. Missing for 10: documented ability to configure fine-grained scopes/permissions per API credential, evidence of agent-specific token restriction UI, and independent confirmation of least-privilege enforcement beyond basic auth gating.

   • [claimed-docs] “AI tools authenticate with your Pylon account via OAuth and can read and update issues, accounts, and contacts within the data you can see i…”
   • [probe] “PROBE runtime (recorded 2026-09-10): Pylon's docs are agent-legible — https://docs.usepylon.com/pylon-docs/llms.txt serves a live '# Pylon' …”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public REST API at api.usepylon.com is live and cleanly auth-gated — a keyless GET returned HTTP 40…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the first-party MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.usepylon.com ans…”

   proof ↗⚑ flag

   Parahelp—none0/10

   Parahelp documents role-based access control, approval guardrails per-tool, and API access for triggering agents, but no evidence describes issuing scoped or least-privilege API credentials/keys specifically for an agent's tool access. Missing for 10: any documentation of API key scoping, credential minting, or permission-limited tokens issued to an agent.

   • [claimed-docs] “Role-based access across the product.”
   • [claimed-docs] “By default, every action requires manual approval. You can set specific tools to auto-approve per task or automation”
   • [claimed-docs] “Enable auto-approve for a task or automation, and the Internal Agent can perform any action through the connection without asking for approv…”
   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system. Your Customer Agent handles them with the same configurations, tool…”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round to Pylon
   Pylon~partialprobed6/10

   Pylon exposes a documented REST API, webhooks, and an OAuth-secured official MCP server (confirmed live via runtime probes), which together let AI-native developers build integrations and agents against Pylon data. However, there is no evidence of traditional language-specific client SDKs (e.g., Python/Node packages) or an OpenAPI spec (probe found 404s for openapi/swagger endpoints), so 'SDK' support is really API+MCP+webhooks rather than packaged SDKs. Missing for 10: dedicated official SDK packages, publicly discoverable OpenAPI/swagger spec, independent developer corroboration of SDK usage.

   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [claimed-docs] “Receive webhooks for various events happening in Pylon.”
   • [claimed-docs] “AI tools authenticate with your Pylon account via OAuth and can read and update issues, accounts, and contacts within the data you can see i…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public REST API at api.usepylon.com is live and cleanly auth-gated — a keyless GET returned HTTP 40…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the first-party MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.usepylon.com ans…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.usepylon.com/openapi.json, https://docs.usepylon.com/swagger.json, https://docs.usepylo…”

   proof ↗⚑ flag

   Parahelp—none0/10

   Parahelp documents a customer-facing API and webhook/automation triggers, but no evidence anywhere mentions official client SDKs (Python, JS, etc.); the OpenAPI/swagger probe also 404s across all candidate paths, suggesting no machine-readable spec for SDK generation either.

   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system. Your Customer Agent handles them with the same configurations, tool…”
   • [claimed-docs] “let the Internal Agent act without waiting for approval, and run it from your own tools via the API.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.parahelp.com/openapi.json, https://docs.parahelp.com/swagger.json, https://docs.parahel…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public API reference at https://app.parahelp.com/api/docs is reachable keylessly — no login wall in…”

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round to Pylon
   Pylon✓fullclaimed7/10

   Pylon documents a dedicated webhooks feature for receiving events happening in Pylon, directly matching the story. missing for 10: no independent/hands-on corroboration of webhook delivery, no detail on event types/payload schema, or subscription management UI/API specifics.

   • [claimed-docs] “Receive webhooks for various events happening in Pylon.”
   • [claimed-docs] “Using a combination of Webhooks, API, and/or Pylon MCP, you can connect your agent to ticketing workflows in Pylon.”

   proof ↗⚑ flag

   Parahelp—none0/10

   No evidence pack item mentions webhooks or event subscriptions; Parahelp's automation/trigger docs reference schedules and GitHub PR merges but nothing about outbound webhook subscriptions for third-party consumption. missing for 10: any mention of webhook subscription/registration, event types, or push-notification mechanism.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   Pylon~partialclaimed6/10

   Pylon documents AI summarization of customer conversations synced to CRM accounts (Salesforce), AI-powered knowledge base features, and analytics dashboards, plus AI Support Agents that surface context and take action — all suggesting embedded AI insight generation. However, there's no dedicated 'insights' feature that proactively surfaces suggestions from the user's own data (e.g., trend detection, anomaly alerts) beyond conversation summarization and agent responses. Missing for 10: a first-party 'insights' or 'suggestions' dashboard feature explicitly generating recommendations from account/ticket data, and independent/hands-on validation of insight quality.

   • [claimed-docs] “Every day, Pylon scans your customer channels for conversations that were had. For every conversation, we use AI to summarize the details, a…”
   • [claimed-docs] “Pylon comes with a number of default analytics dashboards with common support metrics. All dashboards are filterable by a wide selection of …”
   • [claimed-docs] “A dedicated place to host your support content, including question-and-answer style articles, internal runbooks, and more -- all supercharge…”
   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

   Parahelp's Internal Agent generates insights from data: it analyzes historical tickets to auto-build a Customer Agent (docs-19) and runs automations that surface gaps in tools/support queues on their own (docs-17). This is AI-generated insight/suggestion behavior tied to the user's own data, but it's narrowly scoped to ticket/gap analysis rather than a general-purpose insights feature across all product data. Missing for 10: a dedicated insights/analytics dashboard surfacing trends or recommendations beyond gap detection and agent bootstrapping, and independent/hands-on confirmation of insight quality.

   • [claimed-docs] “Set up automations that watch your tools and your support queue and surface gaps on their own.”
   • [claimed-docs] “the Internal Agent analyzes your last 500-1,000 resolved tickets along with your existing context to build the first version of your Custome…”

   proof ↗⚑ flag

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

   weight 2 · round to Parahelp
   Pylon~partialclaimed6/10

   Pylon documents triggers/automations to execute business processes, webhooks, API access, and AI agents that autonomously handle issues assigned to them with monitoring via issue logs, supporting background autonomous automation. However, evidence is mostly first-party docs with no independent/hands-on confirmation of unattended reliability or long-running autonomy at scale. Missing for 10: independent/hands-on verification of autonomous background execution, detail on failure handling/retries in triggers, and third-party confirmation of agent autonomy in production.

   • [claimed-docs] “Set up complex workflows and automations to execute your business processes”
   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “You can assign them to issues you'd like them to take a look at. This means you have full control of which customer issues your AI agent int…”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Receive webhooks for various events happening in Pylon.”
   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”

   proof ↗⚑ flag

   Parahelp✓fullclaimed8/10

   Docs explicitly describe automations as Internal Agent tasks that run on a schedule or trigger (e.g., weekday 9am, GitHub PR merge), configurable with auto-approve so they act without waiting for manual approval, enabling background autonomous operation. Additional support covers auto-approve per tool/task, API-driven triggering, and monitoring/reverting via releases. Missing for 10: independent third-party verification of long-running unattended automations in production and more detail on failure/alerting handling during autonomous runs.

   • [claimed-docs] “An automation is an Internal Agent task that runs on a schedule, like every weekday at 9am, or a trigger, like a GitHub PR merging”
   • [claimed-docs] “By default, every action requires manual approval. You can set specific tools to auto-approve per task or automation”
   • [claimed-docs] “Enable auto-approve for a task or automation, and the Internal Agent can perform any action through the connection without asking for approv…”
   • [claimed-docs] “let the Internal Agent act without waiting for approval, and run it from your own tools via the API.”
   • [claimed-docs] “Configuration actions publish as a release on the Releases page, where you can track the impact and revert with one click.”
   • [claimed-docs] “Set up automations that watch your tools and your support queue and surface gaps on their own.”

   proof ↗⚑ flag

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

   weight 3 · round to Pylon
   Pylon✓fullclaimed8/10

   Pylon ships built-in AI Support Agents that users can build, assign to issues, give runbooks/skills, and monitor outcomes—clearly a built-in assistant users delegate tasks to (assign issues, define workflows, review AI-taken actions). Missing for 10: independent/third-party hands-on validation of assistant task quality and no user-facing UI screenshots/demos beyond docs.

   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “Build your swarm of AI Agents to help augment your team.”
   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”
   • [claimed-docs] “You can assign them to issues you'd like them to take a look at. This means you have full control of which customer issues your AI agent int…”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”

   proof ↗⚑ flag

   Parahelp✓fullclaimed7/10

   Parahelp's Internal Agent is a built-in AI assistant you delegate configuration and operational tasks to via natural language (docs-1), which can act autonomously per auto-approve settings (docs-8, docs-14), run on schedules/triggers (docs-5), and proactively surface gaps (docs-17), with the agent also bootstrapping itself from historical tickets (docs-19). Missing for 10: independent/hands-on user reports of delegating tasks and outcomes, and more detail on the breadth/limits of what can be delegated beyond configuration and support workflows.

   • [claimed-docs] “Describe the flow you want in natural language - the policies, knowledge, and tool connections it combines - and the Internal Agent configur…”
   • [claimed-docs] “the Internal Agent analyzes your last 500-1,000 resolved tickets along with your existing context to build the first version of your Custome…”
   • [claimed-docs] “Set up automations that watch your tools and your support queue and surface gaps on their own.”
   • [claimed-docs] “An automation is an Internal Agent task that runs on a schedule, like every weekday at 9am, or a trigger, like a GitHub PR merging”
   • [claimed-docs] “Enable auto-approve for a task or automation, and the Internal Agent can perform any action through the connection without asking for approv…”
   • [claimed-docs] “let the Internal Agent act without waiting for approval, and run it from your own tools via the API.”

   proof ↗⚑ flag

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

   weight 2 · round to Parahelp
   Pylon~partialprobed6/10

   Pylon exposes a live first-party MCP server (confirmed by runtime probes) that lets AI tools authenticate via OAuth and read/update issues, accounts, and contacts, effectively letting an AI-native user drive Pylon via natural-language-mediated agent actions; runbooks and skills also let admins encode natural-language instructions for agent behavior. However, this is achieved through external AI-tool/agent integration rather than a native in-app NL command interface for end users. Missing for 10: evidence of a built-in chat/command-bar UI where a human directly issues natural-language commands to operate Pylon itself, and independent confirmation of real-world NL-driven task completion.

   • [claimed-docs] “AI tools authenticate with your Pylon account via OAuth and can read and update issues, accounts, and contacts within the data you can see i…”
   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”
   • [probe] “PROBE runtime (recorded 2026-09-10): Pylon's docs are agent-legible — https://docs.usepylon.com/pylon-docs/llms.txt serves a live '# Pylon' …”
   • [probe] “PROBE runtime (recorded 2026-09-10): the first-party MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.usepylon.com ans…”
   • [claimed-docs] “Using a combination of Webhooks, API, and/or Pylon MCP, you can connect your agent to ticketing workflows in Pylon.”

   proof ↗⚑ flag

   Parahelp✓fullclaimed7/10

   Parahelp's core interaction model is describing desired flows, policies, and guardrails in natural language, which the Internal Agent then configures into tasks, automations, and guardrail rules (e.g. 'Require Slack approval before refund tool runs above $100'). This covers configuring agent behavior via NL, though it's scoped to support/ops workflows rather than general-purpose NL command execution. Missing for 10: independent/hands-on evidence of NL command accuracy, and clarity on whether all product actions (not just configuration) can be triggered via natural language versus UI/API.

   • [claimed-docs] “Describe the flow you want in natural language - the policies, knowledge, and tool connections it combines - and the Internal Agent configur…”
   • [claimed-docs] “Require Slack approval before the refund tool runs on amounts above $100.”
   • [claimed-docs] “When a ticket is about an enterprise account, transfer it to the enterprise team with a summary note.”
   • [claimed-docs] “the Internal Agent analyzes your last 500-1,000 resolved tickets along with your existing context to build the first version of your Custome…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Pylon—none0/10

   Pylon documents a REST API and webhooks (pylon-docs-31, pylon-docs-32) but there is no evidence of an interactive API reference with runnable/try-it examples — probes explicitly found no OpenAPI/Swagger spec at any candidate path (pylon-probe-3), only static markdown docs.

   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [claimed-docs] “Receive webhooks for various events happening in Pylon.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.usepylon.com/openapi.json, https://docs.usepylon.com/swagger.json, https://docs.usepylo…”

   proof ↗⚑ flag

   Parahelp—none0/10

   There is an API reference surface (app.parahelp.com/api/docs) and docs are agent-legible, but no evidence shows an interactive reference with runnable examples (e.g. try-it console, code samples execution); explicit openapi.json probes all 404'd, suggesting no standard interactive spec is exposed.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.parahelp.com/openapi.json, https://docs.parahelp.com/swagger.json, https://docs.parahel…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public API reference at https://app.parahelp.com/api/docs is reachable keylessly — no login wall in…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Pylon—none0/10

   Pylon has a REST API and docs, but explicit probes for OpenAPI/Swagger spec files at standard paths all returned 404, and no evidence anywhere shows a downloadable machine-readable spec (OpenAPI, JSON Schema, etc.) for its API.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.usepylon.com/openapi.json, https://docs.usepylon.com/swagger.json, https://docs.usepylo…”
   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public REST API at api.usepylon.com is live and cleanly auth-gated — a keyless GET returned HTTP 40…”

   proof ↗⚑ flag

   Parahelp—none0/10

   Parahelp has a customer-facing API and a public API reference page (app.parahelp.com/api/docs), but explicit probes for a machine-readable OpenAPI/Swagger spec at all standard paths (openapi.json, swagger.json, etc.) returned 404, and no evidence shows a downloadable spec file.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.parahelp.com/openapi.json, https://docs.parahelp.com/swagger.json, https://docs.parahel…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public API reference at https://app.parahelp.com/api/docs is reachable keylessly — no login wall in…”
   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system. Your Customer Agent handles them with the same configurations, tool…”

   proof ↗⚑ flag

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

   weight 1 · round to Parahelp
   Pylon~partialclaimed3/10

   Pylon's Support Agent docs mention a 'test' feature to simulate interactions with the AI without deploying it live (pylon-docs-17), which suggests some sandboxed testing before touching real customer issues, but there's no documented sandbox environment, staging API, or test dataset separate from production data. Missing for 10: explicit sandbox/staging environment, test API keys or test accounts isolated from production, and confirmation that simulated interactions don't touch real customer/production data.

   • [claimed-docs] “Simulate an interaction with the AI and see how it handles different questions.”
   • [claimed-docs] “You can assign them to issues you'd like them to take a look at. This means you have full control of which customer issues your AI agent int…”

   proof ↗⚑ flag

   Parahelp~partialclaimed5/10

   Docs describe simulations that replay historical tickets or mock scenarios against configurations, which functions as a sandbox for testing without touching production, and separately note that 'production tests verify your tool connections' implying a distinction between simulated and production environments. However, there is no explicit mention of a dedicated sandbox environment, isolated test data store, or guarantee that simulations cannot write to production systems/tools. missing for 10: explicit documentation of an isolated sandbox environment separate from production data/tools, confirmation that simulated runs cannot trigger real side-effects, and independent/hands-on verification of this isolation.

   • [claimed-docs] “Simulations replay your historical tickets - or mock scenarios - against the configurations in the task, and production tests verify your to…”
   • [claimed-docs] “Configuration actions publish as a release on the Releases page, where you can track the impact and revert with one click.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Pylon—none0/10

   Evidence shows Pylon has a REST API, webhooks, and MCP server, but no documentation of API versioning scheme or a deprecation policy anywhere in docs/changelog; openapi spec probes 404 and no version headers or changelog entries reference API deprecations. Missing for 10: versioning scheme (e.g., v1/v2 paths), documented deprecation timeline/policy, changelog entries about breaking changes.

   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.usepylon.com/openapi.json, https://docs.usepylon.com/swagger.json, https://docs.usepylo…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public REST API at api.usepylon.com is live and cleanly auth-gated — a keyless GET returned HTTP 40…”

   proof ↗⚑ flag

   Parahelp—none0/10

   There is evidence of an API existing (customer requests via API, run automations via API) and public API docs, but no mention of API versioning or a documented deprecation policy anywhere in the evidence pack. Missing for 10: versioning scheme, deprecation policy, changelog entries about breaking changes or API version sunset.

   ⚑ flag

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

   weight 2 · round to Pylon
   Pylon~partialprobed5/10

   Pylon's API (pylon-docs-31), MCP server (pylon-docs-34, pylon-probe-rt-1/3), and triggers/automations (pylon-docs-30) give AI agents and scripts programmatic read/update access to issues, accounts, and contacts, which could be used to script bulk changes, but no evidence describes a dedicated bulk-edit/bulk-action UI or batch-endpoint for acting on many items in one call. Missing for 10: an explicit bulk-update/bulk-action API or UI feature, and any documentation or demo of multi-item batch operations rather than single-record CRUD via API/MCP.

   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [claimed-docs] “AI tools authenticate with your Pylon account via OAuth and can read and update issues, accounts, and contacts within the data you can see i…”
   • [claimed-docs] “Set up complex workflows and automations to execute your business processes”
   • [probe] “PROBE runtime (recorded 2026-09-10): Pylon's docs are agent-legible — https://docs.usepylon.com/pylon-docs/llms.txt serves a live '# Pylon' …”
   • [probe] “PROBE runtime (recorded 2026-09-10): the first-party MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.usepylon.com ans…”

   proof ↗⚑ flag

   Parahelp~partialclaimed4/10

   Evidence shows batch-style processing (analyzing 500-1,000 historical tickets, simulations replaying many tickets, scheduled/triggered automations) which imply working across many items, but there's no explicit documentation of a user-facing bulk-action feature (e.g., mass-editing or resolving many tickets/items in one command). missing for 10: explicit bulk-operation UI/API (e.g., batch resolve/tag/update across selected items), evidence of throughput/rate limits for bulk actions, independent confirmation of bulk workflows in production.

   • [claimed-docs] “the Internal Agent analyzes your last 500-1,000 resolved tickets along with your existing context to build the first version of your Custome…”
   • [claimed-docs] “Simulations replay your historical tickets - or mock scenarios - against the configurations in the task, and production tests verify your to…”
   • [claimed-docs] “An automation is an Internal Agent task that runs on a schedule, like every weekday at 9am, or a trigger, like a GitHub PR merging”
   • [claimed-docs] “Set up automations that watch your tools and your support queue and surface gaps on their own.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Pylon✓fullprobed8/10

   Pylon has a dedicated Triggers platform docs page describing setting up complex workflows/automations tied to business processes, plus webhooks for events and an API to programmatically act on data, enabling event-driven automated actions. This directly matches rule-based automation triggering actions on events, with runtime probes confirming the API/webhook infrastructure is live. Missing for 10: detailed trigger-rule syntax/examples, independent hands-on validation of complex trigger logic, and explicit AI-agent-specific trigger configuration beyond general workflow automation.

   • [claimed-docs] “Set up complex workflows and automations to execute your business processes”
   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [claimed-docs] “Receive webhooks for various events happening in Pylon.”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public REST API at api.usepylon.com is live and cleanly auth-gated — a keyless GET returned HTTP 40…”

   proof ↗⚑ flag

   Parahelp✓fullclaimed8/10

   Docs explicitly describe automations as Internal Agent tasks that run on schedules or triggers (e.g., GitHub PR merge), plus guardrail rules that trigger actions on events (Slack approval above $100, transfer enterprise tickets), matching the rule-based, event-triggered automation story. Missing for 10: independent/third-party corroboration of automation reliability and a broader list of supported trigger event types beyond the examples given.

   • [claimed-docs] “An automation is an Internal Agent task that runs on a schedule, like every weekday at 9am, or a trigger, like a GitHub PR merging”
   • [claimed-docs] “Require Slack approval before the refund tool runs on amounts above $100.”
   • [claimed-docs] “When a ticket is about an enterprise account, transfer it to the enterprise team with a summary note.”
   • [claimed-docs] “Set up automations that watch your tools and your support queue and surface gaps on their own.”
   • [claimed-docs] “By default, every action requires manual approval. You can set specific tools to auto-approve per task or automation”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Parahelp
   Pylon—none0/10

   Pylon's docs mention 'triggers' for building automations and workflows (pylon-docs-30) plus API/webhooks for programmatic action, but nothing in the evidence pack specifies time-based or recurring scheduling (e.g., cron-like jobs, scheduled runs) as opposed to event-triggered automations. No mention of a scheduler, recurring job configuration, or interval-based execution.

   • [claimed-docs] “Set up complex workflows and automations to execute your business processes”
   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [claimed-docs] “Receive webhooks for various events happening in Pylon.”

   proof ↗⚑ flag

   Parahelp✓fullclaimed8/10

   Parahelp's docs explicitly describe automations as Internal Agent tasks that run on a schedule (e.g. every weekday at 9am) or on triggers, which directly matches recurring scheduled workflows, and these can be run via API for custom automation depth. Missing for 10: no independent/hands-on corroboration of scheduling reliability, and no detail on schedule configuration flexibility (cron-like options, timezone handling, etc.).

   • [claimed-docs] “An automation is an Internal Agent task that runs on a schedule, like every weekday at 9am, or a trigger, like a GitHub PR merging”
   • [claimed-docs] “Set up automations that watch your tools and your support queue and surface gaps on their own.”
   • [claimed-docs] “let the Internal Agent act without waiting for approval, and run it from your own tools via the API.”

   proof ↗⚑ flag

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

   weight 1 · round to Parahelp
   Pylon—none0/10

   Pylon has automations/triggers, agent runbooks, and issue logs for monitoring outcomes, but there is no evidence of version history, diffing, review workflows, or rollback capability for automations/triggers/skills/runbooks. Missing for 10: version history for triggers/runbooks, change review/approval process, rollback to a prior automation version.

   • [claimed-docs] “Set up complex workflows and automations to execute your business processes”
   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

   Parahelp supports release publishing with one-click revert and knowledge version history with diffs (parahelp-docs-4, parahelp-docs-9), directly covering versioning and rollback of configurations/automations. However, there's no explicit review/approval workflow for the versioning itself (approvals exist for actions, not for config changes review), and no evidence of branching, staged review, or audit trail beyond 'who published what and when'. Missing for 10: dedicated review/approval step before publishing a release, granular version comparison across automations (not just knowledge), and independent/hands-on confirmation of rollback working in practice.

   • [claimed-docs] “Configuration actions publish as a release on the Releases page, where you can track the impact and revert with one click.”
   • [claimed-docs] “See your live knowledge and its version history - who published what and when, with a diff for every change”
   • [claimed-docs] “An automation is an Internal Agent task that runs on a schedule, like every weekday at 9am, or a trigger, like a GitHub PR merging”

   proof ↗⚑ flag

Channels

1. support leaderOne agent covers chat, email, and in-app, plus the channels my customers actually use — Slack, WhatsApp, social

   weight 2 · round drawn
   Pylon~partialclaimed5/10

   Pylon clearly supports one-agent omnichannel routing across chat, email, and in-app (chat widget, Slack, email integrations, omnichannel-support doc), but the evidence pack never explicitly documents WhatsApp or social-media channel integrations, which the story specifically calls out. missing for 10: explicit WhatsApp integration docs, explicit social media (e.g. Twitter/Instagram) channel support, and confirmation these route into the same unified agent workflow as chat/email/Slack.

   • [claimed-docs] “Pylon can support you wherever you interact with your customers.”
   • [claimed-docs] “Pylon watches for customer issues in connected customer Slack channels and automatically bundles together relevant messages and creates trac…”
   • [claimed-docs] “Connect your email addresses with Pylon to track and response to support requests over email.”
   • [claimed-docs] “Fully customizable colors, branding, and workflows * Multiple separate chat widgets with different branding and workflows”
   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”

   proof ↗⚑ flag

   Parahelp~partialclaimed5/10

   Parahelp's Customer Agent operates as a team member inside major ticketing/chat platforms (Intercom, Zendesk, Front, Plain, Pylon), and its Pylon integration explicitly covers email, live chat, and Slack tickets, showing some multi-channel reach. However, there is no evidence of native WhatsApp or social-media channel support, so the 'channels customers actually use' claim is only partially substantiated. Missing for 10: explicit WhatsApp support, explicit social media channel support, and independent confirmation beyond vendor docs.

   • [claimed-docs] “Your Customer Agent works as a team member in Intercom, Zendesk, Front, Plain, or Pylon.”
   • [claimed-docs] “Parahelp now integrates with Pylon! ... their agents resolve tickets across email, live chat, and Slack”

   proof ↗⚑ flag

Languages

1. support leaderThe agent supports customers in many languages, even where my knowledge base exists only in English

   weight 2 · round drawn
   Pylon—none0/10

   No evidence in the pack mentions multilingual support, language detection, translation of knowledge base content, or the AI agent responding in customer languages other than English; docs cover agent building, knowledge base, and integrations but never address language coverage.

   ⚑ flag

   Parahelp—none0/10

   No evidence in the pack mentions multilingual support, language detection, or translation capabilities for the Customer Agent; documentation focuses on ticketing integrations, tool connections, and knowledge management without addressing cross-language customer support.

   ⚑ flag

Voice

1. support leaderThe agent handles phone calls — speech in, speech out — with the same knowledge and actions as chat

   weight 2 · round drawn
   Pylon—none0/10

   Pylon's evidence covers omnichannel support (chat, email, Slack), AI support agents, knowledge bases, and MCP/API integrations, but nothing describes voice/phone call handling with speech-in/speech-out capability. The omnichannel doc (pylon-docs-24) is generic and doesn't mention telephony or voice at all.

   ⚑ flag

   Parahelp—none0/10

   Parahelp's evidence describes a text-based Customer Agent that works via ticketing systems and API, with no mention of voice/telephony channels, speech-to-text, or text-to-speech capabilities. No citation addresses phone call handling.

   ⚑ flag

Handoff

1. support leaderWhen the agent escalates, the human gets the full conversation, a summary, and collected details — the customer never repeats themselves

   weight 3 · round drawn
   Pylon~partialclaimed5/10

   Pylon's AI agent operates within the same ticket/issue thread that a human later takes over, and the issue log records the agent's steps and outcomes (pylon-docs-19), while the agent explicitly gathers internal context for the team (pylon-docs-13) and elsewhere Pylon auto-summarizes conversations for CRM sync (pylon-docs-33), suggesting summarization capability exists. However, there is no explicit documentation of an escalation-specific handoff package (conversation + AI summary + structured collected details) being automatically attached to a ticket when an agent escalates to a human. missing for 10: explicit escalation-handoff feature docs, evidence the summary/details are surfaced to the human agent at hand-off time, confirmation customer doesn't need to repeat themselves.

   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Every day, Pylon scans your customer channels for conversations that were had. For every conversation, we use AI to summarize the details, a…”
   • [claimed-docs] “You can assign them to issues you'd like them to take a look at. This means you have full control of which customer issues your AI agent int…”

   proof ↗⚑ flag

   Parahelp~partialclaimed5/10

   Docs show guardrail rules that transfer tickets 'with a summary note' to human teams (parahelp-docs-7) and ticketing-system integrations where the agent works as a team member (parahelp-docs-15), implying handoff context is passed, but there's no explicit description of a full escalation package (full transcript + generated summary + structured collected details) reaching the human agent. missing for 10: dedicated documentation of the escalation handoff artifact itself (transcript, structured details form, summary format), evidence that customers never have to repeat themselves, and any hands-on/independent confirmation of this workflow.

   • [claimed-docs] “When a ticket is about an enterprise account, transfer it to the enterprise team with a summary note.”
   • [claimed-docs] “Your Customer Agent works as a team member in Intercom, Zendesk, Front, Plain, or Pylon.”
   • [claimed-docs] “See your live knowledge and its version history - who published what and when, with a diff for every change”

   proof ↗⚑ flag

Rules

1. support ops leadI configure when the agent must hand off — by topic, sentiment, customer tier, or explicit request — and it reliably obeys

   weight 2 · round to Parahelp
   Pylon~partialclaimed4/10

   Pylon's Support Agent framework lets admins write natural-language runbooks for 'specific scenarios' and assign only certain issues to the agent, plus monitor outcomes via the issue log — this could be used to script handoff conditions, but there is no explicit documentation of built-in triggers for topic, sentiment, or customer-tier-based escalation, nor any evidence about reliability/guardrails ensuring the agent 'reliably obeys' handoff rules. Missing for 10: dedicated sentiment/tier/topic escalation configuration UI, explicit-request handoff trigger documentation, and evidence (docs or hands-on) of enforcement reliability.

   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”
   • [claimed-docs] “You can assign them to issues you'd like them to take a look at. This means you have full control of which customer issues your AI agent int…”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”
   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

   Docs show configurable guardrails that trigger handoff/escalation by topic (e.g., transfer enterprise-account tickets) and by threshold (Slack approval on refunds >$100), plus auto-approve vs manual-approval controls and release tracking for changes — evidence of rule-based handoff configuration and enforcement. However, there is no explicit documentation of sentiment-based triggers, customer-tier-specific rules beyond the enterprise example, or handling of explicit 'transfer me to a human' requests, and no independent/hands-on verification that these rules are reliably obeyed in production. Missing for 10: sentiment-based escalation rules, explicit-request handoff configuration, customer-tier granularity beyond one example, and third-party evidence of reliability.

   • [claimed-docs] “Require Slack approval before the refund tool runs on amounts above $100.”
   • [claimed-docs] “When a ticket is about an enterprise account, transfer it to the enterprise team with a summary note.”
   • [claimed-docs] “By default, every action requires manual approval. You can set specific tools to auto-approve per task or automation”
   • [claimed-docs] “Configuration actions publish as a release on the Releases page, where you can track the impact and revert with one click.”
   • [claimed-docs] “Enable auto-approve for a task or automation, and the Internal Agent can perform any action through the connection without asking for approv…”

   proof ↗⚑ flag

Hallucination

1. ai-native userGuardrails stop the agent from inventing policies, prices, or promises — off-knowledge questions get a safe decline, not a guess

   weight 3 · round to Parahelp
   Pylon~partialclaimed3/10

   Pylon's Support Agent is grounded in a curated knowledge base and runbooks/skills that define scenario-specific instructions, which implicitly limits it to trained content rather than free invention, and 'deflect using content' suggests answers are content-bound. However, there is no explicit documentation of a safe-decline behavior for off-knowledge questions, confidence thresholds, or anti-hallucination guardrails around prices/policies. Missing for 10: explicit safe-decline/escalation mechanism for unknown questions, documentation of hallucination prevention, and evidence of guardrails specifically around prices/policies/promises.

   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”
   • [claimed-docs] “A dedicated place to host your support content, including question-and-answer style articles, internal runbooks, and more -- all supercharge…”

   proof ↗⚑ flag

   Parahelp~partialclaimed4/10

   Parahelp's guardrails docs focus on approval gates for actions (e.g., refund thresholds, enterprise transfers) and versioned knowledge bases, which constrain what the agent can execute and what knowledge it draws from — but there is no explicit documentation of a 'safe decline' behavior when a question falls outside known knowledge/policy. Missing for 10: explicit fallback/decline behavior for off-knowledge queries, evidence of hallucination prevention or confidence thresholds, and independent confirmation the agent refuses rather than guesses.

   • [claimed-docs] “Require Slack approval before the refund tool runs on amounts above $100.”
   • [claimed-docs] “When a ticket is about an enterprise account, transfer it to the enterprise team with a summary note.”
   • [claimed-docs] “See your live knowledge and its version history - who published what and when, with a diff for every change”

   proof ↗⚑ flag

Supervision

1. support ops leadLaunch in a supervised mode where the agent drafts replies for human approval before anything reaches a customer

   weight 2 · round to Parahelp
   Pylon—none0/10

   Pylon's docs describe agent deployment controls (assigning which issues the agent handles, testing/simulating responses, and an issue log for post-hoc review) but nowhere document a supervised 'draft-for-human-approval-before-send' mode; the language instead emphasizes agents 'taking action' autonomously once deployed.

   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “You can assign them to issues you'd like them to take a look at. This means you have full control of which customer issues your AI agent int…”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Simulate an interaction with the AI and see how it handles different questions.”

   proof ↗⚑ flag

   Parahelp✓fullclaimed8/10

   Docs explicitly state that by default every action requires manual approval, with per-tool/task auto-approve override, and cite concrete examples like Slack approval before refund actions run — directly matching a supervised human-approval-before-customer-impact mode. Releases page tracks and reverts config changes, adding auditability to this guardrail workflow. Missing for 10: independent/hands-on verification of the approval UI in practice and confirmation that 'draft for approval' specifically (vs. blocking tool actions) is the default behavior for all reply types.

   • [claimed-docs] “By default, every action requires manual approval. You can set specific tools to auto-approve per task or automation”
   • [claimed-docs] “Require Slack approval before the refund tool runs on amounts above $100.”
   • [claimed-docs] “Enable auto-approve for a task or automation, and the Internal Agent can perform any action through the connection without asking for approv…”
   • [claimed-docs] “Configuration actions publish as a release on the Releases page, where you can track the impact and revert with one click.”

   proof ↗⚑ flag

Topic controls

1. support ops leadI mark topics as human-only — legal threats, cancellations, security — and the agent never freelances on them

   weight 2 · round to Parahelp
   Pylon~partialclaimed4/10

   Pylon documents assignment-based control—agents only interact with issues explicitly assigned to them, giving admins 'full control of which customer issues your AI agent interacts with'—which could be used to withhold sensitive categories from the agent, and runbooks/skills let you write natural-language handling instructions. But there is no documented feature for marking specific topics (legal threats, cancellations, security) as categorically human-only or any guardrail that blocks the agent from acting on flagged topic types. Missing for 10: an explicit topic/category exclusion or block-list mechanism, enforcement guarantees against agent 'freelancing' on excluded topics, and independent verification that assignment-based control reliably prevents agent action on sensitive categories.

   • [claimed-docs] “You can assign them to issues you'd like them to take a look at. This means you have full control of which customer issues your AI agent int…”
   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

   Parahelp's guardrails let ops leads set conditional rules such as escalating enterprise-account tickets to a human team or requiring approval before certain tools run, and every agent action requires manual approval by default unless explicitly auto-approved — which supports building 'never freelance, hand off to human' rules for chosen topics. However, there's no dedicated 'mark topic as human-only' feature or explicit examples for legal threats/cancellations/security specifically, only generic escalation/approval guardrail examples. Missing for 10: explicit topic-blocklist UI, named legal/cancellation/security guardrail templates, and evidence the escalation is airtight (agent truly cannot act) rather than just gated by approval.

   • [claimed-docs] “Require Slack approval before the refund tool runs on amounts above $100.”
   • [claimed-docs] “When a ticket is about an enterprise account, transfer it to the enterprise team with a summary note.”
   • [claimed-docs] “By default, every action requires manual approval. You can set specific tools to auto-approve per task or automation”
   • [claimed-docs] “Enable auto-approve for a task or automation, and the Internal Agent can perform any action through the connection without asking for approv…”

   proof ↗⚑ flag

Analytics

1. support leaderDashboards show resolution rate, CSAT, handoff rate, and cost per resolution — the numbers I report to my exec team

   weight 3 · round to Pylon
   Pylon~partialclaimed5/10

   Pylon docs confirm built-in analytics dashboards with 'common support metrics' filterable by attributes, supporting general resolution/ticket reporting, but no evidence explicitly names CSAT, handoff rate, or cost-per-resolution as tracked metrics. missing for 10: explicit documentation of CSAT scoring, handoff-rate metric, and cost-per-resolution calculation in dashboards.

   • [claimed-docs] “Pylon comes with a number of default analytics dashboards with common support metrics. All dashboards are filterable by a wide selection of …”

   proof ↗⚑ flag

   Parahelp—none0/10

   No evidence of any dashboard or reporting feature covering resolution rate, CSAT, handoff rate, or cost per resolution; the pack only covers agent configuration, guardrails, integrations, and API access, none of which mention analytics/metrics reporting for support leaders.

   ⚑ flag

Insights

1. support leaderThe platform clusters conversations by topic and surfaces emerging product issues before they spike ticket volume

   weight 1 · round drawn
   Pylon—none0/10

   Evidence shows generic analytics dashboards with filterable metrics (pylon-docs-29) and AI summarization of Slack conversations synced to Salesforce (pylon-docs-33), but nothing describes topic clustering of conversations or proactive surfacing of emerging product issues before ticket volume spikes.

   • [claimed-docs] “Pylon comes with a number of default analytics dashboards with common support metrics. All dashboards are filterable by a wide selection of …”
   • [claimed-docs] “Every day, Pylon scans your customer channels for conversations that were had. For every conversation, we use AI to summarize the details, a…”

   proof ↗⚑ flag

   Parahelp—none0/10

   Parahelp's docs describe automations that 'watch your tools and your support queue and surface gaps on their own' (parahelp-docs-17), but this is about detecting configuration/knowledge gaps, not clustering conversations by topic or flagging emerging issues before ticket volume spikes. No evidence pack item describes topic clustering, trend detection, or predictive volume analytics.

   ⚑ flag

Helpdesk

1. developerThe agent runs inside my existing helpdesk — Zendesk, Salesforce, Intercom — or standalone, syncing tickets and context both ways

   weight 3 · round to Parahelp
   Pylon~partialclaimed3/10

   Evidence shows a one-way sync of AI-summarized conversations into Salesforce Accounts and general 'omnichannel' support language, but there is no evidence of the AI agent embedding inside Zendesk or Intercom, nor of two-way ticket/context syncing with any named helpdesk — Pylon's docs otherwise position it as the standalone system of record. Missing for 10: Zendesk/Intercom integration evidence, bidirectional ticket sync (not just one-way conversation summaries), and confirmation the agent itself operates 'inside' another helpdesk's UI/workflow.

   • [claimed-docs] “Every day, Pylon scans your customer channels for conversations that were had. For every conversation, we use AI to summarize the details, a…”
   • [claimed-docs] “Pylon can support you wherever you interact with your customers.”
   • [claimed-docs] “Using a combination of Webhooks, API, and/or Pylon MCP, you can connect your agent to ticketing workflows in Pylon.”

   proof ↗⚑ flag

   Parahelp✓fullclaimed8/10

   Docs explicitly confirm the Customer Agent works inside Zendesk, Intercom, Front, Plain, or Pylon as a 'team member,' with a standalone API mode for ticket-free workflows, and shared tool/knowledge connections across both agents. Ticket sync/context bidirectionality is implied by the 'team member' integration model and API mode, but no explicit two-way sync mechanics or Salesforce-specific mention are documented. Missing for 10: explicit mention of Salesforce support, and detailed description of two-way ticket/context syncing mechanics beyond high-level integration claims.

   • [claimed-docs] “Your Customer Agent works as a team member in Intercom, Zendesk, Front, Plain, or Pylon.”
   • [claimed-docs] “Parahelp now integrates with Pylon! ... their agents resolve tickets across email, live chat, and Slack”
   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system. Your Customer Agent handles them with the same configurations, tool…”
   • [claimed-docs] “Connect a tool once, and both agents can use it”
   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system.”

   proof ↗⚑ flag

Freshness

1. support ops leadKnowledge stays current automatically — the agent re-syncs sources on a schedule or on change, not via manual re-uploads

   weight 2 · round to Pylon
   Pylon~partialclaimed4/10

   Pylon's knowledge base and training-data docs mention connecting external knowledge sources (pylon-docs-22, pylon-docs-23), and product-data sync can be disabled mid-run (pylon-docs-8), implying some sync mechanism exists, but there is no documentation of a re-sync schedule, change-detection triggers, or automatic re-indexing cadence for knowledge sources. missing for 10: explicit scheduling/frequency controls for knowledge source re-sync, change-detection or webhook-triggered re-sync of external knowledge, and any evidence contradicting or confirming this works hands-on.

   • [claimed-docs] “Make them even more powerful by connecting any external sources of knowledge you have!”
   • [claimed-docs] “A dedicated place to host your support content, including question-and-answer style articles, internal runbooks, and more -- all supercharge…”
   • [claimed-docs] “Disabling a product-data sync now stops any run already in progress”

   proof ↗⚑ flag

   Parahelp~partialclaimed3/10

   Parahelp documents a generic automations feature that can run on a schedule or trigger (parahelp-docs-5) and shows live knowledge with version history (parahelp-docs-9), but there is no explicit documentation that knowledge sources are automatically re-synced on a schedule or on change rather than manually updated. missing for 10: explicit knowledge-source auto-sync mechanism, evidence of scheduled/triggered re-ingestion tied specifically to knowledge base content, independent confirmation of this behavior.

   • [claimed-docs] “An automation is an Internal Agent task that runs on a schedule, like every weekday at 9am, or a trigger, like a GitHub PR merging”
   • [claimed-docs] “See your live knowledge and its version history - who published what and when, with a diff for every change”
   • [claimed-docs] “the Internal Agent analyzes your last 500-1,000 resolved tickets along with your existing context to build the first version of your Custome…”

   proof ↗⚑ flag

Gaps

1. support ops leadThe platform surfaces knowledge gaps and conflicting content that cause the agent to miss or fumble questions

   weight 1 · round to Parahelp
   Pylon—none0/10

   Pylon documents training-data ingestion, a knowledge base, agent simulation/testing, and issue logs for reviewing agent outcomes, but nothing in the evidence describes a feature that proactively surfaces knowledge gaps or flags conflicting content driving agent misses. This is a fair axis for a support-agent platform (comparable products ship content-quality/coverage analytics), so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Simulate an interaction with the AI and see how it handles different questions.”
   • [claimed-docs] “Make them even more powerful by connecting any external sources of knowledge you have!”
   • [claimed-docs] “A dedicated place to host your support content, including question-and-answer style articles, internal runbooks, and more -- all supercharge…”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

   Docs show explicit gap-surfacing automations that watch tools/support queues (parahelp-docs-17) plus knowledge version history with diffs and publisher attribution (parahelp-docs-9), which support detecting stale or conflicting knowledge. However, there's no evidence of conflict detection between multiple knowledge sources, no dashboard/reporting UI shown, and no independent/hands-on corroboration of gap surfacing actually catching missed or fumbled questions. missing for 10: evidence of explicit conflicting-content detection across knowledge sources, a surfaced-gaps UI/report example, and independent verification that this reduces missed/fumbled tickets.

   • [claimed-docs] “Set up automations that watch your tools and your support queue and surface gaps on their own.”
   • [claimed-docs] “See your live knowledge and its version history - who published what and when, with a diff for every change”

   proof ↗⚑ flag

Grounding

1. ai-native userEvery answer is grounded in my own content and shows which article or source it drew from

   weight 3 · round to Pylon
   Pylon~partialclaimed5/10

   Pylon's Support Agents are documented to answer/deflect using a dedicated Knowledge Base and connected external knowledge sources (pylon-docs-13, pylon-docs-22, pylon-docs-23), which supports grounding in the user's own content, but there is no evidence that responses explicitly cite or display which specific article/source was used to generate an answer. missing for 10: explicit citation/source-attribution UI in agent answers, evidence of per-answer source linking, independent confirmation of grounding accuracy.

   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “Make them even more powerful by connecting any external sources of knowledge you have!”
   • [claimed-docs] “A dedicated place to host your support content, including question-and-answer style articles, internal runbooks, and more -- all supercharge…”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”

   proof ↗⚑ flag

   Parahelp—none0/10

   Evidence shows Parahelp maintains a versioned knowledge base (docs-9) that the Customer Agent draws on, but there is no evidence that individual answers to users cite or surface the specific article/source they were grounded in. missing for 10: any documentation of per-answer source citation or attribution UI, evidence of end-user-facing 'grounded in X article' display.

   • [claimed-docs] “See your live knowledge and its version history - who published what and when, with a diff for every change”

   proof ↗⚑ flag

Ingestion

1. support ops leadThe agent ingests my help center, docs, past tickets, and internal wikis as knowledge sources without manual re-authoring

   weight 3 · round drawn
   Pylon~partialclaimed5/10

   Pylon documents a 'training-data' page for connecting external knowledge sources and a Knowledge Base feature for hosting support content and runbooks, suggesting some support for knowledge grounding, but there is no concrete evidence of automated ingestion of help center content, past tickets, or internal wikis without manual re-authoring. Missing for 10: explicit documentation of connectors for help center/docs platforms, wiki integrations (Confluence/Notion), automatic ticket-history ingestion, and any hands-on evidence confirming these sources sync without manual re-entry.

   • [claimed-docs] “Make them even more powerful by connecting any external sources of knowledge you have!”
   • [claimed-docs] “A dedicated place to host your support content, including question-and-answer style articles, internal runbooks, and more -- all supercharge…”
   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”

   proof ↗⚑ flag

   Parahelp~partialclaimed5/10

   Parahelp's Internal Agent explicitly analyzes past resolved tickets and existing context to build the Customer Agent's knowledge/configuration automatically, and there's a live knowledge base with version history, but evidence only covers tickets and general 'existing context' rather than explicit ingestion of help center articles, docs, or internal wikis as named sources. missing for 10: explicit documentation of connectors/ingestion for help-center articles, internal wikis, and docs repositories as knowledge sources; independent evidence of successful re-ingestion at scale beyond ticket history.

   • [claimed-docs] “the Internal Agent analyzes your last 500-1,000 resolved tickets along with your existing context to build the first version of your Custome…”
   • [claimed-docs] “See your live knowledge and its version history - who published what and when, with a diff for every change”
   • [claimed-docs] “Describe the flow you want in natural language - the policies, knowledge, and tool connections it combines - and the Internal Agent configur…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Pylon~partialprobed5/10

   Pylon documents a public REST API and webhooks for programmatically accessing/acting on issues, accounts, and contacts (pylon-docs-31, pylon-docs-32, pylon-docs-4), plus an MCP server that lets AI tools read/update the same core objects (pylon-docs-34, pylon-probe-rt-3). However, there's no evidence the API/MCP surface covers the full breadth of UI capabilities shown in the changelog (custom object forms, analytics dashboards, chat widget branding/customization, knowledge base authoring, triggers/automation config) — these appear UI-only in the evidence pack. Missing for 10: documented API/MCP parity for analytics dashboards, chat widget customization, knowledge base management, and workflow/trigger configuration.

   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [claimed-docs] “Receive webhooks for various events happening in Pylon.”
   • [claimed-docs] “Added a GET /task-statuses API endpoint for enumerating configured task statuses”
   • [claimed-docs] “AI tools authenticate with your Pylon account via OAuth and can read and update issues, accounts, and contacts within the data you can see i…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public REST API at api.usepylon.com is live and cleanly auth-gated — a keyless GET returned HTTP 40…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the first-party MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.usepylon.com ans…”

   proof ↗⚑ flag

   Parahelp~partialprobed5/10

   Parahelp documents API access for core operational tasks—receiving customer requests via API (docs-13, docs-20) and running the Internal Agent's automations via API (docs-14, docs-22)—and a live API reference exists (parahelp-probe-rt-2). However, no evidence shows that configuration authoring, simulation/testing, release management, or knowledge-diff review (all UI-centric per docs-1/2/4/9) can be done via API, and no discoverable OpenAPI spec was found (parahelp-probe-2 shows 404s across standard paths). Missing for 10: API parity for configuration/build workflows, testing/simulation via API, release/rollback via API, formal OpenAPI spec confirming full surface coverage.

   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system. Your Customer Agent handles them with the same configurations, tool…”
   • [claimed-docs] “let the Internal Agent act without waiting for approval, and run it from your own tools via the API.”
   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system.”
   • [claimed-docs] “run it from your own tools via the API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.parahelp.com/openapi.json, https://docs.parahelp.com/swagger.json, https://docs.parahel…”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public API reference at https://app.parahelp.com/api/docs is reachable keylessly — no login wall in…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Pylon—none0/10

   Evidence shows a REST API and webhooks for programmatic access to issues/accounts/contacts, but nothing documents a bulk data-export feature, open-format dump, or data-portability/account-closure workflow that would let a user extract all their data and leave.

   • [claimed-docs] “Pylon's API can be used to programmatically access and take action on data within Pylon.”
   • [claimed-docs] “Receive webhooks for various events happening in Pylon.”
   • [probe] “PROBE runtime (recorded 2026-09-10): the public REST API at api.usepylon.com is live and cleanly auth-gated — a keyless GET returned HTTP 40…”

   proof ↗⚑ flag

   Parahelp—none0/10

   No evidence of any data export functionality, open-format export, or account-closure/data-portability capability in the docs or probes; the material covers agent configuration, tools, and integrations but nothing about exporting user/knowledge data or leaving the platform with data intact.

   ⚑ flag

Pricing

1. support leaderPricing is outcome-based and published — I pay per resolution with caps and controls, not an opaque enterprise quote

   weight 2 · round drawn
   Pylon—none0/10

   No evidence anywhere in the pack of outcome-based or per-resolution pricing, published pricing tiers, caps, or usage-based billing controls; Pylon's documentation covers product features, agents, and APIs but is silent on pricing model or billing transparency.

   ⚑ flag

   Parahelp—none0/10

   No evidence anywhere in the pack of published pricing, per-resolution billing, caps, or outcome-based pricing controls — evidence is entirely about product functionality (agents, guardrails, integrations), not commercial terms.

   ⚑ flag

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

   weight 2 · round drawn
   Pylon—none0/10

   No evidence anywhere in the pack mentions data residency, region selection, or storage location options; only compliance/certification via Vanta is mentioned, which does not address data residency choice. Missing for 10: any mention of regional data centers, residency options, or ability to select storage location.

   • [claimed-docs] “Our compliance and certification are managed by Vanta and our incredible audit partners.”

   proof ↗⚑ flag

   Parahelp—none0/10

   No evidence of data residency or region selection options; only related mention is disabling personal data storage entirely, not choosing storage region. Missing for 10: any mention of region/residency controls, data center location choices, or geographic compliance options.

   • [claimed-docs] “Workspace admins can disable all personal data storage in the platform if they do not want Parahelp to retain this data.”

   proof ↗⚑ flag

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

   weight 3 · round to Parahelp
   Pylon—none0/10

   Evidence pack mentions Pylon's compliance is managed via Vanta (SOC2-type certification) but there is no mention of any AI-training data opt-out, data usage policy for model training, or controls letting users prevent their data from being used to train AI models. Missing for 10: explicit AI-training opt-out/data-usage policy, contractual or product-level control preventing training use, and any documentation addressing this specific privacy concern.

   • [claimed-docs] “Our compliance and certification are managed by Vanta and our incredible audit partners.”

   proof ↗⚑ flag

   Parahelp~partialclaimed4/10

   Parahelp only offers a data-retention control (admins can disable personal data storage) but no explicit statement about excluding customer data from AI model training. missing for 10: explicit no-training-on-customer-data guarantee, opt-out toggle for model training, third-party/independent confirmation of training data handling.

   • [claimed-docs] “Workspace admins can disable all personal data storage in the platform if they do not want Parahelp to retain this data.”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Parahelp
   Pylon—none0/10

   The evidence pack shows security/compliance certification via Vanta and general data handling but contains no documentation of data retention periods, deletion policies, or user/admin controls to delete or export data. Missing for 10: retention policy documentation, deletion/export controls, data lifecycle settings.

   • [claimed-docs] “Our compliance and certification are managed by Vanta and our incredible audit partners.”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

   Parahelp's security docs state that workspace admins can disable all personal data storage, giving explicit control over retention, but there is no documented deletion mechanism (e.g., data export/erasure API, retention period settings) beyond this single toggle. missing for 10: explicit data deletion/export controls, granular retention period settings, independent confirmation of the disable-storage feature.

   • [claimed-docs] “Workspace admins can disable all personal data storage in the platform if they do not want Parahelp to retain this data.”
   • [claimed-docs] “Role-based access across the product.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Pylon—none0/10

   No evidence Pylon offers any telemetry opt-out or usage-tracking controls; evidence only covers compliance certification (Vanta) and product features, not telemetry settings.

   ⚑ flag

   Parahelp—none0/10

   Evidence shows a workspace-level admin control to disable personal data storage, but nothing about opting out of telemetry/usage tracking for the product itself as an AI-native/dev-tool user; missing for 10: any telemetry opt-out setting, docs on analytics collection, or user-level tracking controls.

   • [claimed-docs] “Workspace admins can disable all personal data storage in the platform if they do not want Parahelp to retain this data.”

   proof ↗⚑ flag

Personalization

1. support leaderAnswers use the customer's live data — plan, order status, account history — not just generic help articles

   weight 2 · round drawn
   Pylon~partialclaimed6/10

   Pylon documents product-data syncs, Account Fields, custom objects, and Connectors/Custom API tools/MCP that let AI Support Agents pull in live account/product data (e.g., pylon-docs-8, pylon-docs-21, pylon-docs-22, pylon-docs-33) rather than relying solely on the knowledge base, and Skills/Runbooks let agents act on that data during resolution (pylon-docs-13, pylon-docs-20). However there's no first-party or independent case study showing an actual generated answer citing live plan/order-status/account-history data in a real resolution. Missing for 10: concrete example/transcript of an AI answer referencing live order status or plan data, and independent verification that synced data is actually surfaced in agent responses rather than just accessible to admins.

   • [claimed-docs] “Disabling a product-data sync now stops any run already in progress”
   • [claimed-docs] “If a system does not provide an MCP server, an administrator can define a Custom API tool that agents can use to hit internal or third party…”
   • [claimed-docs] “Make them even more powerful by connecting any external sources of knowledge you have!”
   • [claimed-docs] “Every day, Pylon scans your customer channels for conversations that were had. For every conversation, we use AI to summarize the details, a…”
   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”
   • [claimed-docs] “AI tools authenticate with your Pylon account via OAuth and can read and update issues, accounts, and contacts within the data you can see i…”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

   Docs show the Customer Agent can connect tools to any API (Stripe, internal endpoints) and both agents share connections, which enables pulling live account/order data rather than just static knowledge articles, but no concrete example or case study shows it actually surfacing plan/order-status/account-history data in an answer. missing for 10: a documented example or customer case showing live account/order lookups in a real resolution, and specifics on how live data is merged into agent responses vs. knowledge base content.

   • [claimed-docs] “Tools can use any service with an API: public integrations like Stripe, or your own internal endpoints.”
   • [claimed-docs] “Connect a tool once, and both agents can use it”
   • [claimed-docs] “Anyone can build tools for the Customer Agent without waiting on engineering.”
   • [claimed-docs] “See your live knowledge and its version history - who published what and when, with a diff for every change”

   proof ↗⚑ flag

Reasoning

1. support leaderThe agent asks clarifying questions and works through multi-step troubleshooting instead of dumping one canned answer

   weight 2 · round to Pylon
   Pylon~partialclaimed5/10

   Pylon's Support Agent docs describe multi-step behavior—runbooks with natural-language instructions for specific scenarios, skills as reusable workflow instructions, gathering internal context, and taking action—plus an issue log showing 'outcomes and steps taken by the AI' (pylon-docs-13, pylon-docs-15, pylon-docs-20, pylon-docs-19). However, there is no explicit documentation that the agent proactively asks clarifying questions to the customer rather than issuing a single canned reply; the story's core 'asks clarifying questions' behavior is only implied, not confirmed. Missing for 10: explicit product documentation or example of the agent asking clarifying follow-up questions mid-conversation, and independent/hands-on evidence of multi-turn troubleshooting flows in practice.

   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Simulate an interaction with the AI and see how it handles different questions.”

   proof ↗⚑ flag

   Parahelp—none0/10

   The evidence pack covers configuration, guardrails, approvals, integrations, and knowledge versioning, but nothing describes the Customer Agent's actual conversational behavior—no mention of it asking clarifying questions or performing multi-step troubleshooting dialogue rather than a single scripted reply.

   ⚑ flag

Resolution

1. support leaderThe agent fully resolves a meaningful share of conversations end-to-end — measured as resolutions, not mere deflections or bounces

   weight 3 · round drawn
   Pylon~partialclaimed3/10

   Pylon's own docs describe the Support Agent primarily in terms of 'deflecting' questions and taking actions, with an issue log to inspect outcomes/steps, but there is no first-party or independent metric quantifying full end-to-end resolutions distinct from deflections or bounces. missing for 10: quantified resolution-rate reporting, evidence distinguishing true resolutions from deflections, independent/customer validation of resolution outcomes.

   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”
   • [claimed-docs] “You can assign them to issues you'd like them to take a look at. This means you have full control of which customer issues your AI agent int…”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Pylon comes with a number of default analytics dashboards with common support metrics. All dashboards are filterable by a wide selection of …”

   proof ↗⚑ flag

   Parahelp~partialclaimed3/10

   Docs describe the Customer Agent handling tickets end-to-end with tools/guardrails and note integrations 'resolve tickets across email, live chat, and Slack,' implying resolution capability, but there is no quantified resolution rate, case study, or benchmark distinguishing true resolutions from deflections/bounces. Missing for 10: measured resolution-rate metrics, customer case studies with numbers, and independent verification of end-to-end resolution vs. escalation rates.

   • [claimed-docs] “Your Customer Agent works as a team member in Intercom, Zendesk, Front, Plain, or Pylon.”
   • [claimed-docs] “Parahelp now integrates with Pylon! ... their agents resolve tickets across email, live chat, and Slack”
   • [claimed-docs] “Customer requests come in through the API instead of a ticketing system. Your Customer Agent handles them with the same configurations, tool…”

   proof ↗⚑ flag

Voice

1. support leaderI control the agent's tone and brand voice, and it stays consistent across topics and languages

   weight 1 · round to Pylon
   Pylon~partialclaimed3/10

   Pylon's AI Agent can be configured with natural-language runbooks and reusable 'skills' that dictate how it handles specific scenarios, which could be used to encode tone/brand-voice guidance, but the docs never explicitly mention persona/tone control or consistency across languages. missing for 10: explicit tone/brand-voice configuration settings, evidence of multilingual consistency, and any customer/independent proof the agent's voice stays consistent across topics.

   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”
   • [claimed-docs] “Support Agents can deflect customer questions using content, gather internal context for your team, and take action.”

   proof ↗⚑ flag

   Parahelp—none0/10

   The evidence covers configuration via natural language, knowledge base versioning, guardrails, and tool integrations, but nothing addresses tone/brand-voice control or consistency across topics and languages. Missing for 10: any documentation or claim about persona/tone settings, brand voice configuration, or multilingual consistency testing.

   ⚑ flag

Qa

1. support ops leadAI conversations get ongoing QA — scored samples, flagged failures, and a review loop that feeds fixes back into the agent

   weight 1 · round drawn
   Pylon~partialclaimed5/10

   Pylon documents a monitor-and-iterate loop: a 'test' simulation mode to probe agent behavior, an issue log to inspect outcomes/steps taken by the AI, and runbooks/skills that let ops feed corrections back into the agent's instructions. However, there's no evidence of structured QA scoring of samples or a formal flagged-failure workflow with review states — it's more free-form inspection than a scored QA/review pipeline. Missing for 10: sample scoring/rubrics, dedicated failure-flagging workflow with reviewer roles, and quantitative QA metrics tied back to agent training.

   • [claimed-docs] “Simulate an interaction with the AI and see how it handles different questions.”
   • [claimed-docs] “You can assign them to issues you'd like them to take a look at. This means you have full control of which customer issues your AI agent int…”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”
   • [claimed-docs] “Skills are reusable instructions that teach Pylon agents how to handle specific workflows consistently.”

   proof ↗⚑ flag

   Parahelp~partialclaimed5/10

   Parahelp offers simulation-based testing before release (docs-2), release tracking/revert (docs-4), and automations that 'watch your tools and support queue and surface gaps' (docs-17), which map loosely to a QA/review loop feeding fixes back. However there is no evidence of a structured scored-sample QA program, explicit failure flagging on live conversations, or a dedicated review dashboard for support-ops to audit agent conversations. Missing for 10: scored sampling of live conversations, explicit failure-flag workflow, dedicated QA review UI/report distinct from gap-detection automations.

   • [claimed-docs] “Simulations replay your historical tickets - or mock scenarios - against the configurations in the task, and production tests verify your to…”
   • [claimed-docs] “Configuration actions publish as a release on the Releases page, where you can track the impact and revert with one click.”
   • [claimed-docs] “Set up automations that watch your tools and your support queue and surface gaps on their own.”
   • [claimed-docs] “See your live knowledge and its version history - who published what and when, with a diff for every change”

   proof ↗⚑ flag

Simulation

1. support ops leadI test the agent against historical tickets or simulated conversations before it faces real customers

   weight 2 · round to Parahelp
   Pylon~partialclaimed6/10

   Pylon's docs explicitly describe a test/simulate feature ('Simulate an interaction with the AI and see how it handles different questions') plus an issue log to inspect outcomes, which supports pre-deployment validation and monitoring. However, there's no explicit mention of testing against historical ticket datasets in bulk, regression testing, or scoring accuracy across a corpus of past conversations. missing for 10: bulk/historical-ticket backtesting workflow, quantitative accuracy/regression metrics from test runs, independent/hands-on confirmation of the simulate feature's depth.

   • [claimed-docs] “Simulate an interaction with the AI and see how it handles different questions.”
   • [claimed-docs] “You can assign them to issues you'd like them to take a look at. This means you have full control of which customer issues your AI agent int…”
   • [claimed-docs] “The issue log allows you to inspect all the issues the AI agent is associated with and inspect the outcomes and steps taken by the AI.”
   • [claimed-docs] “Write instructions in natural language to help your AI Agent handle specific scenarios.”

   proof ↗⚑ flag

   Parahelp✓fullclaimed8/10

   Docs explicitly describe simulations that replay historical tickets or mock scenarios against configurations, plus production tests to verify tool connections, directly matching the story of pre-launch testing before facing real customers. Missing for 10: no independent/hands-on corroboration of simulation accuracy or third-party validation of the testing workflow.

   • [claimed-docs] “Simulations replay your historical tickets - or mock scenarios - against the configurations in the task, and production tests verify your to…”
   • [claimed-docs] “the Internal Agent analyzes your last 500-1,000 resolved tickets along with your existing context to build the first version of your Custome…”

   proof ↗⚑ flag