स्ट्रक्चर्ड प्रोसीजर

टाइप किए गए चरणों का एक तय क्रम, जिसे आपका एजेंट हर बार एक ही तरह से चलाता है

परिचय

स्ट्रक्चर्ड प्रोसीजर एक प्रोसीजर है, जो चरणों का एक तय क्रम चलाता है। फ़्री-फ़ॉर्म प्रोसीजर प्राकृतिक भाषा में मार्गदर्शन होता है, जिसे एजेंट समझकर स्थिति के अनुसार ढालता है। स्ट्रक्चर्ड प्रोसीजर टाइप किए गए चरणों की क्रमबद्ध सूची होती है, जिसे एजेंट हर बार प्रोसीजर लागू होने पर क्रम से चलाता है।

जब हर कॉल पर खास चरणों को एक ही तरह से चलाना ज़रूरी हो, जैसे कॉलर की पहचान सत्यापित करना, टिकट एस्केलेट करना या पेमेंट लेना, तब स्ट्रक्चर्ड प्रोसीजर इस्तेमाल करें। आप इसे सामान्य भाषा में लिखे चरणों की छोटी सूची के रूप में तैयार करते हैं।

हर प्रोसीजर की तरह, स्ट्रक्चर्ड प्रोसीजर में भी एक ट्रिगर होता है, जो बताता है कि यह कब लागू होगा। जब बातचीत ट्रिगर से मेल खाती है, तो एजेंट प्रोसीजर के चरणों को क्रम से चलाता है और फिर बाकी बातचीत पर लौट आता है।

स्ट्रक्चर्ड प्रोसीजर का इस्तेमाल कब करें

जब खास चरणों को हर बार एक ही तरह से चलाना ज़रूरी हो, लेकिन आप उन्हें सामान्य चरणों में जल्दी लिखना चाहते हों, तब स्ट्रक्चर्ड प्रोसीजर इस्तेमाल करें। फ़्री-फ़ॉर्म प्रोसीजर, वर्कफ़्लो और सिस्टम प्रॉम्प्ट से इसकी तुलना के लिए प्रोसीजर का इस्तेमाल कब करें देखें।

स्ट्रक्चर्ड प्रोसीजर की संरचना

स्ट्रक्चर्ड प्रोसीजर के तीन भाग होते हैं: नाम, ट्रिगर और चरणों की क्रमबद्ध सूची।

नाम

एक छोटा लेबल, जो डैशबोर्ड में प्रोसीजर की पहचान करता है। नाम कभी भी LLM को नहीं भेजा जाता, इसलिए इसका एजेंट के व्यवहार पर कोई असर नहीं पड़ता।

ट्रिगर

एजेंट को यह प्रोसीजर कब चलाना चाहिए, इसका सामान्य भाषा में विवरण। उदाहरण के लिए, जब यूज़र किसी ऑर्डर का रिफंड मांगे। एजेंट यूज़र के इरादे की तुलना हर प्रोसीजर के ट्रिगर से करता है और मेल खाने वाले को चलाता है, इसलिए ट्रिगर ठोस और अलग-अलग होने चाहिए। ट्रिगर हर प्रोसीजर में एक ही तरह से काम करता है; ट्रिगर लिखना देखें।

चरण

प्रोसीजर बॉडी टाइप किए गए चरणों की क्रमबद्ध सूची होती है। चरणों के कई प्रकार होते हैं और आप उन्हें मिलाकर काम का विवरण देते हैं।

चरण	यह क्या करता है
पूछें	यूज़र से जानकारी मांगता है और उपयुक्त जवाब की प्रतीक्षा करता है।
बताएं	एजेंट को निर्देश के आधार पर अपने शब्दों में संदेश जनरेट करने देता है।
कहें	एजेंट को शब्दशः एक सटीक संदेश बोलने देता है।
टूल	किसी खास टूल या API को कॉल करता है।
अगर	पहले मेल खाने वाले if/else-if विकल्प या वैकल्पिक else विकल्प को चुनता है।
सब-प्रोसीजर	दूसरा स्ट्रक्चर्ड प्रोसीजर चलाता है, फिर अगले चरण पर लौटता है।
सिस्टम टूल	अंतर्निहित सिस्टम कार्रवाई करता है। फ़िलहाल सिर्फ़ कॉल समाप्त करना समर्थित है।
फिर से कोशिश	विफल टूल कॉल का फिर से प्रयास करता है। केवल टूल विफलता हैंडलिंग में उपलब्ध है।

API चरण रेफरेंस

स्ट्रक्चर्ड प्रोसीजर content एक JSON-एन्कोडेड दस्तावेज़ है, जिसमें steps ऐरे होता है। हर चरण की पहचान उसके type से होती है।

