Sierra 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
   Sierra~partialcommunity5/10

   Sierra's Agent SDK/Studio docs show agents can call customer APIs to execute actions (order changes, refunds implied by 'internal APIs' use), with guardrails, release governance, and human-in-the-loop approval, and a HN commenter confirms it wires directly into a customer's internal APIs. However there's no explicit documentation of per-action scoped auth/permissioning model for API calls. missing for 10: explicit scoped-auth/permission model per action, concrete refund/subscription action examples, independent confirmation of granular auth scoping.

   • [claimed-docs] “write customer journeys as code, track changes, and build sophisticated logic without giving up our development workflows”
   • [claimed-docs] “Understand and rapidly adjust agent behavior by inspecting API calls, logic traces, and more.”
   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”
   • [community] “Having seen this set up for a customer, what is interesting is how it works with internal APIs for customers. It's all point and click in a …”

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

   Sierra's Agent SDK/Studio explicitly supports authoring step-by-step journeys ('workflows') as code or no-code, with branching logic ('sophisticated logic'), SOP ingestion via Ghostwriter, and simulation/testing to verify deterministic behavior across scenarios. This directly matches encoding SOPs with deterministic branching for known issue types. missing for 10: independent/hands-on verification of deterministic branching behavior specifically (community evidence is generic, not focused on SOP branching), and docs are login-gated so full workflow-editor detail isn't independently viewable.

   • [claimed-docs] “write customer journeys as code, track changes, and build sophisticated logic without giving up our development workflows”
   • [claimed-docs] “Define step-by-step workflows for your agent from scratch, or use AI to instantly generate journeys from your existing operating procedures.”
   • [claimed-docs] “Upload SOPs, raw transcripts, or even audio interviews of subject matter experts to create customer journeys from scratch.”
   • [claimed-docs] “Verify your agent performs as expected across a wide range of scenarios and avoid regressions.”
   • [community] “Having seen this set up for a customer, what is interesting is how it works with internal APIs for customers. It's all point and click in a …”

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

   Direct probes show no llms.txt at sierra.ai (404) and docs.sierra.ai/llms.txt merely resolves to the login SPA HTML shell rather than an actual plain-text agent-oriented index; the real docs are login-gated to contracted customers, so an agent cannot be pointed at a genuine llms.txt or open agent-oriented docs.

   • [probe] “PROBE llms.txt: HTTP 404 at https://sierra.ai/llms.txt”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

   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
   Sierra~partialprobed4/10

   Sierra's Agent SDK is described as code-based with dev workflows retained, and one blog post explicitly notes publishing to ChatGPT can be done 'via CI/CD', implying some automation/pipeline support. However there is no dedicated CLI, headless runtime docs, or CI-specific guidance, and docs/API references are login-gated (probe shows /llms.txt is a login SPA and no public OpenAPI spec), so full headless/CI operation is unconfirmed. Missing for 10: explicit CLI/headless execution docs, public API/OpenAPI spec, independent CI usage reports.

   • [claimed-docs] “write customer journeys as code, track changes, and build sophisticated logic without giving up our development workflows”
   • [claimed-docs] “Publish to ChatGPT with one click: Make your agent available on ChatGPT with the push of a button, or via CI/CD.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://sierra.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sierra.ai/openapi.json, https://sierra.ai/swagger.json, https://sierra.ai/api/openapi.json, …”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   No evidence anywhere in the pack mentions MCP servers or the ability to plug external MCP tool servers into Sierra's agents; Sierra's integration mentions are about internal APIs and custom systems, not MCP. missing for 10: any mention of MCP protocol support, MCP client configuration, or third-party tool server integration via MCP.

   ⚑ 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
   Sierra~partialprobed4/10

   Sierra markets an Agent SDK for building 'customer journeys as code' with API-call inspection, implying a programmatic interface exists, but there's no publicly discoverable OpenAPI spec, llms.txt, or open API reference — docs.sierra.ai is login-gated to contracted customers rather than a documented public API. Missing for 10: publicly accessible API reference/OpenAPI spec, evidence of self-serve API keys or open documentation, independent developer confirmation of using the API without a sales contract.

   • [claimed-docs] “write customer journeys as code, track changes, and build sophisticated logic without giving up our development workflows”
   • [claimed-docs] “Understand and rapidly adjust agent behavior by inspecting API calls, logic traces, and more.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://sierra.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sierra.ai/openapi.json, https://sierra.ai/swagger.json, https://sierra.ai/api/openapi.json, …”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   No evidence anywhere in the pack of scoped or least-privilege API credential/token issuance for agents; docs describe agent building, workflows, channels, and analytics but nothing about credential scoping, permissions, or API key management. Probes even show no public OpenAPI/API docs are accessible (sierra-probe-2, sierra-probe-rt-3), reinforcing the absence of evidence.

   • [probe] “PROBE openapi: all candidate paths 404 (https://sierra.ai/openapi.json, https://sierra.ai/swagger.json, https://sierra.ai/api/openapi.json, …”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

   proof ↗⚑ flag

   Parahelp—none0/10

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

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

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round to Sierra
   Sierra~partialprobed5/10

   Sierra advertises an official "Agent SDK" for writing customer journeys as code with logic traces and testing (sierra-docs-1/2/4), but runtime probes show no public OpenAPI/swagger spec and the SDK/docs reference is login-gated to contracted customers rather than openly available to any AI-native developer (sierra-probe-2, sierra-probe-rt-3). Missing for 10: publicly accessible API reference/OpenAPI spec, evidence of open sign-up or trial SDK access, and independent developer accounts of building against it outside a paid contract.

   • [claimed-docs] “write customer journeys as code, track changes, and build sophisticated logic without giving up our development workflows”
   • [claimed-docs] “Understand and rapidly adjust agent behavior by inspecting API calls, logic traces, and more.”
   • [claimed-docs] “Verify your agent performs as expected across a wide range of scenarios and avoid regressions.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sierra.ai/openapi.json, https://sierra.ai/swagger.json, https://sierra.ai/api/openapi.json, …”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   No evidence in the pack mentions webhooks or event subscription capabilities for Sierra; docs pages describe SDK, studio, insights, voice, and channels features but nothing about outbound event notifications. Probes further show no public API spec or open documentation to confirm such a mechanism exists.

   • [probe] “PROBE openapi: all candidate paths 404 (https://sierra.ai/openapi.json, https://sierra.ai/swagger.json, https://sierra.ai/api/openapi.json, …”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   Sierra's Explorer and Insights products explicitly deliver AI-generated insights: natural-language querying across conversations, automatic weekly briefings on trends/issues with recommendations, and click-to-investigate drill-downs on report data, plus explainability of agent reasoning. This is a first-party documented feature set directly matching the story, with some independent corroboration of Sierra's data-driven production use (sierra-comm-2/3). Missing for 10: independent hands-on validation of the insights/briefing feature specifically (community evidence is about agent setup, not analytics quality), and no detail on data freshness/accuracy limits.

   • [claimed-docs] “Ask any question about your customer experience in natural language, and Explorer identifies the answer across thousands of real conversatio…”
   • [claimed-docs] “Explorer automatically delivers a weekly briefing on key trends, emerging issues, and recommendations — without you having to ask.”
   • [claimed-docs] “Click any data point on a report to launch Explorer and instantly investigate what's driving that trend.”
   • [claimed-docs] “Understand the reasoning behind every agent action or answer—view knowledge sources, systems accessed, and more.”
   • [community] “Having seen this set up for a customer, what is interesting is how it works with internal APIs for customers. It's all point and click in a …”
   • [community] “The magic isn't in a new LLM technology, it is in reliably productionizing a solution for real-world problems... fill in the gap of missing …”

   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
   Sierra~partialcommunity6/10

   Sierra's agents are built to operate autonomously across channels (chat, phone, email, SMS) once deployed, and Explorer explicitly runs in the background to deliver automatic weekly briefings and trend detection 'without you having to ask,' which is genuine unprompted automation. However, there's no documentation of user-configurable scheduled tasks/triggers beyond the always-on conversational agent and the one named automatic-briefing feature. Missing for 10: explicit support for user-defined scheduled/triggered background jobs beyond conversation handling and briefings, and independent/hands-on confirmation of autonomous background execution reliability.

   • [claimed-docs] “Explorer automatically delivers a weekly briefing on key trends, emerging issues, and recommendations — without you having to ask.”
   • [claimed-docs] “Build once and deploy across any channel—chat, phone, email, SMS, and messaging.”
   • [claimed-docs] “Guide care reps through next steps—whether in chat or on calls—automatically capturing and updating customer context as work progresses.”
   • [community] “Having seen this set up for a customer, what is interesting is how it works with internal APIs for customers. It's all point and click in a …”

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

   Sierra's Ghostwriter feature lets users delegate agent-building tasks to a built-in AI assistant via natural-language prompts (build/modify agents, generate journeys from SOPs/transcripts), fitting the 'delegate tasks to built-in AI assistant' story. However, this is vendor-only documentation with no independent/hands-on corroboration of Ghostwriter specifically; community evidence instead describes manual point-and-click agent setup, not AI-assistant delegation. Missing for 10: independent/hands-on validation of Ghostwriter's delegation capability, and detail on scope/limits of what can be delegated.

   • [claimed-docs] “Build or modify agents by describing how you want them to behave. Update workflows, systems integrations, guardrails, tone, and style with s…”
   • [claimed-docs] “Upload SOPs, raw transcripts, or even audio interviews of subject matter experts to create customer journeys from scratch.”
   • [claimed-docs] “Define step-by-step workflows for your agent from scratch, or use AI to instantly generate journeys from your existing operating procedures.”

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

   Sierra provides explicit natural-language control surfaces: Ghostwriter lets users 'build or modify agents by describing how you want them to behave' with 'simple prompts' for workflows, integrations, guardrails, tone and style, and Explorer lets users 'ask any question about your customer experience in natural language.' This directly matches an AI-native user operating the product via NL commands rather than only clicking through UI. Missing for 10: independent hands-on corroboration of NL command reliability/scope beyond vendor docs, and no evidence of NL control over the entire platform (e.g., release governance, channel deployment) rather than just Ghostwriter/Explorer.

   • [claimed-docs] “Build or modify agents by describing how you want them to behave. Update workflows, systems integrations, guardrails, tone, and style with s…”
   • [claimed-docs] “Upload SOPs, raw transcripts, or even audio interviews of subject matter experts to create customer journeys from scratch.”
   • [claimed-docs] “Ask any question about your customer experience in natural language, and Explorer identifies the answer across thousands of real conversatio…”
   • [community] “Having seen this set up for a customer, what is interesting is how it works with internal APIs for customers. It's all point and click in a …”

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

   Probes show no public OpenAPI/interactive reference (404s at openapi.json paths, llms.txt returns login SPA shell), and docs are login-gated to contracted customers rather than an open interactive API reference with runnable examples.

   • [probe] “PROBE llms.txt: HTTP 404 at https://sierra.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sierra.ai/openapi.json, https://sierra.ai/swagger.json, https://sierra.ai/api/openapi.json, …”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   Direct probes show no OpenAPI/Swagger spec at common paths (all 404) and no machine-readable llms.txt index; docs are login-gated rather than publicly exposing a spec. missing for 10: publicly downloadable OpenAPI/Swagger file, any machine-readable API spec endpoint.

   • [probe] “PROBE llms.txt: HTTP 404 at https://sierra.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sierra.ai/openapi.json, https://sierra.ai/swagger.json, https://sierra.ai/api/openapi.json, …”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   Sierra's docs mention scenario testing and regression avoidance (sierra-docs-4) and 'Agent Checks and Simulations' for proactive problem catching (sierra-docs-18), implying some pre-production testing capability, but there is no explicit mention of a dedicated sandbox environment isolated from production data. Missing for 10: explicit sandbox/staging environment documentation, confirmation that test runs don't touch production data, and independent/hands-on verification of this separation.

   • [claimed-docs] “Verify your agent performs as expected across a wide range of scenarios and avoid regressions.”
   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”

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

   No evidence of a public versioned API reference or a documented deprecation policy; probes show no OpenAPI spec and docs are login-gated, and llms.txt/openapi.json all 404 or resolve to a login shell rather than API docs.

   • [probe] “PROBE llms.txt: HTTP 404 at https://sierra.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sierra.ai/openapi.json, https://sierra.ai/swagger.json, https://sierra.ai/api/openapi.json, …”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   No evidence describes bulk operations across many items (e.g., batch editing knowledge entries, mass workflow updates, or bulk conversation actions). The docs describe individual agent building, knowledge editing, and analytics tools, but nothing about performing actions at scale across many items simultaneously.

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

   Sierra supports building workflows/journeys and guardrail-based release governance (e.g., agent checks, split traffic, merge approval) which implies some rule-based triggering, and Ghostwriter/Agent Studio let users define step-by-step logic, but there's no explicit documentation of an event-driven 'if X happens, trigger Y automatically' rules engine for AI-native users to configure independently. missing for 10: explicit event-trigger/rules-engine documentation, API/SDK examples of automated action-on-event configuration, independent verification of this specific automation capability.

   • [claimed-docs] “Define step-by-step workflows for your agent from scratch, or use AI to instantly generate journeys from your existing operating procedures.”
   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”
   • [claimed-docs] “Initiate workflows directly from a conversation—no tab-switching, no referencing instructions, no lost context.”

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

   Sierra's evidence covers agent building, workflows, channels, analytics, and release governance, but nothing describes scheduling recurring jobs/workflows (e.g., cron-like triggers or timed automation runs) for AI-native users. Missing for 10: any documentation of scheduled/recurring job execution, trigger-based automation, or timer-based workflow runs.

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

   Sierra's Agent SDK is described as 'journeys as code' with change tracking, and release-governance docs mention merge approval, agent checks/simulations, and split-traffic gradual rollouts — pointing to versioned, reviewable release workflows. However, no explicit rollback/revert mechanism is documented, and docs are login-gated so no independent confirmation exists. missing for 10: explicit rollback capability, independent/hands-on confirmation of version history and revert function.

   • [claimed-docs] “write customer journeys as code, track changes, and build sophisticated logic without giving up our development workflows”
   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   Sierra's docs confirm one agent can be built once and deployed across chat, phone, email, SMS, and messaging channels (sierra-docs-3), with channel-specific tuning like Voice Personas (sierra-docs-16) and even ChatGPT publishing (sierra-docs-17), showing broad omnichannel intent. However, none of the evidence explicitly names Slack, WhatsApp, or social media as supported channels, leaving the specific channels support leaders care about unconfirmed. Missing for 10: explicit documentation or independent confirmation that Slack, WhatsApp, and social platforms are supported channels, plus hands-on evidence of a single agent operating consistently across these specific channels.

   • [claimed-docs] “Build once and deploy across any channel—chat, phone, email, SMS, and messaging.”
   • [claimed-docs] “Use Voice Personas to design how your agent sounds, speaks, and connects, powered by a constellation of models tuned across 59 languages.”
   • [claimed-docs] “Publish to ChatGPT with one click: Make your agent available on ChatGPT with the push of a button, or via CI/CD.”

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

   Sierra documents multilingual voice capability explicitly ('Voice Personas... tuned across 59 languages') and general multi-channel deployment, implying broad language coverage for customer-facing conversations. However, there is no direct evidence about handling a knowledge base that exists only in English—no mention of automatic translation/grounding of English-only content into other languages, so the specific claim in the story (KB gap bridging) is unevidenced. missing for 10: explicit documentation on cross-language grounding from English-only knowledge base, independent verification of multilingual quality beyond voice.

   • [claimed-docs] “Use Voice Personas to design how your agent sounds, speaks, and connects, powered by a constellation of models tuned across 59 languages.”
   • [claimed-docs] “Build once and deploy across any channel—chat, phone, email, SMS, and messaging.”

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

   Sierra explicitly markets voice as a first-class channel with the same agent logic/knowledge as chat ('Build once and deploy across any channel—chat, phone, email, SMS'), plus voice-specific features like Voice Personas across 59 languages, replacing IVR with empathetic voice agents, and phone payments without IVR handoff. Missing for 10: independent/hands-on verification that voice calls actually share identical knowledge/actions with chat in production (only vendor docs, no community confirmation of phone-specific parity).

   • [claimed-docs] “Build once and deploy across any channel—chat, phone, email, SMS, and messaging.”
   • [claimed-docs] “Use Voice Personas to design how your agent sounds, speaks, and connects, powered by a constellation of models tuned across 59 languages.”
   • [claimed-docs] “Collect card and ACH payments entirely over the phone with no IVR handoff.”
   • [claimed-docs] “Replace rigid IVR menus with an empathetic voice agent that understands customer context”
   • [claimed-docs] “Guide care reps through next steps—whether in chat or on calls—automatically capturing and updating customer context as work progresses.”

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

   Sierra's Live Assist product explicitly targets escalation handoff, claiming reps are guided through next steps with automatically captured and updated customer context and can pick up conversations 'no tab-switching, no referencing instructions, no lost context' — directly addressing the no-repeat-yourself goal. However, there's no explicit mention of a generated conversation summary artifact or hands-on/independent confirmation that reps actually receive full transcript + summary + collected details in practice. Missing for 10: explicit summary-generation evidence, independent/hands-on validation of the handoff experience, confirmation reps see full conversation history alongside context.

   • [claimed-docs] “Guide care reps through next steps—whether in chat or on calls—automatically capturing and updating customer context as work progresses.”
   • [claimed-docs] “Initiate workflows directly from a conversation—no tab-switching, no referencing instructions, no lost context.”

   proof ↗⚑ flag

   Parahelp~partialclaimed5/10

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

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

   proof ↗⚑ flag

Rules

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

   weight 2 · round to Parahelp
   Sierra~partialclaimed3/10

   Sierra's docs mention configurable guardrails, workflows, and a 'Live Assist' human-handoff product, implying some escalation mechanism exists, but no evidence describes explicit configuration of handoff triggers by topic, sentiment, customer tier, or explicit customer request, nor proof of reliable adherence to such rules. Missing for 10: documentation of specific trigger types (topic/sentiment/tier/request), configuration UI/API for these rules, and evidence (first-party or independent) that the agent reliably obeys them in production.

   • [claimed-docs] “Build or modify agents by describing how you want them to behave. Update workflows, systems integrations, guardrails, tone, and style with s…”
   • [claimed-docs] “Guide care reps through next steps—whether in chat or on calls—automatically capturing and updating customer context as work progresses.”
   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”
   • [claimed-docs] “Define step-by-step workflows for your agent from scratch, or use AI to instantly generate journeys from your existing operating procedures.”

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

   Sierra's docs mention grounding agents in knowledge/FAQs/policies (sierra-docs-7) and general 'guardrails' as a configurable behavior via Ghostwriter (sierra-docs-8), plus release-governance guardrails like Agent Checks/Simulations (sierra-docs-18) and visibility into reasoning/knowledge sources (sierra-docs-13). However, no evidence explicitly describes a 'safe decline' mechanism for off-knowledge questions or confirms the agent won't invent prices/policies rather than guess. Missing for 10: explicit documentation or hands-on proof of decline-on-unknown behavior, third-party validation that hallucinated policies/prices are prevented, and detail on the unexplored 'trust-and-reliability' product page.

   • [claimed-docs] “View, manage, and edit knowledge data such as Help Center content, FAQs, and policies that ground your agent.”
   • [claimed-docs] “Build or modify agents by describing how you want them to behave. Update workflows, systems integrations, guardrails, tone, and style with s…”
   • [claimed-docs] “Understand the reasoning behind every agent action or answer—view knowledge sources, systems accessed, and more.”
   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”

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

   Sierra's evidence covers release governance (merge-approval for deploying agent changes) and Live Assist (guiding human reps in real time), but neither describes a mode where the agent drafts individual customer replies that a human must approve before they are sent. No docs or community evidence mention message-level human-in-the-loop approval for live customer conversations.

   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”
   • [claimed-docs] “Guide care reps through next steps—whether in chat or on calls—automatically capturing and updating customer context as work progresses.”
   • [claimed-docs] “Initiate workflows directly from a conversation—no tab-switching, no referencing instructions, no lost context.”

   proof ↗⚑ flag

   Parahelp✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Topic controls

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

   weight 2 · round to Parahelp
   Sierra—none0/10

   Sierra's guardrail evidence covers release governance (Agent Checks, Simulations, merge approval, split traffic) and general knowledge/workflow editing, but nothing describes topic-level human-only flags for categories like legal threats, cancellations, or security that the agent is barred from handling. Live-assist shows human+AI collaboration but not a mechanism to designate certain topics as strictly human-only with enforced escalation.

   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”
   • [claimed-docs] “Guide care reps through next steps—whether in chat or on calls—automatically capturing and updating customer context as work progresses.”

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

   Sierra's Insights and Explorer products provide dashboards/reports with drill-down and natural-language trend analysis (sierra-docs-10, sierra-docs-11, sierra-docs-12, sierra-docs-13), showing the platform surfaces analytics for support leaders, but no evidence specifies the exact metrics named in the story (resolution rate, CSAT, handoff rate, cost per resolution). Missing for 10: explicit documentation naming these specific KPIs, screenshots/examples of the actual dashboard metrics, and independent confirmation that leaders use it for exec-level reporting.

   • [claimed-docs] “Ask any question about your customer experience in natural language, and Explorer identifies the answer across thousands of real conversatio…”
   • [claimed-docs] “Explorer automatically delivers a weekly briefing on key trends, emerging issues, and recommendations — without you having to ask.”
   • [claimed-docs] “Click any data point on a report to launch Explorer and instantly investigate what's driving that trend.”
   • [claimed-docs] “Understand the reasoning behind every agent action or answer—view knowledge sources, systems accessed, and more.”

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

   Sierra's Explorer product explicitly surfaces trends and emerging issues via natural-language querying of conversations and proactive weekly briefings, and Insights lets users drill into data points—directly matching the 'surface emerging issues before they spike' theme. However, evidence doesn't explicitly confirm topic clustering methodology, predictive spike detection, or independent/hands-on validation of this specific capability. Missing for 10: explicit description of topic-clustering mechanics, evidence of predictive alerting before ticket-volume spikes (vs. reactive weekly summaries), and independent/customer corroboration of this specific insights capability.

   • [claimed-docs] “Ask any question about your customer experience in natural language, and Explorer identifies the answer across thousands of real conversatio…”
   • [claimed-docs] “Explorer automatically delivers a weekly briefing on key trends, emerging issues, and recommendations — without you having to ask.”
   • [claimed-docs] “Click any data point on a report to launch Explorer and instantly investigate what's driving that trend.”

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

   No evidence pack citation mentions Zendesk, Salesforce, Intercom, or bidirectional ticket/context syncing with existing helpdesk platforms; only generic 'systems integrations' and 'internal APIs' are referenced without naming any helpdesk system or describing two-way ticket sync.

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

   Evidence shows Sierra lets teams manually 'view, manage, and edit knowledge data' (sierra-docs-7) but nothing describes automatic re-syncing of knowledge sources on a schedule or on-change detection; docs are login-gated so no further detail is visible.

   • [claimed-docs] “View, manage, and edit knowledge data such as Help Center content, FAQs, and policies that ground your agent.”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

   proof ↗⚑ flag

   Parahelp~partialclaimed3/10

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

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

   proof ↗⚑ flag

Gaps

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

   weight 1 · round to Parahelp
   Sierra~partialclaimed5/10

   Sierra's Explorer and Insights products surface emerging issues, trends, and the reasoning/knowledge sources behind agent answers, and Agent Studio lets teams view/manage knowledge content (FAQs, policies), which could help surface gaps — but no evidence explicitly describes detecting knowledge gaps or conflicting content as a distinct feature. Missing for 10: explicit conflicting-content/contradiction detection, explicit 'knowledge gap' flagging, and independent/hands-on confirmation that Explorer or Insights actually pinpoints such gaps rather than general conversation trends.

   • [claimed-docs] “View, manage, and edit knowledge data such as Help Center content, FAQs, and policies that ground your agent.”
   • [claimed-docs] “Ask any question about your customer experience in natural language, and Explorer identifies the answer across thousands of real conversatio…”
   • [claimed-docs] “Explorer automatically delivers a weekly briefing on key trends, emerging issues, and recommendations — without you having to ask.”
   • [claimed-docs] “Click any data point on a report to launch Explorer and instantly investigate what's driving that trend.”
   • [claimed-docs] “Understand the reasoning behind every agent action or answer—view knowledge sources, systems accessed, and more.”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

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

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

   proof ↗⚑ flag

Grounding

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

   weight 3 · round to Sierra
   Sierra✓fullclaimed7/10

   Sierra explicitly supports grounding agent answers in customer-owned knowledge (Help Center content, FAQs, policies) via Agent Studio, and Insights lets teams 'understand the reasoning behind every agent action or answer—view knowledge sources, systems accessed' which directly maps to showing which source an answer drew from. Missing for 10: independent/hands-on verification that end-user-facing answers visibly cite specific articles, and detail on citation UX rather than just admin-side reasoning traces.

   • [claimed-docs] “View, manage, and edit knowledge data such as Help Center content, FAQs, and policies that ground your agent.”
   • [claimed-docs] “Understand the reasoning behind every agent action or answer—view knowledge sources, systems accessed, and more.”
   • [claimed-docs] “Ask any question about your customer experience in natural language, and Explorer identifies the answer across thousands of real conversatio…”

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

   Sierra's docs explicitly claim agent-studio lets teams 'view, manage, and edit knowledge data such as Help Center content, FAQs, and policies' and Ghostwriter can ingest SOPs, transcripts, and audio interviews to build journeys, supporting knowledge ingestion beyond just help center docs. However, there's no explicit evidence of ingesting past tickets or internal wikis specifically, and docs/reference material is login-gated so independent verification of breadth of source-type ingestion is limited. Missing for 10: documented support for tickets/wiki ingestion specifically, and independent/hands-on confirmation of the ingestion workflow beyond marketing copy.

   • [claimed-docs] “View, manage, and edit knowledge data such as Help Center content, FAQs, and policies that ground your agent.”
   • [claimed-docs] “Upload SOPs, raw transcripts, or even audio interviews of subject matter experts to create customer journeys from scratch.”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   Sierra markets an Agent SDK for code-based building alongside a separate no-code Agent Studio, but there is no evidence of API/UI feature parity — no public OpenAPI/swagger spec was found (404s), and the SDK reference docs themselves are login-gated to contracted customers, meaning even documented API scope can't be verified as matching UI capabilities.

   • [claimed-docs] “write customer journeys as code, track changes, and build sophisticated logic without giving up our development workflows”
   • [claimed-docs] “Empower teams to build and manage agents—no code required”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sierra.ai/openapi.json, https://sierra.ai/swagger.json, https://sierra.ai/api/openapi.json, …”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   No evidence of any data export or portability feature for customer journeys, knowledge data, or conversation logs in open formats; probes even show docs/API surfaces are gated or unavailable (404s, login-gated /llms.txt). Missing for 10: any export functionality, data portability documentation, or open-format data dump capability.

   • [probe] “PROBE llms.txt: HTTP 404 at https://sierra.ai/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sierra.ai/openapi.json, https://sierra.ai/swagger.json, https://sierra.ai/api/openapi.json, …”
   • [probe] “PROBE runtime finding (recorded 2026-09-10): docs.sierra.ai has no agent-legible surface — /llms.txt resolves (HTTP 200) to the login SPA's …”

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

   No evidence pack item mentions pricing, resolution-based billing, caps, or published rates; docs and probes cover product features and access gating only. Sierra is widely known anecdotally for outcome-based pricing but nothing in this evidence pack substantiates published, capped, self-serve pricing terms.

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

   No evidence pack item addresses data residency, region selection, or storage location controls; the docs cover agent building, workflows, and channels but not data governance/residency options. missing for 10: any mention of data region selection, residency guarantees, or storage location controls.

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

   No evidence in the pack addresses data-training opt-out or AI model training policies; Sierra's docs focus on product features (agent building, analytics, channels) with no privacy/data-use policy statements provided.

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

   No evidence pack item addresses data retention controls, deletion policies, or user-facing data lifecycle management; docs cover agent building, analytics, and channels but never mention retention/deletion settings, and docs.sierra.ai is login-gated so no public verification exists.

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

   No evidence pack item discusses telemetry, usage tracking, opt-out controls, or privacy settings for AI-native/developer users; docs focus on product features and docs are gated behind login. Missing for 10: any documentation of telemetry collection practices, opt-out mechanism, or privacy controls.

   ⚑ 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 to Sierra
   Sierra~partialcommunity7/10

   Sierra's docs and community evidence show the agent integrates with customers' internal APIs and systems (not just static knowledge), with Insights explicitly noting 'systems accessed' during agent actions, and Live Assist capturing live customer context. However, no evidence explicitly confirms real-time retrieval of specifics like plan, order status, or account history. missing for 10: explicit documented example of pulling live order/plan/account data, independent verification beyond one HN anecdote.

   • [claimed-docs] “Understand and rapidly adjust agent behavior by inspecting API calls, logic traces, and more.”
   • [claimed-docs] “Understand the reasoning behind every agent action or answer—view knowledge sources, systems accessed, and more.”
   • [claimed-docs] “Guide care reps through next steps—whether in chat or on calls—automatically capturing and updating customer context as work progresses.”
   • [community] “Having seen this set up for a customer, what is interesting is how it works with internal APIs for customers. It's all point and click in a …”

   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 Sierra
   Sierra~partialcommunity6/10

   Sierra's docs describe building step-by-step, multi-step 'customer journeys' and workflows (sierra-docs-6, sierra-docs-9) rather than single canned replies, and community commentary confirms agents are configured to work through processes with internal APIs (sierra-comm-2). However, no evidence explicitly demonstrates the agent proactively asking clarifying questions or a hands-on troubleshooting transcript showing multi-turn dialogue in practice. Missing for 10: concrete transcript/demo of clarifying-question behavior, independent evaluation of troubleshooting depth, and explicit mention of clarification-seeking as a designed capability.

   • [claimed-docs] “Define step-by-step workflows for your agent from scratch, or use AI to instantly generate journeys from your existing operating procedures.”
   • [claimed-docs] “Upload SOPs, raw transcripts, or even audio interviews of subject matter experts to create customer journeys from scratch.”
   • [community] “Having seen this set up for a customer, what is interesting is how it works with internal APIs for customers. It's all point and click in a …”

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

   Sierra's marketing emphasizes agent-driven end-to-end workflow execution (journeys, integrations, payments, guardrails, testing) implying resolution rather than mere deflection, and community evidence corroborates real production use handling customer processes end-to-end for at least one customer. However, no quantitative resolution-rate metrics, benchmarks, or third-party validation of 'meaningful share resolved end-to-end' are provided — tau-bench is a research benchmark, not a customer outcome metric. Missing for 10: published resolution-rate statistics, case studies with concrete resolution percentages, independent audits distinguishing resolution from deflection.

   • [claimed-docs] “Define step-by-step workflows for your agent from scratch, or use AI to instantly generate journeys from your existing operating procedures.”
   • [claimed-docs] “Upload SOPs, raw transcripts, or even audio interviews of subject matter experts to create customer journeys from scratch.”
   • [claimed-docs] “Collect card and ACH payments entirely over the phone with no IVR handoff.”
   • [claimed-docs] “Replace rigid IVR menus with an empathetic voice agent that understands customer context”
   • [community] “Having seen this set up for a customer, what is interesting is how it works with internal APIs for customers. It's all point and click in a …”
   • [community] “The magic isn't in a new LLM technology, it is in reliably productionizing a solution for real-world problems... fill in the gap of missing …”
   • [probe] “PROBE runtime (recorded 2026-09-10): Sierra's agent benchmark is genuinely open — the official sierra-research/tau-bench repository README f…”

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

   Sierra provides explicit tone/brand-voice controls (Ghostwriter prompts for tone and style, Voice Personas tuned across 59 languages) plus testing/simulation tools to verify agent behavior across scenarios and avoid regressions, which supports consistency claims. However, all evidence is vendor-authored with no independent or hands-on verification that voice/tone actually stays consistent across topics and languages in production. Missing for 10: independent case studies or benchmarks confirming cross-topic/cross-language tone consistency, and detail on how brand-voice guardrails are enforced at scale.

   • [claimed-docs] “Build or modify agents by describing how you want them to behave. Update workflows, systems integrations, guardrails, tone, and style with s…”
   • [claimed-docs] “Use Voice Personas to design how your agent sounds, speaks, and connects, powered by a constellation of models tuned across 59 languages.”
   • [claimed-docs] “Verify your agent performs as expected across a wide range of scenarios and avoid regressions.”
   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”

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

   Sierra documents Agent Checks and Simulations that proactively catch problems, merge-approval workflows for human review, and split-traffic releases (sierra-docs-18), plus regression testing (sierra-docs-4) and Explorer/Insights tools that surface conversation trends, flag emerging issues, and explain agent reasoning (sierra-docs-10, -11, -13). Ghostwriter lets teams feed fixes back by updating workflows/guardrails via prompts (sierra-docs-8). Missing for 10: explicit description of scored/sampled QA reviews with quantitative scoring rubrics, and independent evidence of the review loop actually closing the gap between flagged failures and shipped fixes.

   • [claimed-docs] “Verify your agent performs as expected across a wide range of scenarios and avoid regressions.”
   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”
   • [claimed-docs] “Ask any question about your customer experience in natural language, and Explorer identifies the answer across thousands of real conversatio…”
   • [claimed-docs] “Explorer automatically delivers a weekly briefing on key trends, emerging issues, and recommendations — without you having to ask.”
   • [claimed-docs] “Understand the reasoning behind every agent action or answer—view knowledge sources, systems accessed, and more.”
   • [claimed-docs] “Build or modify agents by describing how you want them to behave. Update workflows, systems integrations, guardrails, tone, and style with s…”

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

   Sierra explicitly documents 'Agent Checks and Simulations' and 'verify your agent performs as expected across a wide range of scenarios and avoid regressions' (sierra-docs-4, sierra-docs-18), directly matching pre-release testing against scenarios/regressions. This is further corroborated by Sierra's public tau-bench research benchmark for evaluating conversational agents on simulated user interactions (sierra-probe-rt-1), showing real investment in simulation-based testing methodology. Missing for 10: no explicit mention of testing against historical/real ticket transcripts specifically (only 'scenarios' and simulations), and no independent hands-on customer account of the simulation workflow in practice.

   • [claimed-docs] “Verify your agent performs as expected across a wide range of scenarios and avoid regressions.”
   • [claimed-docs] “Agent Checks and Simulations catching problems proactively, merge approval workflows putting a person in the loop, and split traffic release…”
   • [probe] “PROBE runtime (recorded 2026-09-10): Sierra's agent benchmark is genuinely open — the official sierra-research/tau-bench repository README f…”

   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