> This is a page from the ElevenLabs documentation. For a complete page index, fetch https://elevenlabs.io/docs/llms.txt. For the full documentation in a single file, fetch https://elevenlabs.io/docs/llms-full.txt.

# संरचित प्रक्रियाएँ

## परिचय

संरचित प्रक्रिया एक [प्रक्रिया](/docs/hi/eleven-agents/customization/procedures) है, जो चरणों का निश्चित क्रम चलाती है। [मुक्त-रूप प्रक्रिया](/docs/hi/eleven-agents/customization/procedures/free-form-procedures) प्राकृतिक भाषा में दिया गया मार्गदर्शन है, जिसे एजेंट समझकर स्थिति के अनुसार ढालता है। संरचित प्रक्रिया टाइप किए गए चरणों की क्रमबद्ध सूची है, जिसे प्रक्रिया लागू होने पर एजेंट हर बार क्रम से चलाता है।

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

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

![संरचित प्रक्रिया
एडिटर](/docs/_fern-img/bc996f67b2afad8f1de5abe8febcf8af3766b4f098627b0ae60e0456b3c2703b.webp)

## संरचित प्रक्रिया का उपयोग कब करें

संरचित प्रक्रिया का उपयोग तब करें, जब खास चरणों का हर बार एक ही तरह से चलना ज़रूरी हो, लेकिन आप उसे फिर भी सरल चरणों में जल्दी तैयार करना चाहते हों। संरचित प्रक्रियाएँ वर्कफ़्लो की तुलना में लिखने में आसान हैं, लेकिन कम अभिव्यक्तिपूर्ण हैं। वे मुक्त-रूप प्रक्रियाओं, वर्कफ़्लो और सिस्टम प्रॉम्प्ट से कैसे अलग हैं, जानने के लिए [प्रक्रियाओं का उपयोग कब करें](/docs/hi/eleven-agents/customization/procedures#when-to-use-procedures) देखें।

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

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

### नाम

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

### ट्रिगर

यह सामान्य भाषा में बताया गया विवरण है कि एजेंट को यह प्रोसीजर कब चलाना चाहिए, उदाहरण के लिए *जब यूज़र किसी ऑर्डर का रिफ़ंड मांगे*। एजेंट यूज़र के इरादे की तुलना हर प्रोसीजर के ट्रिगर से करता है और मेल खाने वाला प्रोसीजर चलाता है, इसलिए ट्रिगर ठोस और अलग-अलग होने चाहिए। एजेंट को सिर्फ़ ट्रिगर टेक्स्ट दिखता है, प्रोसीजर का नाम या ID नहीं। ट्रिगर किसी भी प्रोसीजर की तरह ही काम करता है; [ट्रिगर लिखना](/docs/hi/eleven-agents/customization/procedures/free-form-procedures#writing-triggers) देखें।

ट्रिगर खाली छोड़ने पर प्रोसीजर एक सब-प्रोसीजर बन जाता है, जो केवल तब चलता है जब कोई दूसरा प्रोसीजर उसे कॉल करता है।

### चरण

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

| चरण               | यह क्या करता है                                                                                                                                                                                                                                     |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Ask**           | यूज़र से जानकारी मांगता है और इंतज़ार करता है। यूज़र के जवाब देने तक पूछता रहता है। यूज़र के लिए रुकने वाला यही एकमात्र चरण है।                                                                                                                     |
| **Tell**          | एजेंट से अपने शब्दों में कुछ कहलवाता है, फिर अगले चरण पर बढ़ता है।                                                                                                                                                                                  |
| **Say**           | एजेंट से एक सटीक संदेश शब्दशः बुलवाता है, फिर अगले चरण पर बढ़ता है। Say चरण में एजेंट की समर्थित हर भाषा के लिए अलग से कॉन्फ़िगर किया गया अनुवाद हो सकता है।                                                                                        |
| **Tool**          | किसी खास टूल को कॉल करता है। टूल को कैसे कॉल करना है, इसके लिए आप LLM को सामान्य भाषा में निर्देश दे सकते हैं या अधिकतम निश्चितता चाहिए होने पर पैरामीटर वैल्यू स्पष्ट रूप से तय कर सकते हैं। टूल कॉल विफल होने पर चलने वाले चरण भी तय कर सकते हैं। |
| **If**            | एक या अधिक शर्तों का क्रम से मूल्यांकन करता है और पहली मेल खाने वाली शर्त के चरण चलाता है। कुछ भी मेल न खाने पर वैकल्पिक Else चलता है।                                                                                                              |
| **Sub-procedure** | दूसरा स्ट्रक्चर्ड प्रोसीजर चलाता है। उसके चरण पूरे होने पर नियंत्रण इस (कॉलर) प्रोसीजर के अगले चरण पर लौट आता है।                                                                                                                                   |
| **System tool**   | बिल्ट-इन सिस्टम कार्रवाई करता है। फ़िलहाल सिर्फ़ कॉल समाप्त करना समर्थित है।                                                                                                                                                                        |
| **Retry**         | टूल कॉल सहित, Tool चरण के विफलता हैंडलर को अधिकतम तीन बार फिर से चलाता है। यह सिर्फ़ Tool चरण के विफलता हैंडलर में उपलब्ध है।                                                                                                                       |

![स्ट्रक्चर्ड प्रोसीजर चरण प्रकार
मेनू](/docs/_fern-img/14976a6b9979d21fd7c77541a49e7475f8aa0764af4940746d3390804e7c4598.webp)

हर चरण हर जगह इस्तेमाल नहीं किया जा सकता। If आर्म के अंदर आप दूसरे If या Retry को छोड़कर कोई भी चरण इस्तेमाल कर सकते हैं। Tool चरण के विफलता हैंडलर के अंदर आप If या दूसरे Tool को छोड़कर कोई भी चरण इस्तेमाल कर सकते हैं।

## API चरण रेफरेंस

स्ट्रक्चर्ड प्रोसीजर का `content`, `steps` ऐरे वाले JSON-एन्कोडेड दस्तावेज़ होता है। हर चरण एक ऑब्जेक्ट है, जिसकी पहचान उसके `type` से होती है। ट्रिगर प्रोसीजर का अलग टॉप-लेवल फ़ील्ड है, `content` का हिस्सा नहीं। API और SDK पेलोड प्रोसीजर के लिए `type: "deterministic"` इस्तेमाल करते हैं।

### Ask

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

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

```json focus={1-4}
{
  "type": "ask",
  "instruction": "Ask the user for their order ID."
}
```

### Tell

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

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

```json focus={1-4}
{
  "type": "tell",
  "instruction": "Explain that the refund normally takes five to ten business days."
}
```

### Say

Say चरण दिए गए टेक्स्ट को जैसा लिखा है वैसा ही बोलता है, फिर आगे बढ़ता है। एजेंट की हर अतिरिक्त समर्थित भाषा के लिए भाषा कोड के आधार पर एक सटीक संदेश देने के लिए `message_translations` दें।

* API प्रकार: `say`
* `message`: ज़रूरी, खाली न होने वाली स्ट्रिंग।
* `message_translations`: भाषा कोड को `{ "value": "..." }` से मैप करने वाला वैकल्पिक ऑब्जेक्ट।

```json focus={1-7}
{
  "type": "say",
  "message": "Your refund has been submitted.",
  "message_translations": {
    "es": { "value": "Su reembolso ha sido enviado." }
  }
}
```

### If, else if और else

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

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

```json focus={1-23}
{
  "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 की तरह काम करता है:

1. शर्तों का क्रम से मूल्यांकन होता है।
2. पहला मेल खाने वाला आर्म चलता है।
3. कोई शर्त मेल न खाने पर `fallback` चलता है।
4. आर्म पूरा होने के बाद प्रोसीजर फिर से मुख्य क्रम में जुड़ जाता है।

ऊपर का उदाहरण टेक्स्ट कंडीशन इस्तेमाल करता है, जिसका मॉडल सामान्य भाषा में मूल्यांकन करता है। कंडीशन डायनामिक वेरिएबल के एक्सप्रेशन भी हो सकती हैं:

```json focus={1-14}
{
  "type": "expression",
  "expression": {
    "type": "eq_operator",
    "left": {
      "type": "dynamic_variable",
      "name": "plan_tier"
    },
    "right": {
      "type": "string_literal",
      "value": "annual"
    }
  }
}
```

एक एक्सप्रेशन कंडीशन डायनामिक वेरिएबल की जांच करती है, जिन्हें टूल रिज़ल्ट से भरा जाता है या बातचीत शुरू होने पर सेट किया जाता है। यह यूज़र का सबसे हालिया जवाब नहीं पढ़ सकती। यूज़र की बात के आधार पर ब्रांच करने के लिए टेक्स्ट कंडीशन इस्तेमाल करें।

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

### Tool

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

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

```json focus={1-6}
{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "lookup_order",
  "instruction": "Look up the order using the order ID provided by the user."
}
```

#### तय पैरामीटर वैल्यू

जब किसी पैरामीटर की वैल्यू हमेशा एक खास होनी चाहिए, तब `schema_overrides` इस्तेमाल करें। मॉडल ओवरराइड किए गए पैरामीटर को नहीं देखता और न ही चुनता है। की टूल के स्कीमा में पैरामीटर पाथ होती हैं; हर वैल्यू एक स्रोत बताती है:

| `source`           | फ़ील्ड              | व्यवहार                                                          |
| ------------------ | ------------------- | ---------------------------------------------------------------- |
| `constant`         | `constant_value`    | हमेशा दी गई वैल्यू भेजता है।                                     |
| `dynamic_variable` | `dynamic_variable`  | नाम वाले डायनामिक वेरिएबल की मौजूदा वैल्यू भेजता है।             |
| `llm`              | `prompt` (वैकल्पिक) | मॉडल को वैल्यू चुनने देता है, वैकल्पिक प्रॉम्प्ट ओवरराइड के साथ। |
| `omit`             |                     | पैरामीटर को कॉल से बाहर रखता है।                                 |

```json focus={1-9}
{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "update_ticket",
  "schema_overrides": {
    "request_body.status": { "source": "constant", "constant_value": "pending" },
    "request_body.ticket_id": { "source": "dynamic_variable", "dynamic_variable": "ticket_id" }
  }
}
```

#### विफलता हैंडलिंग

`on_failure` के बिना, विफल टूल कॉल बातचीत समाप्त कर देता है। इसके बजाय रिकवरी चरण चलाने के लिए `on_failure` जोड़ें।

* `fallback`: टूल विफल होने पर चलने वाले चरणों की ज़रूरी, खाली न होने वाली सूची।
* `branches`: कंडीशनल विफलता हैंडलिंग के लिए आरक्षित। इसे खाली छोड़ें।

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

विफलता हैंडलर में Ask, Tell, Say, Sub-procedure, System tool और Retry चरण हो सकते हैं। इसमें Tool या If चरण नहीं हो सकते। हैंडलर चलने के बाद प्रोसीजर Tool चरण के बाद वाले चरण के साथ जारी रहता है।

### Retry

Retry चरण उस विफलता हैंडलर को फिर से चलाता है जिसमें वह मौजूद है, जिसमें टूल कॉल भी शामिल है। हर प्रयास टूल को फिर से कॉल करता है और, अगर वह फिर विफल हो जाता है, तो हैंडलर के हर चरण को फिर से चलाता है। प्रयास समाप्त होने पर बातचीत खत्म हो जाती है।

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

```json focus={1-4}
{
  "type": "retry",
  "max_retries": 2
}
```

### Sub-procedure

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

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

```json focus={1-4}
{
  "type": "sub_procedure",
  "procedure_id": "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3"
}
```

### System tool

System tool चरण बिल्ट-इन सिस्टम कार्रवाई करता है।

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

```json focus={1-4}
{
  "type": "system_tool",
  "system_tool_name": "end_call"
}
```

## वैलिडेशन नियम

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

* दो If चरण एक के बाद एक नहीं रखे जा सकते।
* If चरण नेस्ट नहीं किए जा सकते।
* एक्सप्रेशन कंडीशन वाला If चरण सीधे Ask चरण के बाद नहीं हो सकता।
* एक If चरण की सभी कंडीशन एक ही प्रकार की होनी चाहिए: `llm` या `expression`।
* Retry सिर्फ़ `on_failure` के अंदर हो सकता है और वहीं का आखिरी चरण होना चाहिए।
* `end_call` जिस भी सूची में हो, उसका आखिरी चरण होना चाहिए।
* विफलता हैंडलर के `fallback` में कम से कम एक चरण होना चाहिए।
* Sub-procedure को उसी एजेंट के किसी मौजूदा स्ट्रक्चर्ड प्रोसीजर की ओर पॉइंट करना चाहिए, खुद की ओर नहीं।
* `tool_id` एजेंट का टूल होना चाहिए, `tool_name` मेल खाना चाहिए और `schema_overrides` टूल के स्कीमा से मेल खाना चाहिए।
* `steps` सूची, हर `instruction` और हर `message` खाली नहीं होने चाहिए।

इनमें से कोई नियम लागू होने पर प्रोसीजर को फिर से व्यवस्थित करने का तरीका जानने के लिए [सर्वोत्तम तरीके](#best-practices) देखें।

## पूरा API उदाहरण

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

```json maxLines=30
{
  "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.",
              "schema_overrides": {
                "request_body.notify_customer": { "source": "constant", "constant_value": true }
              },
              "on_failure": {
                "branches": [],
                "fallback": [
                  {
                    "type": "tell",
                    "instruction": "Apologize that the cancellation did not go through and say you will try once more."
                  },
                  {
                    "type": "retry",
                    "max_retries": 1
                  }
                ]
              }
            }
          ]
        }
      ],
      "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.",
      "message_translations": {
        "es": { "value": "Gracias por contactarnos. Adiós." }
      }
    },
    {
      "type": "system_tool",
      "system_tool_name": "end_call"
    }
  ]
}
```

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

स्ट्रक्चर्ड प्रोसीजर के चरणों को एजेंट द्वारा निष्पादित किए जाने वाले रूप में बदलने को कंपाइल करना कहते हैं। जब आप पब्लिश करते हैं, तो प्लेटफ़ॉर्म हर स्ट्रक्चर्ड प्रोसीजर को कंपाइल करता है; आपको खुद कुछ कंपाइल नहीं करना होता। कंपाइल किया गया परिणाम फ़िलहाल **Workflow** टैब में सिर्फ़ पढ़ने योग्य नोड्स के रूप में दिखता है।

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

नीचे दिए गए नियम बताते हैं कि रनटाइम पर चरण कैसे काम करते हैं।

#### सिर्फ़ Ask यूज़र के लिए रुकता है

Ask के अलावा हर चरण तुरंत चलता है और नियंत्रण उसी टर्न में अगले चरण पर बढ़ जाता है। Tell या Say चरण
अपना संदेश देता है और आगे बढ़ता है। Ask के अलावा ऐसा कोई चरण नहीं है जो बातचीत को रोकता हो,
और ऐसा कोई चरण नहीं है जो मौजूदा टर्न समाप्त करता हो। अगर आपको यूज़र का इनपुट चाहिए, तो Ask चरण
इस्तेमाल करें। अगर बातचीत समाप्त करनी है, तो `end_call` सिस्टम टूल इस्तेमाल करें।

#### प्रोसीजर के अंत तक पहुंचने से टर्न समाप्त नहीं होता

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

#### Tool चरण सिर्फ़ सफलता और विफलता में अंतर करते हैं

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

#### कुछ भी मेल न खाने पर If चरण आगे बढ़ जाते हैं

शर्तों का क्रम से मूल्यांकन होता है और पहला मेल चलता है। कुछ भी मेल न खाने पर Else आर्म चलता है।
अगर Else नहीं है और कुछ भी मेल नहीं खाता, तो प्रोसीजर If के बाद वाले चरण के साथ जारी रहता है।
अनहैंडल किया गया केस त्रुटि नहीं है।

#### If आर्म स्टेट आगे नहीं ले जाते

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

#### Ask, Tell और Say चरणों में टूल नहीं होते

सिर्फ़ Tool चरण ही टूल कॉल कर सकते हैं। Ask, Tell या Say चरण को टूल कॉल न करने के लिए बताने की
ज़रूरत नहीं है; वे ऐसा कर ही नहीं सकते।

## स्ट्रक्चर्ड प्रोसीजर मैनेज करें

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

[डैशबोर्ड](https://elevenlabs.io/app/agents) में अपना एजेंट खोलें, फिर **Procedures** चुनें।
स्ट्रक्चर्ड प्रोसीजर बनाने के लिए **+** इस्तेमाल करें। ट्रिगर जोड़ें, हर चरण के लिए एक प्रकार चुनें और
एजेंट के बदलाव पब्लिश करें।

एडिट करते समय डैशबोर्ड स्ट्रक्चर्ड प्रोसीजर को वैलिडेट करता है। अगर कोई प्रोसीजर
[वैलिडेशन नियम](#validation-rules) तोड़ता है, तो **Publish** बटन त्रुटि स्थिति दिखाता है,
**Procedures** टैब में त्रुटि बैज दिखता है और प्रोसीजर ठीक होने तक प्रीव्यू शुरू नहीं हो सकता।
कौन सा प्रोसीजर और चरण प्रभावित है, यह देखने के लिए त्रुटि संकेतक चुनें।

![त्रुटि स्थिति में Publish बटन और 1 Error
बैज वाला स्ट्रक्चर्ड प्रोसीजर एडिटर](/docs/_fern-img/e406c33fac3966fab26d5d07e10d364a475fc4a56fd75aad2e23edbb0d1940d5.webp)

![विफल प्रोसीजर और संदेश की ज़रूरत वाले चरण को दिखाने वाला वैलिडेशन विवरण
डायलॉग](/docs/_fern-img/a1cc889b2d0e68ce23725609b531938d0f7c417b1c6f4375103531eaae4ada63.webp)

#### CLI से मैनेज करें

[ElevenLabs CLI](/docs/hi/eleven-agents/operate/cli), फ़्री-फ़ॉर्म प्रोसीजर के समान कमांड से स्ट्रक्चर्ड
प्रोसीजर बनाता और पब्लिश करता है। `type` को `deterministic` पर सेट करें और चरणों को `content` में
JSON-एन्कोडेड स्ट्रिंग के रूप में पास करें।

```bash
CONTENT=$(jq -n '{
  trigger: "When the user asks to refund an order",
  steps: [{ type: "ask", instruction: "Ask for the order ID." }]
}')