पूछें

Ask चरण एजेंट को जानकारी मांगने और यूज़र के उपयुक्त जवाब देने तक प्रतीक्षा करने का निर्देश देता है।

API प्रकार: ask
instruction: ज़रूरी, खाली न होने वाली स्ट्रिंग।

{
  "type": "ask",
  "instruction": "Ask the user for their order ID."
}

बताएं

Tell चरण एजेंट को अपने शब्दों में एक संदेश जनरेट करने का निर्देश देता है। Ask के विपरीत, यह आगे बढ़ने से पहले यूज़र के जवाब की प्रतीक्षा नहीं करता।

API प्रकार: tell
instruction: ज़रूरी, खाली न होने वाली स्ट्रिंग।

{
  "type": "tell",
  "instruction": "Explain that the refund normally takes five to ten business days."
}

कहें

Say चरण दिए गए टेक्स्ट को ठीक उसी तरह बोलता है, जैसा वह लिखा गया है।

API प्रकार: say
message: ज़रूरी, खाली न होने वाली स्ट्रिंग।

{
  "type": "say",
  "message": "Your refund has been submitted."
}

अगर, else if और else

If चरण में एक या अधिक क्रमबद्ध कंडीशनल विकल्प होते हैं। पहला मेल खाने वाला विकल्प चलता है। वैकल्पिक fallback ऐरे else विकल्प के रूप में काम करता है।

API प्रकार: branch
branches: ज़रूरी, कंडीशनल विकल्पों की खाली न होने वाली सूची।
fallback: else चरणों की वैकल्पिक सूची।
हर विकल्प के लिए condition और खाली न होने वाली steps सूची ज़रूरी है।

{
  "type": "branch",
  "branches": [
    {
      "condition": {
        "type": "llm",
        "condition": "The user is on an annual plan."
      },
      "steps": [
        {
          "type": "say",
          "message": "Your annual plan is eligible for a prorated refund."
        }
      ]
    }
  ],
  "fallback": [
    {
      "type": "tell",
      "instruction": "Explain that the account's plan could not be determined."
    }
  ]
}

यह if/else-if/else की तरह काम करता है:

कंडीशन का क्रम से मूल्यांकन होता है।
पहला मेल खाने वाला विकल्प चलता है।
अगर कोई कंडीशन मेल नहीं खाती, तो fallback चलता है।
किसी विकल्प के पूरा होने के बाद, प्रोसीजर मुख्य क्रम में वापस जुड़ जाता है।

ऊपर दिया गया उदाहरण प्राकृतिक भाषा की कंडीशन इस्तेमाल करता है। कंडीशन वर्कफ़्लो एक्सप्रेशन भी इस्तेमाल कर सकती हैं:

{
  "type": "expression",
  "expression": {
    "type": "eq_operator",
    "left": {
      "type": "dynamic_variable",
      "name": "plan_tier"
    },
    "right": {
      "type": "string_literal",
      "value": "annual"
    }
  }
}

एक If चरण के सभी विकल्पों में एक ही कंडीशन प्रकार होना चाहिए: llm या expression।

If चरण पहला प्रोसीजर चरण हो सकता है। हालांकि:

If चरण नेस्टेड नहीं हो सकते।
दो If चरण लगातार नहीं रखे जा सकते।
एक्सप्रेशन कंडीशन सीधे Ask चरण के बाद नहीं आ सकती। यूज़र के फ़्री-टेक्स्ट जवाब का मूल्यांकन करने के लिए LLM कंडीशन इस्तेमाल करें।

टूल

Tool चरण किसी खास टूल को कॉल करता है।

API प्रकार: tool_call
tool_id: ज़रूरी, खाली न होने वाली टूल ID।
tool_name: ज़रूरी टूल नाम।
instruction: टूल को कॉल करने का तरीका बताने वाला वैकल्पिक निर्देश।
on_failure: वैकल्पिक विफलता हैंडलर।

{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "lookup_order",
  "instruction": "Look up the order using the order ID provided by the user."
}

on_failure के बिना, विफल टूल कॉल प्रोसीजर को रोक देती है। खास विफलताओं को संभालने, टूल को फिर से आज़माने या फ़ॉलबैक चरणों के साथ आगे बढ़ने के लिए on_failure जोड़ें।

branches: क्रमबद्ध कंडीशन की वैकल्पिक सूची। पहला मेल खाने वाला ब्रांच चलता है।
fallback: ज़रूरी, चरणों की खाली न होने वाली सूची। कोई ब्रांच मेल न खाने पर यह चलती है।

