एजंट पायऱ्या आणि हस्तांतरे

एजंटला स्वतःच्या सूचना, साधने आणि संकलित मूल्यांसह पायऱ्यांमध्ये विभाजित करा आणि कॉलदरम्यान एजंट्समध्ये कॉल हस्तांतरित करा.

एकच prompt मॉडेलला संपूर्ण काम एकाच वेळी देतो. टप्पे त्याला कॉलचा एका वेळी एक टप्पा देतात: प्रत्येक टप्प्याच्या स्वतःच्या सूचना, स्वतःची टूल्स, शब्दशः बोलली जाणारी पर्यायी ओळ आणि पुढे जाण्यापूर्वी गोळा करायची मूल्ये असतात. हस्तांतरणे तुमच्या संस्थेतील दुसऱ्या एजंटला कॉलच्या मधोमध, ट्रान्स्क्रिप्ट जशीच्या तशी ठेवून, जबाबदारी घेऊ देतात, त्यामुळे कॉलरला स्वतःची माहिती पुन्हा सांगावी लागत नाही.

प्रत्येक एजंट एकाच prompt ने सुरू होतो. तुम्ही टप्पे किंवा हस्तांतरणे जोडेपर्यंत त्यात काहीही बदलत नाही.

टप्पे की एकच prompt?#

टप्पे म्हणजे स्क्रिप्ट केलेली फोन ट्री नाही. एका टप्प्यात मॉडेल एकाच prompt प्रमाणे संभाषण चालवते. टप्पा ते कशावर काम करत आहे, कोणती टूल्स वापरू शकते आणि तो सोडण्यापूर्वी त्याला काय आवश्यक आहे हे ठरवतो.

टप्प्यांनुसार एजंट कसा तयार केला जातो#

एजंटमध्ये टप्पे असतील तेव्हा त्याचा prompt सामायिक सूचना ठेवतो: प्रत्येक टप्प्याला लागू होणारे व्यक्तिमत्त्व आणि नियम. प्रत्येक टप्पा त्यावर स्वतःच्या सूचना जोडतो. प्रत्येक टर्नमध्ये मॉडेलला सामायिक सूचना, सध्याच्या टप्प्याचे नाव आणि सूचना तसेच आतापर्यंत गोळा केलेली मूल्ये दिसतात.

बिल्डरमध्ये एजंटला एकच prompt वरून टप्पे वर बदला. तुम्हाला प्रत्येक टप्प्यासाठी त्याचे नाव, सूचना, बोलायची ओळ, टूल्स, गोळा केलेली मूल्ये आणि ट्रान्झिशन्स असलेले कार्ड, हस्तांतरण निवडक आणि टप्प्यांचा फक्त-वाचनीय फ्लो ग्राफ मिळेल. पुन्हा एकाच prompt वर बदलल्यावर सामायिक सूचना आणि प्रत्येक टप्पा एकत्र करणारा एकत्रित prompt दिला जातो.

API मध्ये steps आणि handoffs ही एजंट वरील फील्ड्स आहेत. प्रत्येक एजंट फील्डप्रमाणे, PATCH त्यांना मसुद्यात स्टेज करते; POST /v1/agents/{agent_id}/deploy त्यांना लाइव्ह करते. "steps": null पाठवल्यास एजंट पुन्हा एकाच prompt वर बदलतो. चाचणी कॉल्स आणि संवाद मसुदा चालवतात.

टप्पा फील्ड्स#

ग्राफ स्वतः {"start_step": "<step id>", "steps": [...]} असा असतो. कॉल start_step मध्ये सुरू होतो.

ट्रान्झिशन्स#

प्रत्येक ट्रान्झिशनमध्ये to, एक स्टेप id, आणि खालीलपैकी नेमके एक असते:

• when: साध्या भाषेतील अट, आणि मॉडेल निर्णय घेते. एजंटला अंगभूत go_to_step टूल मिळते, ज्यामध्ये तो ज्या स्टेप्सकडे जाऊ शकतो त्या सूचीबद्ध असतात आणि प्रत्येक when ती निवडण्याचे कारण असते.
• condition: गोळा केलेल्या मूल्यांवरील नियम, आणि कोड निर्णय घेतो. मॉडेल ते वगळू शकत नाही किंवा बोलून त्यातून मार्ग काढू शकत नाही.
• "always": true: तपासणीशिवाय पुढे जा. कोड आधी निर्णय घेतो: एखाद्या स्टेपमध्ये प्रवेश करताच किंवा तिची आवश्यक मूल्ये गोळा झाल्यावर, मॉडेलला when निवडण्यापूर्वी जुळणारे पहिले condition किंवा always ट्रान्झिशन लागू होते. त्यामुळे always हे अटींनंतर त्यांचा फॉलबॅक म्हणून ठेवा किंवा स्टेपला थेट पुढील स्टेपशी जोडण्यासाठी ते एकटे ठेवा. always असलेली स्टेप कधीही when निवडीची वाट पाहत नाही.