elevenlabs agents procedures create \
  --agent-id agent_7101k5zvyjhmfg983brhmhkd98n6 \
  --branch-id agtbranch_0901k4aafjxxfxt93gd841r7tv5t \
  --json "$(jq -n --arg content "$CONTENT" '{
    name: "Refund request",
    type: "deterministic",
    trigger: "When the user asks to refund an order",
    content: $content
  }')"

elevenlabs agents update \
  --agent-id agent_7101k5zvyjhmfg983brhmhkd98n6 \
  --branch-id agtbranch_0901k4aafjxxfxt93gd841r7tv5t \
  --json '{"version_description": "Publish refund procedure"}'
```

पब्लिश ब्रांच के हर स्ट्रक्चर्ड प्रोसीजर को वैलिडेट करता है। कोई अमान्य होने पर कमांड नॉन-ज़ीरो से
एग्ज़िट होती है और प्रोसीजर ID के अनुसार त्रुटियां प्रिंट करती है। प्रोसीजर ड्राफ़्ट ठीक करें और फिर
पब्लिश करें।

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

API और SDK पेलोड स्ट्रक्चर्ड प्रोसीजर के लिए `type: "deterministic"` इस्तेमाल करते हैं। उनका `content`
JSON-एन्कोडेड दस्तावेज़ होता है।

### आवश्यक शर्तें

* `ELEVENLABS_API_KEY` एनवायरनमेंट वेरिएबल में ElevenLabs API की।
* टारगेट `agent_id` और `branch_id`। ब्रांच ऑपरेशन के लिए [एजेंट वर्शनिंग](/docs/hi/eleven-agents/operate/versioning) देखें।
* `elevenlabs` Python पैकेज या `@elevenlabs/elevenlabs-js` JavaScript पैकेज का वर्शन `2.60.0` या नया।

API एडिट, नया एजेंट वर्शन पब्लिश करने तक चुनी गई ब्रांच पर सिर्फ़ आपके यूज़र के लिए निजी होते हैं।

### ड्राफ़्ट बनाएं या अपडेट करें

`POST /procedures` से स्ट्रक्चर्ड प्रोसीजर बनाएं और `type` को `deterministic` पर सेट करें।
नीचे दिखाए अनुसार, मौजूदा प्रोसीजर को `PATCH /procedures/{procedure_id}/draft` से अपडेट करें।

`trigger` को टॉप-लेवल फ़ील्ड के रूप में सेट करें। नेस्टेड ऑब्जेक्ट भेजने के बजाय चरण दस्तावेज़ को
`content` में JSON-एन्कोड करें।

```python focus={6-18}
import json
from elevenlabs import ElevenLabs

