Fin vs Lorikeet

Actions

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

   weight 3 · round to Lorikeet
   Fin~partialclaimed6/10

   Fin's Procedures feature explicitly supports multi-step business logic with third-party systems (refunds, order changes, etc. are common examples in docs like 'Takes action to update external systems' and Procedures training), and data connectors (Stripe, Shopify) plus MCP/API access enable real API calls. However, evidence does not detail per-action scoped authentication/authorization — no documentation on granular auth scoping per action, permission boundaries, or audit trails for individual API calls. missing for 10: explicit scoped-auth-per-action documentation, permission/authorization model for individual actions, and independent verification that real refunds/subscription updates are executed successfully in production.

   • [claimed-docs] “Takes action to update external systems”
   • [claimed-docs] “Building Fin Procedures”
   • [claimed-docs] “Procedures let you train Fin to handle queries with multiple steps, business logic and third-party systems from start to finish.”
   • [claimed-docs] “Data connector templates are now generally available, with ready-to-install templates across Stripe, Shopify and Statuspage.”
   • [claimed-docs] “The Fin API platform includes APIs for answer generation and knowledge retrieval, available as a set or independently.”
   • [claimed-docs] “give you the tools to safely deploy AI within your own boundaries.”

   proof ↗⚑ flag

   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

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

   Fin has a dedicated "Building Fin Procedures" feature explicitly for encoding multi-step SOPs with business logic and branching, plus "Giving Fin Guidance" and escalation-rule configuration to control deterministic branching to humans or other steps, and a testing suite to validate procedures before launch. This directly matches the story of encoding SOPs with deterministic branching for known issue types. Missing for 10: independent hands-on verification of branching logic depth/determinism and more detail on how conditional branches are authored (docs are descriptive marketing/help-article summaries rather than technical specs).

   • [claimed-docs] “Building Fin Procedures”
   • [claimed-docs] “Procedures let you train Fin to handle queries with multiple steps, business logic and third-party systems from start to finish.”
   • [claimed-docs] “Giving Fin Guidance”
   • [claimed-docs] “Manage Fin AI Agent's escalation guidance and rules”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation”
   • [claimed-docs] “Train Fin on your Procedures, knowledge, and policies, test performance before launch, deploy across every channel, then analyze and improve…”

   proof ↗⚑ flag

   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

