> 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.

# प्रॉम्प्टिंग गाइड

## परिचय

प्रभावी प्रॉम्प्टिंग [ElevenLabs Agents](/docs/hi/eleven-agents/overview) को रोबोटिक से जीवंत बनाती है।

![ElevenLabs Agents प्रॉम्प्टिंग गाइड](/docs/_fern-img/255df05f53675feaf54c765c4ee294fda00a7c14de1b02f155922012bf0a5433.webp)

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

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

> **अपने AI असिस्टेंट की मदद से प्रॉम्प्ट पर काम करें**
>
> [होस्टेड MCP सर्वर](/docs/hi/eleven-agents/operate/hosted-mcp) Claude और अन्य MCP क्लाइंट्स को
> किसी एजेंट का सिस्टम प्रॉम्प्ट सीधे पढ़ने और अपडेट करने देता है, ताकि आप बातचीत के ज़रिए प्रॉम्प्ट
> तैयार, समीक्षा और बेहतर कर सकें।

![एंटरप्राइज़ एजेंट विश्वसनीयता
फ्रेमवर्क](/docs/_fern-img/18c7dd3bf58a6715656d588834a278dbc1f368eaed2cbf91aeea3e977c2631ed.webp)

## प्रॉम्प्ट इंजीनियरिंग की बुनियादी बातें

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

ये सिद्धांत प्रोडक्शन-ग्रेड प्रॉम्प्ट इंजीनियरिंग की नींव हैं:

### निर्देशों को साफ़ सेक्शन में बांटें

Markdown हेडिंग के साथ निर्देशों को अलग-अलग सेक्शन में बांटने से मॉडल उन्हें सही प्राथमिकता देने और समझने में मदद मिलती है। निर्देश अलग करने के लिए खाली जगह और लाइन ब्रेक का इस्तेमाल करें।

**विश्वसनीयता के लिए यह क्यों ज़रूरी है:** मॉडल कुछ हेडिंग (खासकर `# Guardrails`) पर अतिरिक्त ध्यान देने के लिए ट्यून किए गए हैं, और स्पष्ट सेक्शन सीमाएं निर्देशों के मिश्रण को रोकती हैं, जहां एक संदर्भ के नियम दूसरे को प्रभावित करते हैं।

**`कम प्रभावी तरीका`**

```mdx title="कम प्रभावी तरीका"
You are a customer service agent. Be polite and helpful. Never share sensitive data. You can look up orders and process refunds. Always verify identity first. Keep responses under 3 sentences unless the user asks for details.
```

**`सुझाया गया तरीका`**

```mdx title="सुझाया गया तरीका"
# Personality

You are a customer service agent for Acme Corp. You are polite, efficient, and solution-oriented.

# Goal

Help customers resolve issues quickly by looking up orders and processing refunds when appropriate.

# Guardrails

Never share sensitive customer data across conversations.
Always verify customer identity before accessing account information.

# Tone

Keep responses concise (under 3 sentences) unless the user requests detailed explanations.
```

### जितना हो सके उतना संक्षिप्त रखें

हर निर्देश छोटा, स्पष्ट और कार्रवाई-आधारित रखें। फालतू शब्द हटाएं और केवल वही दोहराएं जो मॉडल के सही ढंग से काम करने के लिए ज़रूरी है।

**विश्वसनीयता के लिए यह क्यों ज़रूरी है:** संक्षिप्त निर्देश अस्पष्टता और टोकन उपयोग कम करते हैं। हर गैर-ज़रूरी शब्द गलत समझे जाने का संभावित कारण है।

**`कम प्रभावी तरीका`**

```mdx title="कम प्रभावी तरीका"
# Tone

When you're talking to customers, you should try to be really friendly and approachable, making sure that you're speaking in a way that feels natural and conversational, kind of like how you'd talk to a friend, but still maintaining a professional demeanor that represents the company well.
```

**`सुझाया गया तरीका`**

```mdx title="सुझाया गया तरीका"
# Tone

Speak in a friendly, conversational manner while maintaining professionalism.
```

> **Note**
>
> अगर आपको एजेंट से एक खास टोन बनाए रखने की ज़रूरत है, तो उसे `#
>   Personality` या `# Tone` सेक्शन में स्पष्ट और संक्षेप में परिभाषित करें। पूरे प्रॉम्प्ट में टोन से जुड़े निर्देश दोहराने से बचें।

### महत्वपूर्ण निर्देशों पर ज़ोर दें

लाइन के अंत में "This step is important" जोड़कर महत्वपूर्ण चरणों को हाइलाइट करें। प्रॉम्प्ट में सबसे महत्वपूर्ण 1-2 निर्देशों को दो बार दोहराने से उन पर ज़ोर देने में मदद मिल सकती है।

**विश्वसनीयता के लिए यह क्यों ज़रूरी है:** जटिल प्रॉम्प्ट में मॉडल पहले के निर्देशों के बजाय हाल के संदर्भ को प्राथमिकता दे सकते हैं। ज़ोर और दोहराव यह सुनिश्चित करते हैं कि महत्वपूर्ण नियम नज़रअंदाज़ न हों।

**`कम प्रभावी तरीका`**

```mdx title="कम प्रभावी तरीका"
# Goal

Verify customer identity before accessing their account.
Look up order details and provide status updates.
Process refund requests when eligible.
```

**`सुझाया गया तरीका`**

```mdx title="सुझाया गया तरीका"
# Goal

Verify customer identity before accessing their account. This step is important.
Look up order details and provide status updates.
Process refund requests when eligible.

# Guardrails

Never access account information without verifying customer identity first. This step is important.
```

### टेक्स्ट नॉर्मलाइज़ेशन

