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

   Docs explicitly state the agent 'takes action through your APIs and MCP servers' (docs-28), give concrete examples like refund workflows and order-status tool tests (docs-19, docs-24, docs-43), and describe workflow-scoped tool access, server-side identity validation, and hard execution caps enforced in code rather than prompts (docs-34). This directly matches the story of scoped, real-world API actions like refunds/order changes/subscriptions. Missing for 10: independent/hands-on verification of the auth-scoping mechanism, and more granular detail on how 'per action' scopes are configured/enforced beyond high-level guardrails language.

   • [claimed-docs] “The agent takes action through your APIs and MCP servers inside natural-language and deterministic workflows”
   • [claimed-docs] “Customer isolation, server-side identity validation, workflow-scoped tool access and hard execution caps are enforced in code rather than pr…”
   • [claimed-docs] “Test the 'get-order-status' tool with order ID 98765 and check if the response matches what we expect.”
   • [claimed-docs] “/lorikeet:create-simulations build simulations for the refund workflow”
   • [claimed-docs] “Automate disputes, loan inquiries, payments and compliance cases across every customer channel”
   • [claimed-docs] “Connect Lorikeet in seconds to your ticketing system, knowledge base, and internal tools to seamlessly ingest data and take action for your …”

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

   Lorikeet explicitly supports training agents on SOPs (docs-25) and building workflows with 'natural-language and deterministic workflows' plus 'pockets of determinism for regulated steps' (docs-28, docs-32), with workflow-scoped tool access and hard execution caps enforced in code (docs-34), directly matching the deterministic-branching SOP story. Missing for 10: independent/hands-on validation of branching logic in practice and more detail on how branching conditions are authored beyond natural-language workflow builder claims.

   • [claimed-docs] “train the agent on your business context, brand guidelines, help docs and standard operating procedures”
   • [claimed-docs] “The agent takes action through your APIs and MCP servers inside natural-language and deterministic workflows”
   • [claimed-docs] “Lorikeet coordinates a team of specialist agents, with pockets of determinism for regulated steps, to handle multi-party, multi-system workf…”
   • [claimed-docs] “Customer isolation, server-side identity validation, workflow-scoped tool access and hard execution caps are enforced in code rather than pr…”
   • [claimed-docs] “Build workflows - create and iterate on workflows using natural language”
   • [claimed-docs] “Build, edit, and deploy workflows using natural language”

   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 drawn
   Lorikeet✓fullprobed9/10

   Direct probe evidence confirms Lorikeet serves an llms.txt file at docs.lorikeetcx.ai/llms.txt returning HTTP 200 with structured agent-oriented reference links, and documentation is further organized around MCP/agent access. Missing for 10: no independent third-party report of an agent successfully consuming this llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.lorikeetcx.ai/llms.txt # Reference - [Lorikeet MCP Server](https://docs.lorikeetcx.ai/mcp/mcp-serv…”
   • [probe] “official MCP server documented at https://docs.lorikeetcx.ai/mcp/mcp-server”
   • [claimed-docs] “Connect to your Lorikeet account from ChatGPT, Claude, Claude Code, and MintMCP using the Model Context Protocol.”

   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 userPlug MCP servers into this product so it can use their tools

   weight 3 · round to Lorikeet
   Lorikeet~partialclaimed5/10

   Lorikeet's docs state the agent 'takes action through your APIs and MCP servers inside natural-language and deterministic workflows' (lorikeet-docs-28), indicating it can consume external MCP servers as tool sources, but the bulk of the MCP evidence pack actually describes the reverse direction — Lorikeet exposing its own MCP server for external clients like Claude/ChatGPT to connect to (lorikeet-docs-1, lorikeet-docs-46, lorikeet-probe-1/2). Missing for 10: dedicated documentation on how a user configures/adds third-party MCP servers into Lorikeet, a list of supported MCP integrations, and independent confirmation of this client-side tool-use capability.

   • [claimed-docs] “The agent takes action through your APIs and MCP servers inside natural-language and deterministic workflows”
   • [claimed-docs] “Connect Lorikeet in seconds to your ticketing system, knowledge base, and internal tools to seamlessly ingest data and take action for your …”

   proof ↗⚑ flag

   Parahelp—none0/10

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

   ⚑ flag

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

   weight 3 · round to Lorikeet
   Lorikeet✓fullprobed8/10

   Lorikeet publishes a documented MCP server (docs.lorikeetcx.ai/mcp/mcp-server) that lets AI-native users drive the product directly from Claude, ChatGPT, Codex, and Claude Code — diagnosing tickets, auditing knowledge bases, building workflows, testing tools, and running simulations, all documented with concrete examples and even slash-command skills. This is a genuine documented programmatic interface built for AI agents, not just human UI docs. Missing for 10: no separate traditional REST/GraphQL API reference beyond MCP, and no independent third-party corroboration of the API's reliability.

   • [claimed-docs] “The Lorikeet MCP server lets you interact with your Lorikeet account directly from Claude Code, Claude.ai, ChatGPT, and Codex.”
   • [claimed-docs] “Diagnose tickets - trace workflow execution and identify root causes”
   • [claimed-docs] “Audit knowledge bases - analyze articles at scale, find gaps, and spot quality issues”
   • [claimed-docs] “Build workflows - create and iterate on workflows using natural language”
   • [claimed-docs] “Test tools - run and validate tool configurations directly from your AI assistant”
   • [claimed-docs] “Test the 'get-order-status' tool with order ID 98765 and check if the response matches what we expect.”
   • [claimed-docs] “Explore your setup - inspect workflows, tools, and integrations”
   • [claimed-docs] “Connect to your Lorikeet account from ChatGPT, Claude, Claude Code, and MintMCP using the Model Context Protocol.”
   • [claimed-docs] “Run simulations - test workflows against different customer scenarios”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.lorikeetcx.ai/llms.txt # Reference - [Lorikeet MCP Server](https://docs.lorikeetcx.ai/mcp/mcp-serv…”
   • [probe] “official MCP server documented at https://docs.lorikeetcx.ai/mcp/mcp-server”

   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

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

   weight 2 · round to Lorikeet
   Lorikeet~partialclaimed3/10

   Lorikeet's guardrails page mentions 'workflow-scoped tool access' and 'server-side identity validation' enforced in code, suggesting some access scoping, but there is no explicit documentation of issuing or managing scoped/least-privilege API credentials or tokens for agents. Missing for 10: explicit credential/token issuance mechanism, documentation of API key scoping or permission granularity, and any user-facing controls for creating least-privilege credentials.

   • [claimed-docs] “Customer isolation, server-side identity validation, workflow-scoped tool access and hard execution caps are enforced in code rather than pr…”

   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

5. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Lorikeet—none0/10

   Evidence only documents an MCP server and integrations/APIs for connecting tools, but there is no mention of an official SDK (e.g., Python/JS client library) for developers to build against. Missing for 10: any documented official SDK, its language support, or developer-facing library docs.

   ⚑ 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

6. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Lorikeet—none0/10

   The evidence pack covers Lorikeet's MCP server, simulations, coach, and guardrails features, but contains no mention of webhooks or event subscription mechanisms for AI-native users to receive push notifications on events.

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

   Lorikeet's Coach and MCP-server capabilities generate AI-driven insights directly from customer data: ticket quality scoring across 100% of conversations, knowledge-base gap/quality audits, root-cause diagnosis of tickets, and analytics on resolution quality, satisfaction, and revenue impact, with Coach able to 'implement improvements... or make suggestions for you to action yourself.' This is all first-party documentation without independent hands-on corroboration. Missing for 10: independent/third-party validation of insight quality and real-world usage examples beyond vendor docs.

   • [claimed-docs] “Coach's Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “Audit your entire knowledge base for gaps, outdated articles, and quality issues”
   • [claimed-docs] “Diagnose tickets by tracing workflow execution and identifying root causes”
   • [claimed-docs] “Track resolution quality, customer satisfaction, revenue impact, and operational efficiency with industry-leading analytics.”
   • [claimed-docs] “Coach can implement improvements on your behalf, or make suggestions for you to action yourself.”
   • [claimed-docs] “Coach reviews 100% of tickets against your quality standards and turns findings into fixes, so your AI agent improves every week instead of …”
   • [claimed-docs] “Scale and optimize with conversational insights and analytics from Lorikeet Coach”

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

   Lorikeet's core product is an autonomous agent that resolves tickets end-to-end across channels and coordinates specialist agents for multi-step workflows, and Outbound campaigns run on scheduled cadences without human intervention, while Coach can autonomously implement improvements. However, the evidence centers on the vendor's own agent running in background rather than a user-configurable 'automation' builder with triggers/schedules exposed as a general-purpose feature. Missing for 10: explicit user-facing scheduling/trigger configuration UI or API for arbitrary automations, and independent/hands-on confirmation that these automations run unattended reliably.

   • [claimed-docs] “one agent that resolves issues end-to-end across chat, email, voice and SMS”
   • [claimed-docs] “Lorikeet coordinates a team of specialist agents, with pockets of determinism for regulated steps, to handle multi-party, multi-system workf…”
   • [claimed-docs] “campaign cadences with scheduling windows control when outreach happens”
   • [claimed-docs] “Coach can implement improvements on your behalf, or make suggestions for you to action yourself.”
   • [claimed-docs] “The agent takes action through your APIs and MCP servers inside natural-language and deterministic workflows”

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

   Lorikeet's 'Coach' is a built-in AI assistant accessible directly inside the Lorikeet platform (as well as via Slack/Claude/ChatGPT/MCP) that users can delegate tasks to — diagnosing tickets, auditing knowledge bases, building workflows via natural language, running simulations, and even implementing improvements automatically on the user's behalf. This is well documented across multiple first-party pages describing concrete delegated actions (e.g. doc-48 'Coach can implement improvements on your behalf'). missing for 10: independent/hands-on verification of Coach's assistant behavior, and clearer distinction between autonomous action vs. suggestion-only mode.

   • [claimed-docs] “Coach's Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “Talk to Coach wherever you work, whether in Lorikeet, Slack, Claude, ChatGPT, or via MCP.”
   • [claimed-docs] “Diagnose tickets by tracing workflow execution and identifying root causes”
   • [claimed-docs] “Audit your entire knowledge base for gaps, outdated articles, and quality issues”
   • [claimed-docs] “Build, edit, and deploy workflows using natural language”
   • [claimed-docs] “Coach reviews 100% of tickets against your quality standards and turns findings into fixes, so your AI agent improves every week instead of …”
   • [claimed-docs] “Coach can implement improvements on your behalf, or make suggestions for you to action yourself.”

   proof ↗⚑ flag

   Parahelp✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Lorikeet
   Lorikeet✓fullprobed8/10

   Lorikeet ships an MCP server plus Claude/ChatGPT/Codex integrations that let users build workflows, diagnose tickets, audit knowledge bases, and run simulations using natural-language commands (e.g. 'Build workflows - create and iterate on workflows using natural language', example prompts like 'Test the get-order-status tool...'), and even exposes slash-command skills like /lorikeet:create-simulations. This is first-party documentation only, with no independent/hands-on corroboration of the NL command experience. Missing for 10: independent user reports or demos validating the natural-language MCP workflow in practice.

   • [claimed-docs] “The Lorikeet MCP server lets you interact with your Lorikeet account directly from Claude Code, Claude.ai, ChatGPT, and Codex.”
   • [claimed-docs] “Build workflows - create and iterate on workflows using natural language”
   • [claimed-docs] “Build, edit, and deploy workflows using natural language”
   • [claimed-docs] “Test the 'get-order-status' tool with order ID 98765 and check if the response matches what we expect.”
   • [claimed-docs] “/lorikeet:create-simulations build simulations for the refund workflow”
   • [claimed-docs] “Connect to your Lorikeet account from ChatGPT, Claude, Claude Code, and MintMCP using the Model Context Protocol.”
   • [probe] “official MCP server documented at https://docs.lorikeetcx.ai/mcp/mcp-server”

   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 userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Lorikeet—none0/10

   No evidence of a downloadable OpenAPI spec or machine-readable API documentation; evidence only covers MCP server integration, workflows, and product features, not a formal API spec artifact.

   ⚑ 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

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

   weight 1 · round drawn
   Lorikeet~partialclaimed5/10

   Evidence shows robust simulation/testing tooling (replay historical tickets, synthetic scenarios, guardrail adversarial tests) that approximates sandbox-style testing, but no explicit claim of an isolated sandbox environment distinct from production. missing for 10: explicit documentation of a dedicated sandbox/staging environment, confirmation that simulations do not touch or affect live production data/systems, and independent verification of this isolation.

   • [claimed-docs] “Generate simulations straight from your actual tickets and run them in bulk batches, so every workflow change is tested against the conversa…”
   • [claimed-docs] “Run simulation batches to test workflows against different customer scenarios”
   • [claimed-docs] “Replay historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps, then deploy on the topics …”
   • [claimed-docs] “Replay historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps”
   • [claimed-docs] “Author adversarial scenarios such as false authority claims, mid-conversation goal switches and prompt injection attempts, then run them as …”
   • [claimed-docs] “Run simulations - test workflows against different customer scenarios”

   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

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

   weight 2 · round drawn
   Lorikeet—none0/10

   No evidence pack item mentions API versioning, version numbers, or a deprecation policy for Lorikeet's APIs or MCP server; the docs discuss features and integrations but not API lifecycle/versioning commitments. Missing for 10: any documented API version scheme, changelog of breaking changes, or stated deprecation/support timeline.

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

   Lorikeet documents multiple bulk operations available to AI-native users via its MCP server and product surfaces: running simulations in bulk batches across hundreds of scenarios, auditing entire knowledge bases at scale, and reviewing 100% of conversations for quality (not manual spot checks). These are explicitly framed as batch/bulk actions accessible through natural-language or MCP-driven workflows. Missing for 10: independent/hands-on verification of bulk operation scale and performance, and no explicit example of bulk edits/updates to many tickets or records simultaneously (only bulk testing/auditing/review are documented).

   • [claimed-docs] “Generate simulations straight from your actual tickets and run them in bulk batches, so every workflow change is tested against the conversa…”
   • [claimed-docs] “Side-by-side batch comparisons show how a workflow edit changed outcomes across hundreds of scenarios, with per-conversation drill-downs whe…”
   • [claimed-docs] “Audit knowledge bases - analyze articles at scale, find gaps, and spot quality issues”
   • [claimed-docs] “Audit your entire knowledge base for gaps, outdated articles, and quality issues”
   • [claimed-docs] “Coach's Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “Coach’s Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “Replay historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps, then deploy on the topics …”
   • [claimed-docs] “Replay historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps”
   • [claimed-docs] “Side-by-side batch comparisons show how a workflow edit changed outcomes across hundreds of scenarios, with per-conversation drill-downs”

   proof ↗⚑ flag

   Parahelp~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to Parahelp
   Lorikeet~partialclaimed6/10

   Lorikeet's workflows and guardrails encode conditional, event-triggered actions (e.g., prompt-injection detection triggers block/rewrite/escalate, bad QA scores trigger refunds, campaign cadences control scheduled outreach, escalation triggers hand off to humans), and workflows can be built/edited via natural language including deterministic steps. However this is more built-in platform logic than a general-purpose rule-definition interface for arbitrary custom events an AI-native user could freely wire up. Missing for 10: a documented general rules/automation engine or API letting users define arbitrary trigger-condition-action rules beyond the platform's fixed guardrail/workflow/outbound features, and independent confirmation of this working in practice.

   • [claimed-docs] “Customer isolation, server-side identity validation, workflow-scoped tool access and hard execution caps are enforced in code rather than pr…”
   • [claimed-docs] “Incoming messages pass a prompt-injection classifier and bad-actor checks, while response guardrails screen what the agent says for groundin…”
   • [claimed-docs] “When Coach gives a conversation a bad score, we refund the AI portion of that interaction.”
   • [claimed-docs] “campaign cadences with scheduling windows control when outreach happens”
   • [claimed-docs] “When a case requires a specialist or regulatory review, it escalates with full interaction history so your team picks up mid-conversation.”
   • [claimed-docs] “Lorikeet coordinates a team of specialist agents, with pockets of determinism for regulated steps, to handle multi-party, multi-system workf…”
   • [claimed-docs] “The agent takes action through your APIs and MCP servers inside natural-language and deterministic workflows”

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

   The only relevant evidence is outbound campaign cadences with 'scheduling windows' controlling when outreach happens, which implies some recurring/scheduled automation but is narrowly scoped to outbound messaging rather than general recurring jobs or workflow runs. Missing for 10: explicit cron-like or recurring workflow scheduling for MCP-driven tasks (simulations, audits, diagnostics), documentation of scheduling frequency/config options, and any independent confirmation of recurring job execution.

   • [claimed-docs] “campaign cadences with scheduling windows control when outreach happens”

   proof ↗⚑ flag

   Parahelp✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   weight 1 · round to Parahelp
   Lorikeet~partialclaimed4/10

   Lorikeet's docs show workflow building/iteration via natural language and strong review tooling (simulations, batch comparisons showing how an edit changed outcomes across scenarios), which covers the 'review' part of the story. However, there is no explicit mention of a version history or a rollback/undo mechanism for automations. missing for 10: explicit versioning/change-history feature, explicit rollback/undo capability, evidence of restoring a prior workflow state.

   • [claimed-docs] “Build workflows - create and iterate on workflows using natural language”
   • [claimed-docs] “Build, edit, and deploy workflows using natural language”
   • [claimed-docs] “Side-by-side batch comparisons show how a workflow edit changed outcomes across hundreds of scenarios, with per-conversation drill-downs whe…”
   • [claimed-docs] “Side-by-side batch comparisons show how a workflow edit changed outcomes across hundreds of scenarios, with per-conversation drill-downs”
   • [claimed-docs] “Generate simulations straight from your actual tickets and run them in bulk batches, so every workflow change is tested against the conversa…”

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

   Lorikeet documents one agent resolving issues across chat, email, voice, SMS and WhatsApp (docs-31, docs-49), and mentions Slack as a place to interact with Coach (docs-10), but this is Coach access, not evidence that the customer-facing agent itself operates in Slack or social channels. missing for 10: explicit confirmation that the customer-facing support agent (not just Coach) handles Slack and social media channels, and independent/hands-on validation of omnichannel deployment.

   • [claimed-docs] “one agent that resolves issues end-to-end across chat, email, voice and SMS”
   • [claimed-docs] “resolve customer problems end-to-end across their lifecycle - via phone, SMS, chat, email, and WhatsApp”
   • [claimed-docs] “Talk to Coach wherever you work, whether in Lorikeet, Slack, Claude, ChatGPT, or via MCP.”
   • [claimed-docs] “When the AI concierge can't resolve a conversation, a human agent steps in directly inside the same platform”

   proof ↗⚑ flag

   Parahelp~partialclaimed5/10

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

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

   proof ↗⚑ flag

