Okou के साथ Workflow निर्देश बनाएँ

आपको किसी खाली पृष्ठ से Workflow निर्देश लिखने की आवश्यकता नहीं है। शुरुआत अपने एजेंट के साथ एक वास्तविक कार्य पूरा करके करें। जब परिणाम उपयोगी हो जाए, तो एजेंट से कहें कि आप दोनों ने मिलकर जो विधि विकसित की है, उसे एक पुनः उपयोग योग्य Workflow में बदल दे।

पहला मसौदा एजेंट तैयार करता है। आपकी भूमिका उसकी मान्यताओं की समीक्षा करना और यह तय करना है कि Workflow में कहाँ अधिक स्पष्ट सीमाएँ चाहिए, ताकि कोई दूसरा टीम-सदस्य भी विश्वसनीय परिणाम प्राप्त कर सके।

My Okou में, व्यक्तिगत निर्देश (Instructions) प्रत्येक सदस्य की प्राथमिकताएँ रखते हैं; Workspace का Workflow दोहराई जा सकने वाली प्रक्रिया और टीम के मानकों को रखता है। निजी Workflow वर्तमान उपयोगकर्ता के होते हैं, और सार्वजनिक Workflow Workspace के भीतर साझा किए जाते हैं। निष्पादन के समय वही सदस्य के निर्देश, मेमोरी, खाते और अनुमतियाँ उपयोग होती हैं जो उसे चला रहा हो। Legacy Agents में, Workflow एक ही Agent से जुड़े रहते हैं। Instructions and experience modes देखें।

किसी सफल रन से शुरुआत करें

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

1. एजेंट को एक वास्तविक कार्य और उसके लिए आवश्यक वास्तविक इनपुट दें।
2. परिणाम की समीक्षा करें और छूटा हुआ संदर्भ, कमजोर तर्क या गलत प्रारूप ठीक करें।
3. जब परिणाम अच्छा हो जाए, तो एजेंट से कहें कि वह उसमें से दोहराई जा सकने वाली विधि निकाल दे।
4. एजेंट से Workflow का नाम, विवरण, निर्देश और उसके सुझाए गए किसी भी संदर्भ फ़ाइलों का मसौदा तैयार करवाएँ।
5. Workflow को सार्वजनिक करने से पहले मसौदे की साथ मिलकर समीक्षा करें।

आप इस तरह कह सकते हैं:

हमने अभी जो किया, उसे टीम के लिए एक पुनः उपयोग योग्य Workflow में बदल दो। नाम, विवरण और निर्देश का मसौदा तैयार करो। पुनः उपयोग योग्य विधि को उन विवरणों से अलग करो जो केवल इसी मामले पर लागू होते हैं। इसे अंतिम रूप देने से पहले, वे मान्यताएँ और सीमाएँ सूचीबद्ध करो जिनकी मुझे समीक्षा करनी चाहिए।

इससे मसौदा तैयार करने का काम एजेंट को मिलता है। और यह तय करने का काम आपको मिलता है कि किन हिस्सों पर नियंत्रण होना अनिवार्य है।

सीमाएँ तय करने के लिए निर्देश एक सामान्य स्थान है

Workflow का निर्देश Workflow के साथ चलता है और हर बार उसके चलने पर लागू होता है। इसलिए आवश्यक इनपुट, स्वीकृत स्रोत, आउटपुट प्रारूप, गुणवत्ता मानक और पुष्टि की आवश्यकता वाले कार्य जैसी सीमाएँ निर्धारित करने के लिए यह सबसे सामान्य स्थानों में से एक है।

लेकिन यह नियंत्रण की एकमात्र परत नहीं है:

केवल निर्देश के पाठ को access controls का विकल्प न मानें। यदि किसी कार्रवाई को तकनीकी रूप से प्रतिबंधित करना आवश्यक है, तो स्पष्ट निर्देश के साथ वास्तविक connector authorization और नामित permissions भी उपयोग करें।

एजेंट के पहले मसौदे की समीक्षा करें

आपको हर वाक्य फिर से लिखने की आवश्यकता नहीं है। अपनी समीक्षा उन निर्णयों पर केंद्रित रखें जो टीम के लिए मायने रखते हैं।

