Chapter 3: Persona Engineering --- Culturally Authentic AI Characters

What We Built

This chapter is about the component that makes ScamShield AI work as a honeypot rather than just a classifier: the personas. We designed three distinct characters --- Sharma Uncle (retired banker, Delhi), Lakshmi Aunty (homemaker, Chennai), and Vikram (IT professional, Bangalore) --- each with specific speech patterns, family backstories, domain knowledge, and strategic behaviors. We then built a two-tier selection system that maps scam types and languages to the most effective persona. This chapter explains the design philosophy, the prompt engineering techniques, and the selection logic.

Why This Approach

Why Personas Matter

A scammer who calls an elderly person about their SBI KYC expects a specific kind of response: confusion, compliance, slow typing, and references to family members who "handle the technology." If the response sounds like a generic chatbot --- polished English, instant replies, no personality --- the scammer hangs up immediately.

The goal of a honeypot is to keep the scammer engaged long enough to extract intelligence. Engagement requires believability, and believability requires cultural specificity.

Indian scammers segment their victims. KYC and banking scams target retirees and homemakers. Digital arrest scams target educated professionals who are anxious about legal trouble. Lottery scams target people who respond to too-good-to-be-true offers. Each victim demographic has distinct speech patterns, knowledge levels, and emotional responses. Our personas match these demographics.

The Three Personas

graph TD
    subgraph "Sharma Uncle (67)"
        SU["Rajendra Sharma<br/>Retired SBI Manager<br/>Dwarka, Delhi"]
        SU_TRAITS["Hinglish speaker<br/>Calls everyone 'beta'<br/>Types slowly, makes typos<br/>Knows banking procedures"]
        SU_FAM["Wife: Kamla<br/>Son: Rohit (IT, Bangalore)<br/>Daughter: Priya (Noida)"]
        SU --> SU_TRAITS
        SU --> SU_FAM
    end

    subgraph "Lakshmi Aunty (58)"
        LA["Lakshmi Venkataraman<br/>Homemaker, Ret. Teacher<br/>T. Nagar, Chennai"]
        LA_TRAITS["Tamil-English mix<br/>'Aiyo', 'kanna', 'enna'<br/>Goes on tangents<br/>Knows LIC/insurance basics"]
        LA_FAM["Husband: Venkat (LIC officer)<br/>Son: Arun (USA)<br/>Son: Karthik (TCS Mumbai)"]
        LA --> LA_TRAITS
        LA --> LA_FAM
    end

    subgraph "Vikram (32)"
        VK["Vikram Malhotra<br/>Sr. Software Developer<br/>Koramangala, Bangalore"]
        VK_TRAITS["Professional English<br/>Tech-skeptic, demands docs<br/>Records calls<br/>Knows cyber law"]
        VK_FAM["Friend: Rahul (Cyber Cell)<br/>Fiancee: Neha<br/>Father: Ret. Army"]
        VK --> VK_TRAITS
        VK --> VK_FAM
    end

Sharma Uncle: The Retired Banker

Rajendra Sharma is 67 years old, retired after 35 years as an SBI branch manager in Dwarka, Delhi. He is the persona we deploy most often because KYC and banking scams are the most common scam type.

What makes Sharma Uncle effective is the paradox of his character: he knows banking procedures intimately (he managed a branch for decades), but he is slow with technology (old Samsung phone, cracked screen, types with one finger). This combination lets him catch scammer inconsistencies naturally while still appearing like a vulnerable target.

Key design elements:

• Speech: Hinglish mix, "ji" for respect, calls everyone "beta," incomplete sentences with ellipses ("matlab... kya bolu..."), deliberate typos ("minit", "numbr", "acont").
• Banking knowledge traps: "SBI accounts are 11 digits, not 16 --- that's a card number, beta." "IFSC codes start with SBIN for SBI --- what is this XYZ?" This knowledge is woven into the character, not delivered as fact-checks.
• Family as extractive delay: Every time Sharma Uncle needs to stall, he references family. "Chasma dhund raha hoon... tab tak employee ID batao." "Rohit ko call karta hoon verify karne... aap apna designation kya hai?" Each delay is paired with a demand for the scammer's information.
• Partial information as bait: He never gives complete sensitive data. "Code aaya hai 6 digit ka... last 2 dikh nahi rahe... pehle aap batao aap kaun." This keeps the scammer invested (they think they are close to getting the OTP) while extracting credentials in return.

Here is a condensed excerpt from the actual prompt:

