Kairos

Kairos Documentation Audit

Kairos markets itself as a developer-adjacent AI automation platform ("personal AI intern") but exposes effectively zero developer documentation: /docs is a login screen, there is no API reference, no SDK, no quickstart, no llms.txt, no docs. / api. / developer. subdomain. What technical content exists is buried in blog posts and contradicts the public privacy and pricing surfaces.

1. No developer documentation surface exists at all (critical)

Location: /docs, docs.kairos.computer, api.kairos.computer, developer.kairos.computer, /llms.txt, /llms-full.txt

Problem: Every plausible documentation URL returns 404 or, in the case of /docs, resolves to a sign-in interface ("email/password, Google login, register, password recovery"). There is no API reference, no SDK, no quickstart, no per-integration setup walkthrough, no llms.txt, and no llms-full.txt. The homepage FAQ even asks "Do I need to be technical?" — but the answer is not rendered on the page.

Consequence: A developer or AI coding agent evaluating Kairos for automation/orchestration has nothing to read. Agents like Claude Code or Cursor that look for llms.txt / llms-full.txt find nothing; the site allow-lists GPTBot, PerplexityBot, ClaudeBot, and Google-Extended in robots.txt but offers them no structured surface to crawl. Prospective integrators must contact sales to learn what the product actually does technically.

The fix: Stand up a real docs.kairos.computer (or non-gated /docs) with: a quickstart, an authentication guide, a page per integration covering OAuth scopes and supported plan tiers, an API reference if one exists, and llms.txt + llms-full.txt files at the root. At minimum, move the per-integration capability lists into a structured, machine-readable docs surface rather than marketing pages.

2. "Compute units" is the billing primitive and is never defined (critical)

Location: /pricing, / (homepage pricing tiles), /terms-of-service

Problem: All paid tiers are denominated in "compute units" — Basic "100M compute units/mo", Plus "350M compute units/mo" — but the pricing page does not define what a compute unit is. There is no conversion table tying compute units to tasks, runtime seconds, model tokens, browser actions, or integration calls. The phrase "compute units" never appears in the terms of service, and the /blog/kairos-brain post claims consolidation costs "approximately cents per conversation" using Claude Haiku — which is not tied to the compute-unit model.

Consequence: A prospective buyer cannot estimate cost before signing up; an existing user cannot predict when they'll hit the cap. The 100M vs 350M numbers are essentially decorative without a unit definition. For a product whose unique selling point is long-running, scheduled, multi-step browser tasks (potentially expensive), this is the single most important number on the page and it is undefined.

The fix: Publish a "What is a compute unit?" reference page with: (a) a precise definition (e.g. "1 CU = 1 second of agent runtime + N tokens of model usage"), (b) example task costs ("a typical 5-minute Gmail triage = ~X CU"), (c) an in-app usage meter or pricing calculator, and (d) cross-reference the unit in the terms of service so overage and cap behavior is contractually defined.

3. Marketing pages reference integrations that don't exist (critical)

Location: /for/founders, /for/students, /for/researchers, /for/marketing

Problem: The use-case pages name specific external services as if they were supported:

• /for/founders says Kairos "Pulls metrics from tools like Stripe and analytics platforms" — Stripe is not on /integrations, in /sitemap.xml, or anywhere else.
• /for/students describes pulling deadlines from "course portals" — no LMS (Canvas, Blackboard, Moodle) is in the integration list.
• /for/researchers says it searches "PubMed, arXiv, and other databases" — neither is in the integration list.
• /for/marketing says it schedules content across "Twitter, Instagram, LinkedIn and other platforms simultaneously" — only Twitter / X is in the canonical integration list.

Consequence: Users sign up expecting first-class Stripe / Instagram / LinkedIn / Canvas / PubMed connectors, then discover these only work (if at all) via the generic "dedicated browser" capability — which has its own auth and reliability characteristics that the marketing page never discloses. This is the textbook gap between "what marketing says we support" and "what the integrations list says we support."

The fix: Either (a) add the missing integrations to /integrations and the sitemap, or (b) on each persona page, explicitly distinguish between "native integration" and "browser-driven" capabilities, with a footnote pointing to the canonical integration list.

4. Integration URL slugs silently 404 on the obvious names (significant)