elevenlabs = ElevenLabs()

elevenlabs.conversational_ai.agents.procedures.drafts.update(
    agent_id="agent_7101k5zvyjhmfg983brhmhkd98n6",
    branch_id="agtbranch_0901k4aafjxxfxt93gd841r7tv5t",
    procedure_id="agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3",
    name="Refund request",
    type="deterministic",
    trigger="When the user asks to refund an order",
    content=json.dumps(
        {
            "steps": [{"type": "ask", "instruction": "Ask for the order ID."}],
        }
    ),
)
```

```typescript focus={5-17}
import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient();

await elevenlabs.conversationalAi.agents.procedures.drafts.update(
  "agent_7101k5zvyjhmfg983brhmhkd98n6",
  "agtbranch_0901k4aafjxxfxt93gd841r7tv5t",
  "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3",
  {
    name: "Refund request",
    type: "deterministic",
    trigger: "When the user asks to refund an order",
    content: JSON.stringify({
      steps: [{ type: "ask", instruction: "Ask for the order ID." }],
    }),
  }
);
```

```bash focus={1-9}
curl -X PATCH "https://api.elevenlabs.io/v1/convai/agents/agent_7101k5zvyjhmfg983brhmhkd98n6/branches/agtbranch_0901k4aafjxxfxt93gd841r7tv5t/procedures/agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3/draft" \
  -H "xi-api-key: $ELEVENLABS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Refund request",
    "type": "deterministic",
    "trigger": "When the user asks to refund an order",
    "content": "{\"steps\":[{\"type\":\"ask\",\"instruction\":\"Ask for the order ID.\"}]}"
  }'
