ایجنٹ کے مراحل اور ہینڈ آف

ایک ایجنٹ کو ایسے مراحل میں تقسیم کریں جن کی اپنی ہدایات، ٹولز اور جمع کردہ اقدار ہوں، اور کال کے دوران ایجنٹس کے درمیان کال منتقل کریں۔

ایک واحد prompt ماڈل کو ایک ہی وقت میں پورا کام دیتا ہے۔ مراحل اسے کال کا ایک مرحلہ ایک وقت میں دیتے ہیں: ہر مرحلے کی اپنی ہدایات، اپنے ٹولز، اختیاری لفظ بہ لفظ بولی جانے والی لائن، اور وہ اقدار ہوتی ہیں جو آگے بڑھنے سے پہلے اسے جمع کرنی ہوتی ہیں۔ ہینڈ آف آپ کی تنظیم کے کسی دوسرے ایجنٹ کو کال کے دوران ذمہ داری سنبھالنے دیتے ہیں، اور ٹرانسکرپٹ برقرار رہتا ہے، تاکہ کال کرنے والے کو کبھی اپنی بات دہرانا نہ پڑے۔

ہر ایجنٹ ایک واحد prompt کے طور پر شروع ہوتا ہے۔ جب تک آپ مراحل یا ہینڈ آف شامل نہیں کرتے، اس میں کچھ نہیں بدلتا۔

مراحل یا واحد prompt؟#

مراحل کوئی اسکرپٹ شدہ فون ٹری نہیں ہیں۔ کسی مرحلے کے اندر ماڈل گفتگو اسی طرح چلاتا ہے جیسے وہ ایک واحد prompt کے ساتھ چلاتا ہے۔ مرحلہ طے کرتا ہے کہ وہ کس کام پر کام کر رہا ہے، کون سے ٹولز استعمال کر سکتا ہے، اور نکلنے سے پہلے اسے کس چیز کی ضرورت ہے۔

مرحلہ وار ایجنٹ کیسے بنایا جاتا ہے#

جب کسی ایجنٹ میں مراحل ہوتے ہیں تو اس کا prompt مشترکہ ہدایات رکھتا ہے: وہ شخصیت اور قواعد جو ہر مرحلے میں لاگو ہوتے ہیں۔ ہر مرحلہ اپنی الگ ہدایات شامل کرتا ہے۔ ہر ٹرن پر ماڈل مشترکہ ہدایات، موجودہ مرحلے کا نام اور ہدایات، اور اب تک جمع کی گئی اقدار دیکھتا ہے۔

بلڈر میں، ایجنٹ کو واحد prompt سے مراحل پر تبدیل کریں۔ آپ کو ہر مرحلے کے لیے اس کے نام، ہدایات، بولنے کی لائن، ٹولز، جمع کی گئی اقدار اور منتقلیوں کا ایک کارڈ، ایک ہینڈ آف منتخب کنندہ، اور مراحل کا صرف پڑھنے کے قابل فلو گراف ملتا ہے۔ واپس واحد prompt پر تبدیل کرنے سے ایک فلیٹ prompt پیش کیا جاتا ہے جو مشترکہ ہدایات اور ہر مرحلے کو ضم کرتا ہے۔

API کے ذریعے، steps اور handoffs agent پر فیلڈز ہیں۔ ہر ایجنٹ فیلڈ کی طرح، ایک 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: جانچ کے بغیر آگے بڑھیں۔ کوڈ پہلے فیصلہ کرتا ہے: جیسے ہی کسی مرحلے میں داخل ہوا جائے، یا اس کی مطلوبہ اقدار جمع ہو جائیں، پہلی مطابقت رکھنے والی condition یا always منتقلی نافذ ہو جاتی ہے، اس سے پہلے کہ ماڈل when منتخب کر سکے۔ اس لیے 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 ایجنٹ کی ابتدائی سطر ہوتا ہے جب وہ رضامندی کے کسی بھی اعلان کے بعد پہلے بولتا ہے۔ جب کالر پہلے بولتا ہے، تو یہ کسی شخص کو ایجنٹ کے پہلے جواب سے شروع ہوتا ہے، کبھی IVR یا وائس میل کے سلام سے نہیں۔

جب کال __previous__ یا واپسی کے ذریعے کسی مرحلے پر لوٹتی ہے تو اس مرحلے کا 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": "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 پر جاتے ہیں۔ دونوں گراف میں کسی اور جگہ عام مراحل ہیں۔

مثال: اکاؤنٹ تلاش کرنے کا webhook مرحلہ#

کالر اکاؤنٹ نمبر فراہم کرتا ہے، اگلے مرحلے میں داخل ہونے پر تلاش چلتی ہے، اور اس کا نتیجہ راستہ منتخب کرتا ہے۔ اختصار کے لیے 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 ملتا ہے کیونکہ اس کے پیرامیٹر کا یہی نام ہے۔ اگر response body میں "found": false ہو تو کال not_found پر جاتی ہے۔ اگر اس کا account_status، past_due یا suspended ہو تو یہ collections پر جاتی ہے۔ فعال اکاؤنٹ lookup میں رہتا ہے، جہاں ماڈل مدد کرتا ہے اور پھر support پر منتقل ہوتا ہے۔ ناکام تلاش کو اس کے اپنے مرحلے پر بھیجنے کے لیے، پہلے اسٹیٹس کی شرائط شامل کریں: error response اپنا status code محفوظ کرتا ہے، اس لیے {"value": "lookup_account_result.status", "op": "gte", "target": 400} اسے پکڑ لیتا ہے، اور timeout یا جواب نہ ملنے کی صورت میں "error" محفوظ ہوتا ہے، اس لیے {"value": "lookup_account_result.status", "op": "eq", "target": "error"} اس صورت کو پکڑ لیتا ہے۔

مثال: فرنٹ ڈیسک سے بلنگ تک#

دو ایجنٹس۔ فرنٹ ڈیسک (ایجنٹ 412) ہر کال کا جواب دیتا ہے اور بلنگ سے متعلق سوالات کو اپنے prompt، tools اور آواز والے بلنگ ایجنٹ (ایجنٹ 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"}
  ]
}

فرنٹ ڈیسک ایک مختصر جملہ کہتا ہے، مثلاً "میں آپ کو ہماری بلنگ ٹیم سے ملاتا ہوں"، اور بلنگ ایجنٹ اپنا تعارف کرواتا ہے اور گفتگو وہیں سے آگے بڑھاتا ہے جہاں فرنٹ ڈیسک نے چھوڑی تھی۔ جب بلنگ واپس حوالے کرتی ہے تو فرنٹ ڈیسک وہیں سے دوبارہ شروع کرتا ہے، کالر کو دوبارہ سلام کیے بغیر۔ کال کا product، زبانیں، consent announcement اور کال کی دیگر ترتیبات فرنٹ ڈیسک کے ساتھ رہتی ہیں، کیونکہ اسی نے جواب دیا تھا۔

اگر بلنگ کو صرف اپنی ہدایات درکار ہوں اور اپنا الگ ایجنٹ نہ چاہیے ہو تو اس کے بجائے فرنٹ ڈیسک پر global step استعمال کریں۔ سوال کا جواب ملنے پر، کال اس مرحلے پر واپس جاتی ہے جس میں کالر موجود تھا:

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

اگلے مراحل#