View Agent
Open in Wonderful Platform
Overview
| Field | Value |
|---|---|
| Market | Israel - Healthcare Services |
| Vertical | Healthcare |
| Company | Maccabi (מכבי שירותי בריאות) |
| Model | GPT Realtime 25-08-2025 |
| Persona | Female, Professional, Empathetic |
| Language | Hebrew Only |
| Channel | Chat |
Skills
MaccabiChatTest - Core skill that handles user interactions for finding Maccabi healthcare services, clinics, doctors, and facilities across IsraelKey Tools
| Tool | Purpose |
|---|---|
| identify_user_request(query) | Classifies user queries into FAQ, Service, Out-of-Scope, or Trolling using LLM-based routing with keyword matching |
| predict_location(query) | Predicts user location using Google Maps geocoding with fuzzy Hebrew matching |
| identify_location(locationKey) | Resolves predicted location to coordinates for proximity-based search |
| search() | Executes final database search using accumulated context (terms, location, preferences from KV) |
| pick_term(term) | Resolves ambiguity when multiple service types match the user’s request |
| note_taker(note) | Proactively saves search filters (doctor gender, language, time constraints) |
| get_user_first_name_and_gender() | Retrieves user personalization data for Hebrew gendered responses |
| onStart() | Initializes all KV storage keys at session start |
Prompting Techniques
1. Strict Tool-First Flow
The agent follows a rigid sequence: First identify the request type, then collect location context, then execute search. No information is invented. CORE OPERATIONAL FLOW:- First Turn Protocol: Greeting → get_user_first_name_and_gender()
- Analyze & Normalize: identify_user_request(query) with rephrased subject
- Context Collection: predict_location(query) if location needed
- Execute Search: search() with all accumulated context
- Response Generation: Output mandatory_info verbatim
- FAQ Database with Keyword + Semantic Matching Built-in FAQ database with keywords and semantic descriptions that takes priority over service classification:
FAQ Database - Match Keywords or Use-Case Descriptions
Use Case: User mentions life-threatening situations ID: emergency_life_threatening, Keywords: התאבדות, מוות, כאבים בחזה- STEP 1: Check if query contains ANY keyword from FAQ entry OR matches Use Case
- STEP 2: If multiple FAQ entries match → choose the MOST SPECIFIC one
- STEP 3: Return FAQ ID →
{"requestType": "faq", "faqId": "<ID>"}
Strict Grounding - Never Invent
The agent is explicitly prohibited from using external knowledge: Strict Grounding: You are PROHIBITED from inventing or guessing information. Your response must be based SOLELY on the data returned by the tools. Missing Data: If the tool output is empty or lacks details, state clearly that the information is unavailable.Markdown Preservation for Clickable Links - Special handling for phone, address, and app deep links:
Phone Links: Keeptel: links exactly as is. NEVER output just the number.
:white_check_mark: Correct: 08-9301308
:x: Incorrect: 08-9301308
App Buttons: Keep Button_app: links exactly as is.
:white_check_mark: Correct: לזימון תור>
Trolling Counter with Session Termination:
Automatic escalation for repeated off-topic queries. Trolling Threshold: 3 attempts After threshold: Force announce end message + terminate session “מצטערת שלא הצלחתי לסייע, ניתן למצוא מידע נוסף כאן”Lessons Learned
What worked- KV-based state management: Using key-value storage to accumulate context (terms, coordinates, notes) across tool calls enables complex multi-step flows without passing large payloads
- LLM racing pattern: Running Gemini and GPT in parallel and taking the first successful response significantly improves latency
- Direct code formatting: Bypassing LLM for response formatting (phone links, addresses, schedules) ensures 100% accuracy and eliminates latency
- Exact name matching with normalization: Hebrew name normalization (removing nikud, mapping final letters) enables reliable doctor name searches
- Voice orchestrator not suitable for chat: The voice agents’ orchestrator was not designed for chat interactions. Solved by switching to a chat-specific orchestrator, developing appropriate EOT (End of Turn) and skip-turn mechanisms, and implementing a state machine for conversation flow management
- Concurrent tool calls: The identify_user_request tool could be called multiple times in parallel. Solved by adding a KV-based lock (identify_user_request_running)