इसका उपयोग कब होना चाहिए?

• कौन-सा अनुरोध या स्थिति इस Workflow को चुने?
• एजेंट को इसका उपयोग कब नहीं करना चाहिए?
• क्या विवरण इतना विशिष्ट है कि इसे मिलते-जुलते Workflow से अलग पहचाना जा सके?

कौन-सा इनपुट आवश्यक है?

• काम शुरू होने से पहले टीम-सदस्य को क्या देना अनिवार्य है?
• कौन-से अनुपस्थित इनपुट होने पर एजेंट को प्रश्न पूछना चाहिए?
• कौन-सी बातें स्थायी निर्देश के बजाय हर रन में होनी चाहिए?

कौन-से स्रोत और नियम प्राथमिक होंगे?

• रिकॉर्ड का आधिकारिक स्रोत क्या है?
• किस संलग्न फ़ाइल में स्वीकृत rubric या template है?
• यदि दो स्रोतों में टकराव हो, तो किसे प्राथमिकता मिलेगी?
• जिन तथ्यों की एजेंट पुष्टि नहीं कर सकता, उन्हें वह कैसे चिह्नित करे?

आउटपुट कैसा दिखना चाहिए?

• कौन-से अनुभाग या फ़ील्ड अनिवार्य हैं?
• कितना विस्तार उपयोगी है?
• क्या आउटपुट में citations, links या confidence label होना चाहिए?
• जब कोई destination दिया गया हो, तो परिणाम कहाँ जाना चाहिए?

एजेंट को कहाँ रुकना चाहिए?

• किन कार्रवाइयों के लिए पुष्टि आवश्यक है?
• क्या एजेंट को भेजने या प्रकाशित करने के बजाय मसौदा बनाना चाहिए?
• कौन-सा डेटा सार्वजनिक Workflow या साझा परिणाम में नहीं होना चाहिए?

ये वे सीमाएँ हैं जिन्हें स्पष्ट रूप से लिखना उचित है। शब्दांकन एजेंट को संभालने दें, फिर यह पुष्टि करें कि शब्दांकन आपके निर्णय को सही तरह से दर्शाता है।

साथ मिलकर समीक्षा करने के लिए एक संरचना

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

# Goal
State the single outcome this workflow must produce.

# Use this workflow when
Describe when to use it and any important exclusions.

# Required inputs
- List the information needed for a reliable result.
- Explain what to do when an input is missing.

# Sources and tools
- Name authoritative systems, documents, or attached files.
- Explain which source wins if information conflicts.
- Define how to handle facts that cannot be verified.

# Procedure
1. Verify the inputs and scope.
2. Gather the required evidence.
3. Apply the team's rules or rubric.
4. Produce the deliverable.
5. Check it against the quality bar.

# Output
Define the required sections, fields, format, and destination.

# Quality bar
- State what must be accurate, cited, complete, or consistent.
- Define what counts as done.

# Approval boundaries
- List actions that require confirmation.
- Specify when to create a draft instead of taking the final action.

किसी सरल Workflow को केवल कुछ अनुभागों की आवश्यकता हो सकती है। किसी उच्च-जोखिम वाले Workflow को स्रोत, सत्यापन और स्वीकृति नियमों की अधिक स्पष्टता चाहिए हो सकती है। एजेंट से कहें कि वह निर्देश को जितना संभव हो उतना संक्षिप्त रखे, लेकिन ऐसा कोई निर्णय न छिपाए जिस पर टीम निर्भर करती हो।

उदाहरण: मिलकर lead qualification Workflow बनाना

मान लीजिए आप एजेंट से एक inbound lead पर शोध करने और उत्तर का मसौदा तैयार करने के लिए कहते हैं। रन के दौरान, आप कंपनी का आकार ठीक करते हैं, स्पष्ट करते हैं कि CRM ही रिकॉर्ड का आधिकारिक स्रोत है, टीम का ICP rubric लागू करते हैं, और छोटा ईमेल माँगते हैं।

