Skip to main content

Kaito × h.work — End-to-End Client Flow

Audience: h.work engineering, AM, and Expert teams working on the Kaito engagement. Last updated: 2026-06-01 Related: Kaito Engagement Brief (Notion), MVP Launch Checklist


Role Glossary (Kaito Context)

NameRoleVisible to Kaito?
AmySpecialist persona — the AI-backed identity Kaito's team talks toYes — this is who Kaito sees
VeenaExpert — handles explicit human requests, failures, and intentional corrections/follow-ups; may manually publish approved campaign contentNo — Kaito does not interact with her directly
HermesManaged agent — owns Amy's durable session and produces the canonical replyNo
Alex OsForward-deployed AM / PM — supports tooling questions in the backgroundNo

Architecture Overview

Kaito uses two distinct layers. These are often confused:

Communication layer (h.work platform) WhatsApp and Slack. This is how Kaito's team talks to Amy. Successful managed turns reply directly; Veena uses the Expert workspace only for explicit human work, genuine failures, or intentional corrections/follow-ups.

Content distribution layer (Kaito's own tooling) X (Twitter), Telegram, Discord, email. This is where Amy (operated by Veena) posts on behalf of Kaito — using Kaito's existing accounts and tools, exactly as a real employee would on Day 1. For MVP, h.work does not integrate with these platforms. Veena posts manually.


End-to-End Message Flow

The following describes the complete path of a single message from a Kaito team member through the h.work platform and back.

Kaito team member

│ Sends a message to "Amy" via WhatsApp or Slack

WhatsApp / Slack

│ Inbound webhook (HMAC-verified, BullMQ queued)

h.work API — ConversationsService

│ Saves exact inbound message → resumes managed Hermes session

Hermes AI Agent

│ Resumes SessionDB history and uses skills/KB/tools on demand
│ Writes one canonical assistant reply

h.work API — ChannelDispatcherService

│ withRetry + withCircuit + DLQ (three-layer protection)

WhatsApp / Slack

│ Message delivered under Amy's name

Kaito team member receives Amy's reply

Veena may observe or correct the delivered work afterward; that workflow never
withholds the successful Hermes reply.

Day 1–30 Operating Scenarios

Scenario A — Capital Launchpad Campaign Posts

Kaito's team runs 2–4 IDO campaigns per month, each requiring 5–7 templated announcement posts.

Kaito ops → Slack: "Amy, draft today's XYZ IDO announcement thread"

Hermes prepares 5-7 posts using Kaito knowledge and tools on demand

Veena reviews: tone, compliance check
(no token price predictions, no unauthorized disclosures)

Veena sends approved drafts to Kaito ops

Kaito ops manually publishes to X / Telegram / Discord

Scenario B — Launch Window Reply Triage (48–72h windows)

After each IDO launch, community questions flood in across channels.

Kaito ops → WhatsApp: "Amy, someone's asking how to participate in staking"

Hermes produces the canonical FAQ-style reply

Kaito ops manually posts response to community channel

Scenario C — Cross-Channel Content Adaptation

Every X post must be adapted to Telegram and Discord formats.

Kaito ops: "Adapt this tweet for Telegram"

Hermes rewrites: removes $cashtags, adjusts length,
adds Telegram-appropriate formatting

Canonical reply returns to Kaito ops; Veena may correct afterward

Scenario D — BD Associate Execution (Hypothesis B — validate in Week 1)

If validated, Veena may also absorb associate-level BD work: outbound prospecting, inbound qualification, demo scheduling, follow-ups, CRM hygiene. This scope is not confirmed for MVP — subject to Week 1 discovery conversations.


Kaito's Experience

Kaito's team interacts with the platform as if they have a new colleague named Amy.

TouchpointWhat Kaito experiences
CommunicationMessages Amy directly in their existing WhatsApp or Slack — no new platform to learn
Response timeTarget: reply within 5 minutes through the managed Hermes delivery path
Identity continuityAlways "Amy" — even if the Expert behind Amy changes, the persona is uninterrupted
Week 1–4Veena gathers insights on Kaito's workflow, voice, priorities, and pain points
Phase 2Tooling decisions driven by what Veena surfaces — no commitments made upfront

What Kaito Does NOT See

  • Veena exists or may handle explicit human work and corrections
  • The h.work platform UI or any internal tooling
  • Hermes' internal reasoning, session, and tool activity
  • Any automation on X — Veena posts manually under Kaito's accounts (X TOS compliant)

AM Setup Flow

  1. AM opens /ops/clients/new (or /ops/clients/new?specialist=amy for the Kaito launch path).
  2. AM creates the org with name Kaito, slug kaito, industry Technology, timezone, and Kaito corporate domains.
  3. After org creation, the wizard lands on Step 2 at /ops/clients/{orgId}/setup/step-2.
  4. Step 2 selects Amy as the Specialist; the AM confirms the assignment manually.
  5. Steps 3-4 configure email/channel readiness and send the client invite when the setup checks pass.

Compliance Constraints (Hard Limits)

These are enforced in Amy's Specialist prompt and Veena's review gate:

  • No token price predictions or price-dependent framing
  • No unauthorized disclosures about IDO allocation, vesting, or regional eligibility
  • No programmatic posting to X under Kaito's brand (Veena posts manually — fully X TOS compliant post-Yaps shutdown January 2026)
  • Jurisdiction-specific compliance flags enforced per campaign

Owners

AreaOwner
Expert (Amy persona, day-to-day output)Veena
AM / PM supportAlex Os
h.work platform readiness (WhatsApp + Slack + Hermes)Paul X
Production infrastructure (ECS)Emanuele
UAT / platform readiness testingKonstantin
Client relationshipE T
Billing setup (Lago, per-Specialist monthly invoicing — #1069/#1105/#1155 (note: PR #1165 was closed-unmerged and superseded by #1155); Orb retired by #1217)Alexander Kalinin
Product strategyPercy