Languages

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

   weight 2 · round drawn
   Lorikeet—none0/10

   No evidence in the pack addresses multilingual support or the ability to serve customers in languages other than English despite an English-only knowledge base; nothing about translation, language detection, or multilingual training is mentioned.

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

   Lorikeet's marketing claims 'one agent that resolves issues end-to-end across chat, email, voice and SMS' and lists phone/voice among supported channels, implying the same agent handles calls. However, there is no detail on speech-in/speech-out mechanics, telephony integration, or evidence that voice interactions carry the same knowledge/actions/guardrails as chat beyond a generic channel list. missing for 10: specifics on speech recognition/TTS, call-handling architecture, latency/quality benchmarks, and confirmation that voice shares the same knowledge base and action set as chat.

   • [claimed-docs] “one agent that resolves issues end-to-end across chat, email, voice and SMS”
   • [claimed-docs] “resolve customer problems end-to-end across their lifecycle - via phone, SMS, chat, email, and WhatsApp”

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

   Lorikeet documents human handoff happening 'inside the same platform' when AI can't resolve, and specifically claims escalations carry 'full interaction history so your team picks up mid-conversation' (financial-services vertical) — directly supporting no-repeat handoff. However, evidence doesn't explicitly confirm a generated summary or structured 'collected details' package accompanying every escalation across all verticals, only interaction history. Missing for 10: explicit documentation of an auto-generated conversation summary at escalation, structured collected-details extraction, and independent/customer verification that customers never repeat themselves in practice.

   • [claimed-docs] “When the AI concierge can't resolve a conversation, a human agent steps in directly inside the same platform”
   • [claimed-docs] “When a case requires a specialist or regulatory review, it escalates with full interaction history so your team picks up mid-conversation.”
   • [claimed-docs] “Enforce required disclosures and data handling standards through built-in guardrails that balance conversational flexibility with structured…”

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

   Docs show human handoff when the AI can't resolve a ticket, escalation for regulatory/specialist cases with full context, guardrails that can 'escalate' on policy violations, and deployment scoped to trained topics — supporting topic-based and inability/explicit-need escalation. However there is no explicit mention of configuring handoff by sentiment or customer tier, nor independent verification that these rules are 'reliably obeyed'. Missing for 10: explicit sentiment-based trigger config, explicit customer-tier-based trigger config, and independent/hands-on evidence of reliability.

   • [claimed-docs] “When the AI concierge can't resolve a conversation, a human agent steps in directly inside the same platform”
   • [claimed-docs] “deploy on the topics the agent is trained for and leave the rest with your team”
   • [claimed-docs] “Incoming messages pass a prompt-injection classifier and bad-actor checks, while response guardrails screen what the agent says for groundin…”
   • [claimed-docs] “When a case requires a specialist or regulatory review, it escalates with full interaction history so your team picks up mid-conversation.”
   • [claimed-docs] “Outbound runs on recorded consent that is enforced when messages are sent, with opt-out handling and escalation paths for sensitive situatio…”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

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

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

   proof ↗⚑ flag