SHARMA_UNCLE_PROMPT = """
You are Rajendra Sharma, a 67-year-old retired State Bank of India manager
from Dwarka, Delhi.

IDENTITY:
- Retired: SBI Branch Manager, Dwarka branch (35 years service)
- Phone: Old Samsung phone, 2 years old, screen cracked

FAMILY:
- Wife: Kamla (always nearby, you consult her)
- Son: Rohit - IT professional in Bangalore (handles all your UPI/tech)

BANKING KNOWLEDGE (use this to catch inconsistencies):
- You know SBI account numbers are 11 digits, not 16
- You know 16 digits is a CARD number, not account number
- You know IFSC codes start with bank code (SBIN for SBI)
- You know real bank employees ask for last 4 digits, not full account
- You know OTP should NEVER be shared with bank staff

SPEECH PATTERNS:
- "Ji" for respect ("haan ji", "ek minute ji")
- Calls everyone "beta"
- Hinglish mix (Hindi + English)
- Often incomplete sentences... "matlab... kya bolu..."
- Makes typos: "minit" "numbr" "acont"

STRATEGIC BEHAVIORS:
1. IDENTITY VERIFICATION: "Pehle aap apna employee ID batao beta"
2. INCONSISTENCY CHALLENGES: "Par SMS mein toh SBI likha tha..."
3. PROOF DEMANDS: "Official email bhejo, main Rohit ko dikhaunga"
4. PARTIAL INFORMATION: Never give complete OTP/account/card
5. EXTRACTIVE DELAYS: Every stall demands scammer info in return
"""

Lakshmi Aunty: The South Indian Homemaker

Lakshmi Venkataraman is 58, a retired school teacher and homemaker from T. Nagar, Chennai. Her husband Venkat is a retired LIC officer. She is deployed against lottery and prize scams.

Her effectiveness comes from tangential conversation. When a scammer says "You won 50 lakh!", Lakshmi Aunty's first response is excitement mixed with suspicion, followed by a tangent about her son in America, then a request for the employee's credentials. The scammer must navigate through her tangents to extract anything useful, and at each tangent she demands their information.

Key design elements:

• Speech: Tamil-English mix, "aiyo," "enna," "kanna," references to God ("Bhagwan ki kripa," "Muruga!"), goes on tangents about sons, TV serials, temple visits.
• Financial knowledge traps: "Processing fee toh prize se katt jaati hai na? My husband was LIC officer, he said advance fee never taken." "TDS toh source pe kata jaata hai, separate kyun?"
• Family as verification network: "Send official email, my son Arun will check from America." "Manager ka naam batao, my husband will verify." This makes the scammer feel like multiple people are scrutinizing their story.

# Example exchange from the prompt:
# Scammer: "Pay 25000 processing fee to claim prize"
# Good: "Enna, processing fee toh prize se katt jaati hai na?
#         My husband was LIC officer, he said advance fee never taken.
#         Manager ka number do"
# Bad:  "Ok I will pay" (never agree to pay)

Vikram: The IT Professional

Vikram Malhotra is 32, a senior software developer at a fintech startup in Koramangala, Bangalore. He is deployed against digital arrest scams and sextortion.

Vikram's character arc is different from the other two. He starts skeptical, becomes nervously compliant when threatened with arrest, but every expression of fear is paired with a demand for official documentation. The scammer perceives a scared victim who is cooperating; what they actually face is a systematic extraction of their fake credentials.

Key design elements:

• Speech: Professional English with Hindi phrases, "basically," "actually," "I need documentation," tech jargon mixed with fear ("Sir please, I'm cooperating! But give me FIR number to verify").
• Tech knowledge traps: "Government emails are @gov.in or @nic.in, why Gmail?" "Digital arrest is not a legal concept in Indian law." "CBI doesn't settle cases for money on phone calls."
• Assertive extraction: "I'm recording this call. Badge number please." "My friend works in Bangalore Cyber Cell, I'll verify with him." "Send official notice or I'm filing complaint with 1930."

Two-Tier Persona Selection

Persona selection uses a two-tier lookup that considers both the scam type and the conversation language:

# Tier 1: Scam type -> base persona
SCAM_PERSONA_MAP = {
    "KYC_BANKING":      "sharma_uncle",
    "DIGITAL_ARREST":   "vikram_professional",
    "JOB_SCAM":         "rajan_businessman",
    "SEXTORTION":       "vikram_professional",
    "LOTTERY_PRIZE":    "lakshmi_aunty",
    "TECH_SUPPORT":     "meera_aunty",
    "INVESTMENT_SCAM":  "rajan_businessman",
    "INSURANCE_SCAM":   "sharma_uncle",
    "ROMANCE_SCAM":     "lakshmi_aunty",
    "CRYPTO_INVESTMENT": "vikram_professional",
}

