crail

Methodology

Agent-readiness score (crail-ar-v0.1)

Every vendor gets a 0-100 score built from six equally-weighted sub-dimensions: discoverability (llms.txt, robots.txt access for AI bots, schema.org markup), machine-readable content (docs as clean markdown vs. JS-only rendering), programmatic access (self-serve API keys and sandboxes), MCP/agent-native support, self-serve transactability (can you buy without a sales call), and transparency (public pricing and security docs).

Vendor payment never touches ranking

Vendor subscriptions on Crail pay for data completeness, freshness, and analytics — never for rank, review exposure, or review volume. Sponsored placements, where they exist, are shown in a visually and structurally separate shelf, never blended into ranked results.

Review types

Reviews come in three explicit, never-blended types: human_verified (tiered verification via LinkedIn/corporate-email cross-check), agent_test_report (a versioned, pre-published AI agent-run test protocol with a full public transcript — see our test protocol), and expert_analyst (Crail staff writeups, always disclosed as non-independent).

Verification methods

Each vendor record discloses its verificationMethodagent_crawled (an AI research agent verified facts against the vendor's own pricing pages, docs, and GitHub), vendor_submitted_confirmed, or human_analyst — plus a lastVerifiedAt date on every field group, so freshness is auditable rather than asserted.

Absence of evidence isn't evidence of absence

Security/compliance fields (SSO, encryption at rest and in transit, audit logging, pentest reports) are tri-state, not a plain yes/no: Yes means Crail found public evidence for it, No means a vendor explicitly documents its absence, and Not publicly documented — the default — means neither, which is not the same claim as "No." Most vendor research is agent_crawled best-effort crawling, not an exhaustive audit, so treating an undocumented field as a confirmed negative would overstate what Crail actually verified.

Where this is headed

Agent-readiness and vendor-reported pricing describe the software. They don't describe the buyer. Two teams evaluating the same category can need completely different tools depending on the work they actually spend their day doing — and today that gap gets filled by a buyer self-reporting requirements on a form, which is a lossy way to capture it.

Our longer-term direction is to ground recommendations in how work actually happens rather than how it's described after the fact — matching real day-to-day task patterns against the vendor landscape instead of a checklist of declared needs. It's a harder problem than ranking vendors on paper, but it's the one that actually determines fit. See our product roadmap for where that's heading.