{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "lookup_order",
  "on_failure": {
    "fallback": [
      {
        "type": "tell",
        "instruction": "Explain that the order could not be retrieved and offer to connect the user with support."
      }
    ]
  }
}

विफलता-हैंडलर ब्रांच में Ask, Tell, Say, सब-प्रोसीजर, सिस्टम टूल और Retry चरण हो सकते हैं। इनमें Tool या If चरण नहीं हो सकते। एक विफलता हैंडलर की सभी कंडीशनल ब्रांच में एक ही कंडीशन प्रकार होना चाहिए।

फिर से कोशिश

Retry चरण उस Tool चरण को फिर से आज़माता है, जिसके विफलता हैंडलर में यह शामिल होता है।

API प्रकार: retry
max_retries: 1 से 3 तक का वैकल्पिक पूर्णांक। डिफ़ॉल्ट 1 है।
यह मान मूल टूल कॉल के बाद के दोबारा प्रयासों की संख्या गिनता है।
Retry केवल on_failure के अंदर मान्य है।
Retry अपने विफलता-हैंडलर ब्रांच का आखिरी चरण होना चाहिए, क्योंकि इसके बाद के चरण पहुंच से बाहर होंगे।
अगर सभी प्रयास विफल हो जाते हैं, तो प्रोसीजर रुक जाता है।

{
  "type": "retry",
  "max_retries": 2
}

सब-प्रोसीजर

Sub-procedure चरण दूसरा स्ट्रक्चर्ड प्रोसीजर चलाता है। इसके पूरा होने पर, निष्पादन Sub-procedure चरण के बाद वाले चरण पर लौटता है।

API प्रकार: sub_procedure
procedure_id: ज़रूरी, खाली न होने वाली प्रोसीजर ID।
टारगेट उसी एजेंट पर मौजूद होना चाहिए।
टारगेट एक स्ट्रक्चर्ड प्रोसीजर होना चाहिए।
कोई प्रोसीजर खुद को कॉल नहीं कर सकता।

{
  "type": "sub_procedure",
  "procedure_id": "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3"
}

सिस्टम टूल

System tool चरण अंतर्निहित सिस्टम कार्रवाई करता है।

API प्रकार: system_tool
system_tool_name: ज़रूरी सिस्टम-टूल नाम।
फ़िलहाल सिर्फ़ end_call समर्थित है। बाद में और सिस्टम टूल जोड़े जा सकते हैं।
क्योंकि end_call टर्मिनल है, इसलिए इसे अपने क्रम या ब्रांच का आखिरी चरण होना चाहिए।

{
  "type": "system_tool",
  "system_tool_name": "end_call"
}

पूरा API उदाहरण

यह उदाहरण शिपमेंट की स्थिति के आधार पर ऑर्डर रद्द करने को संभालता है। यह विफल टूल कॉल को फिर से आज़माता है, दूसरा स्ट्रक्चर्ड प्रोसीजर चलाता है और फिर कॉल समाप्त करता है।

{
  "trigger": "When the user asks to cancel an order and request a refund.",
  "steps": [
    {
      "type": "ask",
      "instruction": "Ask the user for their order ID."
    },
    {
      "type": "branch",
      "branches": [
        {
          "condition": {
            "type": "llm",
            "condition": "The user says the order has already shipped."
          },
          "steps": [
            {
              "type": "tell",
              "instruction": "Explain that shipped orders must be returned before they can be refunded."
            }
          ]
        },
        {
          "condition": {
            "type": "llm",
            "condition": "The user says the order has not shipped."
          },
          "steps": [
            {
              "type": "tool_call",
              "tool_id": "tool_abc123",
              "tool_name": "cancel_order",
              "instruction": "Cancel the order using the order ID provided by the user.",
              "on_failure": {
                "fallback": [
                  {
                    "type": "retry",
                    "max_retries": 2
                  }
                ]
              }
            }
          ]
        }
      ],
      "fallback": [
        {
          "type": "ask",
          "instruction": "Ask whether the order has already shipped."
        }
      ]
    },
    {
      "type": "sub_procedure",
      "procedure_id": "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3"
    },
    {
      "type": "say",
      "message": "Thank you for contacting us. Goodbye."
    },
    {
      "type": "system_tool",
      "system_tool_name": "end_call"
    }
  ]
}

स्ट्रक्चर्ड प्रोसीजर कैसे चलता है

बातचीत के दौरान जब यूज़र का अनुरोध किसी प्रोसीजर के ट्रिगर से मेल खाता है, तो एजेंट प्रोसीजर में प्रवेश करता है और उसके चरणों को क्रम से, हर बार एक ही तरह से चलाता है। प्रोसीजर के अंदर एजेंट उन चरणों पर ध्यान देता है; अंत तक पहुंचने पर यह बातचीत में वहीं लौटता है, जहां से रुका था।