condition हे {"value": <collected name or dotted path>, "op": <op>, "target": <literal>} असे असते:

eq, ne, in आणि not_in रिकाम्या जागा काढल्यानंतर मजकुराची मोठ्या-लहान अक्षरांकडे दुर्लक्ष करून तुलना करतात. संख्यांची तुलना संख्या म्हणून आणि तारखांची तुलना YYYY-MM-DD स्ट्रिंग म्हणून होते. कधीही गोळा न केलेले मूल्य missing वगळता प्रत्येक op साठी असत्य ठरते.

when आणि global_when हे बोलायच्या मजकुराप्रमाणे नव्हे तर, उदाहरणार्थ "कॉलरला अपॉइंटमेंट बुक करायची आहे" अशा अटीप्रमाणे लिहा. एजंट त्यांना अंतर्गत रूटिंग नोट्स म्हणून पाहतो आणि त्या कधीही वाचून दाखवू नयेत किंवा तो स्टेप्स बदलत असल्याचा उल्लेख करू नये, असे त्याला सांगितले जाते.

मॉडेल go_to_step कॉल करते तेव्हा:

1. स्टेपमधील प्रत्येक required मूल्य उपस्थित असणे आवश्यक आहे. एखादे मूल्य नसल्यास, मॉडेलला कोणते मूल्य नाही ते सांगितले जाते आणि ते कॉलरकडे विचारते.
2. मूल्ये साठवली जातात.
3. condition आणि always ट्रान्झिशन्सची क्रमाने तपासणी होते. पहिले जुळणारे लागू होते.
4. अन्यथा एजंट मॉडेलने निवडलेल्या स्टेपकडे जातो.
5. काहीही जुळले नाही आणि मॉडेलने कोणत्याही स्टेपचे नाव दिले नाही, तर एजंट त्याच ठिकाणी राहतो.

जागतिक स्टेपकडे जाणे हा अपवाद आहे: कॉलरने विषय बदलला आहे, म्हणून सध्याच्या स्टेपची आवश्यक मूल्ये अद्याप नसली तरी आणि त्या स्टेपच्या अटी तपासण्यापूर्वीही ते पुढे जाते.

स्टेपमध्ये प्रत्येक वेळी प्रवेश केल्यावर condition आणि always ट्रान्झिशन्सचीही तपासणी होते, त्यामुळे कोडने ठरवलेल्या स्टेप्सची मालिका एकाच वेळी पूर्ण होते. ही मालिका थांबते:

• या रनमध्ये आधीच भेट दिलेल्या स्टेपवर;
• 8 हॉप्सनंतर;
• अजून आवश्यक मूल्ये गोळा करायची असलेल्या स्टेपवर, जोपर्यंत त्या स्टेपमध्ये on_enter_tool नाही (वेबहुक स्टेप नेहमी तिच्या निकालावर रूट होते).

मालिका ज्या स्टेपवर थांबते, त्या स्टेपची फक्त say ओळ बोलली जाते.

ट्रान्झिशन्स नसलेली स्टेप अंतिम असते. एजंट तेथे पूर्ण करतो आणि त्याच्या नेहमीच्या अंगभूत कृतींसह कॉल समाप्त करतो किंवा ट्रान्सफर करतो.

मूल्ये गोळा करणे#

स्टेपला काय आवश्यक आहे ते collect मध्ये सूचीबद्ध करा. मॉडेल go_to_step कॉल करताना मूल्ये पाठवते आणि ती उर्वरित कॉलसाठी उपलब्ध राहतात.

गोळा केलेली मूल्ये कॉलची सामग्री असतात. ती कॉलमध्ये ट्रान्सक्रिप्टच्या शेजारी दिसतात आणि त्यांना तेच रिटेन्शन, डिलीशन आणि रिडॅक्शन नियम लागू होतात. एजंटचे कॉल रेकॉर्डिंग बंद केल्यावर, गोळा केलेली मूल्ये साठवली जात नाहीत किंवा वेबहुकमध्ये पाठवली जात नाहीत; मात्र स्टेप टाइमलाइन राहते. पहा कॉलवर ते कुठे पाहायचे.

Say ओळी#

एजंट स्टेपमध्ये प्रवेश करताच say मध्ये जसे लिहिले आहे तसेच बोलले जाते. त्यानंतर मॉडेलला ती ओळ नुकतीच बोलली गेली आहे हे माहीत असल्याने, ते त्याच उत्तरात नवीन स्टेप पुढे चालू ठेवते आणि ती ओळ पुन्हा बोलत नाही. अभिवादन, आवश्यक प्रकटीकरणे आणि निश्चित शब्दरचनेसाठी say वापरा आणि उर्वरित उत्तर मॉडेलवर सोडा.

