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

   Decagon documents scoped, short-lived JWT access for agent actions across customer systems and integrations 'with no custom code required,' plus explicit mention of agents adjusting 'refund logic,' supporting real action-taking with scoped auth. However there's no detailed documentation of per-action granularity (e.g., separate refund vs subscription-update scopes), no audit trail examples, and no independent/hands-on verification of actual API action execution — missing for 10: per-action scope definitions, action audit logging, and third-party verification of real transactional actions.

   • [claimed-docs] “Short-lived JWT tokens give AI agents real-time access to customer systems, scoped for minimal privilege and discarded after each session.”
   • [claimed-docs] “no custom code required”
   • [claimed-docs] “with no custom code required”
   • [claimed-docs] “Whether you’re refining tone, adjusting refund logic, or trialing a new onboarding experience, experimentation makes it safe to test, learn,…”
   • [claimed-docs] “lets your Decagon agent access and complete tasks inside systems where there isn’t a traditional integration available”

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

   Decagon explicitly ships 'Agent Operating Procedures (AOPs)' described as letting teams 'define agent behavior in natural language, the same way you train human agents with SOPs,' with Duet auto-generating and iterating these procedures from real interactions. This directly matches encoding step-by-step SOPs for known issue types. Missing for 10: concrete technical detail on how branching logic/decision trees are structured and enforced deterministically, and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “you can define agent behavior in natural language, the same way you train human agents with SOPs”
   • [claimed-docs] “Analyze past customer interactions to automatically generate Agent Operating Procedures (AOPs) rooted in actual customer needs.”
   • [claimed-docs] “Non-technical teams can architect and iterate on agent logic with Agent Operating Procedures (AOPs) and Duet”
   • [claimed-docs] “Non-technical teams can architect and iterate on agent logic with Agent Operating Procedures (AOPs) and Duet, while technical teams retain f…”
   • [claimed-docs] “As conversations reveal gaps and new opportunities, Duet automatically iterates on your agent, from the first launch through every improveme…”

   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
   Decagon~partialprobed6/10

   The probe confirms Decagon serves a working llms.txt file at decagon.ai/llms.txt (HTTP 200) with structured product description, showing the product is discoverable by AI agents pointed at agent-oriented docs. However, there's no evidence of broader agent-oriented documentation (e.g., structured API docs, OpenAPI spec which 404'd) or first-party guidance encouraging users to point agents at this file. missing for 10: OpenAPI/API-level machine-readable docs (404s confirmed), first-party documentation explicitly promoting llms.txt usage for AI agents, and independent corroboration of an agent successfully consuming the file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://decagon.ai/llms.txt # Decagon Decagon is an enterprise-grade AI platform revolutionizing customer suppo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://decagon.ai/openapi.json, https://decagon.ai/swagger.json, https://decagon.ai/api/openapi.jso…”

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

   Decagon is a SaaS conversational-AI platform for customer support with no-code configuration (AOPs, Duet, integrations 'no custom code required'); there is no documented CLI, headless mode, or CI-automation interface, and the openapi probe returned 404s, indicating no public API spec for automated/headless invocation. missing for 10: any CLI/SDK for headless execution, CI-pipeline integration docs, or public API reference enabling automation.

   • [claimed-docs] “no custom code required”
   • [claimed-docs] “with no custom code required”
   • [probe] “PROBE openapi: all candidate paths 404 (https://decagon.ai/openapi.json, https://decagon.ai/swagger.json, https://decagon.ai/api/openapi.jso…”

   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 Decagon
   Decagon~partialclaimed3/10

   Decagon has a blog post explicitly about MCP ("getting the most out of MCP") describing an infrastructure layer to curate, scope, and evaluate tool usage, indicating some MCP integration capability, but there is no concrete documentation of how to actually plug an MCP server into an agent, no config steps, and no independent corroboration of it working. missing for 10: technical setup docs for adding an MCP server, list of supported MCP servers/tools, hands-on or independent verification that agents actually invoke MCP tools.

   • [claimed-docs] “Bridging that gap requires an infrastructure layer purpose-built to curate, scope, and evaluate how tools are actually used.”

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

   No evidence of a documented public API; the openapi probe returned 404s across all candidate paths and no docs reference an API reference, SDK, or programmatic endpoint. Integrations are described as 'no custom code required' (docs-19, docs-26), suggesting no-code/UI-driven configuration rather than a documented API for AI-native control.

   • [probe] “PROBE openapi: all candidate paths 404 (https://decagon.ai/openapi.json, https://decagon.ai/swagger.json, https://decagon.ai/api/openapi.jso…”
   • [claimed-docs] “no custom code required”
   • [claimed-docs] “with no custom code required”

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

   Decagon documents short-lived, scoped JWT tokens for agent access to customer systems and identity-provider (Okta/Entra) integration, which shows some least-privilege credential mechanics, but this is about the agent's own runtime access rather than a user-facing capability to explicitly issue/manage scoped API credentials for an agent. There's no evidence of an API/console feature letting an AI-native user provision, scope, or revoke discrete credentials themselves. missing for 10: user-facing credential issuance/management UI or API, granular scoping controls exposed to users, independent verification of the JWT scoping claims.

   • [claimed-docs] “Short-lived JWT tokens give AI agents real-time access to customer systems, scoped for minimal privilege and discarded after each session.”
   • [claimed-docs] “Decagon integrates with identity providers like Okta and Microsoft Entra, enabling secure access across systems without additional passwords…”

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

   No evidence of official SDKs for developers; the pack shows only no-code integrations, MCP blog commentary, and a failed openapi probe (404s), with no SDK documentation or API libraries surfaced.

   • [claimed-docs] “Bridging that gap requires an infrastructure layer purpose-built to curate, scope, and evaluate how tools are actually used.”
   • [claimed-docs] “no custom code required”
   • [claimed-docs] “with no custom code required”
   • [probe] “PROBE openapi: all candidate paths 404 (https://decagon.ai/openapi.json, https://decagon.ai/swagger.json, https://decagon.ai/api/openapi.jso…”

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

   No evidence in the pack mentions webhooks, event subscriptions, or any push-notification mechanism; the OpenAPI probe returned 404s and no API reference documenting webhook endpoints was found. This axis applies (Decagon integrates with external systems and could plausibly offer webhooks) but there is no supporting evidence.

   • [probe] “PROBE openapi: all candidate paths 404 (https://decagon.ai/openapi.json, https://decagon.ai/swagger.json, https://decagon.ai/api/openapi.jso…”

   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 to Decagon
   Decagon✓fullclaimed8/10

   Decagon's Insights & Reporting and Suggestions features let users ask open-ended natural-language questions (e.g. 'Why are customers requesting refunds?') and get AI-driven analysis, heatmaps, and auto-generated content drafts based on detected knowledge gaps, directly surfacing AI-generated insights from customer data. Duet further auto-generates Agent Operating Procedures from past interactions and iterates based on conversation patterns. Missing for 10: independent/hands-on validation of insight quality and no detail on underlying analytics accuracy or limitations.

   • [claimed-docs] “Ask open-ended questions like “Why are customers requesting refunds?” to instantly analyze customer conversations.”
   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues, so your…”
   • [claimed-docs] “Customizable visual heatmaps... Quickly identify spikes or dips in key metrics.”
   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues”
   • [claimed-docs] “Ask AI powers deeper analysis through flexible, conversational queries.”
   • [claimed-docs] “Analyze past customer interactions to automatically generate Agent Operating Procedures (AOPs) rooted in actual customer needs.”
   • [claimed-docs] “As conversations reveal gaps and new opportunities, Duet automatically iterates on your agent, from the first launch through every improveme…”

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

   Decagon's Proactive Agents can carry context across sessions and autonomously initiate calls/recommendations based on customer signals, and Watchtower continuously monitors every interaction against custom criteria without manual triggering — both indicate background/autonomous operation. However, there's no explicit documentation of a general-purpose automation/scheduling framework (e.g., triggers, cron-like workflows, or arbitrary background tasks) beyond these two specific features. Missing for 10: a dedicated automation/scheduler product surface, independent/hands-on verification of autonomous behavior, and broader configurability beyond proactive outreach and monitoring.

   • [claimed-docs] “Carry conversation history across sessions to pick up where you left off and make proactive recommendations based on customer signals.”
   • [claimed-docs] “Initiate intelligent, on-brand calls that reliably reach customers at the right moments throughout their journey.”
   • [claimed-docs] “Maintain customer context across sessions, complementing your systems of record with data portability and control.”
   • [claimed-docs] “Whether you're monitoring for compliance risks, negative sentiment, or upsell signals, Watchtower reviews every interaction against your cus…”

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

   Decagon's Duet acts as an in-product AI helper that lets (non-technical) users delegate specific tasks — auto-generating Agent Operating Procedures from past conversations, drafting tests, and producing content suggestions — which is a form of delegating work to a built-in assistant, but it's narrowly scoped to agent-configuration/QA tasks rather than a general-purpose assistant for arbitrary user tasks. missing for 10: evidence of a general-purpose in-product assistant handling open-ended user requests beyond AOP/test/content generation, independent/hands-on validation of Duet's delegation quality, and detail on how broadly tasks can be delegated versus templated workflows.

   • [claimed-docs] “Non-technical teams can architect and iterate on agent logic with Agent Operating Procedures (AOPs) and Duet”
   • [claimed-docs] “Analyze past customer interactions to automatically generate Agent Operating Procedures (AOPs) rooted in actual customer needs.”
   • [claimed-docs] “Use Duet to easily generate tests covering diverse pathways that verify whether agents respond accurately, follow policies, and reflect your…”
   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues, so your…”

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

   Decagon lets operators define agent behavior, flagging criteria, and analytics queries via natural language (AOPs, Watchtower, Ask AI), which supports natural-language operation of the product for configuration/analysis purposes. However, this is primarily aimed at business/support-ops users configuring an agent, not a general 'AI-native user' issuing arbitrary natural-language commands to control the whole product end-to-end. missing for 10: evidence of natural-language command interface for broader product operations (e.g., admin tasks, integrations setup, deployment) beyond AOPs/Watchtower/Insights, and independent/hands-on verification of this capability.

   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “you can define agent behavior in natural language, the same way you train human agents with SOPs”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Ask AI powers deeper analysis through flexible, conversational queries.”
   • [claimed-docs] “Ask open-ended questions like “Why are customers requesting refunds?” to instantly analyze customer conversations.”

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

   No evidence of an interactive API reference or runnable examples; the openapi probe returned 404 across all candidate paths and no docs mention API documentation with runnable examples. Missing for 10: any API reference page, SDK/runnable code samples, interactive docs like Swagger/Redoc, or developer sandbox.

   • [probe] “PROBE openapi: all candidate paths 404 (https://decagon.ai/openapi.json, https://decagon.ai/swagger.json, https://decagon.ai/api/openapi.jso…”

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

   Probe explicitly checked common OpenAPI/swagger endpoints and all returned 404, and no documentation references a downloadable machine-readable API spec; only an llms.txt file was found, which is not an API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://decagon.ai/openapi.json, https://decagon.ai/swagger.json, https://decagon.ai/api/openapi.jso…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://decagon.ai/llms.txt # Decagon Decagon is an enterprise-grade AI platform revolutionizing customer suppo…”

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

   Decagon's Testing & QA product describes 'Simulations' that validate agent behavior 'before deploying to production and with every subsequent update' (decagon-docs-29) and Duet-generated test suites (decagon-docs-11), implying a pre-production testing environment. However, there is no explicit documentation of a dedicated sandbox with isolated/non-production data, and the Experiments feature explicitly runs live in production (decagon-docs-7), which cuts against a clear sandbox-vs-production separation. Missing for 10: explicit description of sandbox data isolation, confirmation that test/simulation environments don't touch live customer data, and independent verification of this claim.

   • [claimed-docs] “Simulations, Decagon's integrated testing suite, help teams validate agent behavior across channels before deploying to production and with …”
   • [claimed-docs] “Use Duet to easily generate tests covering diverse pathways that verify whether agents respond accurately, follow policies, and reflect your…”
   • [claimed-docs] “Define your variable and traffic split, then measure results against a stable control group directly in production.”

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

   No evidence of a public/versioned API, API changelog, or deprecation policy; the openapi probe returned 404s across all candidate paths and no docs mention API versioning or deprecation practices.

   • [probe] “PROBE openapi: all candidate paths 404 (https://decagon.ai/openapi.json, https://decagon.ai/swagger.json, https://decagon.ai/api/openapi.jso…”

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

   No evidence describes a bulk-operations feature (e.g., batch editing, bulk tagging, bulk export/import of tickets or conversations) for AI-native users; the closest items describe aggregate analysis (Watchtower reviewing every interaction, Insights analyzing many conversations) rather than user-driven bulk actions across items.

   ⚑ 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 to Parahelp
   Decagon~partialclaimed5/10

   Decagon offers Watchtower, which monitors conversations against natural-language criteria and can flag/surface events (compliance risks, sentiment, etc.), and Proactive Agents that act on customer signals (e.g., initiating calls, recommendations) — both function as event-triggered automation. However, there is no explicit documentation of a general-purpose rule-builder (if-event-then-action) framework that an AI-native user could configure directly; the evidence describes narrower, product-specific triggering mechanisms rather than a flexible automation-rules engine. Missing for 10: explicit rule/condition builder UI or API, documentation of arbitrary event types and action bindings, and independent verification of how these triggers are configured.

   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Whether you're monitoring for compliance risks, negative sentiment, or upsell signals, Watchtower reviews every interaction against your cus…”
   • [claimed-docs] “Carry conversation history across sessions to pick up where you left off and make proactive recommendations based on customer signals.”
   • [claimed-docs] “Initiate intelligent, on-brand calls that reliably reach customers at the right moments throughout their journey.”
   • [claimed-docs] “you can define agent behavior in natural language, the same way you train human agents with SOPs”

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

   Decagon's evidence covers customer-support agent features (chat, voice, email, analytics, testing, proactive outreach) but nothing addresses scheduling recurring jobs or workflows in the AI-native/automation-depth sense; proactive agents mention initiating calls at 'right moments' but no scheduling/cron-like mechanism is documented. missing for 10: any scheduler, cron/recurring trigger config, or workflow automation timing controls.

   ⚑ 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
   Decagon~partialclaimed4/10

   Decagon offers some adjacent controls—technical teams retain 'visibility and control over guardrails, integrations, and versioning' and Simulations/testing validate agent behavior 'before deploying to production and with every subsequent update'—suggesting some change-management workflow exists, but there's no explicit documentation of version history browsing, diffing, review/approval workflows, or a rollback mechanism to a prior automation state. missing for 10: explicit versioning UI/history, review/approval workflow for changes, documented rollback mechanism, independent confirmation of these capabilities in use.

   • [claimed-docs] “technical teams retain full visibility and control over guardrails, integrations, and versioning”
   • [claimed-docs] “Non-technical teams can architect and iterate on agent logic with Agent Operating Procedures (AOPs) and Duet, while technical teams retain f…”
   • [claimed-docs] “Simulations, Decagon's integrated testing suite, help teams validate agent behavior across channels before deploying to production and with …”

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

   Decagon clearly offers a unified agent across chat (web, mobile, messaging platforms), email, and voice, suggesting broad channel reach [decagon-docs-13][decagon-docs-14][decagon-docs-15], with proactive/session-continuity features tying channels together [decagon-docs-22][decagon-docs-28]. However, the evidence never names specific channels like Slack, WhatsApp, or social media explicitly — only generic 'messaging platforms' is mentioned. Missing for 10: explicit documentation naming Slack, WhatsApp, and social media integrations as supported channels, plus any customer proof of omnichannel handoff across these specific channels.

   • [claimed-docs] “Flexible, on-brand chat built for conversations across web, mobile, and messaging platforms.”
   • [claimed-docs] “Voice AI agents built for natural, multilingual conversations and customized to your brand.”
   • [claimed-docs] “Intelligent email that understands context, stays on brand, and handles complex customer threads.”
   • [claimed-docs] “Carry conversation history across sessions to pick up where you left off and make proactive recommendations based on customer signals.”
   • [claimed-docs] “Maintain customer context across sessions, complementing your systems of record with data portability and control.”

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

   Only the Voice product page explicitly claims multilingual capability ('built for natural, multilingual conversations'); there is no evidence that Chat or Email channels support multiple languages, nor any documentation of translating or drawing from an English-only knowledge base to serve other languages. Missing for 10: explicit multilingual support claims for chat/email channels, description of how KB content is translated/localized, and independent verification of multilingual quality.

   • [claimed-docs] “Voice AI agents built for natural, multilingual conversations and customized to your brand.”
   • [claimed-docs] “Flexible, on-brand chat built for conversations across web, mobile, and messaging platforms.”
   • [claimed-docs] “Intelligent email that understands context, stays on brand, and handles complex customer threads.”

   proof ↗⚑ 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 to Decagon
   Decagon~partialclaimed6/10

   Decagon explicitly offers a Voice product for 'natural, multilingual conversations' and can 'initiate intelligent, on-brand calls,' and its platform architecture (AOPs, integrations, guardrails) is shared across channels including chat, implying shared knowledge/actions. However, there's no explicit vendor statement confirming full parity of knowledge/actions between voice and chat, no technical detail on speech-to-speech quality, and no independent/hands-on corroboration of call handling. Missing for 10: explicit parity confirmation between voice and chat agent logic, technical/latency details of the voice pipeline, independent or customer testimonial evidence of voice call handling in production.

   • [claimed-docs] “Voice AI agents built for natural, multilingual conversations and customized to your brand.”
   • [claimed-docs] “Initiate intelligent, on-brand calls that reliably reach customers at the right moments throughout their journey.”
   • [claimed-docs] “Flexible, on-brand chat built for conversations across web, mobile, and messaging platforms.”
   • [claimed-docs] “you can define agent behavior in natural language, the same way you train human agents with SOPs”
   • [claimed-docs] “Non-technical teams can architect and iterate on agent logic with Agent Operating Procedures (AOPs) and Duet, while technical teams retain f…”

   proof ↗⚑ 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 to Parahelp
   Decagon—none0/10

   The evidence pack contains no mention of escalation-to-human handoff, conversation summaries handed to agents, or collected-details transfer preventing repetition. Related items about cross-session context (decagon-docs-22, decagon-docs-28) address agent-to-customer continuity, not human-agent handoff, so the specific story is unevidenced despite being a plausible capability for a support AI platform.

   ⚑ 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
   Decagon~partialclaimed4/10

   Decagon's AOPs let teams define agent behavior in natural language (like SOPs), which could include escalation logic, and Watchtower can flag sentiment/compliance signals, but no evidence explicitly describes configuring handoff triggers by topic, sentiment, customer tier, or explicit request, nor confirms reliable adherence to such rules. Simulations/testing-QA claims validating 'policies' are generic and don't specifically address handoff reliability. Missing for 10: explicit documentation of handoff/escalation configuration options, tier-based routing, and evidence of reliable handoff obedience (e.g., test results or case studies on escalation accuracy).

   • [claimed-docs] “you can define agent behavior in natural language, the same way you train human agents with SOPs”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Whether you're monitoring for compliance risks, negative sentiment, or upsell signals, Watchtower reviews every interaction against your cus…”
   • [claimed-docs] “Non-technical teams can architect and iterate on agent logic with Agent Operating Procedures (AOPs) and Duet, while technical teams retain f…”
   • [claimed-docs] “Simulations, Decagon's integrated testing suite, help teams validate agent behavior across channels before deploying to production and with …”

   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 drawn
   Decagon~partialclaimed4/10

   Decagon provides AOPs to define agent behavior/policies in natural language and a testing suite (Simulations/Duet) that verifies agents 'respond accurately, follow policies' plus Watchtower monitoring for compliance violations, which are the building blocks for guardrails — but no evidence explicitly describes a safe-decline behavior for off-knowledge questions versus fabricating answers. missing for 10: explicit documentation or examples of the agent refusing/declining out-of-scope questions rather than hallucinating, and independent verification that guardrails actually prevent invented prices/policies in practice.

   • [claimed-docs] “you can define agent behavior in natural language, the same way you train human agents with SOPs”
   • [claimed-docs] “Use Duet to easily generate tests covering diverse pathways that verify whether agents respond accurately, follow policies, and reflect your…”
   • [claimed-docs] “Simulations, Decagon's integrated testing suite, help teams validate agent behavior across channels before deploying to production and with …”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Whether you're monitoring for compliance risks, negative sentiment, or upsell signals, Watchtower reviews every interaction against your cus…”

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

   Decagon's evidence covers testing/simulation (Simulations, Duet), experiments, guardrails, and monitoring (Watchtower), but nothing describes a supervised/human-in-the-loop 'draft-for-approval' mode where a human must approve each reply before it reaches a customer. Testing/QA and experiments happen pre-production or on traffic splits, not as a live approval queue for individual replies.

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

   Decagon's AOPs let teams define agent behavior/escalation rules in natural language, and 'guardrails' are described as retained under technical team control, which could support marking certain topics as human-only; Watchtower can flag legal/compliance/sentiment topics for review. However, there's no explicit documentation of a dedicated 'human-only topic' or hard-escalation feature, nor any evidence (hands-on or audit) confirming the agent never engages on flagged categories. Missing for 10: explicit human-only/topic-exclusion configuration feature, proof/testing that the agent reliably refuses or escalates on those topics, and independent verification of enforcement.

   • [claimed-docs] “technical teams retain full visibility and control over guardrails, integrations, and versioning”
   • [claimed-docs] “you can define agent behavior in natural language, the same way you train human agents with SOPs”
   • [claimed-docs] “Non-technical teams can architect and iterate on agent logic with Agent Operating Procedures (AOPs) and Duet, while technical teams retain f…”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Whether you're monitoring for compliance risks, negative sentiment, or upsell signals, Watchtower reviews every interaction against your cus…”

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

   Decagon's Insights & Reporting product includes customizable dashboards, visual heatmaps for key metrics, and 'Ask AI' conversational analytics for querying conversation trends, which supports general exec-reporting use cases. However, the evidence never explicitly names resolution rate, CSAT, handoff rate, or cost-per-resolution as tracked/reported metrics. missing for 10: explicit confirmation that CSAT, resolution rate, handoff rate, and cost-per-resolution are specific dashboard metrics; independent/customer corroboration of these exact KPIs being reported to execs.

   • [claimed-docs] “Ask open-ended questions like “Why are customers requesting refunds?” to instantly analyze customer conversations.”
   • [claimed-docs] “Customizable visual heatmaps... Quickly identify spikes or dips in key metrics.”
   • [claimed-docs] “Ask AI powers deeper analysis through flexible, conversational queries.”

   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 to Decagon
   Decagon~partialclaimed7/10

   Decagon's Insights & Reporting and Watchtower products support natural-language querying of conversations (e.g., 'Why are customers requesting refunds?'), heatmaps to spot spikes/dips in key metrics, and custom flagging criteria across every interaction, which together enable topic-level pattern detection and early issue surfacing. However, the evidence never explicitly describes automated topic clustering or a proactive 'before ticket volume spikes' alerting mechanism—these are inferred from adjacent features. Missing for 10: explicit description of automatic conversation clustering by topic, independent/hands-on evidence of early trend detection preventing ticket spikes, and case-study proof of this specific insight workflow in production.

   • [claimed-docs] “Ask open-ended questions like “Why are customers requesting refunds?” to instantly analyze customer conversations.”
   • [claimed-docs] “Customizable visual heatmaps... Quickly identify spikes or dips in key metrics.”
   • [claimed-docs] “Ask AI powers deeper analysis through flexible, conversational queries.”
   • [claimed-docs] “Whether you're monitoring for compliance risks, negative sentiment, or upsell signals, Watchtower reviews every interaction against your cus…”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues, so your…”

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

   Decagon's integrations page claims no-code integrations and system-of-record data portability, and Browser Actions/MCP posts describe connecting to arbitrary systems including ones without native integrations, implying support for helpdesk platforms like Zendesk/Salesforce/Intercom, but no evidence explicitly names these tools or describes ticket-level two-way sync. Missing for 10: named connectors/case studies for Zendesk, Salesforce, or Intercom, explicit description of bidirectional ticket-context syncing, and confirmation of standalone deployment mode.

   • [claimed-docs] “no custom code required”
   • [claimed-docs] “with no custom code required”
   • [claimed-docs] “Decagon integrates with identity providers like Okta and Microsoft Entra, enabling secure access across systems without additional passwords…”
   • [claimed-docs] “Maintain customer context across sessions, complementing your systems of record with data portability and control.”
   • [claimed-docs] “Browser Actions gives your agent a way through computer use. It extends the agent you've already built so it can log in, navigate, and compl…”
   • [claimed-docs] “lets your Decagon agent access and complete tasks inside systems where there isn’t a traditional integration available”
   • [claimed-docs] “Bridging that gap requires an infrastructure layer purpose-built to curate, scope, and evaluate how tools are actually used.”

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

   The evidence pack covers knowledge gap detection and content suggestions (docs-10/18), integrations without custom code, and agent iteration via Duet, but nowhere mentions automatic re-syncing of knowledge sources on a schedule or on change — the closest analog (Suggestions) generates draft content for humans to review/publish, not an automated re-sync pipeline. Missing for 10: any mention of scheduled/triggered re-ingestion of source documents, sync frequency, or change-detection on connected knowledge bases.

   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues, so your…”
   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues”

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

   Decagon's Suggestions product explicitly automates detection of knowledge gaps and drafts content based on how top human agents resolved similar issues, directly addressing the story's core need, and Insights/Watchtower let ops teams query conversations to surface where the agent struggles or conflicts arise. Missing for 10: independent/hands-on verification of gap detection accuracy, and no explicit mention of surfacing 'conflicting content' across knowledge sources rather than just gaps.

   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues, so your…”
   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues”
   • [claimed-docs] “Ask open-ended questions like “Why are customers requesting refunds?” to instantly analyze customer conversations.”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Customizable visual heatmaps... Quickly identify spikes or dips in key metrics.”

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

   Decagon's evidence describes knowledge-gap detection, AOP generation, and content suggestions (docs-10, docs-18) but nothing shows that end-user-facing answers actually cite or display the specific article/source they were grounded in. Missing for 10: any documentation of inline citations, source attribution UI, or 'view source' feature in chat/voice/email responses.

   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues, so your…”
   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues”
   • [claimed-docs] “Flexible, on-brand chat built for conversations across web, mobile, and messaging platforms.”

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

   Decagon's integrations page claims 'no custom code required' connections (docs-19/26) and its Suggestions product analyzes help-center content and past agent resolutions to fill knowledge gaps (docs-10/18), implying some ingestion of existing content, but there is no explicit documentation naming help center, internal wikis, docs, and past tickets as ingestible knowledge sources without re-authoring. missing for 10: explicit list/documentation of supported knowledge source connectors (help center, wikis, ticket systems), evidence of automatic re-indexing without manual content rewriting, and independent confirmation of successful multi-source ingestion.

   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues, so your…”
   • [claimed-docs] “It automatically detects knowledge gaps and generates content drafts based on how your best human agents resolved those same issues”
   • [claimed-docs] “no custom code required”
   • [claimed-docs] “with no custom code required”

   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 to Parahelp
   Decagon—none0/10

   No evidence of a public API at all — the openapi probe returned 404 across all candidate paths, and none of the docs describe an API that mirrors UI capabilities like AOP configuration, Duet, Watchtower, or experiments. Absence of evidence for this applicable capability yields none.

   • [probe] “PROBE openapi: all candidate paths 404 (https://decagon.ai/openapi.json, https://decagon.ai/swagger.json, https://decagon.ai/api/openapi.jso…”

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

   Decagon's evidence pack contains no documented data-export feature, open-format export tooling, or account-deletion/portability workflow; the only tangential mention ("data portability and control" in decagon-docs-28) is vague marketing language about maintaining conversation context, not a concrete export/exit mechanism, and the probe shows no public API/OpenAPI spec that could support programmatic data extraction.

   • [claimed-docs] “Maintain customer context across sessions, complementing your systems of record with data portability and control.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://decagon.ai/openapi.json, https://decagon.ai/swagger.json, https://decagon.ai/api/openapi.jso…”

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

   No evidence pack item mentions pricing, resolution-based billing, caps, controls, or published pricing pages — all evidence concerns product features (AOPs, Duet, Watchtower, integrations, security) rather than pricing model. Absence of evidence for this applicable axis yields 'none'. Missing for 10: published pricing page, resolution-based billing structure, caps/controls documentation, any pricing transparency claims.

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

   No evidence pack item mentions data residency, region selection, or storage location controls; security page content covers JWTs and SSO but not data residency options. Missing for 10: any mention of regional data storage, residency compliance (e.g., EU/US hosting options), or customer-facing controls to choose storage location.

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

   No evidence in the pack addresses data usage for AI model training or an opt-out/no-training policy; the security page covers JWT tokens and SSO but not training data practices.

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

   Decagon only vaguely references 'data portability and control' alongside customer context retention, and short-lived JWT tokens discarded after each session, but there is no explicit documentation of configurable data retention periods, deletion APIs, or user-facing controls to purge stored customer data. missing for 10: explicit retention policy/settings, a documented deletion mechanism or API, and independent verification that deletion requests are honored.

   • [claimed-docs] “Maintain customer context across sessions, complementing your systems of record with data portability and control.”
   • [claimed-docs] “Short-lived JWT tokens give AI agents real-time access to customer systems, scoped for minimal privilege and discarded after each session.”

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

   No evidence in the pack addresses telemetry/usage-tracking opt-out controls; the security and product pages cover access control, JWT tokens, and SSO but never mention analytics/telemetry opt-out settings for end users. Missing for 10: any documentation of a telemetry toggle, data-collection opt-out mechanism, or privacy settings page.

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

   Decagon's docs describe real-time, scoped access to customer systems via short-lived JWTs, MCP-based tool integrations, and Browser Actions that let agents log into and pull data from any system (including those without native integrations), which supports live-data-driven answers rather than static help content. However, there is no concrete example or case study showing an actual answer surfacing a customer's plan, order status, or account history — the evidence is architectural/capability-level rather than demonstrated output. Missing for 10: a documented example or case study showing live plan/order/account data appearing in an actual customer-facing answer, and independent verification that this works in production.

   • [claimed-docs] “Short-lived JWT tokens give AI agents real-time access to customer systems, scoped for minimal privilege and discarded after each session.”
   • [claimed-docs] “Bridging that gap requires an infrastructure layer purpose-built to curate, scope, and evaluate how tools are actually used.”
   • [claimed-docs] “Browser Actions gives your agent a way through computer use. It extends the agent you've already built so it can log in, navigate, and compl…”
   • [claimed-docs] “lets your Decagon agent access and complete tasks inside systems where there isn’t a traditional integration available”
   • [claimed-docs] “no custom code required”
   • [claimed-docs] “Decagon integrates with identity providers like Okta and Microsoft Entra, enabling secure access across systems without additional passwords…”

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

   Decagon docs describe AOPs that define multi-step agent behavior like human SOPs and mention agents carrying context across sessions and taking multi-step actions (browser actions, integrations), which implies some troubleshooting flow, but there is no direct documentation or example showing the agent asking clarifying questions or walking through iterative multi-step troubleshooting dialogues. missing for 10: concrete example/transcript of clarifying-question behavior, documentation explicitly describing multi-turn troubleshooting logic, independent/hands-on evidence confirming this behavior in practice.

   • [claimed-docs] “you can define agent behavior in natural language, the same way you train human agents with SOPs”
   • [claimed-docs] “Carry conversation history across sessions to pick up where you left off and make proactive recommendations based on customer signals.”
   • [claimed-docs] “lets your Decagon agent access and complete tasks inside systems where there isn’t a traditional integration available”

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

   Decagon's docs emphasize automation infrastructure (AOPs, Duet, Browser Actions, integrations) and analytics (Watchtower, Insights) but provide no quantified resolution-rate metrics, no third-party benchmark, and the one customer quote (Duolingo) speaks to maintenance effort, not resolution outcomes. Missing for 10: independent or customer-reported resolution-rate figures, a clear definition/measurement of 'resolution' vs deflection, and case studies quantifying end-to-end conversation completion rather than agent capability lists.

   • [claimed-docs] “Browser Actions gives your agent a way through computer use. It extends the agent you've already built so it can log in, navigate, and compl…”
   • [claimed-docs] “lets your Decagon agent access and complete tasks inside systems where there isn’t a traditional integration available”
   • [claimed-docs] “With the previous vendor, at least half my week was dedicated to maintaining their system. With Decagon, it’s been a night-and-day differenc…”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Whether you're monitoring for compliance risks, negative sentiment, or upsell signals, Watchtower reviews every interaction against your cus…”

   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 Decagon
   Decagon~partialclaimed7/10

   Decagon's docs show brand-voice consistency built into multiple surfaces: chat, voice (multilingual), and email are all described as 'on-brand', and AOPs let support leaders define agent behavior/tone in natural language like SOPs (docs-13,14,15,16). Testing/QA and Experiments explicitly validate tone/brand across pathways and let leaders 'refine tone' safely before and after deployment (docs-11,29,32). Missing for 10: independent/hands-on evidence that tone actually stays consistent across many topics and languages in production, and no explicit mention of cross-language consistency for chat/email (only voice is called multilingual).

   • [claimed-docs] “Flexible, on-brand chat built for conversations across web, mobile, and messaging platforms.”
   • [claimed-docs] “Voice AI agents built for natural, multilingual conversations and customized to your brand.”
   • [claimed-docs] “Intelligent email that understands context, stays on brand, and handles complex customer threads.”
   • [claimed-docs] “you can define agent behavior in natural language, the same way you train human agents with SOPs”
   • [claimed-docs] “Use Duet to easily generate tests covering diverse pathways that verify whether agents respond accurately, follow policies, and reflect your…”
   • [claimed-docs] “Simulations, Decagon's integrated testing suite, help teams validate agent behavior across channels before deploying to production and with …”
   • [claimed-docs] “Whether you’re refining tone, adjusting refund logic, or trialing a new onboarding experience, experimentation makes it safe to test, learn,…”

   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 to Decagon
   Decagon✓fullclaimed8/10

   Decagon documents a dedicated Testing & QA suite (Simulations) that validates agent behavior pre-deploy and on updates, plus Watchtower which reviews every live interaction against custom flagging criteria (compliance, sentiment, frustration) and surfaces failures, and Duet which auto-generates tests/AOPs and iterates on the agent based on conversation gaps — together covering scored/flagged QA and a feedback loop into agent fixes. missing for 10: no independent/hands-on corroboration of scoring accuracy or the closed-loop fix cycle, and no explicit description of 'sampling' methodology for QA review.

   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Use Duet to easily generate tests covering diverse pathways that verify whether agents respond accurately, follow policies, and reflect your…”
   • [claimed-docs] “Define what matters using natural language. From "mentions of frustration" to "violations of data privacy policy," Watchtower understands yo…”
   • [claimed-docs] “Simulations, Decagon's integrated testing suite, help teams validate agent behavior across channels before deploying to production and with …”
   • [claimed-docs] “As conversations reveal gaps and new opportunities, Duet automatically iterates on your agent, from the first launch through every improveme…”
   • [claimed-docs] “Whether you're monitoring for compliance risks, negative sentiment, or upsell signals, Watchtower reviews every interaction against your cus…”

   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 drawn
   Decagon✓fullclaimed8/10

   Decagon's Simulations product is explicitly described as an integrated testing suite that validates agent behavior across channels before production deployment and on every update, and Duet can generate diverse test pathways to check accuracy, policy adherence, and brand voice. Missing for 10: no explicit mention of testing against historical ticket logs specifically, and no independent/hands-on evidence corroborating the testing suite's effectiveness beyond vendor docs.

   • [claimed-docs] “Simulations, Decagon's integrated testing suite, help teams validate agent behavior across channels before deploying to production and with …”
   • [claimed-docs] “Use Duet to easily generate tests covering diverse pathways that verify whether agents respond accurately, follow policies, and reflect your…”
   • [claimed-docs] “Analyze past customer interactions to automatically generate Agent Operating Procedures (AOPs) rooted in actual customer needs.”

   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