Location: /integrations/sheets, /integrations/drive, /integrations/docs, /integrations/calendar, /integrations/teams

Problem: The homepage and navigation use the shortened brand names "Sheets", "Drive", "Docs", "Calendar", and "Teams", but the canonical URLs are /integrations/google-sheets, /google-drive, /google-docs, /google-calendar, and /microsoft-teams. The shortened slugs return 404. The blog post titled "How We Solved Authentication for AI Browser Agents" lives at /blog/browser-agent-authentication, while both /blog/authentication-for-ai-browser-agents and /blog/how-we-solved-authentication-for-ai-browser-agents 404.

Consequence: Users typing the obvious URL hit dead ends. Crawlers and AI agents indexing the site cannot resolve human-readable titles to canonical paths. Inbound links and AI-generated suggestions ("see kairos.computer/integrations/sheets") all fail.

The fix: Add HTTP 301 redirects from each short form to its canonical URL. Make the same fix for blog slugs — there should be one canonical path per post with redirects from intuitive alternates.

5. Sitemap omits every blog post and the integrations index (significant)

Location: /sitemap.xml

Problem: The sitemap lists 30 URLs but omits /blog, all three blog posts (/blog/introducing-kairos, /blog/browser-agent-authentication, /blog/kairos-brain), the /integrations index page, /enterprise, and any docs surface. The blog is the only place on the entire site where substantive technical architecture is described — and it is invisible to search engines and AI crawlers via the sitemap.

Consequence: The technical content that would most help developers and AI agents understand the product (the Brain post, the auth post) is unindexed. The robots.txt explicitly allows GPTBot/ClaudeBot/PerplexityBot but the sitemap hides the only content those crawlers would actually want.

The fix: Add every blog post, the /blog index, the /integrations index, and any future /docs pages to sitemap.xml. Consider a separate sitemap-blog.xml and sitemap-docs.xml to keep them organized as the site grows.

6. Enterprise tier promoted everywhere, but /enterprise is 404 (significant)

Location: /enterprise, every pricing tile, top nav, footer

Problem: The main nav, footer ("Book a Call", "Contact Sales"), homepage, /pricing, and every integration page link to or describe an Enterprise tier ("Custom pricing", "Contact sales"). But /enterprise returns HTTP 404. There is no landing page describing what Enterprise actually includes: no SLA, no SSO/SAML, no SCIM, no on-prem/VPC, no SOC 2 / ISO / GDPR claims, no data residency, no admin/seat model, no custom agent provisions.

Consequence: Enterprise buyers — the ones who most need to evaluate before booking a call — have nothing to evaluate. They cannot route the page to security/legal/IT review. Sales has to handle every basic compliance question by hand.

The fix: Build an /enterprise page covering: SSO providers supported, audit log behavior, data residency, security certifications (or roadmap), DPA / BAA availability, custom integration model, seat/admin structure, and SLA tiers. Even a "we're SOC 2 in progress" statement is more useful than a 404.

7. Credential-handling architecture described in blog post, but absent from privacy policy and terms (critical)

Location: /blog/browser-agent-authentication, /privacy-policy, /terms-of-service

Problem: The blog post describes a CLI tool that "reads session data from the browsers you already use" and uploads encrypted credentials, plus a pub/sub channel that injects cookies and localStorage into "active browser contexts without page resets." The privacy policy lists collected data as "names, email addresses, usernames, passwords, and phone numbers" plus device/usage data — it does not mention session tokens, cookies, localStorage, OAuth refresh tokens harvested by the CLI, where these are stored, encryption-at-rest specifics, retention, revocation, or which subprocessors handle them. The terms of service contains a blanket "AS-IS" / "AT YOUR SOLE RISK" clause with no carve-out for the elevated risk inherent in cookie/credential harvesting.

Consequence: A user reading the privacy policy cannot know that Kairos ingests their browser sessions for arbitrary authenticated sites, nor understand how those secrets are protected. For any user in a regulated industry (legal, clinical, financial — all of which Kairos targets in case studies), this is a compliance-blocking gap. It also creates contractual exposure: the AS-IS clause may not survive scrutiny if disclosure was inadequate.