परिणाम स्वीकृत हो जाने के बाद, एजेंट से कहें कि वह इस बातचीत को एक Workflow में बदल दे। एजेंट प्रक्रिया का मसौदा तैयार करता है। फिर आप वे सीमाएँ जोड़ते हैं जो इस lead से आगे भी बनी रहनी चाहिए:

• सार्वजनिक शोध करने से पहले CRM जाँचें;
• scoring के लिए संलग्न ICP rubric का उपयोग करें;
• कंपनी के आकार, स्थान और वर्तमान भूमिका के लिए स्रोतों का संदर्भ दें;
• किसी आवश्यक लेकिन अप्रमाणित तथ्य को Unknown के रूप में चिह्नित करें;
• Account summary, Evidence, ICP score, Risks, Recommended next step, और Reply draft लौटाएँ;
• ईमेल का मसौदा बनाएँ और पुष्टि के बिना उसे कभी न भेजें।

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

साधारण भाषा में सीमाओं पर प्रतिक्रिया दें

आप एजेंट को यह बताकर मसौदे को अधिक कड़ा बना सकते हैं कि क्या बदलना आवश्यक है:

• “अगर CRM रिकॉर्ड मौजूद नहीं है, तो शुरू करने से पहले उसे माँगो।”
• “जब कंपनी के नामों में टकराव हो, तो CRM को आधिकारिक रिकॉर्ड मानो।”
• “संक्षिप्त विवरण में हर तथ्यात्मक दावे के लिए स्रोत लिंक होना चाहिए।”
• “Reply को 150 शब्दों से कम रखो, लेकिन उसका tone inbound message के अनुसार ढालो।”
• “ईमेल को मसौदे के रूप में बनाओ। इसे कभी अपने-आप मत भेजो।”
• “यह Workflow मौजूदा opportunities के लिए नहीं चलना चाहिए।”

एजेंट से कहें कि वह Workflow को अपडेट करे और संक्षेप में बताए कि हर बदलाव किस सीमा को संबोधित करता है। इससे उस नियम को पकड़ना आसान हो जाता है जिसे गलत समझ लिया गया हो या गलत अनुभाग में रखा गया हो।

सही चीज़ों को निर्देश के बाहर रखें

कुछ जानकारी स्थायी Workflow पाठ का हिस्सा नहीं बननी चाहिए:

• ग्राहक के नाम, एकबारगी समय-सीमाएँ और मामले-विशेष destination, run request में होने चाहिए;
• passwords, tokens और निजी credentials किसी निर्देश या संलग्न फ़ाइल में नहीं होने चाहिए;
• schedules और events automation में होने चाहिए;
• तकनीकी access boundaries, connector authorization और named permissions में होने चाहिए;
• व्यक्तिगत प्रतिक्रिया, जो केवल एक परिणाम पर लागू होती है, उसी चैट में रह सकती है।

निर्देश में पुनः उपयोग योग्य विधि और व्यवहार संबंधी सीमाएँ होनी चाहिए, काम के आसपास की हर जानकारी नहीं।

साथ मिलकर परीक्षण करें और परिष्कृत करें

कम-से-कम दो यथार्थवादी इनपुट के साथ Workflow चलाएँ, और बेहतर हो कि इसमें एक दूसरा टीम-सदस्य भी शामिल हो। हर रन के बाद पूछें:

• क्या Workflow सही कार्य के लिए सक्रिय हुआ?
• क्या उसने आवश्यक इनपुट माँगे?
• क्या उसने अपेक्षित स्रोत-प्राथमिकता का पालन किया?
• क्या आउटपुट कठोर हुए बिना एकसमान रहा?
• क्या वह आवश्यक स्वीकृति-सीमा पर रुक गया?
• क्या समस्या दोहराई जा सकती है, या वह केवल इसी मामले पर लागू होती है?

एजेंट से कहें कि वह दोहराई जाने वाली कमियों के लिए निर्देश में संशोधन करे। एकबारगी सुधारों को रन में ही रहने दें। जब यह विधि उसके मूल निर्माता के अलावा किसी और के लिए भी काम करने लगे, तो Workflow अपनी टीम के साथ साझा करें।