```

प्रोसीजर ड्राफ़्ट सेव करने से उसके चरण वैलिडेट नहीं होते। वैलिडेशन पब्लिश करने पर या
`POST /v1/convai/agents/{agent_id}/drafts` से एजेंट ड्राफ़्ट सेव करने पर चलता है।

### बदलाव पब्लिश करें

[एजेंट अपडेट करें](/docs/hi/api-reference/agents/update) से पब्लिश करें। पब्लिश ब्रांच के हर
स्ट्रक्चर्ड प्रोसीजर को वैलिडेट करता है, उन्हें कंपाइल करता है और परिणाम नए वर्शन के साथ स्टोर करता
है। रिक्वेस्ट में `workflow` फ़ील्ड की ज़रूरत नहीं है; कंपाइलेशन पब्लिश के हिस्से के रूप में होता है।
कंपाइल करने का मतलब जानने के लिए [स्ट्रक्चर्ड प्रोसीजर कैसे चलता है](#how-a-structured-procedure-runs)
देखें।

```python focus={5-8}
from elevenlabs import ElevenLabs

elevenlabs = ElevenLabs()

elevenlabs.conversational_ai.agents.update(
    agent_id="agent_7101k5zvyjhmfg983brhmhkd98n6",
    branch_id="agtbranch_0901k4aafjxxfxt93gd841r7tv5t",
)
```

```typescript focus={5-7}
import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient();