Hallucination

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

   weight 3 · round to Lorikeet
   Lorikeet✓fullclaimed8/10

   Lorikeet documents explicit guardrails that enforce grounding and policy compliance in code rather than prompts, including response screening for grounding/policy with block/rewrite/escalate actions, and adversarial simulation testing for false authority claims and prompt injection to validate safe-decline behavior before deployment. This directly targets stopping invented policies/prices/promises via server-side enforcement rather than relying on model honesty. Missing for 10: independent/third-party verification or a concrete hands-on example showing an off-knowledge question actually triggering a safe decline rather than a hallucinated answer.

   • [claimed-docs] “Customer isolation, server-side identity validation, workflow-scoped tool access and hard execution caps are enforced in code rather than pr…”
   • [claimed-docs] “Incoming messages pass a prompt-injection classifier and bad-actor checks, while response guardrails screen what the agent says for groundin…”
   • [claimed-docs] “every event lands in your analytics as a tracked outcome your QA team can review”
   • [claimed-docs] “Author adversarial scenarios such as false authority claims, mid-conversation goal switches and prompt injection attempts, then run them as …”
   • [claimed-docs] “Enforce required disclosures and data handling standards through built-in guardrails that balance conversational flexibility with structured…”

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

   Lorikeet's documented model is autonomous resolution with post-hoc QA (Coach reviews 100% of tickets after the fact) and escalation to humans only when the AI can't resolve a case, not a pre-send draft-for-approval workflow. No evidence describes a mode where every agent reply is queued for human sign-off before reaching a customer. Missing for 10: any mention of a draft/approve workflow, human-in-the-loop send gating, or a configurable 'supervised' launch mode.

   • [claimed-docs] “When the AI concierge can't resolve a conversation, a human agent steps in directly inside the same platform”
   • [claimed-docs] “Incoming messages pass a prompt-injection classifier and bad-actor checks, while response guardrails screen what the agent says for groundin…”
   • [claimed-docs] “Coach’s Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “When a case requires a specialist or regulatory review, it escalates with full interaction history so your team picks up mid-conversation.”

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

   Lorikeet documents topic-scoped deployment ("deploy on the topics the agent is trained for and leave the rest with your team"), workflow-scoped tool access with hard execution caps enforced in code, and escalation paths for regulated/specialist cases with full history handoff — all consistent with restricting the agent from acting on sensitive topics. However, there's no explicit documentation of a UI/config for support-ops to designate specific topics (e.g., legal threats, cancellations, security) as strictly human-only with enforced non-freelancing. Missing for 10: explicit topic-tagging/human-only designation feature, confirmation that agent cannot even attempt those topics (vs. escalating mid-conversation), and independent verification of this behavior in production.

   • [claimed-docs] “deploy on the topics the agent is trained for and leave the rest with your team”
   • [claimed-docs] “Lorikeet coordinates a team of specialist agents, with pockets of determinism for regulated steps, to handle multi-party, multi-system workf…”
   • [claimed-docs] “Customer isolation, server-side identity validation, workflow-scoped tool access and hard execution caps are enforced in code rather than pr…”
   • [claimed-docs] “When a case requires a specialist or regulatory review, it escalates with full interaction history so your team picks up mid-conversation.”
   • [claimed-docs] “Enforce required disclosures and data handling standards through built-in guardrails that balance conversational flexibility with structured…”

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

   Lorikeet claims analytics tracking 'resolution quality, customer satisfaction, revenue impact, and operational efficiency' and that 'every event lands in your analytics as a tracked outcome,' which loosely maps to resolution rate, CSAT, and cost metrics, but there is no explicit mention of a handoff-rate metric or a dedicated exec-facing dashboard view combining these four numbers. missing for 10: explicit handoff-rate metric, dedicated dashboard UI/screenshot evidence, cost-per-resolution specifics, and independent corroboration of dashboard usability.

   • [claimed-docs] “Track resolution quality, customer satisfaction, revenue impact, and operational efficiency with industry-leading analytics.”
   • [claimed-docs] “Scale and optimize with conversational insights and analytics from Lorikeet Coach”
   • [claimed-docs] “every event lands in your analytics as a tracked outcome your QA team can review”

   proof ↗⚑ flag

   Parahelp—none0/10

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

   ⚑ flag