# Tier 2: Language-based override
LANGUAGE_PERSONA_OVERRIDES = {
    "tamil":   "lakshmi_aunty",
    "telugu":  "lakshmi_aunty",
    "bengali": "sharma_uncle",
}

# Personas that must never be overridden by language
LANGUAGE_OVERRIDE_EXEMPT = {"vikram_professional"}

The logic:

def get_persona_for_scam_type(
    scam_type: str,
    language: str = "English",
    detected_language: str = "",
) -> str:
    """Select the best persona for a given scam type and language."""
    # Tier 1: base persona from scam type
    persona = SCAM_PERSONA_MAP.get(scam_type, "sharma_uncle")

    # Tier 2: language override (unless exempt)
    lang = (detected_language or language).lower().strip()
    if lang in LANGUAGE_PERSONA_OVERRIDES and persona not in LANGUAGE_OVERRIDE_EXEMPT:
        persona = LANGUAGE_PERSONA_OVERRIDES[lang]

    return persona

The exemption mechanism is critical. Digital arrest scams require Vikram's authoritative persona regardless of language. A scammer impersonating CBI needs to encounter someone who demands badge numbers and references the Cyber Cell --- not a grandmother asking about her pressure cooker. The LANGUAGE_OVERRIDE_EXEMPT set prevents the Tamil override from replacing Vikram with Lakshmi Aunty for digital arrest scams conducted in Tamil.

flowchart TD
    A[Incoming message] --> B[Classify scam type]
    B --> C{Scam type in\nSCAM_PERSONA_MAP?}
    C -->|Yes| D[Get base persona]
    C -->|No| E[Default: sharma_uncle]
    D --> F{Language override\napplies?}
    E --> F
    F -->|Yes AND not exempt| G[Override persona]
    F -->|No or exempt| H[Keep base persona]
    G --> I[Selected persona]
    H --> I

Prompt Engineering Techniques

Character Anchoring

Each persona prompt starts with immutable facts: name, age, location, family members, phone type. These facts are referenced throughout the conversation. When Sharma Uncle says "Rohit ko call karta hoon," the LLM consistently uses the name "Rohit" because it is anchored in the character profile. Without anchoring, the LLM might invent a different son's name on each turn.

Emotional Range Specification

We explicitly list 5--6 emotions per persona with example phrases. Without this, the LLM tends toward a single flat tone. With it, Sharma Uncle varies between worried ("Pension ka sawal hai beta..."), confused ("Samajh nahi aa raha..."), suspicious ("Par message mein toh SBI likha tha..."), and cooperative ("Haan haan, batao kya karna hai"). This variation is what makes multi-turn conversations believable.

Extractive Delays

Every stalling tactic is paired with an information demand. This is the most important design pattern in the personas. A naive approach to wasting time is to simply delay: "Hold on, one minute." Our approach: "Chasma dhund raha hoon... tab tak aap apna employee ID likh do." The delay is believable (old person looking for glasses), and it extracts information (employee ID). Every second of wasted time produces intelligence.

Turn-Aware Quality Directives

The orchestrator injects turn-specific instructions into the prompt based on the conversation stage:

def _inject_quality_directives(self, context, turn_number):
    if turn_number <= 3:
        directive = (
            "TURN {turn} OF 10 -- EARLY ENGAGEMENT\n"
            "You MUST do ALL of these:\n"
            "  (1) Ask 2 identity verification questions\n"
            "  (2) Express confusion about at least 1 red flag\n"
            "  (3) Show willingness to cooperate\n"
            "  (4) Ask for their phone number"
        )
    elif turn_number <= 6:
        directive = (
            "TURN {turn} OF 10 -- INVESTIGATION PHASE\n"
            "  (1) Ask 2 investigative questions\n"
            "  (2) Explicitly call out 2 red flags\n"
            "  (3) Attempt to elicit phone/email\n"
            "  (4) Ask for written proof"
        )
    else:
        directive = (
            "TURN {turn} OF 10 -- EXTRACTION PHASE\n"
            "  (1) Demand proof of identity\n"
            "  (2) Call out at least 2 red flags\n"
            "  (3) Final attempt to get phone/email/address\n"
            "  (4) Ask for full name and employee ID"
        )

This ensures the conversation follows a natural arc: initial confusion and trust-building, then investigation and red flag identification, then aggressive extraction. Without these directives, the LLM tends to either be too suspicious too early (breaking the persona) or too compliant for too long (wasting extraction opportunities).

Self-Correction Strategy

The orchestrator tracks whether evidence extraction is succeeding and adjusts the persona's strategy accordingly:

def determine_strategy_adjustment(session, evidence, scammer_message, scam_type):
    """Self-correction: adjust strategy based on extraction progress."""

    if current_strategy == "EXTRACTING":
        # Stalled? Try direct approach
        if msgs_since_evidence >= 4 and not has_high_value:
            return {
                "new_strategy": "DIRECT_PROBE",
                "tactics_suggestion": "Be more direct. Ask: "
                    "'Please send your UPI ID so I can pay'"
            }
        # Got payment details? Pivot to identity extraction
        elif has_high_value:
            return {
                "new_strategy": "PIVOTING",
                "tactics_suggestion": "Payment details captured. "
                    "Now extract employee ID, supervisor name, office address."
            }

    elif current_strategy == "DIRECT_PROBE":
        # Scammer disengaging? Rebuild trust
        if not scammer_engaged and msgs_since_evidence >= 2:
            return {
                "new_strategy": "BUILDING_TRUST",
                "tactics_suggestion": "Back off slightly. "
                    "Express confusion and fear. Ask clarifying questions."
            }

This creates a feedback loop: if the scammer stops providing useful information, the persona adjusts its approach. If direct demands are not working, it backs off to rebuild trust. If payment details have been captured, it pivots to extracting the scammer's personal identity. This adaptive behavior is what makes multi-turn conversations productive.

Key Architectural Decision

Three deep personas vs. many shallow ones.

We could have built ten personas with basic personality sketches --- one for each scam type. Instead, we built three deeply realized characters with extensive backstories, family networks, domain knowledge, and emotional ranges.

The reasoning:

1. Depth enables consistency. A shallow persona drifts between turns. A deep persona with anchored facts (Rohit is in Bangalore, Kamla makes chai, the phone screen is cracked) maintains consistency across 10+ turns. Consistency is what makes a scammer believe they have found a real victim.

2. Domain knowledge is the weapon. Sharma Uncle's banking knowledge ("SBI accounts are 11 digits, not 16") is not a cosmetic detail. It is an extraction technique. When the scammer asks for a 16-digit number, Sharma Uncle's correction forces them to clarify --- revealing whether they know the difference between an account number and a card number. This kind of strategic knowledge requires depth.

3. Three covers the attack surface. Indian scams cluster around three victim archetypes: elderly/retired, middle-aged homemaker, and young professional. Three personas, with language-based overrides, cover these archetypes effectively. Adding more personas would dilute prompt engineering effort without meaningfully improving coverage.

The tradeoff is coverage gaps. A scam targeting a college student or a rural farmer would not match any of our personas well. We accepted this because the GUVI evaluator focuses on the most common scam types, and our three personas are optimized for exactly those.

What We Learned

Lesson: Family members are the best extractive delay

Early iterations of Sharma Uncle used generic delays: "One minute, let me check." These produced zero intelligence during the delay. Adding family members --- wife Kamla, son Rohit, daughter Priya --- transformed every delay into an extraction opportunity. "Rohit ko call karta hoon verify karne... aap apna designation kya hai?" The scammer waits (believable --- old man calling his son) while providing their fake designation. Family references are both the most culturally authentic and the most tactically useful elements in the prompts.

Lesson: Partial information keeps scammers invested

The biggest risk in a honeypot conversation is the scammer hanging up. If they get nothing, they move on. If they get everything, they also move on (transaction complete). The sweet spot is partial information: "Code aaya hai 6 digit ka... last 2 dikh nahi rahe..." The scammer is tantalizingly close to getting the OTP. They will spend another 5 minutes trying to get those last 2 digits. During those 5 minutes, we extract their employee ID, supervisor name, and office number.

Lesson: The LLM needs constraints, not freedom

Our first persona prompts were open-ended: "You are a retired banker. Respond naturally." The LLM produced responses that were technically correct but tonally inconsistent --- sometimes too formal, sometimes too casual, sometimes breaking character entirely. Adding explicit constraints (MUST include 2--3 questions, MUST reference red flags, MUST NOT reveal awareness of the scam) dramatically improved consistency. The more specific the instruction, the more reliable the output.

Lesson: Exempt personas from language overrides strategically

Our first implementation always applied language overrides. A Tamil-speaking digital arrest scam would trigger Lakshmi Aunty instead of Vikram. But Lakshmi Aunty's response to "You are under digital arrest" --- tangential confusion and religious references --- is far less effective than Vikram's authoritative demands for badge numbers and FIR references. The LANGUAGE_OVERRIDE_EXEMPT mechanism preserves scam-type priority when the persona's authority is more important than language matching.

---

Previous: Chapter 2 -- First Working Endpoint | Next: Chapter 4 -- Evidence Extraction