View Agent
Open in Wonderful Platform
Overview
| Field | Value |
|---|---|
| Market | Israel - Telecommunications |
| Vertical | Telecommunications |
| Company | Partner (פרטנר) |
| Model | gpt-realtime-2025-08-28 |
| Language | Hebrew |
| Channels | Voice |
Skills
- Remote Control Identification — Identifies the exact remote model (S70, Jade, TopBox) using physical descriptions or visual confirmation via SMS\
- Hardware-Specific Troubleshooting — Executes tailored pairing, reset, and recovery procedures per remote model\
- Operational Guidance — Provides step-by-step instructions for Android TV navigation and app usage (Netflix, YouTube, Home screen)
Key Tools
| Tool | Purpose |
|---|---|
| get_jade_codes() / get_s70_codes() | Retrieve TV manufacturer codes for RC-to-TV pairing |
| OnStart() | Initializes the session (OAuth tokens, GMS call metadata) |
| pCRM() | Submits call summaries and quality metrics to Partner CRM |
Prompting Techniques
Hierarchical modular prompting — All remote control models share a mirrored prompt architecture to ensure consistency while allowing precise technical variation:- Each remote model has an identical prompt skeleton
- Only model-specific steps differ
- Pair RC to DTA
- Unpair RC from DTA
- Reset RC
- Control TV Volume
- The agent must identify the symptom
- Only then may it call the relevant Atomic Skill
The Troubleshooting - Skill Synergy
The core strength of Bar lies in the strict separation between diagnosis and execution:- Logical Mapping - Troubleshooting flows act as deterministic decision trees.
- Precision - The agent never improvises technical steps; it executes predefined skills only.
- Modularity - Pairing logic can be updated independently of diagnostic logic.
Example: S70 Logic Relationship
SYMPTOM: Volume and Power work, but Channels do not FLOW: Troubleshooting PATH B ACTION SEQUENCE:- Unpair RC from DTA
- Pair RC to DTA
Lessons Learned
What worked- Single-feature identification (turquoise button) dramatically improved model detection accuracy\
- Strict step confirmation reduced user errors during pairing flows\
- Modular skills prevented hallucination of technical procedures
- Hardware identification over voice/chat is inherently limited\
- SMS-based image galleries were required to compensate for lack of visuals\
- Maintaining consistent Hebrew technical terminology required a strict internal dictionary
Deep Dive
1. Remote Control Identification - Physical Feature Classifier
Purpose: Identify the correct hardware model without serial numbers or device metadata. What it does- Asks the user about unique physical characteristics (button color, layout, labels)\
- Optionally sends an SMS link to a visual gallery\
- Confirms the remote model before allowing any troubleshooting
- No troubleshooting is allowed before model confirmation
2. Troubleshooting Flows - Symptom-Based Decision Engine
Purpose: Diagnose the user’s issue and select the correct execution path. What it does- Classifies the issue (pairing, volume, channels, power, navigation)\
- Maps the symptom to a predefined path (A—H)\
- Determines the exact Atomic Skill sequence required
- Eliminates random trial-and-error steps\
- Ensures repeatable, support-grade diagnostics
3. Atomic Skills - Deterministic Technical Execution
Purpose: Execute hardware procedures safely and consistently. What they do- Provide exact button sequences\
- Enforce wait-and-confirm pacing\
- Use approved Hebrew terminology only\
- Prevent skipping or reordering steps
How They Work Together
User: “השלט עובד על ווליום אבל לא מחליף ערוצים”- Remote Identification → S70 confirmed
- Troubleshooting Flow → PATH B
- Atomic Skill: Unpair RC from DTA
- Atomic Skill: Pair RC to DTA
- Confirmation → Issue resolved
- CRM() → Call summary submitted