संमतीची कोणतीही घोषणा झाल्यानंतर, एजंट प्रथम बोलत असल्यास प्रारंभिक स्टेपचे say हे एजंटचे उद्घाटन वाक्य असते. कॉलर प्रथम बोलल्यास, ते एजंटचे एखाद्या व्यक्तीला दिलेले पहिले उत्तर सुरू करते; IVR किंवा व्हॉइसमेल अभिवादनाला कधीही नाही.

कॉल __previous__ किंवा परत हस्तांतरणाद्वारे त्या स्टेपवर परतल्यास, स्टेपचे say पुन्हा बोलले जात नाही. ते जसे ऐकू यावे तसे लिहा: व्हॉइस चुकीचे वाचू शकतो असे सर्व काही पूर्णपणे लिहा. Say ओळी {{var}} कॉल व्हेरिएबल्सना समर्थन देतात, पण संकलित मूल्यांना नाही.

Webhook स्टेप्स#

on_enter_tool एजंटच्या टूल्सपैकी एकावर सेट करा; स्टेपमध्ये प्रवेश होताच ते मॉडेलची वाट न पाहता चालते. त्याचे आर्ग्युमेंट्स ही अशी संकलित मूल्ये असतात ज्यांची नावे टूलच्या पॅरामीटर नावांशी जुळतात. निकाल <tool>_result नावाच्या संकलित मूल्यासारखा जतन केला जातो, 4 KB पर्यंत संक्षिप्त केला जातो आणि स्टेपचे condition व always ट्रांझिशन्स त्वरित तपासले जातात, त्यामुळे लुकअप त्याच्या स्वतःच्या निकालावरून कॉलला मार्गस्थ करू शकतो.

जतन केलेल्या मूल्यात दोन फील्ड असतात:

बॉडी फील्डनुसार मार्गस्थ करण्यासाठी lookup_account_result.response.<field> वापरा आणि स्टेटस कोडनुसार मार्गस्थ करण्यासाठी lookup_account_result.status वापरा.

लुकअप जास्तीत जास्त 8 सेकंद चालतो किंवा टूलचा स्वतःचा टाइमआउट कमी असल्यास तेवढाच चालतो. त्याला 3 सेकंदांपेक्षा जास्त वेळ लागल्यास, कॉलरला शांततेत ठेवले जाऊ नये म्हणून एजंट एक छोटी ओळ बोलतो. तुमचा एंडपॉइंट 400 किंवा त्यापेक्षा जास्त स्टेटस परत करत असल्यास किंवा वेळेत उत्तर देत नसल्यास, एजंट कॉलरला सांगतो की तो आत्ता ते तपासू शकला नाही आणि जे शक्य आहे ते पुढे चालू ठेवतो.

ग्लोबल स्टेप्स#

global_when असलेली स्टेप हे वर्णन लागू असेल तेव्हा कोणत्याही स्टेपमधून गाठता येते. when प्रमाणेच निर्णय मॉडेल घेते. कॉलर कोणत्याही वेळी उपस्थित करू शकणाऱ्या विषयांसाठी याचा वापर करा: बिलिंगविषयक प्रश्न, एखाद्या व्यक्तीशी बोलण्याची विनंती, तक्रार.

ग्लोबल स्टेपवर "to": "__previous__" असलेले ट्रांझिशन कॉलला त्यापूर्वी सक्रिय असलेल्या स्टेपवर परत घेऊन जाते, त्यामुळे कॉलर जिथे थांबला होता तिथून पुढे सुरू करू शकतो. स्टेप पुन्हा सुरू होते: तिचे on_enter_tool पुन्हा चालत नाही, तिचे say पुन्हा बोलले जात नाही आणि एजंट ती सुरुवातीपासून सुरू न करता पुढे चालू ठेवतो.

हस्तांतरणे#

handoffs तुमच्या संस्थेतील इतर एजंटची सूची देते जे कॉल ताब्यात घेऊ शकतात:

[{"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 ही नावे स्टेप्स किंवा हस्तांतरणे असलेल्या एजंटसाठी राखीव आहेत, त्यामुळे तुमची स्वतःची टूल्स ही नावे वापरू शकत नाहीत.

कॉलवर ते कुठे पाहायचे#

कॉल इतिहास मध्ये कॉल उघडा. ट्रान्स्क्रिप्टच्या शेजारील स्टेप टाइमलाइन कॉलने प्रविष्ट केलेली प्रत्येक स्टेप आणि त्याचे कारण दाखवते, तसेच गोळा केलेली मूल्ये त्यासोबत सूचीबद्ध असतात.

कॉल ऑब्जेक्ट आणि कॉल-पूर्ण वेबहुक (telephony.complete / web.complete) मध्ये steps_trace आणि collected_values म्हणून तोच डेटा असतो. स्टेप्स नसलेल्या कॉलवर दोन्ही अनुपस्थित असतात.

"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 कॉल कशामुळे पुढे गेला ते सांगते:

स्टेप्स कुठे चालतात#

स्टेप्स Spark, Bolt आणि प्रत्येक Storm उत्पादनावर, इनबाउंड, आउटबाउंड आणि कॅम्पेन कॉल्सवर, चाचणी कॉल्सवर तसेच वेब आणि विजेट कॉल्सवर नेटिव्हपणे चालतात.

इतर सर्व ठिकाणी एजंट तरीही कार्य करतो, फक्त संरचनेशिवाय: तो शेअर केलेल्या सूचना आणि प्रत्येक स्टेप क्रमाने एकत्र करणारा सपाट prompt चालवतो. यात समाविष्ट आहे:

• प्रायोगिक Bolt उत्पादने;
• सेव्ह केलेल्या एजंटसाठीच्या सेशनसह Realtime सेशन्स;
• डायनॅमिक कॉल कॉन्फिग वेबहुकद्वारे परत केलेली इनलाइन कॉन्फिगरेशन्स. agent_id परत करणारा वेबहुक त्या एजंटच्या स्टेप्स वापरतो.

मर्यादा#

नियम मोडणारे सेव्ह 400 परत करते, त्यासोबत चुकीच्या फील्डचा पथ दिला जातो, उदाहरणार्थ steps.steps[2].transitions[0].to. tools आणि on_enter_tool मधील टूल नावे एजंटला जोडलेली टूल्स असणे आवश्यक आहे.

प्रति-पायरी भाषा, मॉडेल वगळणाऱ्या स्क्रिप्टेड पायऱ्या आणि say ओळींमधील गोळा केलेली मूल्ये समर्थित नाहीत.

इम्पोर्ट केलेले एजंट#

Retell, Bland, Vapi किंवा ElevenLabs वरून इम्पोर्ट केल्यास अनेक-prompt एजंट, फ्लो, मार्ग आणि वर्कफ्लो पायऱ्या म्हणून, तसेच स्क्वॉड्स आणि एजंट ट्रान्सफर इम्पोर्ट केलेल्या एजंटमधील हँडऑफ म्हणून येतात. तुम्ही इम्पोर्ट करण्यापूर्वी पुनरावलोकन पृष्ठ दोन्ही दाखवते.

उदाहरण: दंतवैद्यकीय माहिती संकलन#

क्रमाने तीन पायऱ्या: अभिवादन करा, रुग्णाचा तपशील गोळा करा, बुक करा.

{
  "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 ऐच्छिक आहे.

उदाहरण: वय-आधारित शाखा#

मॉडेल कोणाशीही बोलू शकते, पण कोणाची बुकिंग होईल हे कोड ठरवते. वय गोळा करा, नंतर मॉडेलच्या स्वतःच्या निवडीचा विचार होण्यापूर्वी त्यानुसार रूट करा.

{
  "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 पायऱ्या वगळल्या आहेत.

[
  {
    "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) सोपवतो.

फ्रंट डेस्कवर:

{
  "handoffs": [
    {"agent_id": 413, "when": "The caller asks about a bill, a payment or a refund"}
  ]
}

बिलिंग एजंटवर, जेणेकरून तो कॉल करणाऱ्या व्यक्तीला परत सोपवू शकेल:

{
  "handoffs": [
    {"agent_id": 412, "when": "The billing question is resolved and the caller needs something else"}
  ]
}

फ्रंट डेस्क "मी तुम्हाला आमच्या बिलिंग टीमकडे जोडतो" अशी छोटी ओळ सांगतो, आणि बिलिंग एजंट स्वतःची ओळख करून देतो व फ्रंट डेस्कने जिथे संभाषण सोडले होते तिथून ते पुढे सुरू करतो. बिलिंग परत सोपवल्यावर, फ्रंट डेस्क कॉल करणाऱ्या व्यक्तीचे पुन्हा स्वागत न करता जिथे होता तिथूनच सुरू ठेवतो. कॉलचे उत्पादन, भाषा, संमतीची घोषणा आणि इतर कॉल सेटिंग्ज फ्रंट डेस्ककडेच राहतात, कारण त्याने उत्तर दिले होते.

बिलिंगला स्वतःच्या एजंटची नव्हे, तर फक्त स्वतंत्र सूचना आवश्यक असल्यास, त्याऐवजी फ्रंट डेस्कवर ग्लोबल पायरी वापरा. प्रश्नाचे उत्तर दिल्यावर, कॉल करणारी व्यक्ती ज्या पायरीमध्ये होती त्या पायरीकडे कॉल परत जातो:

{
  "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"
}

पुढील पायऱ्या#