await elevenlabs.conversationalAi.agents.update("agent_7101k5zvyjhmfg983brhmhkd98n6", {
  branchId: "agtbranch_0901k4aafjxxfxt93gd841r7tv5t",
});
```

```bash focus={1-5}
curl -X PATCH \
  "https://api.elevenlabs.io/v1/convai/agents/agent_7101k5zvyjhmfg983brhmhkd98n6?branch_id=agtbranch_0901k4aafjxxfxt93gd841r7tv5t" \
  -H "xi-api-key: $ELEVENLABS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'
```

स्ट्रक्चर्ड प्रोसीजर अमान्य होने पर पब्लिश `400` लौटाता है और कुछ भी लिखा नहीं जाता:

```json
{
  "detail": {
    "status": "procedure_validation_failed",
    "message": "Structured procedures failed validation.",
    "data": {
      "errors": {
        "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3": [
          {
            "path": "steps[0].ask.instruction",
            "message": "Step 1: Ask step requires an instruction"
          }
        ]
      }
    }
  }
}
```

`errors` की को प्रोसीजर ID होती है। हर एंट्री विफल फ़ील्ड और चरण का नाम बताती है। प्रोसीजर
ड्राफ़्ट ठीक करें और फिर पब्लिश करें।

> **Note**
>
> इस API के पुराने वर्शन का `/procedures/compile` एंडपॉइंट अब भी काम करता है, लेकिन यह
> लेगेसी है और आखिरकार डिप्रिकेट हो जाएगा। पब्लिशिंग कंपाइलेशन संभालती है; नए कोड में कंपाइल
> एंडपॉइंट को कॉल न करें।

ड्राफ़्ट हटाने और डिस्कार्ड व्यवहार के लिए [प्रोसीजर मैनेज करें](/docs/hi/eleven-agents/customization/procedures#manage-procedures)
देखें, या पूरे एंडपॉइंट स्कीमा के लिए
[Procedures API रेफरेंस](/docs/hi/api-reference/agents/procedures/) देखें।

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

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

किसी स्ट्रक्चर्ड प्रोसिजर को टेस्ट करने के लिए, [प्रोसिजर को बेहतर बनाना](/docs/hi/eleven-agents/customization/procedures/free-form-procedures#iterating-on-a-procedure) देखें।

### स्टेप टाइप चुनना

#### हर Ask स्टेप में एक सवाल पूछें

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

#### बयानों के लिए Tell और सवालों के लिए Ask इस्तेमाल करें

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

#### जब सिर्फ सवाल पर्याप्त न हो, तो Ask के लिए स्पष्ट एग्ज़िट कंडीशन दें

Ask स्टेप उपयुक्त जवाब मिलते ही आगे बढ़ जाता है। अगर सवाल से यह स्पष्ट नहीं है कि किसे जवाब माना जाएगा,
तो इसे निर्देश में बताएं, उदाहरण के लिए \_ऑर्डर ID पूछें; मान्य
ID आठ अंकों की होती है \_।

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

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

#### नॉन-टूल स्टेप्स को टूल्स से बचने के लिए न कहें

Ask, Tell और Say स्टेप्स टूल्स को कॉल नहीं कर सकते। इनमें *कोई टूल कॉल न करें* लिखने से
व्यवहार बदले बिना निर्देश में अनावश्यक जानकारी जुड़ती है।

### प्रोसिजर की संरचना बनाना

#### दो If स्टेप्स के बीच अनावश्यक स्टेप न जोड़ें

दो If स्टेप्स को एक के बाद एक नहीं रखा जा सकता। नियम पूरा करने के लिए उनके बीच कोई असंबंधित Tell या Say जोड़ने से
एजेंट वह बात कह सकता है जो उसे नहीं कहनी चाहिए। इसके बजाय, दूसरे निर्णय को पहले If में
अतिरिक्त Else if आर्म्स के रूप में जोड़ें या उसे किसी सब-प्रोसिजर में ले जाएं।

#### नेस्टेड निर्णयों को सब-प्रोसिजर में रखें

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

#### जब 'इनमें से कोई नहीं' मायने रखता हो, तो Else जोड़ें

बिना Else वाला If स्टेप कुछ भी मैच न होने पर अगले स्टेप पर चला जाता है। अगर न मिलने वाले
मामले का व्यवहार अलग होना चाहिए, तो उसके लिए Else आर्म जोड़ें।

#### बाद के स्टेप को ज़रूरी हर चीज़ सेव करें

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

#### एक्सप्रेशन कंडीशन्स को उन्हें भरने वाले टूल के बाद रखें

एक्सप्रेशन कंडीशन्स डायनामिक वेरिएबल्स को टेस्ट करती हैं। इन्हें इस्तेमाल करने वाला If स्टेप, उन वेरिएबल्स को सेट करने वाले Tool
स्टेप के ठीक बाद रखें। यूज़र के कहे आधार पर ब्रांच करने के लिए टेक्स्ट कंडीशन इस्तेमाल करें।

#### साझा स्टेप्स को सब-प्रोसिजर में निकालें

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

### टूल्स के साथ काम करना

#### Tool स्टेप को उसके निर्देश से नहीं, If से नियंत्रित करें

Tool स्टेप हमेशा अपना टूल कॉल करता है। निर्देश में लिखी कंडीशन, जैसे \_अगर टिकट पर पहले से टैग लगा है तो इसे
छोड़ दें \_, कॉल को रोक नहीं सकती। अगर कॉल हर बार नहीं होनी चाहिए,
तो Tool स्टेप से पहले If स्टेप में कंडीशन रखें।

#### पैरामीटर वैल्यू का वर्णन करने के बजाय उन्हें तय करें

जब किसी पैरामीटर को हमेशा एक खास वैल्यू लेनी हो, तो उसे
`schema_overrides` में `constant` ओवरराइड से सेट करें। *स्टेटस को हमेशा pending पर सेट करें* जैसा निर्देश मॉडल से
पालन करने को कहता है; ओवरराइड लागू होता है और उसे छोड़ा नहीं जा सकता।

#### हर Tool स्टेप के लिए फेल्योर हैंडलर दें

`on_failure` के बिना, कोई भी टूल फेल होने पर बातचीत खत्म हो जाती है। ऐसा हैंडलर जोड़ें जो यूज़र को
बताए कि क्या हुआ और फिर दोबारा कोशिश करे, एस्केलेट करे या आगे बढ़े।

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

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

### निर्देश लिखना

#### सिर्फ मौजूदा स्टेप का वर्णन करें

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

#### गद्य से टर्न खत्म करने की कोशिश न करें

स्टेप निर्देशों में लिखे वाक्य, जैसे *यह इस टर्न का आखिरी संदेश है*,
एजेंट से ऐसी सीमा लागू करने को कहते हैं जो प्लेटफ़ॉर्म नहीं करता। यूज़र का इंतज़ार करने के लिए Ask स्टेप या
बातचीत खत्म करने के लिए `end_call` सिस्टम टूल इस्तेमाल करें।

#### ग्लोबल नियम सिस्टम प्रॉम्प्ट में रखें

टोन, फ़ॉर्मैटिंग, साइन-ऑफ और इनकार की नीतियां [सिस्टम प्रॉम्प्ट](/docs/hi/eleven-agents/best-practices/prompting-guide) में होती हैं। स्टेप निर्देश में सिर्फ वही लिखें
जो उस स्टेप के लिए खास हो।

### प्रोसिजर को संयोजित करना

प्रोसिजर को संयोजित करने के सामान्य निर्देश स्ट्रक्चर्ड प्रोसिजर पर भी लागू होते हैं; फ्री-फॉर्म प्रोसिजर पेज पर [प्रोसिजर को संयोजित करना](/docs/hi/eleven-agents/customization/procedures/free-form-procedures#composing-procedures) देखें।

एक पैटर्न खास तौर पर टाइप्स को मिलाने के लिए है: फ्री-फॉर्म प्रोसिजर किसी स्ट्रक्चर्ड प्रोसिजर को रेफ़र कर सकता है। खुले तौर पर संभालने वाले काम फ्री-फॉर्म प्रोसिजर में रखें और वे हिस्से जिन्हें हर बार एक ही तरीके से चलना चाहिए, जैसे पहचान की पुष्टि या एस्केलेशन, स्ट्रक्चर्ड प्रोसिजर को सौंपें।

## सीमाएं

* If स्टेप्स को नेस्ट नहीं किया जा सकता और दो If स्टेप्स को एक के बाद एक नहीं रखा जा सकता।
* केवल `end_call` सिस्टम टूल समर्थित है।
* स्ट्रक्चर्ड प्रोसिजर नॉलेज बेस डॉक्यूमेंट्स को रेफ़र नहीं कर सकते।
* प्रोसिजर पूरा होने पर मौजूदा टर्न खत्म करने का कोई तरीका नहीं है; एजेंट टर्न खुला रखता है और बोलना जारी रख सकता है।
* डैशबोर्ड में किसी खास वर्कफ़्लो नोड से स्ट्रक्चर्ड प्रोसिजर शुरू नहीं किया जा सकता।
* प्रोसिजर शुरू करने से लेटेंसी बढ़ती है: एजेंट इसमें प्रवेश करने के लिए टूल कॉल करता है और फिर जनरेटेड वर्कफ़्लो से आगे बढ़ता है।

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

स्ट्रक्चर्ड प्रोसिजर सब-प्रोसिजर में प्रवेश करते समय और प्रोसिजर पूरा करते समय इंटरनल टूल कॉल्स को फ़ोर्स करते हैं। प्रमुख OpenAI, Anthropic, Gemini और Grok मॉडल फैमिलीज़ फ़ोर्स्ड टूल चॉइस को सपोर्ट करती हैं। अन्य मॉडल या कस्टम प्रोवाइडर इसकी गारंटी नहीं दे सकते, जिससे सब-प्रोसिजर ट्रांज़िशन या प्रोसिजर पूरा होना कम भरोसेमंद हो सकता है। किसी दूसरे मॉडल प्रोवाइडर का इस्तेमाल करते समय फ़ोर्स्ड टूल-चॉइस सपोर्ट की पुष्टि करें।

कंटेंट साइज़ सीमा और स्ट्रक्चर्ड प्रोसिजर फ्री-फॉर्म प्रोसिजर से कैसे अलग हैं, सहित सभी प्रोसिजर पर लागू सीमाओं के लिए [प्रोसिजर](/docs/hi/eleven-agents/customization/procedures#limitations) देखें।