AI Support Inbox — Kapable v2 starter

Incoming support messages are triaged, AI drafts a reply, a human reviews and edits the draft, then sends a real email. The flagship ai + comms + data starter.

The core value loop

incoming message → AI-drafted reply (kapable-ai) → human approve/edit → real email sent (kapable-comms at_ app-token).

Services

• kapable-ai — BYO-key proxy, one-shot non-streaming completion with response_format: json_object to draft { subject, body }. (app/lib/ai.server.ts)
• kapable-comms — the at_ app-token → POST /v1/internal/send for the REAL outbound email. Send-only, org-scoped, from-domain-pinned. (app/lib/comms.server.ts)
• kapable-data — source of truth for threads + messages (inbox_threads, inbox_messages, app-slug-prefixed). (app/lib/inbox.server.ts)

Credentials (server-only deploy secrets — never in the client bundle)

• KAPABLE_ORG_KEY — an sk_live_ org key ({read,write} scopes) for data + AI.
• KAPABLE_COMMS_APP_TOKEN — the comms at_ app-token for sending email.
• INBOX_MODEL (optional) — the OpenRouter model (default openai/gpt-4o-mini).
• INBOX_EMAIL_FROM (optional) — the bare from-address (default noreply@kapable.ai).

Inbound verdict

No app credential can READ the org's comms inbox: list_messages requires a member kses_ session (which doesn't reach .run and expires) or an ak_ agent-key (itself mintable only via a member session); the sk_live_ org key validates with member_id=None → 401, and the at_ token is send-only. So inbound arrives via the in-app "new incoming message" intake — the seam where a real inbound-email webhook would post. Outbound send and the AI draft are 100% real (never mocked).

Develop

bun install
KAPABLE_ORG_KEY=sk_live_… KAPABLE_COMMS_APP_TOKEN=at_… bun run dev

Build (production)

bun install && bun run build && bun run start   # serves on :3000