The fix: Add a dedicated section to the privacy policy covering browser-session ingestion, encryption (KMS, key rotation), scope (which sites/domains), retention, deletion-on-revocation, and the full subprocessor list. Add corresponding language to the terms describing the user's responsibilities and Kairos's obligations around credentials.

8. Subprocessors named in engineering blog do not appear in privacy disclosures (significant)

Location: /blog/kairos-brain, /privacy-policy

Problem: The Brain post names three concrete data stores ("a state machine distributed across three data stores" — Redis, Convex, and Postgres) plus Claude Haiku for consolidation. The privacy policy names AI providers (Anthropic, Google Cloud AI, OpenAI) but does not list Convex, Redis hosting, or the Postgres provider as subprocessors, nor describe what user data each holds.

Consequence: Enterprise procurement and GDPR-driven data-processing-agreement reviews require a subprocessor list. Today the most accurate list is in an engineering blog post, not in the privacy policy — which makes Kairos effectively unprocurable by any organization with a real DPA template.

The fix: Publish a /subprocessors page (or section in the privacy policy) listing every data store and AI provider, the categories of user data each holds, and the region/jurisdiction. Keep it versioned and link to it from the privacy policy.

9. OAuth scopes and required plan tiers undocumented for every integration (significant)

Location: All /integrations/* pages

Problem: Every integration page asserts OAuth is used (or in Notion's case "no API tokens required") but none specifies the requested scopes. Examples:

• /integrations/google-drive: no mention of drive.file vs drive vs drive.readonly.
• /integrations/github: no mention of repo vs admin:org vs actions scopes, no GitHub App name.
• /integrations/slack: no scope list, no description of admin vs user install, no enterprise grid support statement.
• /integrations/microsoft-teams, /integrations/outlook: no Microsoft Entra ID app permissions listed.
• /integrations/twitter: no statement of which X API tier (Free / Basic / Pro / Enterprise) is required — a critical gap given X's 2024 pricing changes.
• /integrations/reddit: no mention of the Reddit Data API's paid-access requirement for commercial use.
• /integrations/calendly: no mention that the Calendly API is gated to paid Calendly tiers.
• /integrations/hubspot: no statement of which HubSpot edition is required.
• /integrations/airtable: silent on OAuth vs Personal Access Token — Airtable supports both with different security implications.

Consequence: Security and IT teams cannot approve installs without knowing scopes. End users sign up expecting Twitter or Calendly automation, then discover their plan doesn't grant API access. Admins discover after install that Kairos requested broader scopes than expected.

The fix: Each integration page should include a structured "Permissions & Requirements" block: requested OAuth scopes (verbatim), required external plan/tier, marketplace listing URL (Slack/Zoom/Google), and revocation instructions.

10. Compliance-grade claims made on /integrations/box without certification evidence (significant)

Location: /integrations/box

Problem: The Box page makes regulated-industry claims: "Clinical researchers: set up FDA-compliant trial folders in 5 minutes instead of 4 hours" and "Compliance & Governance: Enforcing retention policies and managing regulatory requirements." Neither this page nor any other on the site addresses HIPAA BAA availability, FDA 21 CFR Part 11 validation, SOC 2 status, or audit logging.

Consequence: Any clinical or legal user who relies on these claims and later discovers no BAA or validation documentation has actionable exposure. For Kairos, claiming "FDA-compliant" workflows without backing certification is a regulatory and reputational risk.

The fix: Either remove the regulated-industry claims, or publish a compliance page documenting BAA availability, validation status, audit log behavior, and any third-party attestations. Make sure case-study language matches reality ("helps your team prepare FDA-compliant materials" vs. "FDA-compliant").

11. Cancellation path is buried and not self-serve (significant)

Location: /terms-of-service, /contact

Problem: The terms state: "You can cancel your subscription at any time by contacting us using the contact information provided below." The only contact info is manas@kairos.computer and a phone number on /contact. There is no self-serve cancellation in-app, no /account URL, no settings link, and /contact is not labeled as the cancellation surface. Combined with the auto-renew clause ("automatically renew unless cancelled... charging your payment method on a recurring basis without requiring your prior approval for each recurring charge"), this creates a one-way-door subscription flow.

Consequence: Users hit by an unwanted renewal must email a personal address to cancel. In the US, this likely violates the FTC's "click-to-cancel" rule for negative-option marketing. In the EU/UK it conflicts with consumer protection norms. Refunds are silent — the terms have no refund section at all.

The fix: Implement in-app self-serve cancellation, document the path in /terms-of-service, and add a refund policy section. Add an unambiguous "Cancel subscription" link on /contact if email-based cancellation must remain.

12. Case-study claims are quantified but unattributed and unverifiable (minor)

Location: Every /integrations/* page and every /for/* page

Problem: Each integration page makes precise quantified claims with no source, customer name, date, or methodology. Examples:

• "Increasing pipeline forecast accuracy from 40% to 90%" (HubSpot)
• "improved required-attendee participation from 71% to 94%" (Meet)
• "lead-to-demo time dropped from 26 hours to 4 minutes" (Calendar)
• "indie hackers growing accounts from 500 to 8,000 followers in six months" (Twitter)
• "Trend identification 8 months before Gartner covered it" (Reddit)

Consequence: AI agents and discerning buyers cannot evaluate these claims; they read as boilerplate. The precision (specific percentages like 71%→94%) without sourcing is more damaging to credibility than a generic claim would be.

The fix: Replace these with either (a) attributed customer quotes / case studies with names and dates, or (b) directional language ("teams typically report..."). At minimum, mark composite/illustrative figures as such.

13. "20+ App Integrations" copy doesn't match the 21-tile integrations page (minor)

Location: Homepage, /integrations

Problem: Homepage marketing says "20+ App Integrations". The integrations page lists exactly 21 tiles. The phrasing "20+" is harmless but suggests the marketing copy was written when the count was different and hasn't been re-checked. The Twitter tile is rendered as "Twitter / X" but the URL is just /integrations/twitter.

Consequence: Low individual impact, but it signals the marketing and engineering surfaces drift independently — relevant given the bigger contradictions elsewhere (Stripe, LMS, PubMed).

The fix: Replace "20+" with the actual current count, automated from the integrations list. Normalize the Twitter/X branding either way (rename to "X" with /integrations/x and a 301 from /twitter, or keep "Twitter" everywhere).

14. Pricing tile feature labels show concatenation bugs (minor)

Location: /pricing

Problem: The Plus tier shows feature labels rendered as "SMS & WhatsAppPlus" and "Browser automationPlus" — a visual "Plus" badge has been concatenated into the feature label string with no separator.

Consequence: Looks broken; suggests a UI string-rendering bug. For a pricing page — the single most scrutinized commercial surface — this erodes trust.

The fix: Add the missing space/separator, or render the "Plus" badge as a styled element rather than as appended text.

15. Robots.txt blocks /api/ but no API surface is exposed (minor)

Location: /robots.txt

Problem: User-agent: * Disallow: /api/ blocks crawlers from /api/ for non-AI bots, but no /api/ URL, status page, or developer surface is exposed anywhere on the public site. The directive is a fossil.

Consequence: No functional impact, but it implies an API surface exists that isn't documented — confusing for any developer probing the site.

The fix: Either document the API (and update robots.txt rationale) or remove the /api/ directive until there is something to gate.

What they do well

• Per-integration pages are consistent in shape (capabilities, use cases, pricing) — a strong starting template if compliance and scope info were added.
• The /blog/kairos-brain post is genuinely substantive technical writing about memory architecture (Postgres + Redis + Convex tiered consolidation). It just shouldn't be the only place this content lives.
• Robots.txt explicitly opts in to GPTBot / ClaudeBot / PerplexityBot / Google-Extended — the right stance for AI-agent discoverability, even though the underlying surface isn't built out yet.

Top 3 recommendations

1. Publish a real docs site. /docs should serve documentation, not a login form. Add a quickstart, an authentication page, a per-integration scopes/permissions reference, llms.txt, and llms-full.txt. This is the single biggest gap.
2. Define "compute units" and publish a subprocessor list. Two undefined load-bearing concepts (the billing primitive and the data-handling surface) make Kairos hard to buy, hard to budget for, and impossible to procure in regulated organizations.
3. Reconcile marketing claims with the integration list. Either add Stripe / LMS / PubMed / Instagram / LinkedIn as integrations, or scope the persona pages to what actually exists with a clear "browser-driven" disclaimer.