--- title: "एजंट पायऱ्या आणि हस्तांतरे" description: "एजंटला स्वतःच्या सूचना, साधने आणि संकलित मूल्यांसह पायऱ्यांमध्ये विभाजित करा आणि कॉलदरम्यान एजंट्समध्ये कॉल हस्तांतरित करा." --- एकच prompt मॉडेलला संपूर्ण काम एकाच वेळी देतो. **टप्पे** त्याला कॉलचा एका वेळी एक टप्पा देतात: प्रत्येक टप्प्याच्या स्वतःच्या सूचना, स्वतःची टूल्स, शब्दशः बोलली जाणारी पर्यायी ओळ आणि पुढे जाण्यापूर्वी गोळा करायची मूल्ये असतात. **हस्तांतरणे** तुमच्या संस्थेतील दुसऱ्या एजंटला कॉलच्या मधोमध, ट्रान्स्क्रिप्ट जशीच्या तशी ठेवून, जबाबदारी घेऊ देतात, त्यामुळे कॉलरला स्वतःची माहिती पुन्हा सांगावी लागत नाही. प्रत्येक एजंट एकाच prompt ने सुरू होतो. तुम्ही टप्पे किंवा हस्तांतरणे जोडेपर्यंत त्यात काहीही बदलत नाही. ## टप्पे की एकच prompt? | टप्पे कधी वापरावेत | एकच prompt कधी ठेवावा | | --- | --- | | कॉलमध्ये क्रमाने होणारे टप्पे असतात: आधी पडताळणी, मग बुकिंग. | संभाषण खुले असते: FAQ, रिसेप्शन, सामान्य सपोर्ट. | | एजंट पुढे जाण्यापूर्वी एखादे मूल्य कॅप्चर करणे आवश्यक असते. | ठराविक क्रमाने काहीही गोळा करण्याची गरज नसते. | | एखादा नियम कधीही वाकता कामा नये, जसे की "18 वर्षांखालील कॉलरना पालकाकडे पाठवा". | प्रत्येक शाखेसाठी मॉडेलचा निर्णय पुरेसा चांगला असतो. | | कॉलमधील ठराविक बिंदूवर लुकअप चालवणे आवश्यक असते. | कॉलरने विचारल्यावर कधीही टूल्स कॉल करता येतात. | | कॉलचा काही भाग वेगळ्या एजंटचा असतो, ज्याचा स्वतःचा prompt आणि व्हॉइस असतो. | एकच व्यक्तिमत्त्व सर्वकाही हाताळते. | टप्पे म्हणजे स्क्रिप्ट केलेली फोन ट्री नाही. एका टप्प्यात मॉडेल एकाच prompt प्रमाणे संभाषण चालवते. टप्पा ते कशावर काम करत आहे, कोणती टूल्स वापरू शकते आणि तो सोडण्यापूर्वी त्याला काय आवश्यक आहे हे ठरवतो. ## टप्प्यांनुसार एजंट कसा तयार केला जातो एजंटमध्ये टप्पे असतील तेव्हा त्याचा `prompt` **सामायिक सूचना** ठेवतो: प्रत्येक टप्प्याला लागू होणारे व्यक्तिमत्त्व आणि नियम. प्रत्येक टप्पा त्यावर स्वतःच्या सूचना जोडतो. प्रत्येक टर्नमध्ये मॉडेलला सामायिक सूचना, सध्याच्या टप्प्याचे नाव आणि सूचना तसेच आतापर्यंत गोळा केलेली मूल्ये दिसतात. बिल्डरमध्ये एजंटला **एकच prompt** वरून **टप्पे** वर बदला. तुम्हाला प्रत्येक टप्प्यासाठी त्याचे नाव, सूचना, बोलायची ओळ, टूल्स, गोळा केलेली मूल्ये आणि ट्रान्झिशन्स असलेले कार्ड, हस्तांतरण निवडक आणि टप्प्यांचा फक्त-वाचनीय फ्लो ग्राफ मिळेल. पुन्हा एकाच prompt वर बदलल्यावर सामायिक सूचना आणि प्रत्येक टप्पा एकत्र करणारा एकत्रित prompt दिला जातो. API मध्ये `steps` आणि `handoffs` ही [एजंट](/api-reference/agents) वरील फील्ड्स आहेत. प्रत्येक एजंट फील्डप्रमाणे, `PATCH` त्यांना मसुद्यात स्टेज करते; `POST /v1/agents/{agent_id}/deploy` त्यांना लाइव्ह करते. `"steps": null` पाठवल्यास एजंट पुन्हा एकाच prompt वर बदलतो. चाचणी कॉल्स आणि **संवाद** मसुदा चालवतात. [कोपायलट](/mr/guides/ask-the-copilot) वर्णनावरून टप्पे तयार करू शकतो ("बुकिंगपूर्वी जन्मतारीख पडताळणारा टप्पा जोडा") आणि इतरांना न बदलता एक टप्पा संपादित करू शकतो. ### टप्पा फील्ड्स | फील्ड | अर्थ | | --- | --- | | `id` | आवश्यक. लहान अक्षरे, अंक आणि अंडरस्कोअर, अक्षराने सुरू होणारे, जास्तीत जास्त 40 वर्ण. एजंटमध्ये अद्वितीय. | | `name` | आवश्यक प्रदर्शन नाव, 1 ते 80 वर्ण. | | `instructions` | आवश्यक, जास्तीत जास्त 20,000 वर्ण. `prompt` प्रमाणे `{{var}}` [कॉल व्हेरिएबल्स](/mr/guides/call-variables) समर्थित आहेत. | | `say` | टप्प्यात प्रवेश करताना शब्दशः बोलली जाणारी पर्यायी ओळ, जास्तीत जास्त 1,000 वर्ण. `{{var}}` समर्थित आहे. | | `tools` | `null` टप्प्याला एजंटशी जोडलेले प्रत्येक टूल देते. सूची टप्प्याला नावानुसार त्या टूल्सपुरते मर्यादित करते. `end_call` आणि `transfer_call` सारख्या अंगभूत क्रिया प्रत्येक टप्प्यात एजंटच्या सेटिंग्जचे पालन करतात. | | `collect` | टप्पा गोळा करत असलेली जास्तीत जास्त 20 मूल्ये. प्रत्येकाचे `name`, `type`, `description` आणि `required` (डीफॉल्ट `true`) असते. | | `on_enter_tool` | पर्यायी टूलचे नाव, टप्प्यात प्रवेश करताना आपोआप कॉल केले जाते. [वेबहुक टप्पे](#webhook-steps) पहा. | | `transitions` | टप्पा पुढे कुठे जाऊ शकतो याची क्रमबद्ध सूची. [ट्रान्झिशन्स](#transitions) पहा. | | `global_when` | पर्यायी. टप्पा कोणत्याही टप्प्यातून उपलब्ध करते. [जागतिक टप्पे](#global-steps) पहा. | | `voice` | या टप्प्यासाठी पर्यायी व्हॉइस आयडी. एजंट सानुकूल व्हॉइस कॉन्फिगरेशन वापरत असल्यास दुर्लक्षित केले जाते. | ग्राफ स्वतः `{"start_step": "", "steps": [...]}` असा असतो. कॉल `start_step` मध्ये सुरू होतो. ## ट्रान्झिशन्स प्रत्येक ट्रान्झिशनमध्ये `to`, एक स्टेप id, आणि खालीलपैकी नेमके एक असते: - **`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` वगळता प्रत्येक op साठी असत्य ठरते. `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` वापरा आणि उर्वरित उत्तर मॉडेलवर सोडा. संमतीची कोणतीही घोषणा झाल्यानंतर, एजंट प्रथम बोलत असल्यास प्रारंभिक स्टेपचे `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` ही अंतर्गत राउटिंग नोंद असते; ती कधीही मोठ्याने वाचली जात नाही. हस्तांतरण करताना, एजंट कॉलरला ते कुठे जात आहेत हे सांगणारे एक छोटे वाक्य स्वतःच्या आवाजात बोलतो, जसे की "नक्की, मी तुम्हाला आमच्या बिलिंग टीमकडे जोडतो". त्यानंतर लक्ष्य एजंटचा prompt, स्टेप्स, टूल्स आणि आवाज ताबा घेतात व कॉल त्याच ट्रान्स्क्रिप्टसह सुरू राहतो. नवीन एजंट थोडक्यात स्वतःची ओळख करून देतो आणि कॉलरच्या शेवटच्या विनंतीला उत्तर देतो; तो हस्तांतरणाची घोषणा करत नाही. त्या क्षणापासून लक्ष्य एजंटचा नॉलेज बेस उपलब्ध असतो. कॉल प्रथमच एखाद्या एजंटपर्यंत पोहोचल्यावर, तो त्या एजंटच्या `start_step` मध्ये सुरू होतो: स्टेपचे `on_enter_tool` चालते आणि त्याचे `say` बोलले जाते. कॉल यापूर्वी भेट दिलेल्या एजंटकडे परत हस्तांतरित झाल्यास, तो एजंट `on_enter_tool` न चालवता, त्याचे `say` पुन्हा न बोलता किंवा स्वतःची पुन्हा ओळख न करून देता, तो ज्या स्टेपवर होता ती पुन्हा सुरू करतो. गोळा केलेली मूल्ये कॉलवरील प्रत्येक एजंटसह शेअर केली जातात. - लक्ष्य एजंट त्याच संस्थेतील असणे आवश्यक आहे आणि एजंट स्वतःकडे हस्तांतरण करू शकत नाही. - कॉल-स्तरीय सर्वकाही उत्तर देणाऱ्या एजंटकडेच राहते: उत्पादन, भाषा, प्रथम कोण बोलते, व्हॉइसमेल, संमती घोषणा आणि कॉलची इतर प्रत्येक सेटिंग. - लक्ष्य एजंट पुढे आणि परत हस्तांतरण करू शकतात. एका कॉलमध्ये कमाल 8 एजंटपर्यंत पोहोचता येते. - चाचणी कॉल तुम्ही चाचणी करत असलेल्या एजंटचा ड्राफ्ट चालवतो. तो ज्या एजंटकडे हस्तांतरण करतो ते एजंट त्यांच्या डिप्लॉय केलेल्या आवृत्त्या चालवतात. - दोन एजंटकडे एकाच नावाचे पण वेगळ्या व्याख्यांचे टूल असल्यास, कॉलसाठी फक्त एकच ठेवले जाते आणि उत्तर देणाऱ्या एजंटचे टूल नेहमी प्राधान्य पावते. तुम्ही सेव्ह करताना बिल्डर तुम्हाला इशारा देतो. - एजंटकडे स्टेप्स नसतानाही हस्तांतरणे असू शकतात. त्याचा संपूर्ण prompt जसा आहे तसाच वापरला जातो. `go_to_step` आणि `hand_off` ही नावे स्टेप्स किंवा हस्तांतरणे असलेल्या एजंटसाठी राखीव आहेत, त्यामुळे तुमची स्वतःची टूल्स ही नावे वापरू शकत नाहीत. ## कॉलवर ते कुठे पाहायचे **कॉल इतिहास** मध्ये कॉल उघडा. ट्रान्स्क्रिप्टच्या शेजारील स्टेप टाइमलाइन कॉलने प्रविष्ट केलेली प्रत्येक स्टेप आणि त्याचे कारण दाखवते, तसेच गोळा केलेली मूल्ये त्यासोबत सूचीबद्ध असतात. [कॉल ऑब्जेक्ट](/api-reference/calls#retrieve-a-call) आणि कॉल-पूर्ण वेबहुक ([`telephony.complete` / `web.complete`](/mr/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` म्हणजे एजंट आयडीच्या आधीचे `a`. `via` कॉल कशामुळे पुढे गेला ते सांगते: | `via` | अर्थ | | --- | --- | | `start` | कॉल या स्टेपमध्ये सुरू झाला. | | `model` | मॉडेलने `go_to_step`, `when` किंवा `global_when` द्वारे स्टेप निवडली. | | `condition` | `condition` किंवा `always` ट्रान्झिशन जुळले. | | `on_enter` | वेबहुक स्टेपच्या परिणामावर ट्रान्झिशन जुळले. | | `handoff` | दुसऱ्या एजंटने ताबा घेतला. | ## स्टेप्स कुठे चालतात स्टेप्स **Spark**, **Bolt** आणि प्रत्येक **Storm** उत्पादनावर, इनबाउंड, आउटबाउंड आणि कॅम्पेन कॉल्सवर, चाचणी कॉल्सवर तसेच वेब आणि विजेट कॉल्सवर नेटिव्हपणे चालतात. इतर सर्व ठिकाणी एजंट तरीही कार्य करतो, फक्त संरचनेशिवाय: तो शेअर केलेल्या सूचना आणि प्रत्येक स्टेप क्रमाने एकत्र करणारा सपाट prompt चालवतो. यात समाविष्ट आहे: - प्रायोगिक Bolt उत्पादने; - सेव्ह केलेल्या एजंटसाठीच्या सेशनसह [Realtime](/mr/guides/use-with-openai-realtime) सेशन्स; - [डायनॅमिक कॉल कॉन्फिग](/mr/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 वरून [इम्पोर्ट केल्यास](/mr/guides/import-agents) अनेक-prompt एजंट, फ्लो, मार्ग आणि वर्कफ्लो पायऱ्या म्हणून, तसेच स्क्वॉड्स आणि एजंट ट्रान्सफर इम्पोर्ट केलेल्या एजंटमधील हँडऑफ म्हणून येतात. तुम्ही इम्पोर्ट करण्यापूर्वी पुनरावलोकन पृष्ठ दोन्ही दाखवते. ## उदाहरण: दंतवैद्यकीय माहिती संकलन क्रमाने तीन पायऱ्या: अभिवादन करा, रुग्णाचा तपशील गोळा करा, बुक करा. ```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}` सह स्टेज करा, **बोला** वापरून तपासा, नंतर डिप्लॉय करा. नाव, जन्मतारीख आणि कारण गोळा होईपर्यंत `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`) प्रत्येक कॉलला उत्तर देतो आणि बिलिंगशी संबंधित प्रश्न त्याच्या स्वतंत्र prompt, टूल्स आणि आवाज असलेल्या बिलिंग एजंटकडे (एजंट `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" } ``` ## पुढील पायऱ्या फोनवर प्रभावीपणे काम करणाऱ्या सामायिक सूचना आणि पायरीच्या सूचना लिहा. तुमच्या पायऱ्या आणि webhook पायऱ्या कॉल करतात ती टूल्स तयार करा. deploy करण्यापूर्वी प्रत्येक शाखेवर समान परिस्थिती चालवा. प्रत्येक एजंट फील्ड, draft आणि deploy.