---
title: "एजेंट स्टेप्स और हैंडऑफ"
description: "किसी एजेंट को उसके अपने निर्देशों, टूल्स और एकत्र किए गए मानों वाले स्टेप्स में विभाजित करें, और कॉल के बीच में एजेंटों के बीच कॉल हैंड ऑफ करें।"
---
एकल प्रॉम्प्ट मॉडल को पूरा काम एक साथ देता है। **स्टेप्स** उसे कॉल का एक समय में एक चरण देते हैं: हर स्टेप के अपने निर्देश, अपने टूल्स, शब्दशः बोली जाने वाली एक वैकल्पिक पंक्ति, और आगे बढ़ने से पहले इकट्ठा किए जाने वाले मान होते हैं। **हैंडऑफ्स** आपके संगठन के किसी अन्य एजेंट को कॉल के बीच में, ट्रांसक्रिप्ट को बरकरार रखते हुए, काम संभालने देते हैं, ताकि कॉलर को कभी खुद को दोहराना न पड़े।
हर एजेंट एक एकल प्रॉम्प्ट के रूप में शुरू होता है। जब तक आप स्टेप्स या हैंडऑफ्स नहीं जोड़ते, इसमें कुछ नहीं बदलता।
## स्टेप्स या एकल प्रॉम्प्ट?
| स्टेप्स का उपयोग करें जब | एकल प्रॉम्प्ट रखें जब |
| --- | --- |
| कॉल में ऐसे चरण हों जो क्रम से होने चाहिए: पहले सत्यापित करें, फिर बुक करें। | बातचीत ओपन-एंडेड हो: FAQ, रिसेप्शन, सामान्य सहायता। |
| एजेंट के आगे बढ़ने से पहले कोई मान कैप्चर करना आवश्यक हो। | किसी निश्चित क्रम में कुछ इकट्ठा नहीं करना हो। |
| कोई नियम कभी नहीं बदलना चाहिए, जैसे "18 वर्ष से कम उम्र के कॉलर को अभिभावक के पास भेजें"। | हर ब्रांच के लिए मॉडल का निर्णय पर्याप्त हो। |
| कॉल के एक निश्चित बिंदु पर लुकअप चलना आवश्यक हो। | कॉलर के पूछने पर कभी भी टूल्स को कॉल किया जा सकता हो। |
| कॉल का कोई भाग किसी अलग एजेंट का हो, जिसके पास अपना प्रॉम्प्ट और वॉइस हो। | एक पर्सोना सब कुछ संभालता हो। |
स्टेप्स कोई स्क्रिप्टेड फोन ट्री नहीं हैं। किसी स्टेप के भीतर मॉडल बातचीत को उसी तरह चलाता है जैसे वह एकल प्रॉम्प्ट के साथ चलाता है। स्टेप तय करता है कि वह किस पर काम कर रहा है, कौन से टूल्स का उपयोग कर सकता है और बाहर निकलने से पहले उसे क्या चाहिए।
## स्टेप्स वाले एजेंट को कैसे बनाया जाता है
जब किसी एजेंट में स्टेप्स होते हैं, तो उसका `prompt` **साझा निर्देशों** को रखता है: वह पर्सोना और नियम जो हर स्टेप पर लागू होते हैं। हर स्टेप इसके ऊपर अपने निर्देश जोड़ता है। हर टर्न पर मॉडल साझा निर्देश, वर्तमान स्टेप का नाम और निर्देश, और अब तक इकट्ठा किए गए मान देखता है।
बिल्डर में, एजेंट को **एकल प्रॉम्प्ट** से **स्टेप्स** पर स्विच करें। आपको हर स्टेप के लिए उसके नाम, निर्देशों, से पंक्ति, टूल्स, इकट्ठा किए गए मान और ट्रांज़िशन्स वाला एक कार्ड, एक हैंडऑफ्स पिकर, और स्टेप्स का एक रीड-ओनली फ्लो ग्राफ मिलता है। एकल प्रॉम्प्ट पर वापस स्विच करने पर एक फ्लैटन किया हुआ प्रॉम्प्ट मिलता है जो साझा निर्देशों और हर स्टेप को मर्ज करता है।
API में, `steps` और `handoffs`, [agent](/api-reference/agents) के फ़ील्ड हैं। हर एजेंट फ़ील्ड की तरह, `PATCH` उन्हें ड्राफ्ट में स्टेज करता है; `POST /v1/agents/{agent_id}/deploy` उन्हें लाइव करता है। `"steps": null` भेजने से एजेंट फिर से एकल प्रॉम्प्ट पर स्विच हो जाता है। टेस्ट कॉल्स और **बात करें** ड्राफ्ट चलाते हैं।
[कोपायलट](/hi/guides/ask-the-copilot) किसी विवरण से स्टेप्स बना सकता है
("बुकिंग से पहले जन्मतिथि सत्यापित करने वाला एक स्टेप जोड़ें") और अन्य स्टेप्स
को छुए बिना एक स्टेप संपादित कर सकता है।
### स्टेप फ़ील्ड्स
| फ़ील्ड | अर्थ |
| --- | --- |
| `id` | आवश्यक। छोटे अक्षर, अंक और अंडरस्कोर, अक्षर से शुरू होने वाला, अधिकतम 40 वर्ण। एजेंट के भीतर यूनिक। |
| `name` | आवश्यक डिस्प्ले नाम, 1 से 80 वर्ण। |
| `instructions` | आवश्यक, अधिकतम 20,000 वर्ण। `prompt` की तरह `{{var}}` [कॉल वेरिएबल्स](/hi/guides/call-variables) का समर्थन करता है। |
| `say` | स्टेप में प्रवेश करने पर शब्दशः बोली जाने वाली वैकल्पिक पंक्ति, अधिकतम 1,000 वर्ण। `{{var}}` का समर्थन करता है। |
| `tools` | `null` स्टेप को एजेंट से जुड़े हर टूल देता है। एक सूची स्टेप को नाम के आधार पर उन्हीं टूल्स तक सीमित करती है। `end_call` और `transfer_call` जैसी बिल्ट-इन कार्रवाइयाँ हर स्टेप में एजेंट की सेटिंग्स का पालन करती हैं। |
| `collect` | स्टेप द्वारा इकट्ठा किए जाने वाले अधिकतम 20 मान। हर एक में `name`, `type`, `description` और `required` (डिफ़ॉल्ट `true`) होता है। |
| `on_enter_tool` | वैकल्पिक टूल नाम, जिसे स्टेप में प्रवेश करने पर अपने-आप कॉल किया जाता है। [Webhook स्टेप्स](#webhook-steps) देखें। |
| `transitions` | स्टेप के आगे जाने के स्थानों की क्रमबद्ध सूची। [ट्रांज़िशन्स](#transitions) देखें। |
| `global_when` | वैकल्पिक। स्टेप को किसी भी स्टेप से पहुंचने योग्य बनाता है। [ग्लोबल स्टेप्स](#global-steps) देखें। |
| `voice` | इस स्टेप के लिए वैकल्पिक वॉइस id। एजेंट द्वारा कस्टम वॉइस कॉन्फ़िगरेशन उपयोग करने पर अनदेखा किया जाता है। |
ग्राफ स्वयं `{"start_step": "", "steps": [...]}` है। कॉल `start_step` में शुरू होती है।
## ट्रांज़िशन
हर ट्रांज़िशन में `to`, एक स्टेप आईडी, और ठीक इनमें से एक होता है:
- **`when`**: साधारण भाषा, और **मॉडल निर्णय लेता है**। एजेंट को एक
बिल्ट-इन `go_to_step` टूल मिलता है, जिसमें वे स्टेप सूचीबद्ध होते हैं जिन पर वह जा सकता है, और हर
`when` उसे चुनने का कारण होता है।
- **`condition`**: कलेक्ट किए गए मानों पर एक नियम, और **कोड निर्णय लेता है**। मॉडल
इसे स्किप नहीं कर सकता या बातचीत करके इसके आसपास नहीं जा सकता।
- **`"always": true`**: बिना जांच के आगे बढ़ें। कोड पहले निर्णय लेता है: जैसे ही
किसी स्टेप में प्रवेश किया जाता है, या उसके जरूरी मान कलेक्ट हो जाते हैं, मॉडल के
`when` चुनने से पहले पहली मैचिंग `condition` या `always` ट्रांज़िशन लागू होती है।
इसलिए `always` को शर्तों के बाद उनके फॉलबैक के रूप में रखें, या किसी स्टेप को सीधे
अगले स्टेप से जोड़ने के लिए इसे अकेले रखें। `always` वाला स्टेप कभी भी
`when` विकल्प की प्रतीक्षा नहीं करता।
एक `condition` है `{"value": , "op": , "target": }`:
| `op` | मान के लिए सत्य होने की स्थिति |
| --- | --- |
| `eq`, `ne` | `target` के बराबर है या उसके बराबर नहीं है |
| `lt`, `lte`, `gt`, `gte` | `target` से कम है, अधिकतम है, अधिक है या कम से कम है |
| `in`, `not_in` | `target` सूची के मानों में से एक है या नहीं है |
| `exists`, `missing` | कलेक्ट किया गया है या नहीं किया गया है (`target` नहीं) |
`eq`, `ne`, `in` और `not_in` स्पेस हटाने के बाद टेक्स्ट की तुलना केस-इंसेंसिटिव तरीके से करते हैं।
संख्याओं की तुलना संख्या के रूप में और तारीखों की तुलना `YYYY-MM-DD` स्ट्रिंग के रूप में होती है। ऐसा मान
जो कभी कलेक्ट नहीं किया गया था, `missing` को छोड़कर हर ऑप के लिए असत्य होता है।
`when` और `global_when` को किसी कथन के बजाय एक शर्त के रूप में लिखें, जैसे "कॉलर अपॉइंटमेंट
बुक करना चाहता है"। एजेंट इन्हें आंतरिक रूटिंग नोट्स के रूप में देखता है और उसे इन्हें कभी
ज़ोर से न पढ़ने या यह उल्लेख न करने के लिए कहा जाता है कि वह स्टेप बदल रहा है।
जब मॉडल `go_to_step` कॉल करता है:
1. स्टेप में हर `required` मान मौजूद होना चाहिए। यदि कोई मान मौजूद नहीं है, तो
मॉडल को बताया जाता है कि कौन सा मान मौजूद नहीं है, और वह कॉलर से उसे पूछता है।
2. मान स्टोर किए जाते हैं।
3. `condition` और `always` ट्रांज़िशन को क्रम से जांचा जाता है। पहला मैच
लागू होता है।
4. अन्यथा एजेंट उस स्टेप पर जाता है जिसे मॉडल ने चुना।
5. यदि कुछ भी मैच नहीं होता और मॉडल ने किसी स्टेप का नाम नहीं दिया, तो एजेंट वहीं रहता है।
किसी [ग्लोबल स्टेप](#global-steps) पर जाना अपवाद है: कॉलर ने विषय बदल दिया है,
इसलिए वर्तमान स्टेप में जरूरी मान मौजूद न होने पर भी, और उस स्टेप की शर्तों की जांच से पहले,
यह आगे बढ़ता है।
हर बार किसी स्टेप में प्रवेश करने पर `condition` और `always` ट्रांज़िशन की भी जांच होती है,
इसलिए कोड-निर्णीत स्टेप का क्रम एक ही बार में पूरा होता है। यह क्रम रुकता है:
- उस स्टेप पर जिस पर इस रन में पहले ही जाया जा चुका है;
- 8 हॉप्स के बाद;
- ऐसे स्टेप पर जिसमें अभी भी जरूरी मान कलेक्ट करने हैं, जब तक स्टेप में
`on_enter_tool` न हो (वेबहुक स्टेप हमेशा अपने परिणाम पर रूट होता है)।
जिस स्टेप पर क्रम रुकता है, केवल उसकी `say` लाइन बोली जाती है।
बिना ट्रांज़िशन वाला स्टेप **टर्मिनल** होता है। एजेंट वहीं पूरा करता है और अपने सामान्य बिल्ट-इन एक्शन के साथ
कॉल समाप्त या ट्रांसफर करता है।
## मान कलेक्ट करना
किसी स्टेप के लिए आवश्यक चीज़ों को `collect` में सूचीबद्ध करें। मॉडल जब `go_to_step` कॉल करता है,
तो मान पास करता है, और वे कॉल के बाकी समय के लिए उपलब्ध रहते हैं।
| `type` | इसमें होता है |
| --- | --- |
| `string` | कोई भी टेक्स्ट |
| `number` | एक संख्या |
| `boolean` | `true` या `false` |
| `date` | `YYYY-MM-DD` के रूप में एक तारीख |
कलेक्ट किए गए मान कॉल कंटेंट हैं। वे ट्रांसक्रिप्ट के साथ कॉल पर दिखते हैं और
उन्हीं रिटेंशन, डिलीशन और रिडैक्शन नियमों का पालन करते हैं। जब एजेंट की कॉल रिकॉर्डिंग बंद होती है,
तो कलेक्ट किए गए मान न तो स्टोर होते हैं और न ही वेबहुक में भेजे जाते हैं; स्टेप टाइमलाइन फिर भी रहती है। देखें
[कॉल पर इसे कहाँ देखें](#where-to-see-it-on-a-call)।
## पंक्तियाँ कहें
एजेंट के स्टेप में प्रवेश करते ही `say` को ठीक वैसे ही बोला जाता है जैसा लिखा है। मॉडल
फिर उसी उत्तर में नए स्टेप पर आगे बढ़ता है और जानता है कि पंक्ति अभी बोली गई थी,
इसलिए उसे दोहराता नहीं है। अभिवादन, आवश्यक डिस्क्लोज़र और तय शब्दावली के लिए `say`
का उपयोग करें, और उत्तर का बाकी हिस्सा मॉडल पर छोड़ दें।
स्टार्ट स्टेप का `say` एजेंट की शुरुआती पंक्ति होती है, जब वह किसी सहमति घोषणा के
बाद पहले बोलता है। जब कॉलर पहले बोलता है, तो यह किसी व्यक्ति को एजेंट के पहले उत्तर
से शुरू होता है, IVR या वॉइसमेल अभिवादन से कभी नहीं।
कॉल `__previous__` या हैंड-बैक के ज़रिए किसी स्टेप पर लौटने पर उस स्टेप का `say`
दोबारा नहीं बोला जाता। इसे वैसे लिखें जैसा इसे सुनाई देना चाहिए: ऐसी किसी भी चीज़ को
पूरा लिखें जिसे आवाज़ गलत पढ़ सकती है। Say पंक्तियाँ `{{var}}` कॉल वेरिएबल को सपोर्ट
करती हैं, लेकिन कलेक्ट किए गए वैल्यू को नहीं।
## Webhook स्टेप
`on_enter_tool` को एजेंट के किसी एक टूल पर सेट करें और स्टेप में प्रवेश होते ही वह मॉडल
की प्रतीक्षा किए बिना चल जाता है। इसके आर्ग्युमेंट वे कलेक्ट किए गए वैल्यू होते हैं जिनके
नाम टूल के पैरामीटर नामों से मेल खाते हैं। परिणाम को `_result` नाम के कलेक्टेड
वैल्यू के रूप में स्टोर किया जाता है, जिसे 4 KB तक ट्रंकेट किया जाता है, और स्टेप के
`condition` और `always` ट्रांज़िशन तुरंत जांचे जाते हैं, ताकि लुकअप अपने परिणाम के
आधार पर स्वयं कॉल को रूट कर सके।
स्टोर किए गए वैल्यू में दो फ़ील्ड होते हैं:
| फ़ील्ड | इसमें होता है |
| --- | --- |
| `status` | आपके एंडपॉइंट द्वारा लौटाया गया HTTP स्टेटस कोड। |
| `response` | रिस्पॉन्स बॉडी। |
बॉडी फ़ील्ड के आधार पर `lookup_account_result.response.` से और स्टेटस कोड के
आधार पर `lookup_account_result.status` से रूट करें।
लुकअप अधिकतम 8 सेकंड तक चलता है, या टूल के अपने टाइमआउट तक यदि वह इससे कम हो।
यदि इसमें 3 सेकंड से अधिक समय लगता है, तो एजेंट एक छोटी पंक्ति बोलता है ताकि कॉलर
को चुप्पी में न छोड़ा जाए। यदि आपका एंडपॉइंट 400 या उससे अधिक का स्टेटस लौटाता है,
या समय पर उत्तर नहीं देता, तो एजेंट कॉलर को बताता है कि वह अभी इसे जांच नहीं सका और
जो वह कर सकता है उसके साथ आगे बढ़ता है।
## ग्लोबल स्टेप
`global_when` वाला स्टेप किसी भी स्टेप से पहुंचा जा सकता है, जब भी वह विवरण लागू हो।
`when` की तरह मॉडल निर्णय लेता है। इसका उपयोग उन विषयों के लिए करें जिन्हें कॉलर किसी
भी समय उठा सकता है: बिलिंग संबंधी सवाल, किसी इंसान से बात करने का अनुरोध, शिकायत।
ग्लोबल स्टेप पर `"to": "__previous__"` वाला ट्रांज़िशन कॉल को उस स्टेप पर वापस ले जाता
है जो उससे पहले सक्रिय था, ताकि कॉलर वहीं से जारी रख सके जहाँ उसने छोड़ा था। स्टेप
फिर से शुरू होता है: उसका `on_enter_tool` दोबारा नहीं चलता, उसका `say` दोहराया नहीं
जाता, और एजेंट उसे शुरुआत से शुरू किए बिना जारी रखता है।
## हैंडऑफ
`handoffs` आपके संगठन के उन अन्य एजेंटों की सूची देता है जो कॉल संभाल सकते हैं:
```json
[{"agent_id": 413, "when": "The caller asks about billing or a refund"}]
```
एजेंट को उन एजेंटों और कारणों के साथ एक बिल्ट-इन `hand_off` टूल मिलता है। ट्रांज़िशन की तरह, हर `when` एक आंतरिक रूटिंग नोट है, जिसे कभी पढ़कर नहीं सुनाया जाता।
हैंडऑफ करते समय, एजेंट कॉलर को एक छोटी लाइन में बताता है कि उन्हें कहाँ भेजा जा रहा है, जैसे "ज़रूर, मैं आपको हमारी बिलिंग टीम से कनेक्ट कर देता हूँ", अपनी आवाज़ में। फिर लक्ष्य एजेंट का प्रॉम्प्ट, स्टेप्स, टूल्स और आवाज़ नियंत्रण संभाल लेते हैं और कॉल उसी ट्रांसक्रिप्ट के साथ जारी रहती है। नया एजेंट संक्षेप में अपना परिचय देता है और कॉलर के आखिरी अनुरोध का उत्तर देता है; वह ट्रांसफर की घोषणा नहीं करता। उस समय से लक्ष्य एजेंट का नॉलेज बेस उपलब्ध रहता है।
कॉल के पहली बार किसी एजेंट तक पहुँचने पर, वह उस एजेंट के `start_step` में शुरू होती है: स्टेप का `on_enter_tool` चलता है और उसका `say` बोला जाता है। जब कॉल किसी पहले देखे जा चुके एजेंट को वापस हैंडऑफ की जाती है, तो वह एजेंट बिना `on_enter_tool` चलाए, अपना `say` दोहराए या फिर से परिचय दिए बिना, उसी स्टेप से आगे बढ़ता है जिस पर वह था। एकत्रित वैल्यू कॉल के हर एजेंट के साथ साझा होती हैं।
- लक्ष्य उसी संगठन का एजेंट होना चाहिए, और कोई एजेंट खुद को हैंडऑफ नहीं कर सकता।
- कॉल-लेवल की हर सेटिंग उस एजेंट के साथ रहती है जिसने कॉल का जवाब दिया: प्रोडक्ट, भाषाएँ, पहले कौन बोलेगा, वॉइसमेल, सहमति घोषणा और अन्य सभी कॉल सेटिंग्स।
- लक्ष्य आगे और वापस हैंडऑफ कर सकते हैं। एक कॉल अधिकतम 8 एजेंटों तक पहुँच सकती है।
- एक टेस्ट कॉल उस एजेंट का ड्राफ्ट चलाती है जिसका आप टेस्ट करते हैं। जिन एजेंटों को वह हैंडऑफ करती है, वे अपने डिप्लॉय किए गए वर्ज़न चलाते हैं।
- यदि दो एजेंटों के पास एक ही नाम के लेकिन अलग परिभाषाओं वाले टूल हैं, तो कॉल के लिए केवल एक रखा जाता है, और जवाब देने वाले एजेंट का टूल हमेशा प्राथमिकता पाता है। सेव करने पर बिल्डर आपको चेतावनी देता है।
- किसी एजेंट के पास स्टेप्स के बिना हैंडऑफ हो सकते हैं। उसका पूरा प्रॉम्प्ट जैसा है वैसा ही उपयोग होता है।
स्टेप्स या हैंडऑफ वाले एजेंटों पर `go_to_step` और `hand_off` आरक्षित हैं, इसलिए आपके अपने टूल्स इन नामों का उपयोग नहीं कर सकते।
## कॉल पर इसे कहाँ देखें
कॉल को **कॉल हिस्ट्री** में खोलें। ट्रांसक्रिप्ट के पास एक स्टेप टाइमलाइन हर उस स्टेप को दिखाती है जिसमें कॉल पहुँची और उसका कारण बताती है, और इसके साथ एकत्रित वैल्यू सूचीबद्ध होती हैं।
[कॉल ऑब्जेक्ट](/api-reference/calls#retrieve-a-call) और कॉल-पूर्ण
वेबहुक ([`telephony.complete` / `web.complete`](/hi/webhooks/call-complete)) में
`steps_trace` और `collected_values` के रूप में वही डेटा होता है। स्टेप्स के बिना कॉल पर दोनों अनुपस्थित होते हैं।
```json
"steps_trace": [
{"t_ms": 0, "agent": "a412", "step": "greet", "via": "start"},
{"t_ms": 51230, "agent": "a412", "step": "verify", "via": "model"},
{"t_ms": 98410, "agent": "a412", "step": "minor", "via": "condition"}
],
"collected_values": {"full_name": "Dana Reyes", "dob": "2010-04-02", "age": 15}
```
`agent`, एजेंट ID से पहले लगा `a` होता है। `via` बताता है कि कॉल को किसने आगे बढ़ाया:
| `via` | अर्थ |
| --- | --- |
| `start` | कॉल इस स्टेप में शुरू हुई। |
| `model` | मॉडल ने `go_to_step`, `when` या `global_when` के माध्यम से स्टेप चुना। |
| `condition` | कोई `condition` या `always` ट्रांज़िशन मैच हुआ। |
| `on_enter` | किसी वेबहुक स्टेप के परिणाम पर एक ट्रांज़िशन मैच हुआ। |
| `handoff` | किसी अन्य एजेंट ने नियंत्रण संभाला। |
## स्टेप्स कहाँ चलते हैं
स्टेप्स **Spark**, **Bolt** और हर **Storm** प्रोडक्ट पर, इनबाउंड, आउटबाउंड और कैंपेन कॉल्स, टेस्ट कॉल्स, और वेब व विजेट कॉल्स में नेटिव रूप से चलते हैं।
अन्य सभी जगह एजेंट फिर भी काम करता है, बस संरचना के बिना: वह एक फ्लैट प्रॉम्प्ट चलाता है जो साझा निर्देशों और हर स्टेप को क्रम में मर्ज करता है। इसमें शामिल हैं:
- प्रयोगात्मक Bolt प्रोडक्ट्स;
- [Realtime](/hi/guides/use-with-openai-realtime) सेशन, जिनमें सेव किए गए एजेंट के सेशन भी शामिल हैं;
- [डायनामिक कॉल कॉन्फ़िगरेशन](/hi/guides/dynamic-call-config) वेबहुक द्वारा लौटाए गए इनलाइन कॉन्फ़िगरेशन। `agent_id` लौटाने वाला वेबहुक उस एजेंट के स्टेप्स का उपयोग करता है।
## सीमाएं
| सीमा | मान |
| --- | --- |
| प्रति एजेंट चरण | 100 |
| प्रति चरण एकत्र किए गए मान | 20 |
| प्रति एजेंट हैंडऑफ टारगेट | 8 |
| एक कॉल में पहुंच योग्य एजेंट | 8 |
| `steps` JSON का आकार | 200 KB |
| चरण `instructions` | 20,000 वर्ण |
| `say` लाइन | 1,000 वर्ण |
| स्टोर किया गया `on_enter_tool` परिणाम | 4 KB |
किसी नियम को तोड़ने वाला सेव खराब फ़ील्ड के पथ के साथ `400` लौटाता है, जैसे
`steps.steps[2].transitions[0].to`। `tools` और `on_enter_tool` में टूल नाम एजेंट से जुड़े टूल होने चाहिए।
प्रति-चरण भाषाएं, मॉडल को स्किप करने वाले स्क्रिप्टेड चरण, और say लाइनों के अंदर एकत्र किए गए मान समर्थित नहीं हैं।
## इंपोर्ट किए गए एजेंट
Retell, Bland, Vapi या ElevenLabs से [इंपोर्ट करना](/hi/guides/import-agents)
मल्टी-प्रॉम्प्ट एजेंट, फ्लो, पाथवे और वर्कफ़्लो को चरणों के रूप में, और स्क्वाड्स व एजेंट ट्रांसफ़र को इंपोर्ट किए गए एजेंटों के बीच हैंडऑफ के रूप में लाता है। इंपोर्ट करने से पहले रिव्यू पेज दोनों दिखाता है।
## उदाहरण: डेंटल इंटेक
क्रम में तीन चरण: अभिवादन, मरीज की जानकारी एकत्र करना, बुक करना।
```json
{
"prompt": "You are Ava, the front desk assistant at Acme Dental. Be warm and brief. Ask one question at a time.",
"steps": {
"start_step": "greet",
"steps": [
{
"id": "greet",
"name": "Greeting",
"instructions": "Greet the caller and ask how you can help.",
"say": "Thanks for calling Acme Dental, this is Ava. How can I help you today?",
"tools": null,
"collect": [],
"transitions": [
{"to": "details", "when": "The caller wants to book an appointment"}
]
},
{
"id": "details",
"name": "Patient details",
"instructions": "Ask for the caller's full name, date of birth and the reason for the visit. Read the date of birth back and ask the caller to confirm it.",
"tools": null,
"collect": [
{"name": "full_name", "type": "string", "description": "Caller's full name", "required": true},
{"name": "dob", "type": "date", "description": "Date of birth", "required": true},
{"name": "reason", "type": "string", "description": "Reason for the visit", "required": true},
{"name": "new_patient", "type": "boolean", "description": "First visit to the practice", "required": false}
],
"transitions": [
{"to": "book", "when": "The caller has confirmed their details"}
]
},
{
"id": "book",
"name": "Book",
"instructions": "Offer the two earliest open slots from book_slot and book the one the caller picks. Confirm the date and time, then say goodbye and end the call.",
"tools": ["book_slot"],
"collect": [],
"transitions": []
}
]
}
}
```
इसे `PATCH /v1/agents/{agent_id}` के साथ स्टेज करें, **Talk** से आज़माएं, फिर डिप्लॉय करें।
नाम, जन्म तिथि और कारण एकत्र होने तक `details` चरण बुकिंग को हैंडऑफ नहीं कर सकता; `new_patient` वैकल्पिक है।
## उदाहरण: आयु-आधारित ब्रांच
मॉडल किसी से भी बात कर सकता है, लेकिन किसकी बुकिंग होगी यह कोड तय करता है। आयु एकत्र करें, फिर मॉडल के अपने चयन पर विचार करने से पहले उसके आधार पर रूट करें।
```json
{
"id": "verify",
"name": "Verify age",
"instructions": "Ask for the caller's age.",
"tools": null,
"collect": [
{"name": "age", "type": "number", "description": "Caller's age in years", "required": true}
],
"transitions": [
{"to": "guardian", "condition": {"value": "age", "op": "lt", "target": 18}},
{"to": "book", "when": "The caller has given their age"}
]
}
```
पंद्रह कहने वाला कॉलर `guardian` पर जाता है, चाहे मॉडल कुछ भी तय करे।
बाकी सभी `book` पर जाते हैं। दोनों ग्राफ़ में अन्यत्र सामान्य चरण हैं।
## उदाहरण: अकाउंट लुकअप वेबहुक स्टेप
कॉलर अकाउंट नंबर देता है, अगले स्टेप में प्रवेश करते ही लुकअप चलता है,
और उसका परिणाम रूट चुनता है। संक्षिप्तता के लिए `not_found`, `collections` और `support`
स्टेप छोड़े गए हैं।
```json
[
{
"id": "identify",
"name": "Identify",
"instructions": "Ask for the caller's account number and read it back digit by digit.",
"tools": null,
"collect": [
{"name": "account_number", "type": "string", "description": "Account number", "required": true}
],
"transitions": [
{"to": "lookup", "when": "The caller has confirmed their account number"}
]
},
{
"id": "lookup",
"name": "Look up account",
"instructions": "Tell the caller what you found on their account and ask how you can help.",
"tools": ["lookup_account"],
"collect": [],
"on_enter_tool": "lookup_account",
"transitions": [
{"to": "not_found", "condition": {"value": "lookup_account_result.response.found", "op": "eq", "target": false}},
{"to": "collections", "condition": {"value": "lookup_account_result.response.account_status", "op": "in", "target": ["past_due", "suspended"]}},
{"to": "support", "when": "The caller needs help with an active account"}
]
}
]
```
`lookup_account` को `account_number` मिलता है क्योंकि उसके पैरामीटर का वही
नाम है। अगर रिस्पॉन्स बॉडी में `"found": false` है, तो कॉल
`not_found` पर जाती है। अगर उसका `account_status` `past_due` या `suspended` है, तो वह
`collections` पर जाती है। एक सक्रिय अकाउंट `lookup` में रहता है, जहाँ मॉडल सहायता करता है और
फिर `support` पर आगे बढ़ता है। विफल लुकअप को उसके अपने स्टेप पर भेजने के लिए,
पहले स्टेटस पर कंडीशन जोड़ें: एरर रिस्पॉन्स अपना स्टेटस कोड स्टोर करता है, इसलिए
`{"value": "lookup_account_result.status", "op": "gte", "target": 400}`
उसे कैच करता है, और टाइमआउट या कोई जवाब न मिलने पर `"error"` स्टोर होता है, इसलिए
`{"value": "lookup_account_result.status", "op": "eq", "target": "error"}`
उसे कैच करता है।
## उदाहरण: फ्रंट डेस्क से बिलिंग
दो एजेंट। फ्रंट डेस्क (एजेंट `412`) हर कॉल का जवाब देता है और बिलिंग
सवालों को अपने प्रॉम्प्ट, टूल्स और वॉइस वाले बिलिंग एजेंट (एजेंट `413`) को हैंडऑफ करता है।
फ्रंट डेस्क पर:
```json
{
"handoffs": [
{"agent_id": 413, "when": "The caller asks about a bill, a payment or a refund"}
]
}
```
बिलिंग एजेंट पर, ताकि वह कॉलर को वापस हैंडऑफ कर सके:
```json
{
"handoffs": [
{"agent_id": 412, "when": "The billing question is resolved and the caller needs something else"}
]
}
```
फ्रंट डेस्क एक छोटी पंक्ति कहता है, जैसे "मैं आपको हमारी बिलिंग
टीम से जोड़ता हूँ", और बिलिंग एजेंट अपना परिचय देता है और बातचीत को
वहीं से आगे बढ़ाता है जहाँ फ्रंट डेस्क ने छोड़ा था। जब बिलिंग वापस हैंडऑफ करता है, तो फ्रंट डेस्क
कॉलर का फिर से अभिवादन किए बिना वहीं से जारी रखता है जहाँ वह था। कॉल का प्रोडक्ट,
भाषाएँ, सहमति घोषणा और अन्य कॉल सेटिंग्स फ्रंट डेस्क के साथ रहती हैं,
क्योंकि उसी ने जवाब दिया था।
अगर बिलिंग को केवल अपने निर्देश चाहिए, अपना एजेंट नहीं, तो इसके बजाय फ्रंट डेस्क पर
ग्लोबल स्टेप इस्तेमाल करें। सवाल का जवाब मिलने पर, कॉल उस स्टेप पर वापस जाती है
जिसमें कॉलर था:
```json
{
"id": "billing",
"name": "Billing questions",
"instructions": "Answer questions about bills and payments. Offer to send a payment link by email.",
"tools": null,
"collect": [],
"transitions": [
{"to": "__previous__", "when": "The billing question is answered"}
],
"global_when": "The caller asks about a bill or payment at any point"
}
```
## अगले चरण
साझा निर्देश और चरण निर्देश लिखें जो फोन पर भी प्रभावी रहें।
वे टूल बनाएं जिन्हें आपके चरण और वेबहुक चरण कॉल करते हैं।
डिप्लॉय करने से पहले हर ब्रांच पर समान सिनेरियो चलाएं।
हर एजेंट फ़ील्ड, ड्राफ्ट और डिप्लॉय।