Insights

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

   weight 1 · round drawn
   Lorikeet—none0/10

   Evidence shows general analytics and quality-review features (e.g., 'Track resolution quality, customer satisfaction... with industry-leading analytics', Coach reviewing 100% of conversations) but no mention of topic clustering of conversations or proactive surfacing of emerging product issues before ticket-volume spikes. missing for 10: topic clustering of conversations, trend/anomaly detection for emerging issues, ticket-volume spike prediction or alerting.

   • [claimed-docs] “Track resolution quality, customer satisfaction, revenue impact, and operational efficiency with industry-leading analytics.”
   • [claimed-docs] “Scale and optimize with conversational insights and analytics from Lorikeet Coach”
   • [claimed-docs] “Coach's Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”

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

   Docs claim Lorikeet works 'alongside your existing tools' and connects 'in seconds to your ticketing system' via integrations, implying helpdesk co-existence, but there is no specific evidence of named Zendesk/Salesforce/Intercom connectors or two-way ticket/context sync — the pack focuses on MCP client integrations (Claude, ChatGPT) rather than helpdesk platforms. missing for 10: named Zendesk/Salesforce/Intercom integration docs, evidence of bidirectional ticket sync, standalone-mode confirmation, independent corroboration of integration reliability.

   • [claimed-docs] “No migration required: Lorikeet works alongside your existing tools.”
   • [claimed-docs] “Connect Lorikeet in seconds to your ticketing system, knowledge base, and internal tools to seamlessly ingest data and take action for your …”
   • [claimed-docs] “When the AI concierge can't resolve a conversation, a human agent steps in directly inside the same platform”
   • [claimed-docs] “The agent takes action through your APIs and MCP servers inside natural-language and deterministic workflows”

   proof ↗⚑ flag

   Parahelp✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Freshness

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

   weight 2 · round to Parahelp
   Lorikeet—none0/10

   Evidence shows Lorikeet ingests knowledge bases and can audit them for gaps/outdated articles, and connects to ticketing/knowledge sources 'in seconds', but there is no mention of scheduled or change-triggered re-syncing of sources without manual re-upload. missing for 10: explicit scheduled/webhook-based re-sync mechanism, evidence of automatic detection of source updates, any documentation of sync cadence or on-change triggers.

   • [claimed-docs] “Audit knowledge bases - analyze articles at scale, find gaps, and spot quality issues”
   • [claimed-docs] “Connect Lorikeet in seconds to your ticketing system, knowledge base, and internal tools to seamlessly ingest data and take action for your …”
   • [claimed-docs] “Audit your entire knowledge base for gaps, outdated articles, and quality issues”
   • [claimed-docs] “train the agent on your business context, brand guidelines, help docs and standard operating procedures”

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

   Lorikeet explicitly documents auditing knowledge bases at scale to find gaps and quality issues, and its simulation/replay tooling surfaces knowledge gaps by replaying historical tickets and synthetic scenarios to project resolution quality before deployment. Coach's Ticket Quality Score also reviews 100% of conversations to catch fumbled answers and feed fixes back. Missing for 10: independent/hands-on validation of the gap-detection accuracy and no explicit mention of detecting 'conflicting' content specifically (only gaps/outdated/quality issues).

   • [claimed-docs] “Audit knowledge bases - analyze articles at scale, find gaps, and spot quality issues”
   • [claimed-docs] “Audit your entire knowledge base for gaps, outdated articles, and quality issues”
   • [claimed-docs] “Replay historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps, then deploy on the topics …”
   • [claimed-docs] “Replay historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps”
   • [claimed-docs] “Coach's Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “Coach’s Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “Coach reviews 100% of tickets against your quality standards and turns findings into fixes, so your AI agent improves every week instead of …”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

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

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

   proof ↗⚑ flag