अगर Tool चरण विफल हो जाता है और उसमें on_failure परिभाषित नहीं है, तो बचे हुए चरण चलाए बिना प्रोसीजर रुक जाता है। on_failure कॉन्फ़िगर होने पर, प्रोसीजर पहले मेल खाने वाले विफलता ब्रांच या उसके ज़रूरी फ़ॉलबैक को चलाता है। संभाली गई विफलता अगले प्रोसीजर चरण पर जारी रहती है, जब तक चुना गया हैंडलर टूल को फिर से न आज़माए, कॉल समाप्त न करे या कोई दूसरा टर्मिनल पथ न चलाए।

संरचित प्रोसीजर मैनेज करें

डैशबोर्ड से बनाएं

API से मैनेज करें

अपना एजेंट डैशबोर्ड में खोलें, फिर Procedures चुनें। संरचित प्रोसीजर बनाने के लिए + का इस्तेमाल करें। ट्रिगर जोड़ें, हर स्टेप के लिए एक टाइप चुनें और एजेंट के बदलाव पब्लिश करें।

सर्वोत्तम तरीके

हर स्टेप टाइप पहले से अपना व्यवहार लागू करता है, इसलिए आपको उसे विस्तार से बताने की ज़रूरत कम ही पड़ती है। हर स्टेप का मकसद लिखें और बाकी काम स्टेप टाइप को करने दें। नीचे दी गई गाइडेंस उन मामलों को कवर करती है जिन्हें सही रखना ज़रूरी है।

स्टेप्स लिखना

Ask स्टेप्स को यूज़र का इंतज़ार करने दें

Ask स्टेप तब तक आगे नहीं बढ़ता, जब तक वह आपका सवाल पूछ न ले और उचित जवाब न मिल जाए। जानकारी इकट्ठा हुई या नहीं, यह जांचने के लिए आपको follow-up step की ज़रूरत नहीं है; Ask स्टेप आगे बढ़ने से पहले इसकी गारंटी देता है।

Tool स्टेप्स को सिर्फ़ टूल कॉल तक सीमित रखें

Tool स्टेप सिर्फ़ टूल चलाता है; इस दौरान एजेंट बोल या कोई फ़ैसला नहीं कर सकता। यूज़र से बात करने के लिए या टूल के लौटाए गए नतीजे के आधार पर branch करने के लिए, उसे Tool स्टेप के पहले या बाद में अलग स्टेप में रखें।

वाक्य बनाने के लिए Tell, सटीक शब्दों के लिए Say चुनें

जब एजेंट को खुद संदेश बनाना हो, तो Tell स्टेप इस्तेमाल करें; और जब शब्द बिल्कुल वैसे ही होने चाहिए, तो Say स्टेप इस्तेमाल करें। दोनों ठीक एक संदेश भेजते हैं, इसलिए किसी स्टेप को एक ही संदेश भेजने का निर्देश देने की ज़रूरत नहीं है।

प्रोसीजर्स तैयार करना

प्रोसीजर्स तैयार करने की सामान्य गाइडेंस संरचित प्रोसीजर्स पर भी लागू होती है — Free-form procedures पेज पर Composing procedures देखें।

टाइप्स को मिलाने के लिए एक खास पैटर्न है: free-form procedure किसी structured procedure को refer कर सकता है। open-ended handling को free-form procedure में रखें और उन हिस्सों को structured procedure को सौंपें जिन्हें हर बार एक ही तरह चलना चाहिए, जैसे identity verification या escalation।

सीमाएं

If स्टेप्स को nest नहीं किया जा सकता, और दो If स्टेप्स को एक के बाद एक नहीं रखा जा सकता।

मॉडल प्रोवाइडर सपोर्ट

संरचित प्रोसीजर्स sub-procedure में प्रवेश करते समय और प्रोसीजर पूरा करते समय internal tool calls को force करते हैं। प्रमुख OpenAI, Anthropic, Gemini और Grok मॉडल families forced tool choice को सपोर्ट करती हैं। दूसरे मॉडल या custom providers इसकी गारंटी नहीं दे सकते, जिससे sub-procedure transitions या procedure completion कम भरोसेमंद हो सकते हैं। किसी दूसरे मॉडल प्रोवाइडर का इस्तेमाल करते समय forced tool-choice support की पुष्टि करें।

content size cap और structured procedures, free-form procedures से कैसे अलग हैं, समेत सभी प्रोसीजर्स पर लागू सीमाओं के लिए Procedures देखें।