Kai onboarding

Connecting…

Kairospex
Kai — Onboarding describe a new Kai deployment

Organization

Tenant identity (customer / Clerk org) is bound from your verified session — not entered here.

How Kai refers to its employer ("you work for …") in its persona. Optional — defaults to a humanized customer id.
Kai runs on UTC; pick the client's standard-time offset (e.g., UTC-05:00 for US Eastern). Fixed offset — DST isn't auto-applied. Schedules are interpreted against this.
$400 is the minimum and the default.

Task classes

Pick the classes of work Kai will own. Each is a preset of deny-by-default capabilities. Every class starts at A0 (shadow) by policy; the ceiling shown is the highest it may ever be promoted to.

What ad-hoc requests run as.

People

Map each person to a tier and (optionally) who they report to. Authority is granted explicitly here — never inferred from a profile. Per-person allow/deny widens or narrows the tier (deny wins). When a team member's request needs approval, it routes to their nearest manager (set "Reports to" + that manager's "Escalation channel") — not to every approver.

Connectors

Tools to give Kai. First-class connectors (real Kai integrations) are grouped by category below. No tokens here — secrets are provisioned out-of-band.

Connect Kai to your Slack workspace — you'll be sent to Slack to approve, then back here.
Which chat surface is primary (any others are secondary). Captured as a routing preference and set during provisioning — not yet enforced by the runtime.

Requestable connectors — no first-class integration yet; checking one captures it as a provisioning request (an integration + credentials are wired out-of-band before Kai can use it):

Anything else (free-text):

Schedules

Recurring duties to provision as cron jobs. Schedule accepts a cron expression (e.g. 0 8 * * 1-5 = 08:00 Mon–Fri) or every 1d / every 4h; times are read in the org's local timezone (set above). Click a starter below to prefill a row, then pick its task class.

Escalation & approvers

Deployment-wide fallback for escalations/approvals — used when a person has no manager set in People. Per-person routing (to a nearest manager) takes priority over this.

Members allowed to approve/deny inline. Managers (anyone set as a "Reports to" target) are auto-included so the escalations they receive are actionable.

Guardrails

Check anything Kai must never do on this deployment, in plain terms. These become hard, deployment-wide bans on top of every tier.

Posts matching these are treated as internal (not external sends). Optional.