Agent access

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

   weight 2 · round to Lorikeet
   Fin✓fullprobed8/10

   A live probe confirms Fin publishes an llms.txt file at https://fin.ai/llms.txt (HTTP 200) explicitly framed to help LLMs understand its content structure, and Fin also offers an MCP server and a CLI agents can be pointed at for setup. Missing for 10: markdown-doc mirrors (docs-md probe 404) and a discoverable OpenAPI spec (all candidates 404), which would round out agent-friendly documentation.

   • [probe] “PROBE llms.txt: HTTP 200 at https://fin.ai/llms.txt # Fin — llms.txt > This file helps large language models (LLMs) understand the content …”
   • [claimed-docs] “Point your AI coding Agent at the Fin CLI to set up Fin on your website and configure your Intercom helpdesk — all without leaving your codi…”
   • [probe] “official MCP server documented at https://developers.intercom.com/docs/guides/mcp”
   • [probe] “PROBE docs-md: HTTP 404 at https://fin.ai/help/en/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://fin.ai/openapi.json, https://fin.ai/swagger.json, https://fin.ai/api/openapi.json, https://f…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Fin
   Fin✓fullclaimed7/10

   Fin's own docs state it 'works through MCP or API Data Connectors for your business tools' (docs-40/54) and explicitly describe connecting the 'Zapier MCP connector to Fin' (intdir-3), confirming Fin can consume external MCP servers as tools. Missing for 10: independent/hands-on verification of MCP tool usage in production and a broader list of supported MCP servers beyond the Zapier example.

   • [claimed-docs] “It works through MCP or API Data Connectors for your business tools, integrations with Intercom or your existing helpdesk”
   • [claimed-docs] “It works through MCP or API Data Connectors for your business tools, integrations with Intercom or your existing helpdesk, and native suppor…”
   • [claimed-docs] “Connect the Zapier MCP connector to Fin Manage workspace owners”
   • [claimed-docs] “Learn how to use the Model Context Protocol (MCP) to enable AI agents to securely access and interact with your Intercom data whenever helpf…”
   • [claimed-docs] “MCP is a protocol that enables AI tools and applications to securely access and interact with your Intercom data whenever helpful.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Fin
   Fin✓fullprobed8/10

   Intercom publishes official docs for an MCP server that lets AI agents securely access and interact with Intercom data, and this is corroborated by a dedicated probe confirming the documented endpoint plus Fin's own integrations page referencing MCP connectivity. missing for 10: independent/hands-on confirmation of the MCP server working in practice beyond vendor docs, and clearer detail on scope/auth setup.

   • [claimed-docs] “Learn how to use the Model Context Protocol (MCP) to enable AI agents to securely access and interact with your Intercom data whenever helpf…”
   • [claimed-docs] “MCP is a protocol that enables AI tools and applications to securely access and interact with your Intercom data whenever helpful.”
   • [claimed-docs] “It works through MCP or API Data Connectors for your business tools, integrations with Intercom or your existing helpdesk”
   • [claimed-docs] “It works through MCP or API Data Connectors for your business tools, integrations with Intercom or your existing helpdesk, and native suppor…”
   • [probe] “official MCP server documented at https://developers.intercom.com/docs/guides/mcp”

   proof ↗⚑ flag

   Lorikeet✓fullprobed7/10

   Lorikeet publishes an official MCP server (docs.lorikeetcx.ai/mcp/mcp-server) that lets Claude, ChatGPT, Claude Code, Codex, and MintMCP connect directly to a Lorikeet account, with documented capabilities like diagnosing tickets, auditing knowledge bases, building workflows, testing tools, and running simulations via MCP. This is confirmed live (HTTP 200) via probe evidence, not just marketing copy. Missing for 10: independent/hands-on third-party verification of the MCP server working end-to-end, and no community reports corroborating 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] “Connect to your Lorikeet account from ChatGPT, Claude, Claude Code, and MintMCP using the Model Context Protocol.”
   • [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

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Fin—none0/10

   Evidence shows Fin has an API, Node SDK, and MCP server, but no official CLI tool is documented or referenced anywhere in the evidence pack.

   ⚑ flag

   Lorikeet—none0/10

   Lorikeet is a customer-support AI platform; the story asks for an official CLI for AI-native workflows. Evidence shows an MCP server and Claude-code skills/slash commands but no standalone CLI tool is documented anywhere in the pack. missing for 10: any mention of a CLI binary/tool, installation instructions, or CLI command reference.

   • [claimed-docs] “The Lorikeet MCP server lets you interact with your Lorikeet account directly from Claude Code, Claude.ai, ChatGPT, and Codex.”
   • [claimed-docs] “/lorikeet:create-simulations build simulations for the refund workflow”
   • [probe] “official MCP server documented at https://docs.lorikeetcx.ai/mcp/mcp-server”

   proof ↗⚑ flag

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

   weight 3 · round to Lorikeet
   Fin~partialprobed7/10

   Fin ships a documented Fin Agent API and an official TypeScript SDK (intercom-node) with concrete usage examples, plus a separate API platform for answer generation/knowledge retrieval, giving AI-native users a real programmatic path to drive Fin. However, key orchestration endpoints (Discover capabilities, Ask Fin, Run a procedure, Escalate) are only in Preview API version, and automated probes found no discoverable OpenAPI/swagger spec, suggesting the public API surface is not fully standardized/discoverable yet. Missing for 10: stable (non-preview) orchestration endpoints, a machine-readable OpenAPI spec, and independent hands-on developer corroboration beyond vendor docs/SDK repo.

   • [claimed-docs] “Fin can be accessed programmatically via an API. You call Fin from your o”
   • [claimed-docs] “The new orchestration endpoints — Discover capabilities, Ask Fin, Run a procedure, and Escalate to a human — are currently available in the …”
   • [claimed-docs] “The Fin API platform includes APIs for answer generation and knowledge retrieval, available as a set or independently.”
   • [claimed-docs] “Build world-class customer experiences, agents, and products with the best-performing models for customer service.”
   • [github] “await client.aiContent.createContentImportSource({ url: "https://www.example.com" });”
   • [github] “List endpoints are paginated. The SDK provides an iterator so that you can simply loop over the items”
   • [github] “The Intercom TypeScript library provides convenient access to the Intercom APIs from TypeScript.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://fin.ai/openapi.json, https://fin.ai/swagger.json, https://fin.ai/api/openapi.json, https://f…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Lorikeet
   Fin—none0/10

   Evidence covers API access, MCP, webhooks, and integrations, but there is no mention of scoped or least-privilege API credential/token issuance for agents (e.g., granular permission scopes, per-agent API keys). Absence of evidence for an applicable capability yields 'none'. missing for 10: scoped/least-privilege credential issuance, API key/token permission granularity, agent-specific credential management docs.

   • [claimed-docs] “Fin can be accessed programmatically via an API. You call Fin from your o”
   • [claimed-docs] “Learn how to use the Model Context Protocol (MCP) to enable AI agents to securely access and interact with your Intercom data whenever helpf…”
   • [claimed-docs] “MCP is a protocol that enables AI tools and applications to securely access and interact with your Intercom data whenever helpful.”

   proof ↗⚑ flag

   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

7. ai-native userBuild against official SDKs

   weight 2 · round to Fin
   Fin~partialprobed6/10

   Intercom publishes an official TypeScript/Node SDK (intercom-node) with convenient API access and iterator support, plus a documented Fin Agent API and API platform for programmatic use. However, only one official SDK language is evidenced, there's no public OpenAPI spec (probe returned 404s across all candidate paths), and no independent corroboration of SDK quality/adoption exists. Missing for 10: multi-language SDK coverage, publicly discoverable OpenAPI/schema, and third-party validation of SDK reliability.

   • [github] “await client.aiContent.createContentImportSource({ url: "https://www.example.com" });”
   • [github] “List endpoints are paginated. The SDK provides an iterator so that you can simply loop over the items”
   • [github] “The Intercom TypeScript library provides convenient access to the Intercom APIs from TypeScript.”
   • [claimed-docs] “Fin can be accessed programmatically via an API. You call Fin from your o”
   • [claimed-docs] “The Fin API platform includes APIs for answer generation and knowledge retrieval, available as a set or independently.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://fin.ai/openapi.json, https://fin.ai/swagger.json, https://fin.ai/api/openapi.json, https://f…”

   proof ↗⚑ flag

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Fin
   Fin✓fullclaimed8/10

   Intercom's developer docs explicitly document webhooks for subscribing to real-time event notifications (Contact created, Conversation received, Outbound Message receipt), directly matching the story. Missing for 10: independent/hands-on corroboration of webhook reliability and broader event coverage beyond the three examples cited.

   • [claimed-docs] “Webhooks allow you to subscribe to real-time notifications of events happening in Intercom; a Contact created, an incoming Conversation rece…”
   • [claimed-docs] “Webhooks allow you to subscribe to real-time notifications of events happening in Intercom”

   proof ↗⚑ flag

   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

Agentic features

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

   weight 2 · round to Lorikeet
   Fin~partialclaimed6/10

   Fin's 'Insights', 'AI Recommendations', 'AI Topics', 'Trends', and CX Score features (docs-16, docs-47, docs-61) show it surfaces AI-generated analysis of conversation data, and 'Monitors'/'Custom AI Scorecards' extend this to proactive alerting. However this is framed around support-conversation analytics rather than a general 'insights from your data' experience, and there's no independent/hands-on validation of accuracy or usefulness of these AI-generated insights. missing for 10: independent corroboration of insight quality, broader data-source coverage beyond support conversations, concrete UI examples of AI-generated suggestions.

   • [claimed-docs] “Operator, CX Score, AI Topics, Trends, AI Recommendations, Monitors, Custom AI Scorecards, Incident Detection”
   • [claimed-docs] “Insights continuously analyzes every Fin and human conv”
   • [claimed-docs] “With Insights, Monitors New, and Recommendations, you have everything you need to understand, measure, and improve your customer experience”
   • [claimed-docs] “Train Fin on your Procedures, knowledge, and policies, test performance before launch, deploy across every channel, then analyze and improve…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Lorikeet
   Fin~partialcommunity6/10

   Fin's Procedures, Tasks, Workflows, and Proactive Outbound Suite are documented as letting Fin autonomously handle multi-step customer queries, business logic, and third-party system actions end-to-end without human intervention, and Fin resolves a majority of queries (76%) without agent involvement. However, evidence is entirely vendor marketing/help docs with no independent or hands-on confirmation of scheduling/background execution mechanics, and one community comment questions whether open-ended autonomous agent behavior is even desirable versus deterministic workflows. Missing for 10: independent verification of autonomous background execution, technical detail on triggers/scheduling for Procedures/Tasks, and hands-on confirmation that these run without ongoing human oversight.

   • [claimed-docs] “Building Fin Procedures”
   • [claimed-docs] “Manage your Fin workflows”
   • [claimed-docs] “Introduction to Fin Tasks”
   • [claimed-docs] “Procedures let you train Fin to handle queries with multiple steps, business logic and third-party systems from start to finish.”
   • [claimed-docs] “Proactive Outbound Suite”
   • [claimed-docs] “Fin resolves 76% of customer queries on average, and handles multi-step queries end to end. Your customers get fast, accurate answers. Your …”
   • [community] “A commenter with a decade of customer-service AI/NLP experience argued 99% of support tasks (order status, returns, troubleshooting) are ful…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Fin
   Fin✓fullcommunity8/10

   Fin is itself a built-in AI agent that customers and support teams delegate tasks to — it resolves ~76% of queries end-to-end, handles multi-step 'Procedures' with business logic, takes actions on external systems, and works across channels (chat, email, voice, Slack, WhatsApp). This is documented extensively in first-party docs/help articles covering delegation-style use (Fin Tasks, Fin Procedures, escalation rules, API/Agent API for programmatic delegation). missing for 10: independent hands-on validation of delegation quality (one HN commenter says they've never seen Fin in the wild, and another questions whether autonomous agent reasoning is even the right approach vs deterministic workflows), and no live product screenshots/demo confirming smooth end-user delegation experience.

   • [claimed-docs] “Handles tickets, cases, emails, live chat, WhatsApp, SMS, and more”
   • [claimed-docs] “Takes action to update external systems”
   • [claimed-docs] “Building Fin Procedures”
   • [claimed-docs] “Introduction to Fin Tasks”
   • [claimed-docs] “Procedures let you train Fin to handle queries with multiple steps, business logic and third-party systems from start to finish.”
   • [claimed-docs] “Fin resolves 76% of customer queries on average, and handles multi-step queries end to end. Your customers get fast, accurate answers. Your …”
   • [claimed-docs] “Fin can be accessed programmatically via an API. You call Fin from your o”
   • [community] “"I've never seen or interacted with Fin that I've noticed... I suspect it's very visible for Intercom, but not necessarily so for everyone e…”
   • [community] “A commenter with a decade of customer-service AI/NLP experience argued 99% of support tasks (order status, returns, troubleshooting) are ful…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Lorikeet
   Fin~partialclaimed6/10

   Fin's core function is responding to customer queries in natural language across channels, and admins can 'give Fin guidance' and train Procedures using natural-language instructions (docs-22, docs-44, docs-60); the Fin CLI also lets an AI coding agent configure Fin setup based on natural-language prompts (docs-38). However there's no clear evidence of a full natural-language command interface for operating/administering the product itself (e.g., configuring settings, running reports) beyond training/guidance content. Missing for 10: documented NL-driven admin console commands, evidence of broad NL task execution beyond content/guidance training, and independent verification of this capability in practice.

   • [claimed-docs] “Giving Fin Guidance”
   • [claimed-docs] “Procedures let you train Fin to handle queries with multiple steps, business logic and third-party systems from start to finish.”
   • [claimed-docs] “Point your AI coding Agent at the Fin CLI to set up Fin on your website and configure your Intercom helpdesk — all without leaving your codi…”
   • [claimed-docs] “Train Fin on your knowledge, data, policies, and tone of voice. Fin will use everything it knows to deliver consistent, accurate answers”

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round drawn
   Fin—none0/10

   Fin has documented REST APIs (Fin Agent API, Node/TS SDK) but no evidence of a downloadable machine-readable spec; a direct probe for OpenAPI/swagger files at common paths returned 404 for all candidates, and no docs page links such a spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://fin.ai/openapi.json, https://fin.ai/swagger.json, https://fin.ai/api/openapi.json, https://f…”
   • [claimed-docs] “Fin can be accessed programmatically via an API. You call Fin from your o”
   • [claimed-docs] “The new orchestration endpoints — Discover capabilities, Ask Fin, Run a procedure, and Escalate to a human — are currently available in the …”

   proof ↗⚑ flag

   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

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

   weight 1 · round to Lorikeet
   Fin~partialclaimed4/10

   Fin documents a testing/preview workflow ('How to preview and test Fin', testing across thousands of scenarios before going live) that implies an isolated test/preview mode, but no evidence explicitly describes a sandbox environment separate from production data or confirms production data isolation during testing. Missing for 10: explicit sandbox/staging environment documentation, confirmation that test scenarios don't touch live customer data, and any independent/hands-on corroboration of this isolation.

   • [claimed-docs] “How to preview and test Fin”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation... …”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Fin—none0/10

   The evidence shows Fin has a REST API with a 'Preview API version' for new endpoints (docs-4) and a general changes/changelog page (docs-1), but there is no documented versioning scheme or explicit deprecation policy (e.g., version sunset timelines, backward-compatibility guarantees) cited anywhere in the pack.

   • [claimed-docs] “Fin can be accessed programmatically via an API. You call Fin from your o”
   • [claimed-docs] “The new orchestration endpoints — Discover capabilities, Ask Fin, Run a procedure, and Escalate to a human — are currently available in the …”
   • [claimed-docs] “See exactly when errors started, which status codes came back, and confirm a fix actually worked.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Lorikeet
   Fin~partialclaimed3/10

   Fin exposes a programmatic API and TypeScript SDK with a pagination iterator for looping over items, plus a content-import endpoint, implying some capacity for scripted bulk actions, but there is no documented bulk-edit, bulk-resolve, or batch-action feature for AI-native users. missing for 10: explicit bulk operation/batch endpoint documentation, hands-on evidence of processing many items in one call, and any UI/CLI bulk-action support.

   • [claimed-docs] “Fin can be accessed programmatically via an API. You call Fin from your o”
   • [github] “await client.aiContent.createContentImportSource({ url: "https://www.example.com" });”
   • [github] “List endpoints are paginated. The SDK provides an iterator so that you can simply loop over the items”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Fin~partialclaimed6/10

   Fin exposes several automation primitives that fit an event→action rule model: webhooks that fire on real-time Intercom events, configurable escalation guidance/rules, Fin Procedures/workflows, and Operator/Monitors for incident-triggered behavior. This is more than none, but the pack lacks a first-class 'if event X then action Y' rule-builder walkthrough or independent confirmation of how flexible/robust these triggers are. Missing for 10: a documented dedicated rules/automation builder UI, concrete example of a user-defined trigger-condition-action rule, and independent (non-vendor) evidence that automation rules work reliably in practice.

   • [claimed-docs] “Webhooks allow you to subscribe to real-time notifications of events happening in Intercom; a Contact created, an incoming Conversation rece…”
   • [claimed-docs] “Manage Fin AI Agent's escalation guidance and rules”
   • [claimed-docs] “Building Fin Procedures”
   • [claimed-docs] “Manage your Fin workflows”
   • [claimed-docs] “Operator, CX Score, AI Topics, Trends, AI Recommendations, Monitors, Custom AI Scorecards, Incident Detection”

   proof ↗⚑ flag

   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

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Lorikeet
   Fin—none0/10

   Fin's evidence covers webhooks (event-driven, not scheduled), procedures, and a Proactive Outbound Suite, but nothing describes cron-like scheduling of recurring jobs or workflows on a time-based schedule. missing for 10: any documentation of scheduled/recurring workflow triggers, cron-style job scheduling, or recurring automation configuration.

   • [claimed-docs] “Webhooks allow you to subscribe to real-time notifications of events happening in Intercom; a Contact created, an incoming Conversation rece…”
   • [claimed-docs] “Proactive Outbound Suite”
   • [claimed-docs] “Procedures let you train Fin to handle queries with multiple steps, business logic and third-party systems from start to finish.”

   proof ↗⚑ flag

   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

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

   weight 1 · round to Lorikeet
   Fin—none0/10

   The evidence pack shows Fin Procedures/workflow management and testing before go-live ('test it across thousands of scenarios before anything goes live, roll out changes with control'), but there is no concrete documentation of version history, diffing/review of automation changes, or an explicit rollback mechanism for Procedures/Workflows/Guidance. Nothing describes a changelog, version comparison, or a 'revert to previous version' feature for automations.

   • [claimed-docs] “Building Fin Procedures”
   • [claimed-docs] “Manage your Fin workflows”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation”

   proof ↗⚑ flag

   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

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

   Fin explicitly documents multi-channel support spanning live chat/messenger (in-app), email, Slack, WhatsApp, SMS, and voice, with dedicated channel pages for each (docs-9, docs-50, docs-51, docs-65, docs-48). Missing for 10: explicit named coverage of broader 'social' channels like Instagram/Facebook/X/Twitter — only 'and more' is implied, not documented by name, so the specific 'social' claim in the story is only partially evidenced.

   • [claimed-docs] “Handles tickets, cases, emails, live chat, WhatsApp, SMS, and more”
   • [claimed-docs] “Fin delivers unrivaled performance across every channel. Wherever customers reach out, Fin provides fast, accurate, personalized support”
   • [claimed-docs] “Fin over Email resolves everything from simple FAQs to complex threads with attachments and multiple recipients”
   • [claimed-docs] “Fin for Slack supports your customers directly in Slack communities and dedicated Connect channels, resolving questions instantly with repli…”
   • [claimed-docs] “Fin for messenger brings the highest-performing AI Agent for customer service to live chat, delivering exceptional, on-brand support”

   proof ↗⚑ flag

   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

Languages

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

   weight 2 · round to Fin
   Fin✓fullclaimed7/10

   Intercom/Fin explicitly documents multi-language support ('Use Fin AI Agent in multiple languages') allowing Fin to answer in customers' languages even when the knowledge base content is authored in English, which directly matches the story. Missing for 10: independent/hands-on verification of translation quality or explicit detail on how English-only knowledge base content is translated/handled per language.

   • [claimed-docs] “Use Fin AI Agent in multiple languages”

   proof ↗⚑ flag

   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

Voice

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

   weight 2 · round to Fin
   Fin✓fullclaimed7/10

   Fin Voice is a documented dedicated product ('Deploy Fin Voice', 'Fin Voice 2 runs on Apex Flash... latency-sensitive tasks', 'grounded in your knowledge base, and trained to apply your specific policies on every call'), indicating speech-in/speech-out phone support using the same knowledge base as chat. Missing for 10: independent/hands-on validation of voice call quality or action-taking parity specifically for phone, and no detail on how actions (e.g., updating systems) work identically on voice vs chat.

   • [claimed-docs] “Deploy Fin Voice”
   • [claimed-docs] “grounded in your knowledge base, and trained to apply your specific policies on every call.”
   • [claimed-docs] “Fin Voice 2 runs on Apex Flash - our latest Fin model, built for latency-sensitive tasks.”
   • [claimed-docs] “Fin delivers unrivaled performance across every channel. Wherever customers reach out, Fin provides fast, accurate, personalized support”

   proof ↗⚑ flag

   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

Handoff

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

   weight 3 · round drawn
   Fin~partialclaimed6/10

   Docs confirm Fin can transfer/escalate to human agents within the preferred inbox, has configurable escalation guidance/rules, and supports hand-off via JavaScript and an orchestration 'Escalate to a human' API — showing escalation handoff is a real, built feature. However, none of the evidence explicitly confirms that a generated summary or a structured collection of gathered details is passed along with the full conversation to the human agent, so the 'never repeats themselves' guarantee is not directly documented. Missing for 10: explicit documentation of automatic conversation summary generation at escalation, evidence that collected customer details are packaged and handed off, and independent/hands-on confirmation the handoff actually eliminates repetition.

   • [claimed-docs] “The new orchestration endpoints — Discover capabilities, Ask Fin, Run a procedure, and Escalate to a human — are currently available in the …”
   • [claimed-docs] “Transfers to agents directly in preferred Inbox”
   • [claimed-docs] “Manage Fin AI Agent's escalation guidance and rules”
   • [claimed-docs] “Hand-off with JavaScript”

   proof ↗⚑ flag

   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

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

   Docs explicitly cover configuring escalation/handoff behavior — 'Manage Fin AI Agent's escalation guidance and rules', 'Giving Fin Guidance', 'Hand-off with JavaScript', an orchestration 'Escalate to a human' API endpoint, and 'Transfers to agents directly in preferred Inbox' — showing topic/guidance-based and explicit-request handoff configuration exists. However, none of the evidence specifically documents sentiment- or customer-tier-based handoff triggers, nor is there independent/hands-on verification that the agent reliably obeys these rules in practice. Missing for 10: explicit sentiment/tier-based escalation config docs, and third-party evidence confirming reliable adherence to configured handoff rules.

   • [claimed-docs] “Manage Fin AI Agent's escalation guidance and rules”
   • [claimed-docs] “Giving Fin Guidance”
   • [claimed-docs] “Hand-off with JavaScript”
   • [claimed-docs] “The new orchestration endpoints — Discover capabilities, Ask Fin, Run a procedure, and Escalate to a human — are currently available in the …”
   • [claimed-docs] “Transfers to agents directly in preferred Inbox”

   proof ↗⚑ flag

   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

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

   Docs show Fin is 'trained on your knowledge, data, policies, and tone' and grounded in the knowledge base (docs-46/60/49), with configurable 'escalation guidance and rules' (docs-25) and pre-launch testing across scenarios (docs-45/59), which together imply guardrails against off-knowledge answers and hand-off rather than free invention. However there is no explicit documentation of a 'safe decline' behavior or hallucination-refusal mechanism, and no independent/hands-on evidence confirming Fin actually declines rather than guesses on off-knowledge questions. Missing for 10: explicit safe-decline/refusal documentation, third-party or hands-on verification that Fin avoids inventing policies/prices, and quantified guardrail testing results.

   • [claimed-docs] “Train Fin on your knowledge, data, policies, and tone of voice.”
   • [claimed-docs] “Train Fin on your knowledge, data, policies, and tone of voice. Fin will use everything it knows to deliver consistent, accurate answers”
   • [claimed-docs] “Manage Fin AI Agent's escalation guidance and rules”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation... …”
   • [claimed-docs] “grounded in your knowledge base, and trained to apply your specific policies on every call.”
   • [claimed-docs] “give you the tools to safely deploy AI within your own boundaries.”
   • [claimed-docs] “We meet the world's leading compliance standards—and give you the tools to safely deploy AI within your own boundaries.”

   proof ↗⚑ flag

   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

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

   Evidence shows Fin's guardrails center on escalation rules, hand-off to human agents, and pre-launch testing/preview (docs-25, docs-29, docs-31, docs-45), but nothing describes a supervised/draft-for-approval mode where Fin composes replies that a human must approve before they reach the customer on every interaction. Community commentary (comm-3) even argues for more deterministic, human-controlled workflows, but that's not evidence Fin ships this specific approval-gate mode.

   • [claimed-docs] “Manage Fin AI Agent's escalation guidance and rules”
   • [claimed-docs] “How to preview and test Fin”
   • [claimed-docs] “Hand-off with JavaScript”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation”
   • [community] “A commenter with a decade of customer-service AI/NLP experience argued 99% of support tasks (order status, returns, troubleshooting) are ful…”

   proof ↗⚑ flag

   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

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

   Fin has documented first-party features for exactly this: 'Giving Fin Guidance' and 'Manage Fin AI Agent's escalation guidance and rules' let ops teams define escalation/human-handoff rules, and the Agent API includes an 'Escalate to a human' capability. However this escalate-to-human orchestration endpoint is explicitly noted as Preview-only, and there is no independent or hands-on evidence confirming the agent reliably respects human-only topic boundaries without ever freelancing. Missing for 10: independent verification that escalation rules are strictly enforced (no freelancing), and GA (non-preview) status of escalate-to-human tooling.

   • [claimed-docs] “Giving Fin Guidance”
   • [claimed-docs] “Manage Fin AI Agent's escalation guidance and rules”
   • [claimed-docs] “The new orchestration endpoints — Discover capabilities, Ask Fin, Run a procedure, and Escalate to a human — are currently available in the …”

   proof ↗⚑ flag

   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

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

   Fin's Insights/Monitors/AI Recommendations pages reference analyzing conversations and measuring CX, and CX Score/Trends are listed as features, implying some dashboard capability, but no evidence explicitly confirms a unified dashboard reporting resolution rate, CSAT, handoff rate, and cost per resolution together. missing for 10: explicit documentation or screenshots of a dashboard showing resolution rate, CSAT, handoff rate, and cost per resolution metrics; independent confirmation these specific KPIs are surfaced for exec reporting.

   • [claimed-docs] “Insights continuously analyzes every Fin and human conv”
   • [claimed-docs] “With Insights, Monitors New, and Recommendations, you have everything you need to understand, measure, and improve your customer experience”
   • [claimed-docs] “Operator, CX Score, AI Topics, Trends, AI Recommendations, Monitors, Custom AI Scorecards, Incident Detection”
   • [claimed-docs] “Fin resolves 76% of customer queries on average, and handles multi-step queries end to end. Your customers get fast, accurate answers. Your …”

   proof ↗⚑ flag

   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

Insights

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

   weight 1 · round to Fin
   Fin~partialclaimed6/10

   Fin's pricing page lists analytics features like 'AI Topics, Trends... Monitors... Incident Detection' and 'Insights continuously analyzes every Fin and human conversation,' indicating topic clustering and emerging-issue detection capability, but there is no deeper documentation, screenshots, or independent corroboration of how this works in practice. Missing for 10: detailed product docs on topic clustering methodology, evidence of proactive alerting before ticket-volume spikes, and independent/hands-on validation of the insights/analytics feature.

   • [claimed-docs] “Operator, CX Score, AI Topics, Trends, AI Recommendations, Monitors, Custom AI Scorecards, Incident Detection”
   • [claimed-docs] “Insights continuously analyzes every Fin and human conv”
   • [claimed-docs] “With Insights, Monitors New, and Recommendations, you have everything you need to understand, measure, and improve your customer experience”

   proof ↗⚑ flag

   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

Helpdesk

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

   weight 3 · round to Fin
   Fin✓fullclaimed8/10

   Fin explicitly documents standalone deployment plus deep integrations with Zendesk, Salesforce, HubSpot, Freshdesk and 'any helpdesk', with two-way data sync (bring content/history over, surface data in inbox) and APIs/MCP/webhooks for programmatic ticket/context sync. Multiple dedicated integration pages (Zendesk, Salesforce, HubSpot, Freshdesk) and platform docs (Agent API, MCP, webhooks, data connectors) corroborate bidirectional context flow. missing for 10: independent/hands-on verification of the bidirectional sync working in production, and no direct evidence of Intercom-native standalone ticketing depth compared to third-party helpdesks.

   • [claimed-docs] “Fin AI Agent works seamlessly with any helpdesk, including Salesforce, HubSpot, and more.”
   • [claimed-docs] “How Fin integrates with Zendesk”
   • [claimed-docs] “How Fin integrates with Salesforce”
   • [claimed-docs] “bring your team over from any helpdesk without losing your content, your history, or a single day of support.”
   • [claimed-docs] “Surface data from Salesforce, HubSpot, and 450+ apps and integrations directly in the inbox”
   • [claimed-docs] “Fin can be accessed programmatically via an API. You call Fin from your o”
   • [claimed-docs] “Learn how to use the Model Context Protocol (MCP) to enable AI agents to securely access and interact with your Intercom data whenever helpf…”
   • [claimed-docs] “Webhooks allow you to subscribe to real-time notifications of events happening in Intercom; a Contact created, an incoming Conversation rece…”
   • [claimed-docs] “It works through MCP or API Data Connectors for your business tools, integrations with Intercom or your existing helpdesk”
   • [claimed-docs] “Intercom connects to 450+ first- and third-party apps and integrations, including CRMs like Salesforce and HubSpot, dev tools like Jira, Lin…”

   proof ↗⚑ flag

   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

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

   Docs mention 'Sync and manage websites' and content import via API (createContentImportSource), implying re-syncing of website sources, but there is no explicit documentation of scheduled or change-triggered automatic re-syncing across all source types (docs, help centers, files) without manual re-upload. missing for 10: explicit scheduling/cron documentation for content refresh, confirmation of automatic change-detection re-sync for non-website sources (PDFs, articles), and independent/hands-on verification that sync happens without manual re-upload.

   • [claimed-docs] “Sync and manage websites”
   • [github] “await client.aiContent.createContentImportSource({ url: "https://www.example.com" });”

   proof ↗⚑ flag

   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

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

   Fin's analytics stack (Insights, Monitors, AI Topics/Trends, AI Recommendations, Incident Detection) implies some ability to flag where Fin underperforms or topics trend poorly, and 'Giving Fin Guidance'/'Adding content to Fin' suggest content curation workflows, but no evidence explicitly describes detecting knowledge gaps or conflicting source content as a distinct surfaced capability. Missing for 10: explicit documentation of a 'knowledge gap' or 'content conflict' detection feature, and any hands-on/independent confirmation that such gaps are surfaced to support-ops leads.

   • [claimed-docs] “Operator, CX Score, AI Topics, Trends, AI Recommendations, Monitors, Custom AI Scorecards, Incident Detection”
   • [claimed-docs] “Insights continuously analyzes every Fin and human conv”
   • [claimed-docs] “With Insights, Monitors New, and Recommendations, you have everything you need to understand, measure, and improve your customer experience”
   • [claimed-docs] “Giving Fin Guidance”
   • [claimed-docs] “Adding content to Fin”

   proof ↗⚑ flag

   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

Grounding

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

   weight 3 · round to Fin
   Fin~partialclaimed5/10

   Fin's docs confirm it is trained/grounded on the customer's own content (help center, websites, docs, knowledge sources) via content import and knowledge retrieval APIs (e.g., docs-46/60 'train Fin on your knowledge', docs-28 'Adding content to Fin', docs-27 'Sync and manage websites', gh-1 content import API, docs-39 knowledge retrieval API), but no evidence explicitly shows that end-user answers surface or cite the specific source article they were drawn from. missing for 10: explicit documentation or UI evidence of in-answer source citation/attribution, independent/hands-on confirmation of citation behavior.

   • [claimed-docs] “Train Fin on your knowledge, data, policies, and tone of voice.”
   • [claimed-docs] “Train Fin on your knowledge, data, policies, and tone of voice. Fin will use everything it knows to deliver consistent, accurate answers”
   • [claimed-docs] “Adding content to Fin”
   • [claimed-docs] “Sync and manage websites”
   • [github] “await client.aiContent.createContentImportSource({ url: "https://www.example.com" });”
   • [claimed-docs] “The Fin API platform includes APIs for answer generation and knowledge retrieval, available as a set or independently.”
   • [claimed-docs] “grounded in your knowledge base, and trained to apply your specific policies on every call.”

   proof ↗⚑ flag

   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

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

   Fin explicitly supports ingesting websites/help center content (createContentImportSource, 'Sync and manage websites', 'Adding content to Fin'), integrates with helpdesks (Zendesk, Salesforce, HubSpot, Freshdesk) preserving existing content/history, and pulls in Confluence, Notion, Zendesk content into a unified knowledge source alongside data connectors for third-party tools. This covers help center, docs, past ticket/helpdesk content, and wiki tools (Confluence/Notion) without manual re-authoring. Missing for 10: no explicit mention of ingesting 'internal wikis' broadly beyond Confluence/Notion, and no independent/hands-on verification of ingestion fidelity or effort required.

   • [github] “await client.aiContent.createContentImportSource({ url: "https://www.example.com" });”
   • [claimed-docs] “Sync and manage websites”
   • [claimed-docs] “Adding content to Fin”
   • [claimed-docs] “Bring content from your help center, Zendesk, Confluence, Notion, and more into one place, so Fin, Copilot, and your team always work from t…”
   • [claimed-docs] “bring your team over from any helpdesk without losing your content, your history, or a single day of support.”
   • [claimed-docs] “How Fin integrates with Zendesk”
   • [claimed-docs] “How Fin integrates with Salesforce”
   • [claimed-docs] “Your team stays on Freshdesk.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Lorikeet
   Fin~partialprobed4/10

   Fin exposes an Agent API, Node SDK, MCP, webhooks, and data-connector APIs for programmatic interaction, but there is no evidence of full UI/API parity — no OpenAPI spec was discoverable (404s on all candidate paths) and no documentation claims that every configuration (e.g., inbox setup, workflows, Procedures, escalation rules) manageable in the UI is also manageable via API. Missing for 10: comprehensive API reference/OpenAPI spec, explicit parity claims, evidence that admin/config UI actions (not just conversational/data actions) are API-accessible.

   • [claimed-docs] “Fin can be accessed programmatically via an API. You call Fin from your o”
   • [claimed-docs] “The new orchestration endpoints — Discover capabilities, Ask Fin, Run a procedure, and Escalate to a human — are currently available in the …”
   • [github] “The Intercom TypeScript library provides convenient access to the Intercom APIs from TypeScript.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://fin.ai/openapi.json, https://fin.ai/swagger.json, https://fin.ai/api/openapi.json, https://f…”
   • [claimed-docs] “The Fin API platform includes APIs for answer generation and knowledge retrieval, available as a set or independently.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Fin
   Fin~partialclaimed2/10

   The only export-related evidence is a narrow feature to 'Export a saved View exactly as you see it,' not a comprehensive data export mechanism; migration language found in the evidence is framed only around bringing data INTO Intercom from other helpdesks, not exporting all data out in open formats. Missing for 10: bulk/full account data export, documented open file formats (CSV/JSON), a migration-out or offboarding process, and any independent confirmation of successful full data extraction.

   • [claimed-docs] “Export a saved View exactly as you see it”
   • [claimed-docs] “bring your team over from any helpdesk without losing your content, your history, or a single day of support.”
   • [claimed-docs] “bring your team over from any helpdesk without losing your content, your history, or a single day of support”

   proof ↗⚑ flag

   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

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 Fin
   Fin~partialcommunity4/10

   A community source states Fin charges '$1 per successful customer session', which is consistent with outcome-based, per-resolution pricing, and a dedicated fin.ai/pricing page exists (cited repeatedly for feature lists). However, none of the evidence shows the actual published rate table, caps, or usage controls on that pricing page — the citations only reference features (integrations, channels, AI Agent capabilities), not price mechanics or caps. Missing for 10: first-party documentation of the per-resolution rate/caps/controls on fin.ai/pricing, and independent corroboration beyond a single HN comment.

   • [community] “Fin charges $1 per successful customer session, incentivizing it to be helpful; at the time of an earlier interview Fin was reportedly still…”
   • [claimed-docs] “Fin AI Agent works seamlessly with any helpdesk, including Salesforce, HubSpot, and more.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Fin—none0/10

   The evidence pack contains extensive documentation on Fin's features, integrations, and compliance messaging (e.g., 'meet the world's leading compliance standards') but no mention of data residency, region selection, or storage location controls anywhere in the docs or community evidence.

   ⚑ flag

   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

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

   weight 3 · round to Lorikeet
   Fin—none0/10

   No evidence in the pack addresses data being used for AI model training or an opt-out/data-use control; general trust/compliance mentions (e.g., trust-reliability page) do not specify training data usage or opt-out mechanisms.

   ⚑ flag

   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

3. ai-native userControl data retention and deletion

   weight 2 · round to Lorikeet
   Fin—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or user-facing controls over how long data is kept or when it is deleted; the docs cover integrations, channels, MCP access, and training but never retention/deletion settings.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Fin—none0/10

   No evidence pack items mention telemetry opt-out, usage tracking controls, or privacy settings for Fin; only trust/compliance marketing language and unrelated docs are present.

   ⚑ flag

   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

Personalization

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

   weight 2 · round drawn
   Fin✓fullprobed7/10

   Docs show Fin connects to live business data via data connector templates (Stripe, Shopify, Statuspage), MCP/API data connectors, webhooks, and CRM integrations (Salesforce, HubSpot, Zendesk) that surface data like plan/order status directly in the inbox, plus Procedures that let Fin execute multi-step logic against third-party systems to update/retrieve real account data rather than just canned articles. Missing for 10: independent/hands-on verification that live data grounding actually improves accuracy in practice, and no case study quantifying resolution based specifically on live account/order data vs. help-article content.

   • [claimed-docs] “Data connector templates are now generally available, with ready-to-install templates across Stripe, Shopify and Statuspage.”
   • [claimed-docs] “Track data connector health over time”
   • [claimed-docs] “Takes action to update external systems”
   • [claimed-docs] “See everything in one view in the inbox — pull in data from tools like Shopify and Stripe alongside the conversation, so agents never have t…”
   • [claimed-docs] “Surface data from Salesforce, HubSpot, and 450+ apps and integrations directly in the inbox”
   • [claimed-docs] “Procedures let you train Fin to handle queries with multiple steps, business logic and third-party systems from start to finish.”
   • [claimed-docs] “MCP is a protocol that enables AI tools and applications to securely access and interact with your Intercom data whenever helpful.”
   • [probe] “official MCP server documented at https://developers.intercom.com/docs/guides/mcp”

   proof ↗⚑ flag

   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

Reasoning

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

   weight 2 · round drawn
   Fin~partialcommunity6/10

   Fin's docs describe 'Procedures' that train it to handle multi-step queries with business logic across systems, and marketing claims it 'handles multi-step queries end to end,' supporting structured troubleshooting rather than single canned replies. However, no evidence explicitly documents Fin asking clarifying questions mid-conversation, and one HN commenter argues open-ended agentic reasoning is unnecessary versus deterministic workflows, adding some uncertainty. missing for 10: explicit documentation/example of clarifying-question behavior, independent hands-on proof of multi-step troubleshooting quality.

   • [claimed-docs] “Procedures let you train Fin to handle queries with multiple steps, business logic and third-party systems from start to finish.”
   • [claimed-docs] “Fin resolves 76% of customer queries on average, and handles multi-step queries end to end. Your customers get fast, accurate answers. Your …”
   • [claimed-docs] “Giving Fin Guidance”
   • [community] “A commenter with a decade of customer-service AI/NLP experience argued 99% of support tasks (order status, returns, troubleshooting) are ful…”

   proof ↗⚑ flag

   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

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

   Fin explicitly claims a resolution metric ("Fin resolves 76% of customer queries on average, and handles multi-step queries end to end") across multiple integration pages, plus dedicated testing/evaluation tooling ("evaluate every live conversation") and analytics (Insights, Monitors) framed around resolution outcomes rather than deflection. Community commentary raises philosophical skepticism about autonomous agents vs. deterministic workflows, but does not concretely contradict the stated resolution rate. Missing for 10: independent/third-party audit of the 76% figure, and clear definition distinguishing 'resolution' from deflection/bounce in the metric methodology.

   • [claimed-docs] “Fin resolves 76% of customer queries on average, and handles multi-step queries end to end. Your customers get fast, accurate answers. Your …”
   • [claimed-docs] “Perfect customer experiences no longer come with a migration project. Fin resolves 76% of customer queries on average... Your team stays on …”
   • [claimed-docs] “Perfect customer experiences no longer come with a migration project... Your team stays on HubSpot.”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation... …”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation”
   • [claimed-docs] “With Insights, Monitors New, and Recommendations, you have everything you need to understand, measure, and improve your customer experience”
   • [community] “A commenter with a decade of customer-service AI/NLP experience argued 99% of support tasks (order status, returns, troubleshooting) are ful…”

   proof ↗⚑ flag

   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

Voice

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

   weight 1 · round drawn
   Fin~partialclaimed6/10

   Docs support tone/brand control ("Customizable tone and answer length", "Train Fin on your knowledge, data, policies, and tone of voice") and multi-language support is documented ("Use Fin AI Agent in multiple languages"), plus multi-channel consistency claims (email, Slack, live chat, voice) suggest tone carries across surfaces. However, there is no independent evidence or hands-on validation that tone/brand voice actually stays consistent across topics and languages in practice — only vendor marketing claims. Missing for 10: independent/third-party validation of tone consistency, concrete examples of cross-language tone fidelity, and evidence of consistency across many topics rather than just a training feature description.

   • [claimed-docs] “Customizable tone and answer length”
   • [claimed-docs] “Train Fin on your knowledge, data, policies, and tone of voice.”
   • [claimed-docs] “Train Fin on your knowledge, data, policies, and tone of voice. Fin will use everything it knows to deliver consistent, accurate answers”
   • [claimed-docs] “Use Fin AI Agent in multiple languages”
   • [claimed-docs] “Fin for messenger brings the highest-performing AI Agent for customer service to live chat, delivering exceptional, on-brand support”
   • [claimed-docs] “Fin delivers unrivaled performance across every channel. Wherever customers reach out, Fin provides fast, accurate, personalized support”

   proof ↗⚑ flag

   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

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

   Fin ships explicit QA tooling: fin.ai/testing describes testing across thousands of scenarios before launch and evaluating every live conversation, fin.ai/analyze describes Insights, Monitors, and Recommendations continuously analyzing every conversation, and pricing docs list Custom AI Scorecards and Incident Detection alongside guidance and procedure-editing docs that let fixes feed back into the agent behavior. missing for 10: independent or hands-on verification of the scoring and review loop, and detail on how flagged failures are routed to specific fixes.

   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation... …”
   • [claimed-docs] “Insights continuously analyzes every Fin and human conv”
   • [claimed-docs] “With Insights, Monitors New, and Recommendations, you have everything you need to understand, measure, and improve your customer experience”
   • [claimed-docs] “Operator, CX Score, AI Topics, Trends, AI Recommendations, Monitors, Custom AI Scorecards, Incident Detection”
   • [claimed-docs] “Giving Fin Guidance”
   • [claimed-docs] “Building Fin Procedures”

   proof ↗⚑ flag

   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

Simulation

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

   weight 2 · round to Lorikeet
   Fin✓fullclaimed7/10

   Fin has a dedicated testing capability documented at fin.ai/testing ("test it across thousands of scenarios before anything goes live") and a specific help article "How to preview and test Fin," directly matching the support-ops need to validate the agent before it faces customers. Missing for 10: independent/hands-on corroboration of the testing workflow and explicit mention of importing historical ticket transcripts as test scenarios rather than only generic 'scenarios'.

   • [claimed-docs] “How to preview and test Fin”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation”
   • [claimed-docs] “you test it across thousands of scenarios before anything goes live, roll out changes with control, and evaluate every live conversation... …”
   • [claimed-docs] “Train Fin on your Procedures, knowledge, and policies, test performance before launch, deploy across every channel, then analyze and improve…”

   proof ↗⚑ flag

   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