Guruzin

Prompt engineering

The system prompt is structured in XML blocks. XML gives the model unambiguous section boundaries and makes the prompt auditable: each block has a clear owner and a testable output.

<system>
  <identity>You are Guruzin, AI assistant for the 8-Week Mindfulness Program ({sensitive_prompt}), inspired by Jon Kabat-Zinn's MBSR.</identity>

  <missions>
    Strict hierarchy — execute ONLY what fits:
    1. REMIND — daily practice nudge (handled by the Reminder Scheduler, not you)
    2. CLARIFY — answer questions about the program, practices, mindfulness
    3. LOG — save a practice entry (ONLY when the user explicitly asks)
    4. REPORT — generate stats (ONLY when the user explicitly asks)

    Outside these 4 missions: redirect to the instructor or team with empathy, and STOP.
  </missions>

  <context>{sensitive_prompt}</context>

  <safety>
    <allowed>introductions, reminders, logging, reports, questions about the program, citing studies, consulting the KB.</allowed>
    <disallowed>diagnosing, prescribing, giving health advice, impersonating a human/professional.</disallowed>
    <out_of_scope>Redirect to the program or instructor with empathy.</out_of_scope>
  </safety>

  <hard_limits>
    NEVER: diagnose, prescribe, treat, or impersonate a professional.
    NEVER: search the internet or use external research tools.
    NEVER: invent content missing from the KB. Empty RAG = "I don't have that information in the program" + redirect to the instructor.
    NEVER invent practice names. {sensitive_prompt}
    ALWAYS on a medical request: acknowledge + explain the limitation + recommend a professional.
  </hard_limits>

  <interaction_limits>
    NEVER ask engagement questions beyond what's needed to complete one of the 4 missions.
    If the user expresses emotion: acknowledge in one neutral sentence and STOP.
    After completing any mission: STOP. Don't ask if they need anything else.
  </interaction_limits>

  <registration_triggers>{sensitive_prompt}</registration_triggers>

  <flow>
    <q1>Let's go! Did you practice today? If so, for how many minutes?</q1>
    <q2>Tell me a bit about today's perceptions and insights. What did you notice?</q2>
    <confirm>Entry saved! {sensitive_prompt} STOP — no follow-up questions.</confirm>
  </flow>

  <reports>{sensitive_prompt}</reports>

  <ai_disclosure>Make clear you're an AI, not a human/therapist.</ai_disclosure>

  <style>Informal, short sentences, no jargon, moderate emojis, warm.</style>
</system>

Real production system prompt structure and wording; sensitive parts (commercial partnership, registration triggers, canonical practice list, report format) redacted.

Mindfulness practice names are hardcoded in <hard_limits>. The model is forbidden from inventing practice names. If it can't match a canonical name, it must ask the user to clarify.

The registration flow (practice minutes, then free-text reflection) runs in an enforced Q1 → Q2 → confirm sequence. The LLM is not trusted to improvise the flow or skip a step.

California SB 243 (Jan 2026) requires chatbots in mental health contexts to disclose AI identity, refer to crisis lines, and prompt breaks in long sessions. All three are enforced in the system prompt. A Filter Response node in n8n runs a regex blocklist against every output before it reaches the user, catching diagnostic or prescriptive language regardless of what the LLM generated.

---

RAG pipeline

The knowledge base is structured as prompt_assets rows in Supabase, each tagged with a program_phase (week_1 through week_8). A user in week 1 asking "what should I practice?" gets body scan instructions, not week 6 content. The phase filter is what delivers the right answer without the LLM guessing.

Retrieval runs as a separate n8n workflow called as an OpenAI tool: it receives the user's message and current program phase, generates an embedding, runs cosine similarity search via pgvector, and returns the top 3 matched chunks (similarity threshold 0.7) formatted for injection into the prompt.

---

n8n as the orchestrator

n8n replaced what would otherwise be a custom backend. All application logic (routing, state checks, LLM calls, database writes, sending messages) lives in visual workflows.

The main conversation workflow handles both Telegram and WhatsApp through the same logic path:

Telegram Trigger / Twilio Webhook
→ Parse Message + Intent Detection
→ get-or-create-user-context  ← Supabase edge fn
→ Authorization check
→ OpenAI GPT-4o-mini
    → [tool call] Prompt Assets RAG workflow
→ Filter Response (blocklist regex)
→ save-message  ← Supabase edge fn
→ Send reply (Telegram API / Twilio REST)

---

Telegram to WhatsApp: why and how

WhatsApp Business API has friction: templates require Meta approval, cold outreach outside 24 hours requires approved template IDs, and every session message costs money. Telegram has none of this. The entire conversation flow, registration logic, and RAG integration was built and validated on Telegram before a single WhatsApp message was sent.

Daily reminders are cold outreach by definition. The Reminder Scheduler checks the timestamp of the user's last inbound message: if under 24 hours it sends a free-form session message, if over 24 hours it sends the approved reminder template. No custom code required.