टेक्स्ट टू स्पीच मॉडल, खासकर तेज़ मॉडल, वर्णमाला वाले टेक्स्ट से स्पीच जनरेट करने में बेहतर होते हैं। इसलिए अंक और "@" या "£" जैसे प्रतीक गलत उच्चारण या वॉइस हैलुसिनेशन की संभावना बढ़ा सकते हैं।

इसे ठीक करने के लिए, हम TTS मॉडल तक पहुंचने से पहले गैर-वर्णमाला टेक्स्ट को शब्दों में नॉर्मलाइज़ करते हैं (जैसे, `123` -> `one-hundred and twenty three`, `john@gmail.com` -> `john at gmail dot com`) और आपको अलग-अलग समझौतों वाली विभिन्न नॉर्मलाइज़ेशन रणनीतियों में से चुनने देते हैं।

#### नॉर्मलाइज़ेशन रणनीतियां

हम [`text_normalisation_type`](/docs/hi/api-reference/agents/create#request.body.conversation_config.tts.text_normalisation_type) एजेंट कॉन्फ़िगरेशन के ज़रिए दो नॉर्मलाइज़ेशन रणनीतियों का समर्थन करते हैं:

**`system_prompt` (डिफ़ॉल्ट)** — सिस्टम प्रॉम्प्ट में निर्देश जोड़ता है, जो LLM को TTS मॉडल तक टेक्स्ट पहुंचने से पहले संख्याओं और प्रतीकों को शब्दों में लिखने के लिए कहते हैं।

* कोई अतिरिक्त लेटेंसी नहीं
* LLM कभी-कभी सही ढंग से नॉर्मलाइज़ नहीं कर सकते
* ट्रांसक्रिप्ट में सब कुछ शब्दों में लिखा होता है (जैसे, "\$1,000" के बजाय "one thousand dollars")

> **Tip**
>
> अगर आप TTS नॉर्मलाइज़र इस्तेमाल नहीं करना चाहते और देखते हैं कि LLM कभी-कभी अभी भी
> बिना नॉर्मलाइज़ किया टेक्स्ट भेजता है, तो अधिक बुद्धिमान LLM पर स्विच करने या सिस्टम प्रॉम्प्ट में
> अतिरिक्त नॉर्मलाइज़ेशन निर्देश जोड़ने पर विचार करें।

**`elevenlabs`** — LLM जनरेशन के बाद और TTS मॉडल तक पहुंचने से पहले टेक्स्ट को नॉर्मलाइज़ करने के लिए हमारे [TTS नॉर्मलाइज़र](/docs/hi/overview/capabilities/text-to-speech/best-practices#text-normalization) का इस्तेमाल करता है।

* LLM-आधारित नॉर्मलाइज़ेशन से अधिक विश्वसनीय
* सिस्टम प्रॉम्प्ट में बदलाव नहीं होता
* ट्रांसक्रिप्ट में प्रतीकों और संख्याओं के साथ स्वाभाविक फ़ॉर्मैटिंग बनी रहती है (जैसे, "\$1,000")
* थोड़ी लेटेंसी जोड़ता है

> **Tip**
>
> अगर आपके उपयोग के मामले में ट्रांसक्रिप्ट की पठनीयता महत्वपूर्ण है, तो `elevenlabs` नॉर्मलाइज़र इस्तेमाल करने पर विचार करें। यह
> ट्रांसक्रिप्ट को स्वाभाविक प्रतीकों और संख्याओं के साथ साफ़ रखता है, साथ ही सही तरह से बोला गया
> ऑडियो भी देता है।

यह कॉन्फ़िगरेशन हमारे प्लैटफ़ॉर्म में "Agent" टैब के तहत मिलेगा। "Voices" सेक्शन में कॉग आइकन पर क्लिक करके सामान्य वॉइस सेटिंग्स शीट खोलें और नीचे इसे कॉन्फ़िगर करें।

#### टूल इनपुट के लिए संरचित डेटा

`system_prompt` नॉर्मलाइज़ेशन सेटिंग का उपयोग करने पर LLM अपने जवाबों में प्रतीकों और संख्याओं को शब्दों में लिखता है (जैसे, `john@gmail.com` के बजाय `john at gmail dot com`)। स्पीच टू टेक्स्ट से मिली यूज़र ट्रांसक्रिप्शन भी गैर-मानक रूप में आ सकती हैं। इसका मतलब है कि टूल कॉल में इन विवरणों को पैरामीटर के रूप में इस्तेमाल करते समय LLM बातचीत के संदर्भ में मौजूद असंरचित संस्करण का उपयोग कर सकता है।

अगर किसी टूल पैरामीटर को सही फ़ॉर्मैट वाला मान चाहिए (जैसे, `john at gmail dot com` नहीं, बल्कि `john@gmail.com`), तो LLM को यह पता होना चाहिए। उदाहरण के साथ अपेक्षित फ़ॉर्मैट सीधे टूल पैरामीटर के विवरण में शामिल करें।

**`कम प्रभावी: अस्पष्ट पैरामीटर विवरण`**

```mdx title="कम प्रभावी: अस्पष्ट पैरामीटर विवरण"
## `lookupAccount` tool parameters

- `email` (required): "The user's email."
- `phone` (required): "The user's phone number."
- `confirmation_code` (required): "The user's confirmation code."
```

**`सुझाया गया: पैरामीटर विवरण में स्पष्ट फ़ॉर्मैट`**

```mdx title="सुझाया गया: पैरामीटर विवरण में स्पष्ट फ़ॉर्मैट"
## `lookupAccount` tool parameters

- `email` (required): "The user's email in standard email format, e.g. 'john@gmail.com'."
- `phone` (required): "The user's phone number as digits only, e.g. '5551234567'."
- `confirmation_code` (required): "The user's confirmation code as a single alphanumeric string without spaces, e.g. 'ABC123'."
```

### गार्डरेल्स के लिए अलग सेक्शन रखें

मॉडल को हमेशा मानने वाले सभी गैर-परक्राम्य नियम एक अलग `# Guardrails` सेक्शन में सूचीबद्ध करें। मॉडल इस हेडिंग पर अतिरिक्त ध्यान देने के लिए ट्यून किए गए हैं।

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

**`सुझाया गया तरीका`**

```mdx title="सुझाया गया तरीका"
# Guardrails

Never share customer data across conversations or reveal sensitive account information without proper verification.
Never process refunds over $500 without supervisor approval.
Never make promises about delivery dates that aren't confirmed in the order system.
Acknowledge when you don't know an answer instead of guessing.
If a customer becomes abusive, politely end the conversation and offer to escalate to a supervisor.
```

प्रभावी गार्डरेल्स डिज़ाइन करने के बारे में अधिक जानने के लिए, हमारी [गार्डरेल्स](/docs/hi/eleven-agents/best-practices/guardrails) गाइड देखें।

## विश्वसनीयता के लिए टूल कॉन्फ़िगरेशन

लेन-देन वाले वर्कफ़्लो संभालने में सक्षम एजेंट बेहद प्रभावी हो सकते हैं। इसे संभव बनाने के लिए, उन्हें ऐसे टूल से लैस होना चाहिए जो उन्हें दूसरे सिस्टम में कार्रवाइयां करने या उनसे लाइव डेटा लाने दें।

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

### विस्तृत पैरामीटर के साथ टूल का सटीक वर्णन करें

टूल बनाते समय, सभी पैरामीटर में विवरण जोड़ें। इससे LLM को सटीक टूल कॉल बनाने में मदद मिलती है।

**टूल विवरण:** "ऑर्डर ID से ग्राहक के ऑर्डर की स्थिति खोजता है और वर्तमान स्थिति, अनुमानित डिलीवरी तारीख और ट्रैकिंग नंबर देता है।"

**पैरामीटर विवरण:**

* `order_id` (ज़रूरी): "अद्वितीय ऑर्डर पहचानकर्ता, लिखे गए अक्षरों के रूप में फ़ॉर्मैट किया हुआ (जैसे, 'ORD123456')"
* `include_history` (वैकल्पिक): "अगर true है, तो स्थिति में हुए बदलावों सहित पूरा ऑर्डर इतिहास देता है"

**विश्वसनीयता के लिए यह क्यों ज़रूरी है:** पैरामीटर विवरण मॉडल के लिए इनलाइन दस्तावेज़ के रूप में काम करते हैं। ये फ़ॉर्मैट की अपेक्षाएं, ज़रूरी और वैकल्पिक फ़ील्ड, और स्वीकार्य मान स्पष्ट करते हैं।

### सिस्टम प्रॉम्प्ट में बताएं कि हर टूल का उपयोग कब और कैसे करना है

अपने सिस्टम प्रॉम्प्ट में स्पष्ट रूप से परिभाषित करें कि हर टूल का उपयोग कब और कैसे होना चाहिए। सिर्फ़ टूल विवरण पर निर्भर न रहें—उपयोग का संदर्भ और क्रम तय करने का तर्क भी दें।

**`सुझाया गया तरीका`**

```mdx title="सुझाया गया तरीका"
# Tools

You have access to the following tools:

## `getOrderStatus`

Use this tool when a customer asks about their order. Always call this tool before providing order information—never rely on memory or assumptions.

**When to use:**

- Customer asks "Where is my order?"
- Customer provides an order number
- Customer asks about delivery estimates

**How to use:**

1. Collect the order ID from the customer
2. Call `getOrderStatus` with the order ID
3. Present the results to the customer in natural language

**Error handling:**
If the tool returns "Order not found", ask the customer to verify the order number and try again.

## `processRefund`

Use this tool only after verifying:

1. Customer identity has been confirmed
2. Order is eligible for refund (within 30 days, not already refunded)
3. Refund amount is under $500 (escalate to supervisor if over $500)

**Required before calling:**

- Order ID (from `getOrderStatus`)
- Refund reason code
- Customer confirmation

This step is important: Always confirm refund details with the customer before calling this tool.
```

### टूल पैरामीटर विवरण में अपेक्षित फ़ॉर्मैट बताएं

जब टूल को संरचित पहचानकर्ता (ईमेल, फ़ोन नंबर, कोड) चाहिए हों, तो उदाहरण के साथ पैरामीटर विवरण में अपेक्षित फ़ॉर्मैट साफ़ तौर पर बताएं। यह खास तौर पर महत्वपूर्ण है क्योंकि नॉर्मलाइज़ेशन और स्पीच टू टेक्स्ट ट्रांसक्रिप्शन बातचीत के संदर्भ में बोले गए रूप वाले मान बना सकते हैं। पृष्ठभूमि के लिए [टूल इनपुट के लिए संरचित डेटा](#structured-data-for-tool-inputs) देखें।

**`कम प्रभावी: अस्पष्ट पैरामीटर विवरण`**

```mdx title="कम प्रभावी: अस्पष्ट पैरामीटर विवरण"
## `lookupAccount` tool parameters

- `email` (required): "The customer's email address."
```

**`सुझाया गया: उदाहरण के साथ स्पष्ट फ़ॉर्मैट`**

```mdx title="सुझाया गया: उदाहरण के साथ स्पष्ट फ़ॉर्मैट"
## `lookupAccount` tool parameters

- `email` (required): "The customer's email in standard email format, e.g. 'john.smith@company.com'."
```

### टूल कॉल विफलताओं को आसानी से संभालें

नेटवर्क समस्याओं, डेटा न मिलने या अन्य त्रुटियों की वजह से टूल कभी-कभी विफल हो सकते हैं। रिकवरी के लिए अपने सिस्टम प्रॉम्प्ट में स्पष्ट निर्देश शामिल करें।

**विश्वसनीयता के लिए यह क्यों ज़रूरी है:** प्रोडक्शन में टूल विफलताएं अपरिहार्य हैं। स्पष्ट हैंडलिंग निर्देशों के बिना, एजेंट जवाब गढ़ सकते हैं या गलत जानकारी दे सकते हैं।

**`सुझाया गया तरीका`**

```mdx title="सुझाया गया तरीका"
# Tool error handling

If any tool call fails or returns an error:

1. Acknowledge the issue to the customer: "I'm having trouble accessing that information right now."
2. Do not guess or make up information
3. Offer alternatives:
   - Try the tool again if it might be a temporary issue
   - Offer to escalate to a human agent
   - Provide a callback option
4. If the error persists after 2 attempts, escalate to a supervisor

**Example responses:**

- "I'm having trouble looking up that order right now. Let me try again... [retry]"
- "I'm unable to access the order system at the moment. I can transfer you to a specialist who can help, or we can schedule a callback. Which would you prefer?"
```

विश्वसनीय टूल इंटीग्रेशन बनाने के विस्तृत निर्देशों के लिए, [क्लाइंट टूल्स](/docs/hi/eleven-agents/customization/tools/client-tools), [वेबहुक टूल्स](/docs/hi/eleven-agents/customization/tools/webhook-tools) और [MCP टूल्स](/docs/hi/eleven-agents/customization/tools/mcp) पर हमारा दस्तावेज़ देखें।

## एंटरप्राइज़ एजेंट के लिए आर्किटेक्चर पैटर्न

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

### एजेंट को विशेषज्ञ बनाए रखें

बहुत व्यापक निर्देश या बड़े कॉन्टेक्स्ट विंडो लेटेंसी बढ़ाते हैं और सटीकता घटाते हैं। हर एजेंट के पास संकीर्ण, स्पष्ट रूप से परिभाषित नॉलेज बेस और ज़िम्मेदारियों का सेट होना चाहिए।

**विश्वसनीयता के लिए यह क्यों ज़रूरी है:** विशेषज्ञ एजेंट के लिए संभालने को कम एज केस होते हैं, सफलता के मानदंड साफ़ होते हैं और जवाब का समय तेज़ होता है। उनका परीक्षण, डीबग और सुधार करना आसान होता है।

> **Note**
>
> सामान्य उद्देश्य वाला "सब कुछ करने वाला" एजेंट, स्पष्ट हैंडऑफ़ वाले विशेषज्ञ एजेंटों के नेटवर्क की तुलना में,
> बनाए रखना कठिन होता है और प्रोडक्शन में विफल होने की संभावना अधिक होती है।

### ऑर्केस्ट्रेटर और विशेषज्ञ पैटर्न का उपयोग करें

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

**आर्किटेक्चर पैटर्न:**

1. **ऑर्केस्ट्रेटर एजेंट:** इंटेंट क्लासिफ़िकेशन के आधार पर आने वाले अनुरोधों को सही विशेषज्ञ एजेंट तक भेजता है
2. **विशेषज्ञ एजेंट:** डोमेन-विशिष्ट कार्य संभालते हैं (बिलिंग, शेड्यूलिंग, तकनीकी सहायता आदि)
3. **मानव एस्केलेशन:** जटिल या संवेदनशील मामलों के लिए तय हैंडऑफ़ मानदंड

**इस पैटर्न के फ़ायदे:**

* हर विशेषज्ञ के पास केंद्रित प्रॉम्प्ट और कम संदर्भ होता है
* सिस्टम को प्रभावित किए बिना अलग-अलग विशेषज्ञों को अपडेट करना आसान होता है
* हर डोमेन के लिए स्पष्ट मेट्रिक्स (बिलिंग समाधान दर, शेड्यूलिंग सफलता दर आदि)
* हर इंटरैक्शन में कम लेटेंसी (छोटे प्रॉम्प्ट, तेज़ इन्फ़रेंस)

### स्पष्ट हैंडऑफ़ मानदंड तय करें

मल्टी-एजेंट वर्कफ़्लो डिज़ाइन करते समय, साफ़ बताएं कि एजेंटों के बीच या मानव ऑपरेटर को नियंत्रण कब और कैसे ट्रांसफ़र होना चाहिए।

**`ऑर्केस्ट्रेटर एजेंट का उदाहरण`**

```mdx title="ऑर्केस्ट्रेटर एजेंट का उदाहरण"
# Goal

Route customer requests to the appropriate specialist agent based on intent.

## Routing logic

**Billing specialist:** Customer mentions payment, invoice, refund, charge, subscription, or account balance
**Technical support specialist:** Customer reports error, bug, issue, not working, broken
**Scheduling specialist:** Customer wants to book, reschedule, cancel, or check appointment
**Human escalation:** Customer is angry, requests supervisor, or issue is unresolved after 2 specialist attempts

## Handoff process

1. Classify customer intent based on first message
2. Provide brief acknowledgment: "I'll connect you with our [billing/technical/scheduling] team."
3. Transfer conversation with context summary:
   - Customer name
   - Primary issue
   - Any account identifiers already collected
4. Do not repeat information collection that already occurred
```

**`विशेषज्ञ एजेंट का उदाहरण`**

```mdx title="विशेषज्ञ एजेंट का उदाहरण"
# Personality

You are a billing specialist for Acme Corp. You handle payment issues, refunds, and subscription changes.

# Goal

Resolve billing inquiries by:

1. Verifying customer identity
2. Looking up account and billing history
3. Processing refunds (under $500) or escalating (over $500)
4. Updating subscription settings when requested

# Guardrails

Never access account information without identity verification.
Never process refunds over $500 without supervisor approval.
If the customer's issue is not billing-related, transfer back to the orchestrator agent.
```

मल्टी-एजेंट वर्कफ़्लो बनाने के विस्तृत निर्देशों के लिए, [वर्कफ़्लो](/docs/hi/eleven-agents/customization/agent-workflows) पर हमारा दस्तावेज़ देखें।

## एंटरप्राइज़ विश्वसनीयता के लिए मॉडल चयन

सही मॉडल चुनना आपकी प्रदर्शन आवश्यकताओं—खासकर लेटेंसी, सटीकता और टूल-कॉलिंग विश्वसनीयता—पर निर्भर करता है। अलग-अलग मॉडल स्पीड, रीजनिंग क्षमता और लागत के बीच अलग-अलग संतुलन देते हैं।

### समझौतों को समझें

**लेटेंसी:** छोटे मॉडल (कम पैरामीटर वाले) आमतौर पर तेज़ जवाब देते हैं, इसलिए वे अधिक बार होने वाले, कम जटिल इंटरैक्शन के लिए उपयुक्त हैं।

**सटीकता:** बड़े मॉडल बेहतर रीजनिंग क्षमता देते हैं और जटिल, मल्टी-स्टेप कार्यों को बेहतर ढंग से संभालते हैं, लेकिन उनकी लेटेंसी और लागत अधिक होती है।

**टूल-कॉलिंग विश्वसनीयता:** सभी मॉडल टूल/फ़ंक्शन कॉलिंग को समान सटीकता से नहीं संभालते। कुछ संरचित आउटपुट में बेहतर होते हैं, जबकि अन्य को अधिक स्पष्ट प्रॉम्प्टिंग की ज़रूरत पड़ सकती है।

### उपयोग के मामले के अनुसार मॉडल सुझाव

लाखों एजेंट इंटरैक्शन पर हुए डिप्लॉयमेंट के आधार पर, ये पैटर्न सामने आते हैं:

* **GLM 5.2 या GPT-6 Luna (सुझाया गया शुरुआती विकल्प):** सामान्य उद्देश्य वाले एंटरप्राइज़ एजेंट के लिए सबसे अच्छा, जहां लेटेंसी, सटीकता और लागत—तीनों में संतुलन ज़रूरी हो। मज़बूत टूल-कॉलिंग प्रदर्शन और प्रति इंटरैक्शन उचित लागत के साथ कम से मध्यम लेटेंसी देता है। ग्राहक सहायता, शेड्यूलिंग, ऑर्डर मैनेजमेंट और सामान्य पूछताछ संभालने के लिए आदर्श।

* **DeepSeek Flash 4.1 या Gemini 3.5 Flash-Lite (बहुत कम लेटेंसी):** अधिक बार होने वाले, सरल इंटरैक्शन के लिए सबसे अच्छा, जहां स्पीड बहुत महत्वपूर्ण हो। व्यापक सामान्य ज्ञान के साथ सबसे कम लेटेंसी देता है, हालांकि जटिल टूल-कॉलिंग में प्रदर्शन कम हो सकता है। शुरुआती रूटिंग/ट्राइएज, सरल FAQ, अपॉइंटमेंट पुष्टि और बुनियादी डेटा संग्रह के लिए बड़े पैमाने पर किफ़ायती।

* **Claude Sonnet 5.5 (जटिल रीजनिंग):** मल्टी-स्टेप समस्या समाधान, सूक्ष्म निर्णय और जटिल टूल ऑर्केस्ट्रेशन के लिए सबसे अच्छा। बेहतरीन टूल-कॉलिंग विश्वसनीयता के साथ सबसे अधिक सटीकता और रीजनिंग क्षमता देता है, लेकिन लेटेंसी और लागत अधिक होती है। ऐसे कामों के लिए आदर्श जहां गलतियां महंगी हों, जैसे तकनीकी ट्रबलशूटिंग, वित्तीय सलाह, अनुपालन-संवेदनशील वर्कफ़्लो और जटिल रिफ़ंड/एस्केलेशन निर्णय।

प्रोवाइडर के मॉडल लाइनअप अक्सर बदलते रहते हैं। किसी मॉडल को प्रोडक्शन के लिए चुनने से पहले [मॉडल्स](/docs/hi/eleven-agents/customization/llm) पेज पर मौजूदा विकल्प और कीमतों की पुष्टि करें।

### अपने वास्तविक प्रॉम्प्ट के साथ बेंचमार्क करें

मॉडल का प्रदर्शन प्रॉम्प्ट संरचना और कार्य की जटिलता के आधार पर काफी बदलता है। किसी मॉडल को चुनने से पहले:

1. अपने वास्तविक सिस्टम प्रॉम्प्ट के साथ 2-3 उम्मीदवार मॉडल टेस्ट करें
2. वास्तविक यूज़र क्वेरी या सिंथेटिक टेस्ट केस पर मूल्यांकन करें
3. लेटेंसी, सटीकता और टूल-कॉलिंग सफलता दर मापें
4. अपनी खास ज़रूरतों के हिसाब से सबसे अच्छे संतुलन के लिए ऑप्टिमाइज़ करें

मॉडल कॉन्फ़िगरेशन विकल्पों के विस्तृत विवरण के लिए, हमारा [मॉडल्स दस्तावेज़](/docs/hi/eleven-agents/customization/llm) देखें।

## पुनरावृत्ति और परीक्षण

प्रोडक्शन में विश्वसनीयता लगातार पुनरावृत्ति से आती है। अच्छी तरह बनाए गए प्रॉम्प्ट भी वास्तविक उपयोग में विफल हो सकते हैं। महत्वपूर्ण यह है कि उन विफलताओं से सीखें और व्यवस्थित परीक्षण से सुधार करें।

### मूल्यांकन मानदंड कॉन्फ़िगर करें

समय के साथ सफलता पर नज़र रखने और रिग्रेशन जांचने के लिए हर एजेंट में ठोस मूल्यांकन मानदंड जोड़ें।

**ट्रैक करने के लिए मुख्य मेट्रिक्स:**

* **कार्य पूरा होने की दर:** सफलतापूर्वक संबोधित किए गए यूज़र इंटेंट का प्रतिशत
* **एस्केलेशन दर:** मानव हस्तक्षेप की ज़रूरत वाली बातचीत का प्रतिशत

ElevenLabs में मूल्यांकन मानदंड कॉन्फ़िगर करने के विस्तृत निर्देशों के लिए, [सफलता मूल्यांकन](/docs/hi/eleven-agents/customization/agent-analysis/success-evaluation) देखें।

### विफलता पैटर्न का विश्लेषण करें

जब एजेंट उम्मीद के मुताबिक प्रदर्शन न करें, तो समस्याग्रस्त इंटरैक्शन में पैटर्न पहचानें:

* **एजेंट गलत जानकारी कहां देता है?** → खास सेक्शन में निर्देश मज़बूत करें
* **यह यूज़र का इंटेंट कब समझने में विफल होता है?** → उदाहरण जोड़ें या भाषा सरल करें
* **कौन-से यूज़र इनपुट इसके चरित्र से बाहर होने का कारण बनते हैं?** → एज केस के लिए गार्डरेल्स जोड़ें
* **कौन-से टूल सबसे ज़्यादा विफल होते हैं?** → एरर हैंडलिंग या पैरामीटर विवरण बेहतर करें

उन बातचीत ट्रांसक्रिप्ट की समीक्षा करें जहां यूज़र संतुष्टि कम रही या कार्य पूरे नहीं हुए।

### लक्षित सुधार करें

पहचानी गई समस्याओं को हल करने के लिए अपने प्रॉम्प्ट के खास सेक्शन अपडेट करें:

1. **समस्या को अलग करें:** पहचानें कि कौन-सा प्रॉम्प्ट सेक्शन या टूल परिभाषा विफलता का कारण है
2. **खास उदाहरणों पर बदलाव टेस्ट करें:** पहले विफल हुई बातचीत को टेस्ट केस के रूप में इस्तेमाल करें
3. **एक बार में एक बदलाव करें:** यह समझने के लिए सुधार अलग रखें कि क्या काम कर रहा है
4. **उन्हीं टेस्ट केस के साथ फिर से मूल्यांकन करें:** जांचें कि बदलाव ने नई समस्याएं पैदा किए बिना समस्या ठीक कर दी है

> **Warning**
>
> एक साथ कई प्रॉम्प्ट बदलाव करने से बचें। इससे किसी खास बदलाव के कारण हुए
> सुधार या रिग्रेशन को पहचानना असंभव हो जाता है।

### डेटा संग्रह कॉन्फ़िगर करें

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

ElevenLabs में डेटा संग्रह कॉन्फ़िगर करने के विस्तृत निर्देशों के लिए, [डेटा संग्रह](/docs/hi/eleven-agents/customization/agent-analysis/data-collection) देखें।

### रिग्रेशन परीक्षण के लिए सिमुलेशन का उपयोग करें

प्रॉम्प्ट बदलावों को प्रोडक्शन में डिप्लॉय करने से पहले, रिग्रेशन पकड़ने के लिए ज्ञात परिदृश्यों के एक सेट पर टेस्ट करें।

एजेंट को प्रोग्रामेटिक रूप से टेस्ट करने के निर्देशों के लिए, [बातचीत सिमुलेट करें](/docs/hi/eleven-agents/guides/simulate-conversation) देखें।

## प्रोडक्शन संबंधी बातें

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

### सभी टूल इंटीग्रेशन में त्रुटियों को संभालें

हर बाहरी टूल कॉल विफलता का संभावित बिंदु है। सुनिश्चित करें कि आपके प्रॉम्प्ट में इनके लिए स्पष्ट एरर हैंडलिंग शामिल हो:

* **नेटवर्क विफलताएं:** "मुझे हमारे सिस्टम से कनेक्ट करने में समस्या हो रही है। मैं फिर से कोशिश करता हूं।"
* **डेटा उपलब्ध नहीं है:** "मुझे हमारे सिस्टम में वह जानकारी नहीं दिख रही है। क्या आप विवरण की पुष्टि कर सकते हैं?"
* **टाइमआउट त्रुटियां:** "इसमें उम्मीद से ज़्यादा समय लग रहा है। मैं इसे किसी विशेषज्ञ को एस्केलेट कर सकता हूं या फिर से कोशिश कर सकता हूं।"
* **अनुमति त्रुटियां:** "मेरे पास उस जानकारी का एक्सेस नहीं है। मैं आपको ऐसे व्यक्ति के पास ट्रांसफ़र करता हूं जो मदद कर सकता है।"

## उदाहरण प्रॉम्प्ट

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

### उदाहरण 1: तकनीकी सहायता एजेंट

**`तकनीकी सहायता विशेषज्ञ`**

```mdx title="तकनीकी सहायता विशेषज्ञ" maxLines=60
# Personality

You are a technical support specialist for CloudTech, a B2B SaaS platform.
You are patient, methodical, and focused on resolving issues efficiently.
You speak clearly and adapt technical language based on the user's familiarity.

# Environment

You are assisting customers via phone support.
Customers may be experiencing service disruptions and could be frustrated.
You have access to diagnostic tools and the customer account database.

# Tone

Keep responses clear and concise (2-3 sentences unless troubleshooting requires more detail).
Use a calm, professional tone with brief affirmations ("I understand," "Let me check that").
Adapt technical depth based on customer responses.
Check for understanding after complex steps: "Does that make sense?"

# Goal

Resolve technical issues through structured troubleshooting:

1. Verify customer identity using email and account ID
2. Identify affected service and severity level
3. Run diagnostics using `runSystemDiagnostic` tool
4. Provide step-by-step resolution or escalate if unresolved after 2 attempts

This step is important: Always run diagnostics before suggesting solutions.

# Guardrails

Never access customer accounts without identity verification. This step is important.
Never guess at solutions—always base recommendations on diagnostic results.
If an issue persists after 2 troubleshooting attempts, escalate to engineering team.
Acknowledge when you don't know the answer instead of speculating.

# Tools

## `verifyCustomerIdentity`

**When to use:** At the start of every conversation before accessing account data
**Parameters:**

- `email` (required): Customer email in standard written format (e.g., "user@company.com"). Convert from spoken format: "at" → "@", "dot" → ".", remove spaces between words.
- `account_id` (optional): Account ID if customer provides it

**Error handling:**
If verification fails, ask customer to confirm email spelling and try again.

## `runSystemDiagnostic`

**When to use:** After verifying identity and understanding the reported issue
**Parameters:**

- `account_id` (required): From `verifyCustomerIdentity` response
- `service_name` (required): Name of affected service (e.g., "api", "dashboard", "storage")

**Usage:**

1. Confirm which service is affected
2. Run diagnostic with account ID and service name
3. Review results before providing solution

**Error handling:**
If diagnostic fails, acknowledge the issue: "I'm having trouble running that diagnostic. Let me escalate to our engineering team."

# Error handling

If any tool call fails:

1. Acknowledge: "I'm having trouble accessing that information right now."
2. Do not guess or make up information
3. Offer to retry once, then escalate if failure persists
```

**दिखाए गए सिद्धांत:**

* ✓ साफ़ सेक्शन विभाजन (`# Personality`, `# Goal`, `# Tools` आदि)
* ✓ हर लाइन में एक कार्रवाई (`# Goal` के क्रमांकित चरण देखें)
* ✓ संक्षिप्त निर्देश (टोन सेक्शन छोटा और स्पष्ट है)
* ✓ महत्वपूर्ण चरणों पर ज़ोर ("This step is important")
* ✓ पैरामीटर विवरण में फ़ॉर्मैट कन्वर्ज़न (ईमेल नॉर्मलाइज़ेशन)
* ✓ अलग गार्डरेल्स सेक्शन
* ✓ कब/कैसे/त्रुटि संबंधी निर्देशों के साथ सटीक टूल विवरण
* ✓ स्पष्ट एरर हैंडलिंग निर्देश

### उदाहरण 2: ग्राहक सेवा रिफ़ंड एजेंट

**`रिफ़ंड प्रोसेसिंग विशेषज्ञ`**

```mdx title="रिफ़ंड प्रोसेसिंग विशेषज्ञ" maxLines=50
# Personality

You are a refund specialist for RetailCo.
You are empathetic, solution-oriented, and efficient.
You balance customer satisfaction with company policy compliance.

# Goal

Process refund requests through this workflow:

1. Verify customer identity using order number and email
2. Look up order details with `getOrderDetails` tool
3. Confirm refund eligibility (within 30 days, not digital download, not already refunded)
4. For refunds under $100: Process immediately with `processRefund` tool
5. For refunds $100-$500: Apply secondary verification, then process
6. For refunds over $500: Escalate to supervisor with case summary

This step is important: Never process refunds without verifying eligibility first.

# Guardrails

Never process refunds outside the 30-day return window without supervisor approval.
Never process refunds over $500 without supervisor approval. This step is important.
Never access order information without verifying customer identity.
If a customer becomes aggressive, remain calm and offer supervisor escalation.

# Tools

## `verifyIdentity`

**When to use:** At the start of every conversation
**Parameters:**

- `order_id` (required): Order ID in uppercase alphanumeric format (e.g., "ORD123456"). Convert from spoken format: spell out letters and spoken digits to written form, no spaces.
- `email` (required): Customer email in standard written format (e.g., "john.smith@retailco.com"). Convert from spoken format: "at" → "@", "dot" → ".", remove spaces between words.

## `getOrderDetails`

**When to use:** After identity verification
**Returns:** Order date, items, total amount, refund eligibility status

**Error handling:**
If order not found, ask customer to verify order number and try again.

## `processRefund`

**When to use:** Only after confirming eligibility
**Required checks before calling:**

- Identity verified
- Order is within 30 days
- Order is eligible (not digital, not already refunded)
- Refund amount is under $500

**Parameters:**

- `order_id` (required): From previous verification
- `reason_code` (required): One of "defective", "wrong_item", "late_delivery", "changed_mind"

**Usage:**

1. Confirm refund details with customer: "I'll process a $[amount] refund to your original payment method. It will appear in 3-5 business days. Does that work for you?"
2. Wait for customer confirmation
3. Call this tool

**Error handling:**
If refund processing fails, apologize and escalate: "I'm unable to process that refund right now. Let me escalate to a supervisor who can help."
```

**दिखाए गए सिद्धांत:**

* ✓ विशेषज्ञ एजेंट का दायरा (सिर्फ़ रिफ़ंड, सामान्य सहायता नहीं)
* ✓ `# Goal` सेक्शन में स्पष्ट वर्कफ़्लो चरण
* ✓ महत्वपूर्ण नियमों पर बार-बार ज़ोर (रिफ़ंड सीमा, सत्यापन)
* ✓ "कब उपयोग करें" और "ज़रूरी जांच" के साथ विस्तृत टूल उपयोग
* ✓ पैरामीटर विवरण में फ़ॉर्मैट कन्वर्ज़न (ऑर्डर ID, ईमेल)
* ✓ हर टूल के लिए स्पष्ट एरर हैंडलिंग
* ✓ एस्केलेशन मानदंड स्पष्ट रूप से परिभाषित

## फ़ॉर्मैटिंग के सर्वोत्तम तरीके

आप अपने प्रॉम्प्ट को कैसे फ़ॉर्मैट करते हैं, इससे भाषा मॉडल उसे कितनी प्रभावी ढंग से समझता है, इस पर असर पड़ता है:

* **Markdown हेडिंग्स इस्तेमाल करें:** मुख्य सेक्शन के लिए `#` और उप-सेक्शन के लिए `##` इस्तेमाल करके सेक्शन व्यवस्थित करें
* **बुलेटेड लिस्ट को प्राथमिकता दें:** निर्देशों को आसानी से समझे जाने वाले बुलेट पॉइंट्स में बाँटें
* **व्हाइटस्पेस इस्तेमाल करें:** खाली लाइनों से सेक्शन और निर्देशों के समूह अलग करें
* **हेडिंग्स को sentence case में रखें:** `# Goal` लिखें, `# GOAL` नहीं
* **एकरूप रहें:** पूरे प्रॉम्प्ट में एक ही फ़ॉर्मैटिंग पैटर्न इस्तेमाल करें

## अक्सर पूछे जाने वाले सवाल

#### मैं कई एजेंट्स के बीच एकरूपता कैसे बनाए रखूँ?

कैरेक्टर नॉर्मलाइज़ेशन, एरर हैंडलिंग और गार्डरेल्स जैसे सामान्य सेक्शन के लिए साझा प्रॉम्प्ट टेम्प्लेट्स बनाएं।
इन्हें एक केंद्रीय रिपॉज़िटरी में रखें और विशेषज्ञ एजेंट्स में इनका संदर्भ दें।
एकरूप रूटिंग लॉजिक और हैंडऑफ़ प्रक्रियाएं सुनिश्चित करने के लिए ऑर्केस्ट्रेटर पैटर्न इस्तेमाल करें।

#### प्रोडक्शन के लिए न्यूनतम व्यवहार्य प्रॉम्प्ट क्या है?

कम से कम ये शामिल करें: (1) पर्सनैलिटी/रोल की परिभाषा, (2) मुख्य लक्ष्य, (3) मुख्य गार्डरेल्स और
(4) अगर टूल्स इस्तेमाल हो रहे हैं, तो उनके विवरण। साधारण एजेंट्स को भी स्पष्ट सेक्शन
संरचना और एरर हैंडलिंग निर्देशों का लाभ मिलता है।

#### एजेंट्स को प्रभावित किए बिना टूल डिप्रिकेशन कैसे संभालूँ?

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

#### क्या अलग-अलग LLMs के लिए अलग प्रॉम्प्ट इस्तेमाल करने चाहिए?

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

#### मेरा सिस्टम प्रॉम्प्ट कितना लंबा होना चाहिए?

कोई सार्वभौमिक सीमा नहीं है, लेकिन 2000 टोकन्स से लंबे प्रॉम्प्ट लेटेंसी और लागत बढ़ाते हैं। संक्षिप्तता पर ध्यान दें:
हर लाइन का एक स्पष्ट उद्देश्य होना चाहिए। अगर आपका प्रॉम्प्ट 2000 टोकन्स से अधिक है, तो उसे
कई विशेषज्ञ एजेंट्स में बाँटने या रेफ़रेंस सामग्री को नॉलेज बेस में रखने पर विचार करें।

#### मैं एकरूपता और अनुकूलनशीलता के बीच संतुलन कैसे बनाऊँ?

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

#### क्या मैं डिप्लॉयमेंट के बाद प्रॉम्प्ट अपडेट कर सकता हूँ?

हाँ। व्यवहार को समायोजित करने के लिए सिस्टम प्रॉम्प्ट्स को किसी भी समय बदला जा सकता है। यह खास तौर पर
उभरती समस्याओं को हल करने या यूज़र इंटरैक्शन से सीखते हुए क्षमताओं को बेहतर बनाने के लिए उपयोगी है।
प्रोडक्शन में डिप्लॉय करने से पहले बदलावों को हमेशा स्टेजिंग एनवायरनमेंट में टेस्ट करें।

#### टूल्स के विफल होने पर मैं एजेंट्स को हैलुसिनेट करने से कैसे रोकूँ?

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

## अगले चरण

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

* **[वर्कफ़्लोज़](/docs/hi/eleven-agents/customization/agent-workflows):** मल्टी-एजेंट ऑर्केस्ट्रेशन और विशेषज्ञ हैंडऑफ़ डिज़ाइन करें
* **[सफलता मूल्यांकन](/docs/hi/eleven-agents/customization/agent-analysis/success-evaluation):** मेट्रिक्स और मूल्यांकन मानदंड कॉन्फ़िगर करें
* **[डेटा कलेक्शन](/docs/hi/eleven-agents/customization/agent-analysis/data-collection):** बातचीत से संरचित इनसाइट्स कैप्चर करें
* **[टेस्टिंग](/docs/hi/eleven-agents/customization/agent-testing):** रिग्रेशन टेस्टिंग और सिमुलेशन लागू करें
* **[गार्डरेल्स](/docs/hi/eleven-agents/best-practices/guardrails):** सुरक्षित एजेंट प्रतिक्रियाओं के लिए कंटेंट मॉडरेशन कॉन्फ़िगर करें
* **[प्राइवेसी](/docs/hi/eleven-agents/customization/privacy):** अनुपालन और डेटा सुरक्षा सुनिश्चित करें
* **[हमारा डॉक्स एजेंट](/docs/hi/eleven-agents/guides/elevenlabs-docs-agent):** इन सिद्धांतों का इस्तेमाल करते हुए एक पूरा केस स्टडी देखें

एंटरप्राइज़ डिप्लॉयमेंट सहायता के लिए, [हमारी टीम से संपर्क करें](https://elevenlabs.io/contact-sales)।