Kova Bot

Most enterprise AI deployments fail because they treat all users the same. A founder needs strategic framing and executive brevity. An analyst needs precision and sourcing. A new user needs guardrails and guided onboarding. A single generic system prompt collapses these needs into mediocrity, and mediocrity in AI looks like confident wrong answers. Kova Bot is a WhatsApp-based conversational AI that assigns each user one of five roles during onboarding and runs every subsequent interaction through role-aware constraints.

1. 1.
   Role Taxonomy Design: Define five user roles from first principles based on what each type of user actually needs from an AI system, not based on what the LLM makes easy to configure.
2. 2.
   Role-Aware Prompting: Build a Claude API integration where the system prompt is dynamically assembled from the user's assigned role, constraining tone, depth, and framing per persona.
3. 3.
   Async Reliability: Design the message processing layer to handle WhatsApp's webhook delivery guarantees and ensure no message is dropped or responded to out of order.
4. 4.
   Audit Trail: Log every interaction, role assignment, system prompt used, user message, model response, to a Prisma-managed database for accountability and future tuning.

• ◆
  Role Definition: Spent one week interviewing the five primary user types before writing any code. Documented what each role needed, what responses would actively harm them, and what constraints mattered.
• ◆
  System Prompt Engineering: Built a prompt assembly layer that composes role-specific context, constraints, and framing rules into a single coherent system prompt per conversation turn.
• ◆
  Webhook Architecture: Built the Express backend to handle WhatsApp's delivery guarantees, idempotency on message IDs, queue-based processing, and retry logic for failed Claude API calls.
• ◆
  Validation via Pilot: Ran a closed pilot with 5K testers across all five roles, collecting response quality ratings and role-misattribution incidents to tune the taxonomy.

The five roles, Founder, Analyst, Operator, Explorer, and Newcomer, were not arbitrary labels. Each maps to a distinct interaction pattern: Founders get strategic brevity and tradeoff framing. Analysts get precise, sourced answers with uncertainty quantified. Operators get procedural, step-by-step outputs. Explorers get breadth over depth, with deliberate ambiguity preserved. Newcomers get guided, scaffolded responses that build context before giving answers.

Role-aware prompting isn't just prepending 'you are talking to a Founder'. It means constraining response length, vocabulary register, confidence calibration, and call-to-action structure differently per role. The system prompt layer is modular, a base Claude context plus role-specific constraint blocks, so each dimension can be tuned independently without breaking the others.

The role taxonomy is a product decision, not an engineering one. I designed the five roles and their constraint logic from first principles, what does each user type actually need from this system, and where does a generic response actively harm them? That thinking preceded any code.

Role-aware AI responses that match user context, with async reliability and a full audit trail for accountability.