Grounding

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

   weight 3 · round drawn
   Lorikeet—none0/10

   Lorikeet documents training its agent on 'business context, brand guidelines, help docs and standard operating procedures' (docs-25) and mentions 'grounding' as a guardrail check (docs-35), but there is no evidence that end-user-facing answers cite or display the specific article/source used to generate a response. Missing for 10: any documented citation/source-attribution UI or API in agent responses, and independent confirmation that answers reference specific knowledge-base articles.

   • [claimed-docs] “train the agent on your business context, brand guidelines, help docs and standard operating procedures”
   • [claimed-docs] “Incoming messages pass a prompt-injection classifier and bad-actor checks, while response guardrails screen what the agent says for groundin…”
   • [claimed-docs] “Audit your entire knowledge base for gaps, outdated articles, and quality issues”

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

   Lorikeet explicitly claims to 'seamlessly ingest data' from ticketing systems and knowledge bases (docs-13), to train the agent on 'business context, brand guidelines, help docs and standard operating procedures' (docs-25), to audit the entire knowledge base for gaps/outdated content (docs-3, docs-16), and to replay historical tickets to surface knowledge gaps (docs-21, docs-26) — covering help center, docs, and past tickets without manual re-authoring. Internal wikis are not explicitly named as a source type, and all evidence is first-party vendor documentation with no independent/hands-on corroboration of ingestion working end-to-end. Missing for 10: explicit mention of internal wiki ingestion, and independent verification of the ingestion pipeline's fidelity/accuracy.

   • [claimed-docs] “Connect Lorikeet in seconds to your ticketing system, knowledge base, and internal tools to seamlessly ingest data and take action for your …”
   • [claimed-docs] “train the agent on your business context, brand guidelines, help docs and standard operating procedures”
   • [claimed-docs] “Audit knowledge bases - analyze articles at scale, find gaps, and spot quality issues”
   • [claimed-docs] “Audit your entire knowledge base for gaps, outdated articles, and quality issues”
   • [claimed-docs] “Replay historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps, then deploy on the topics …”
   • [claimed-docs] “Replay historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps”

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

   Lorikeet's MCP server exposes a broad set of actions also available in the UI—diagnosing tickets, auditing knowledge bases, building/testing workflows, running simulations—letting AI-native users act via Claude/ChatGPT/Codex instead of the dashboard. However, there's no evidence of a general-purpose REST/GraphQL API or explicit claim of full UI/API parity (e.g., outbound campaign management, guardrail configuration, analytics dashboards aren't shown as MCP-accessible). Missing for 10: explicit full API parity statement, broader API coverage beyond MCP-listed actions, independent confirmation of completeness.

   • [claimed-docs] “The Lorikeet MCP server lets you interact with your Lorikeet account directly from Claude Code, Claude.ai, ChatGPT, and Codex.”
   • [claimed-docs] “Diagnose tickets - trace workflow execution and identify root causes”
   • [claimed-docs] “Audit knowledge bases - analyze articles at scale, find gaps, and spot quality issues”
   • [claimed-docs] “Build workflows - create and iterate on workflows using natural language”
   • [claimed-docs] “Test tools - run and validate tool configurations directly from your AI assistant”
   • [claimed-docs] “Explore your setup - inspect workflows, tools, and integrations”
   • [claimed-docs] “Run simulations - test workflows against different customer scenarios”
   • [claimed-docs] “The agent takes action through your APIs and MCP servers inside natural-language and deterministic workflows”
   • [probe] “official MCP server documented at https://docs.lorikeetcx.ai/mcp/mcp-server”

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

   No evidence pack items mention data export, open data formats, or account/data portability for leaving the platform; the docs cover MCP integrations, workflows, simulations, and guardrails but nothing about exporting or migrating data out. Missing for 10: any documentation of export functionality, supported open formats (CSV/JSON), or data portability/exit process.

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

   The only evidence touching pricing-economics is the refund policy tying billing to Coach's quality score ('When Coach gives a conversation a bad score, we refund the AI portion of that interaction'), which shows some outcome-linkage in billing, but there is no published price list, per-resolution rate, cap structure, or self-serve pricing page. Missing for 10: a published price sheet or rate card, explicit per-resolution cost, spend/volume caps, and any evidence pricing is transparent versus custom enterprise quoting.

   • [claimed-docs] “When Coach gives a conversation a bad score, we refund the AI portion of that interaction.”

   proof ↗⚑ 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
   Lorikeet—none0/10

   The evidence covers compliance/trust items (Vanta certifications, zero-data-retention with model vendors) but no mention of data residency or region-selection options for storage. Missing for 10: any documentation of regional data storage choices, residency guarantees, or data localization 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 Lorikeet
   Lorikeet✓fullclaimed7/10

   Lorikeet explicitly states zero-data-retention agreements with all model vendors and no fine-tuning on customer data, directly addressing the story's request to prevent data from being used for AI training. This is backed by independently verified trust/compliance reports on their Vanta Trust Center. Missing for 10: independent hands-on verification or third-party audit confirmation of this specific claim, and no detail on user-level opt-out controls or granularity of enforcement.

   • [claimed-docs] “Zero-data-retention agreements with all model vendors and no fine-tuning on customer data.”
   • [claimed-docs] “All four are independently verified, published on our public Vanta Trust Center with reports downloadable under NDA, and refreshed annually.”

   proof ↗⚑ flag

   Parahelp~partialclaimed4/10

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

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

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Parahelp
   Lorikeet~partialclaimed4/10

   Lorikeet mentions zero-data-retention agreements with model vendors and no fine-tuning on customer data, plus SOC2-style independently verified reports on a trust center, which touches data retention posture at the vendor-model level. However, there is no evidence of user-facing controls letting an AI-native user configure or request deletion/retention of their own conversation or account data within Lorikeet itself. Missing for 10: explicit customer-data deletion/export controls, retention period configuration, and user-initiated deletion workflows.

   • [claimed-docs] “All four are independently verified, published on our public Vanta Trust Center with reports downloadable under NDA, and refreshed annually.”
   • [claimed-docs] “Zero-data-retention agreements with all model vendors and no fine-tuning on customer data.”

   proof ↗⚑ flag

   Parahelp~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Lorikeet—none0/10

   Lorikeet is a customer-support AI platform, and telemetry opt-out for the product itself is a fair privacy-posture question, but none of the evidence mentions any telemetry/usage-tracking opt-out mechanism for users of the product; it only discusses data retention with model vendors and consent handling for outbound customer messaging, which is unrelated to product telemetry opt-out.

   • [claimed-docs] “All four are independently verified, published on our public Vanta Trust Center with reports downloadable under NDA, and refreshed annually.”
   • [claimed-docs] “Zero-data-retention agreements with all model vendors and no fine-tuning on customer data.”

   proof ↗⚑ 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 Lorikeet
   Lorikeet✓fullclaimed7/10

   Lorikeet's docs describe connecting to ticketing systems, knowledge bases, and internal tools/APIs to 'ingest data and take action for your customers' (lorikeet-docs-13, lorikeet-docs-28, lorikeet-docs-29), with concrete examples like testing a 'get-order-status' tool with a real order ID (lorikeet-docs-19) and financial-services use cases like disputes/loan inquiries requiring account-specific data (lorikeet-docs-43, lorikeet-docs-44). This shows the agent is designed to pull and act on live customer data rather than just static help content. missing for 10: independent/hands-on verification that responses actually reflect real-time account state in production, and more detail on latency/freshness guarantees for live data lookups.

   • [claimed-docs] “Connect Lorikeet in seconds to your ticketing system, knowledge base, and internal tools to seamlessly ingest data and take action for your …”
   • [claimed-docs] “Test the 'get-order-status' tool with order ID 98765 and check if the response matches what we expect.”
   • [claimed-docs] “The agent takes action through your APIs and MCP servers inside natural-language and deterministic workflows”
   • [claimed-docs] “Build your customer Concierge to take actions inside the tools your team already uses”
   • [claimed-docs] “Automate disputes, loan inquiries, payments and compliance cases across every customer channel”
   • [claimed-docs] “When a case requires a specialist or regulatory review, it escalates with full interaction history so your team picks up mid-conversation.”

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

   Lorikeet's docs describe workflows that coordinate multi-step, multi-system troubleshooting (e.g. 'coordinates a team of specialist agents... to handle multi-party, multi-system workflows end-to-end' and 'diagnose tickets by tracing workflow execution') rather than single canned replies, and its agent resolves issues 'end-to-end' across channels. However, there is no explicit documentation showing the agent proactively asking clarifying questions mid-conversation or examples of dialogue-based troubleshooting turns. Missing for 10: explicit examples/transcripts of clarifying-question behavior, documentation describing conversational back-and-forth troubleshooting logic rather than just workflow/tool orchestration.

   • [claimed-docs] “Lorikeet coordinates a team of specialist agents, with pockets of determinism for regulated steps, to handle multi-party, multi-system workf…”
   • [claimed-docs] “one agent that resolves issues end-to-end across chat, email, voice and SMS”
   • [claimed-docs] “Diagnose tickets by tracing workflow execution and identifying root causes”
   • [claimed-docs] “Build, edit, and deploy workflows using natural language”
   • [claimed-docs] “The agent takes action through your APIs and MCP servers inside natural-language and deterministic workflows”

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

   Lorikeet's docs repeatedly claim end-to-end resolution (chat, email, voice, SMS), with escalation to humans when it can't resolve, plus QA scoring (Ticket Quality Score) and analytics tracking 'resolution quality' as an outcome metric, and even a refund-on-bad-score mechanism tied to quality. However, all evidence is vendor-authored marketing/docs; there are no independent benchmarks, customer case studies, or hard resolution-rate numbers (e.g., % of conversations fully resolved) to substantiate the claims. Missing for 10: independent/third-party resolution-rate data, customer-reported metrics, and clear definition/measurement methodology distinguishing true resolution from deflection.

   • [claimed-docs] “one agent that resolves issues end-to-end across chat, email, voice and SMS”
   • [claimed-docs] “resolve customer problems end-to-end across their lifecycle - via phone, SMS, chat, email, and WhatsApp”
   • [claimed-docs] “When the AI concierge can't resolve a conversation, a human agent steps in directly inside the same platform”
   • [claimed-docs] “Track resolution quality, customer satisfaction, revenue impact, and operational efficiency with industry-leading analytics.”
   • [claimed-docs] “Coach’s Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “When Coach gives a conversation a bad score, we refund the AI portion of that interaction.”
   • [claimed-docs] “Coach's Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”

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

   Lorikeet docs show the agent can be trained on 'business context, brand guidelines, help docs and standard operating procedures' (lorikeet-docs-25), and Coach's Ticket Quality Score reviews 100% of conversations against quality standards to catch drift (lorikeet-docs-9, lorikeet-docs-38), supporting brand-voice control and consistency monitoring. However, there is no explicit evidence of multi-language tone consistency or dedicated brand-voice/style configuration tooling beyond general training inputs. Missing for 10: explicit multilingual consistency support, dedicated tone/voice configuration UI, and independent evidence of voice consistency across topics/languages.

   • [claimed-docs] “train the agent on your business context, brand guidelines, help docs and standard operating procedures”
   • [claimed-docs] “Coach's Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “Coach’s Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “deploy on the topics the agent is trained for and leave the rest with your team”

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

   Lorikeet's Coach product directly addresses this story: it reviews 100% of conversations against quality standards (not just samples), scores them via a Ticket Quality Score, flags failures (bad scores trigger refunds), and turns findings into fixes that feed back into the agent so it 'improves every week instead of drifting.' Simulations complement this with batch testing and adversarial scenario scoring tied to guardrails and analytics tracking. Missing for 10: independent/hands-on verification of the review loop in practice and more detail on how flagged failures are triaged/assigned to human reviewers.

   • [claimed-docs] “Coach's Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “Coach reviews 100% of tickets against your quality standards and turns findings into fixes, so your AI agent improves every week instead of …”
   • [claimed-docs] “Coach’s Ticket Quality Score reviews 100% of conversations against your quality standards, AI and human alike, replacing manual spot checks …”
   • [claimed-docs] “When Coach gives a conversation a bad score, we refund the AI portion of that interaction.”
   • [claimed-docs] “Coach can implement improvements on your behalf, or make suggestions for you to action yourself.”
   • [claimed-docs] “every event lands in your analytics as a tracked outcome your QA team can review”
   • [claimed-docs] “Generate simulations straight from your actual tickets and run them in bulk batches, so every workflow change is tested against the conversa…”
   • [claimed-docs] “Author adversarial scenarios such as false authority claims, mid-conversation goal switches and prompt injection attempts, then run them as …”

   proof ↗⚑ flag

   Parahelp~partialclaimed5/10

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

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

   proof ↗⚑ flag

Simulation

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

   weight 2 · round to Lorikeet
   Lorikeet✓fullclaimed9/10

   Lorikeet's Simulations product directly supports this story: it generates simulations from actual historical tickets and runs them in bulk batches before workflow changes go live, with side-by-side batch comparisons and per-conversation drill-downs, plus authored adversarial/guardrail scenarios to pre-test against tricky real-world behavior. Docs also describe replaying historical tickets and synthetic scenarios in bulk to project resolution quality before deploying on trained topics. Missing for 10: independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “Generate simulations straight from your actual tickets and run them in bulk batches, so every workflow change is tested against the conversa…”
   • [claimed-docs] “Side-by-side batch comparisons show how a workflow edit changed outcomes across hundreds of scenarios, with per-conversation drill-downs whe…”
   • [claimed-docs] “Author adversarial scenarios such as false authority claims, mid-conversation goal switches and prompt injection attempts, then run them as …”
   • [claimed-docs] “Replay historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps, then deploy on the topics …”
   • [claimed-docs] “Replay historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps”
   • [claimed-docs] “Run simulations - test workflows against different customer scenarios”

   proof ↗⚑ flag

   Parahelp✓fullclaimed8/10

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

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

   proof ↗⚑ flag