सन् २०२६ मा एजेन्टिक मार्केटिङ: कुनै प्रणालीले देखाउनैपर्ने चार कुरा

छोटो उत्तर: एजेन्टिक मार्केटिङ भनेको आफ्नै अर्को कदम छान्ने र त्यसपछि त्यो चाल्ने सफ्टवेयरद्वारा गरिने मार्केटिङ काम हो। सहमति लगभग यतिखेरै टुंगिन्छ। हामीले १८ अगस्ट २०२६ मा यो शब्द र यसका भेरियन्टहरूका लागि फर्किएका एघार पृष्ठ ल्यायौँ, र तीमध्ये आठले प्रोटोकल, टुल कलिङ वा फङ्सन कलिङको कुरै गर्दैनन् — जुन तहमा एजेन्ट च्याट विन्डो हुन छाडेर तपाईंको कम्युनिटी, तपाईंको क्याम्पेन वा तपाईंको ग्राहक रेकर्ड बदल्न सक्ने कुरा बन्छ। त्यसैले यो पोस्टले एजेन्टले कुनै पनि मार्केटिङ काम गर्न सक्नुअघि कुनै प्रणालीले देखाउनैपर्ने चार कुराका आधारमा एजेन्टिक मार्केटिङलाई परिभाषित गर्छ, ती प्रणालीहरूले आफ्नैबारे प्रकाशित गर्ने लेबलहरू किन अविश्वसनीय हुन्छन् भन्नेमा Model Context Protocolको भनाइ उद्धृत गर्छ, र Zealy को आफ्नै एजेन्ट सतहलाई यो परिभाषासँग जोख्छ — हामी असफल हुने भागसमेत।

खुलासा: Zealy ले यो पृष्ठ प्रकाशित गर्छ र Zealy ले यसको विषयवस्तु बेच्छ। Zealy एउटा कम्युनिटी र क्वेस्ट प्लेटफर्म हो। यसका दुई सुविधा यो लेखले परिभाषित गरेको अर्थमा एजेन्ट हुन्: बाहिरी AI ले चलाउन सक्ने MCP सर्भर, र उत्पादनभित्रकै AI समीक्षक। तीनैवटा तल देखिन्छन्। Zealy को आफ्नै एजेन्ट सतहबारे यहाँ भएका सबै कुरा प्रथम-पक्षीय हुन्: Zealy को रिपोजिटरीबाट पढिएको, हामीद्वारा Zealy को आफ्नै सर्भरविरुद्ध चलाइएको, अरू कसैले अडिट नगरेको। कुनै पनि विक्रेताले आफ्नै उत्पादनबारे गर्ने वर्णनमा तपाईंले देखाउने शङ्काका साथ यसलाई पढ्नुपर्छ।

अन्तिम पटक प्रमाणित: १८ अगस्ट २०२६।

एजेन्टिक मार्केटिङ के हो?

एजेन्टिक मार्केटिङ भनेको सफ्टवेयरद्वारा गरिने मार्केटिङ काम हो, जसले मानिसले बनाएको कार्यप्रवाह पछ्याउनुको सट्टा लक्ष्यतर्फ आफ्नै अर्को कदम छान्छ। कुनै प्रणाली त्यतिबेला मात्र योग्य ठहरिन्छ जब त्यसले चार कुरा प्रस्तुत गर्छ: च्याट बक्सको सट्टा नाम दिइएका उपकरण, काम गर्नुअघि तिनलाई पत्ता लगाउने तरिका, जानाजानी बनाइएको स्वीकृति सीमा, र फर्किएर आउने कुरामा विश्वास सीमा।

त्यो परिभाषा हाम्रो हो, र यो महत्वाकांक्षाबाट होइन, जानाजानी मेसिनरीबाट बनाइएको हो। हामीले पढेका प्रत्येक प्रकाशित परिभाषाले सफ्टवेयरले के गर्न खोजिरहेको छ भन्ने वर्णन गर्छ। तीमध्ये कुनैले पनि त्यो काम गर्न सक्नुअघि तपाईंको स्ट्याकमा के सत्य हुनुपर्छ भन्ने वर्णन गर्दैन। यहाँ चार भाग छन्, कुनै प्रणालीले ती पूरा गर्नुपर्ने क्रमअनुसार।

1. टेक्स्ट बक्स होइन, नाम दिइएका उपकरण। एजेन्टलाई नाम, आर्गुमेन्ट र रिटर्न आकार भएका अपरेसनहरू चाहिन्छन्, जस्तै create_campaign, list_members र send_message, किनकि गद्य मात्र उत्पादन गर्न सक्ने मोडेलले गद्य मात्र उत्पादन गर्न सक्छ। Model Context Protocol यस्तो सूची प्रकाशित गर्ने हालको सामान्य तरिका हो, र यसका उपकरणहरूलाई यसले मोडेल-नियन्त्रित भन्छ: भाषा मोडेलले सन्दर्भ र प्रयोगकर्ताको प्रम्प्टका आधारमा तिनलाई आफैँ पत्ता लगाउँछ र आह्वान गर्छ। यो तहबिना तपाईंसँग लेखन सहायक हुन्छ। त्यो उपयोगी उत्पादन हो; यो त्यो होइन।
2. कार्य गर्नु अघि खोज। एजेन्टले केही गर्न प्रतिबद्ध हुनु अघि के अस्तित्वमा छ र प्रत्येक कुराले के गर्छ भनी सोध्न सक्नुपर्छ। मानिसले पहिले नै तीनवटा कल छानिसकेको हार्डकोडेड एकीकरण भनेको प्रतिलिपिमा मोडेल जोडिएको स्वचालन मात्र हो।
3. कसैले जानाजान छानेको स्वीकृति सीमा। प्रत्येक कार्य या त व्यक्तिका लागि रोकिन्छ या रोकिँदैन, र कतै कुन हो भनी निर्णय गर्ने नियम हुन्छ। नियम कडा वा खुकुलो हुन सक्छ। हुन नसक्ने कुरा भनेको त्यसको जाँच नहुनु हो।
4. फर्केर आउने कुरामा विश्वास सीमा। उपकरणका नतिजा अन्य व्यक्तिहरूले लेखेको डेटा हुन्: सदस्य, ग्राहक, फारम, स्क्र्याप गरिएका पृष्ठ। यदि फर्किएको स्ट्रिङले एजेन्टलाई यसको अर्को उपकरण कलका लागि मनाउन सक्छ भने, तपाईंले तपाईंको क्वेस्ट सबमिशन फिल्ड भर्ने जो कोहीबाट निर्देशन लिने प्रणाली बनाउनुभएको छ।

दुई परिणामहरू आउँछन्, र हामीले परिभाषा लेख्न किन दुःख गर्यौं भन्ने कारण तिनै हुन्। पहिलो भाग नभएको जुनसुकै कुरा राम्रो मार्केटिङ भएको च्याटबोट मात्र हो। र तेस्रो भाग नभएको कुनै पनि कुराले स्वायत्तताबारे निर्णय गरेको छैन — त्यसमा भइसकेको छ। तपाईंले नरोजेको स्वीकृति सीमा डिजाइन अवस्था होइन, यो अझै कुनै क्षति नगरेको दुर्घटना हो।

अवस्थित परिभाषाहरू, र प्रत्येकले स्वायत्तताको रेखा कहाँ तान्छ

प्रकाशित परिभाषाहरू एजेन्टले आफैं योजना बनाएर काम गर्छ भन्नेमा सहमत छन्, तर कति मानव संलग्नता रहन दिने भन्नेमा असहमत छन्। Vlerick Business School न्यूनतम हस्तक्षेपलाई अनुमति दिन्छ। Braze ले बुझ्ने, निर्णय गर्ने र काम गर्ने प्रणालीहरूको वर्णन गर्छ। Young Urban Project र Netcore दुवैले प्रत्येक चरणमा मानव स्वीकृतिको रेखा तान्छन्। Forrester ले एजेन्टहरूलाई एजेन्टिक AI बाट पूर्ण रूपमा अलग गर्छ।

दायाँ स्तम्भभन्दा पहिले बीचको स्तम्भ पढ्नुहोस्। श्रेणी कसले परिभाषित गर्दैछ भन्ने कुराले उनीहरूले रेखा कहाँ तान्छन् भन्ने धेरै कुरा बताउँछ।

दायाँ स्तम्भको प्रत्येक स्ट्रिङलाई १८ अगस्ट २०२६ मा फेच गरिएको लिङ्क गरिएको पृष्ठको कच्चा पाठसँग मिलाइएको थियो, खोज परिणामबाट पढिएको होइन। यस शब्दका लागि र्‍याङ्किङ गर्ने छवटा पृष्ठहरू पटक्कै पढ्न सकिएन। Salesforce, IBM, Gartner र BCG ले प्रत्येक प्रयासमा 403 फर्काए, र McKinsey र Adobe को समय सकियो। तीमध्ये कुनै पनि यहाँ उद्धृत गरिएको छैन।

तीनवटा पृष्ठहरूले छेउछाउको शब्दसँग प्रयोगयोग्य सीमा पनि कोर्छन्, र राख्न योग्य भनी हामीले भेटेका ती तीनवटा मात्र हुन्।

मार्केटिङ स्वचालनसँगको भिन्नता। Treasure Data ले लेख्छ कि "Agentic marketing AI marketing भन्दा साँघुरो छ र marketing automation भन्दा फरक छ", किनभने "marketing automation ले मानिसद्वारा परिभाषित स्थिर कार्यप्रवाहहरू कार्यान्वयन गर्छ"। परीक्षण यो होइन कि सफ्टवेयरले तपाईंबिना काम गर्छ कि गर्दैन। तपाईंको इमेल उपकरणले पहिले नै त्यो गर्छ। परीक्षण यो हो कि चरणहरूको क्रम कुनै व्यक्तिले अग्रिम रूपमा छानेको हो कि होइन।

जेनेरेटिभ AI सँगको भिन्नता। Optimove ले यसलाई दुई ट्रिगरबीचको भिन्नताका रूपमा राख्छ: "Generative AI ले मानवीय प्रम्प्टका आधारमा सामग्री सिर्जना गर्छ", जबकि "Agentic AI ले प्रम्प्टको प्रतीक्षा नगरी स्वायत्त कार्य गर्छ।" प्रम्प्ट-आकारको बनाम लक्ष्य-आकारको, जुन वास्तविक भिन्नता हो र विरलै पालना गरिने भिन्नता हो।

सहायकसँगको भिन्नता। यस सेटमा कसैले लेखेको सबैभन्दा तीखो वाक्य यसको हो: Docket को Arjun Pillai: "एक सहायक प्रयोगकर्ताको प्रतीक्षा गर्छ, कुनै काममा सहयोग गर्छ, र मानव कार्यप्रवाहभित्र बस्छ।" यसको एजेन्ट पक्ष हो "एक एजेन्ट लक्ष्यतर्फ काम गर्छ, सीमित निर्णय गर्छ, कार्यप्रवाह सुरु गर्छ, र निरीक्षणमा कार्यान्वयनको एक भागको जिम्मेवारी लिन्छ।" एउटै पृष्ठको छुट्टै अनुच्छेदले त्यो वाक्यांशमा नभएको संयन्त्र दिन्छ: मानिसहरूले "उद्देश्य, एस्केलेसन नियम, विषय सीमा, र स्वीकृति थ्रेसहोल्ड परिभाषित गर्छन्। एजेन्ट ती सीमाभित्र काम गर्छ। केही कुरा तीभन्दा बाहिर परेमा, यो एस्केलेट गर्छ।" एस्केलेसन हाम्रो परिभाषाको स्वीकृति सीमा हो, जुन एजेन्टको पक्षबाट वर्णन गरिएको छ।

एउटा असहमति मेटाउनुभन्दा छाप्न योग्य छ। Forrester, AI एजेन्ट प्रयोगका केसहरूबारेको पृष्ठमा जसमा Craig Le Clair नाम दिइएको छ, त्यसले माथिका हरेक विक्रेता पृष्ठले एउटै मान्ने दुई शब्दलाई छुट्याउँछ: AI एजेन्टहरू "पूर्वनिर्धारित नियम"मा चल्छन्, जबकि "एजेन्टिक AI ले फराकिलो स्वायत्तता र अनुकूलनशीलता ल्याउँछ"। त्यो उद्धरणबारे सावधानी — यो पोडकास्ट ल्यान्डिङ पृष्ठ हो, प्रकाशित अनुसन्धान नोट होइन, र हामी यसलाई निष्कर्षको रूपमा नभई एक विश्लेषक फर्मको ढाँचाको रूपमा उद्धृत गर्दैछौं।

एघार परिभाषामध्ये आठले छोडेको तह

18 August 2026 मा यो शब्दका लागि हामीले ल्याएका एघार पृष्ठमध्ये आठले Model Context Protocol, tool calling वा function calling कहिल्यै उल्लेख गर्दैनन्। त्यो तह भनेको तपाईंलाई अभियान ब्रिफ लेखिदिने मोडेल र क्वेस्ट सिर्जना गर्न, सदस्यलाई प्रतिबन्ध लगाउन, वा तपाईंको इभेन्ट स्ट्रिम नयाँ ठाउँमा पुर्‍याउन सक्ने मोडेलबीचको भिन्नता हो।

ती आठ जसमा तीमध्ये कुनै पनि स्ट्रिङको उल्लेख छैन: braze.com, cdp.com, docket.io, forrester.com, netcore.ai, tofuhq.com, vlerick.com र youngurbanproject.com। बाँकी तीनमध्ये, hubspot.com ले Model Context Protocol को उल्लेख गर्छ तर परिभाषामूलक पृष्ठ होइन। Optimove हामीलाई सबैभन्दा बढी टाँसिएको हो: स्ट्रिङ MCP यसको पृष्ठमा नेभिगेसन मेनुमा "The Optimove MCP" का रूपमा मात्र देखिन्छ, र यो श्रेणी व्याख्या गर्ने लेखको मुख्य भागमा कहिल्यै देखिँदैन। एउटा विक्रेता जसले MCP सर्भर पठाउँछ, तर एजेन्टिक मार्केटिङबारे उसको आफ्नै व्याख्याले उसले पठाउने चीजसम्म कहिल्यै पुग्दैन। यो एक दिनका एघार पृष्ठबारेको कथन हो, सम्पूर्ण श्रेणीबारे होइन — तर हामीले जाँचेको हरेक पृष्ठमा यो लागू भयो।

सेटमा दुई पृष्ठले हराइरहेको तहको नाम लिन्छन्, र दुवैले राम्ररी गर्छन्।

HubSpot का Duncan Lennox लेख्छन्: "तर एजेन्टहरू ड्यासबोर्डमा क्लिक गर्दैनन् वा इन्टरफेसहरूमा नेभिगेट गर्दैनन्; तिनीहरू API कल गर्छन्, संरचित आउटपुट पढ्छन्, र कार्य गर्छन्।" त्यही पृष्ठले दायरालाई "एजेन्टहरूले के पढ्न, लेख्न र केमा कार्य गर्न सक्छन्" का रूपमा परिभाषित गर्छ, जुन सही एकाइ हो। "के यो मार्केटिङ गर्न सक्छ" होइन, तर कुन नाम र कुन क्रियाहरू।

Real Story Group, मार्केटिङ प्रविधि अनुसन्धान फर्म जसले विक्रेता मूल्याङ्कन बेच्छ, त्यसले बहस अन्त्य गर्ने वाक्य दिन्छ। एउटा MCP सम्बन्धी लेखमा 11 जुन 2025 मा प्रकाशित, प्रमुख विश्लेषक Scott Simmons यसलाई "AI एजेन्टहरूका लागि बनाइएको सार्वभौमिक API एब्स्ट्र्याक्सन तह" भन्छन्, र निष्कर्ष निकाल्छन् कि एजेन्ट "विक्रेताले के उजागर गर्न रोज्छ, त्यति नै शक्तिशाली हुन्छ।"

त्यो अन्तिम वाक्यांश नै सबै कुरा हो। एजेन्टिक मार्केटिङ तपाईंले छानेको मोडेलको गुण होइन। यो तपाईंका विक्रेताहरूले प्रकाशित गर्ने सतहको गुण हो। यदि उपकरणहरू पढ्ने-मात्र छन् भने, तपाईंको एजेन्टले रिपोर्ट गर्छ। यदि उपकरणहरू छैनन् भने, तपाईंको एजेन्टले कपी लेख्छ। क्षमताको प्रश्न र खरिदको प्रश्न एउटै प्रश्न हो, त्यसैले यो तह छोड्ने परिभाषाहरू पढ्न धेरै रमाइलो र कार्यान्वयन गर्न धेरै गाह्रो हुन्छ। यदि एजेन्टले काम गर्ने च्यानलहरूको फराकिलो चित्र चाहनुहुन्छ भने, हाम्रो web3 मार्केटिङ स्तम्भ ले ती र तिनको लागत समेट्छ।

किन उपकरण सूची प्रमाण हो र उपकरण लेबल केवल सङ्केत मात्र हो

Model Context Protocol ले एजेन्टले तपाईंलाई के गर्न सक्छ भन्ने प्रश्नको उत्तर सर्भरको उपकरण सूची पढ्न भनेर दिन्छ, र त्यसपछि क्लाइन्टहरूलाई त्यो सूचीले आफ्नै बारेमा के भन्छ त्यसलाई नपत्याउन भन्छ। त्यो कुरा बताउने टिप्पणी गद्यमा नभई स्किमामा रहेको छ, जुन किन धेरै कम मानिसले यो पढेका छन् भन्ने कुराको एउटा कारण हो।

यहाँबाट अनुच्छेद यहाँ छ, ToolAnnotations इन्टरफेस मा विनिर्देशको स्किमा संशोधन 2026-07-28 मा:

नोट: सबै गुणहरू ToolAnnotations हुन् संकेतहरू. तिनीहरूले उपकरणको व्यवहारको विश्वासयोग्य वर्णन प्रदान गर्ने ग्यारेन्टी गर्दैनन् (जस्तै वर्णनात्मक गुणहरू सहित title).

र यसै विषयमा, बाट उपकरण पृष्ठ:

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

त्यसको आकारसँग एकछिन बस्नुहोस्। "मैले यो चीजले मलाई के गर्न सक्छ भनेर कसरी थाहा पाउने" भन्ने प्रश्नको प्रोटोकलको उत्तर हो: सूची पढ्नुहोस्। यसको ठ्याक्कै अर्को निर्देशन हो: सूची तपाईंले मूल्याङ्कन गरिरहनुभएको पक्षको दाबी हो। उपकरण नामहरू र schemas भार वहन गर्ने हुन्, किनकि मोडेलले तिनीहरूलाई कल गर्छ र सर्भरले तिनीहरूलाई सम्मान गर्नुपर्छ। तिनीहरूमा संलग्न जोखिम लेबलहरू सर्भरको आफ्नै व्यवहारको आफ्नै वर्णन हुन्।

त्यस्ता चार लेबलहरू छन् — readOnlyHint, destructiveHint, idempotentHint र openWorldHint — र तीमध्ये दुईवटा, destructiveHint र openWorldHint, पूर्वनिर्धारित हुन्छन् true. अलेबल नगरिएको टुललाई त्यसैले विनाशकारी मानिन्छ र बाह्य संसारलाई छुने मानिन्छ, जुन सही निर्णय हो र अधिकांश मानिसहरूले अपेक्षा गर्ने कुराको विपरीत हो।

एजेन्टिक मार्केटिङको परिभाषाका लागि महत्त्वपूर्ण कुरा हो destructiveHint, किनभने यसले नसोध्ने कुराको कारणले। यसले ओभरराइटिङलाई थप्नेबाट अलग गर्छ। हानि फरक अक्ष हो र स्किमामा यसका लागि कुनै स्तम्भ छैन, त्यसैले पूर्ण रूपमा सद्भावनापूर्वक काम गर्ने सर्भरले विशुद्ध रूपमा थप्ने कललाई तपाईंको स्ट्याकमा एजेन्टले गर्ने सबैभन्दा परिणामकारी काम हुँदा पनि सुरक्षित तरिकाको रूपमा लेबल गर्न सक्छ। व्यवहारमा प्रत्येक फ्ल्यागको अर्थ के हो, र पूर्वनिर्धारितहरू लागू गरेपछि वास्तविक लिस्टिङ कस्तो देखिन्छ, त्यो छेउको वाकथ्रु.

यो पनि मार्केटरहरूले एजेन्ट वासिङ भनिरहने कुराको इमानदार संस्करण हो। Young Urban Project ले यसलाई ठ्याक्कै नाम दिन्छ: "सबैभन्दा सामान्य असफलता एजेन्ट वासिङ हो, अर्थात् विद्यमान अटोमेसन वा च्याटबोट उत्पादनलाई तल्लो तहमा योजना वा निर्णय तह नथपी एजेन्टिक भनेर पुनःब्रान्ड गर्नु", र थप्छ कि "डेमो ठ्याक्कै त्यो खाडल लुकाउन स्क्रिप्ट गरिएको हुन्छ जुन महत्त्वपूर्ण छ"। टुल सूची डेमोभन्दा स्क्रिप्ट गर्न धेरै गाह्रो हुन्छ। यो यस सम्पूर्ण वर्गमा खरिदकर्ताले विक्रेताको सहयोगबिना जाँच गर्न सक्ने एक मात्र कलाकृति पनि हो, त्यसैले हामीले छुट्टै वाकथ्रु लेख्यौं कुनै पनि MCP सर्भर जोड्नुअघि त्यसका टुलहरू कसरी सूचीबद्ध गर्ने.

स्वीकृति सीमा कहाँ जान्छ, र त्यो त्यहाँ राख्ने कसले हो

Model Context Protocol भन्छ कि मानिस सधैं लूपमा हुनुपर्छ र टुल इन्भोकेशन अस्वीकार गर्ने क्षमता हुनुपर्छ, र यो कुरा क्लाइन्ट एप्लिकेसनलाई भन्छ, MUST नभई SHOULD को रूपमा। प्रोटोकलमा तपाईंले जडान गर्नुभएको सर्भरलाई कुनै बाध्यता छैन। तपाईंको स्वीकृति सीमा कहाँ पर्छ भन्ने कसैले गरेको छनोट हो, र प्रायः तपाईंले होइन।

ठ्याक्कै वाक्य:

विश्वास, सुरक्षा र सुरक्षाका लागि, त्यहाँ SHOULD सधैं लूपमा मानिस हुनुपर्छ र टुल इन्भोकेशन अस्वीकार गर्ने क्षमता हुनुपर्छ।

त्यही सुरक्षा खण्डले क्लाइन्टहरूलाई "सर्भर कल गर्नुअघि प्रयोगकर्तालाई टुल इनपुटहरू देखाउन, दुर्भावनापूर्ण वा दुर्घटनावश डेटा चोरीबाट बच्न" र "LLM मा पठाउनुअघि टुल परिणामहरू प्रमाणित गर्न" भन्छ। दुवै क्लाइन्टलाई सम्बोधित छन्: तपाईंको तर्फ चल्ने कुरा, मोडेल राख्ने Claude वा ChatGPT वा इन-हाउस हार्नेस। त्यसैले प्रोटोकलको सरल पठनमा, तपाईंको एजेन्टिक मार्केटिङको सुरक्षा तपाईंको क्लाइन्टको काम हो, र तपाईंले जडान गर्नुभएको सर्भरले इमानदार टुल सूचीबाहेक तपाईंलाई केही दिन्न।

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

बहस गर्न लायक संस्करण न त "पूर्ण स्वायत्तता" हो न त "सबै स्वीकृत गर्ने"। यो हो कि सीमा प्रत्येक निर्णयको सेटिङ हो जसको दुवैतर्फ लागत हुन्छ, र यसलाई लागू गर्ने संयन्त्र आफैँ पनि सफल हुन सक्ने सफ्टवेयर हो — जुन यसै वर्षको सुरुमा भएको Discord मोडरेसन असफलताले देखाएको थियो, जहाँ प्रकाशित डिजाइनमा मानव समीक्षाको चरण थियो र एउटा बगले त्यसलाई मार्गबाट हटाइदियो। हामीले एजेन्टलाई समुदाय चलाउन दिनुको अर्थ के हुन्छ भन्नेबारे छुट्टै लेख्यौँ, किनकि यो एउटा वाक्यांशभन्दा बढी योग्य छ।

अब कुन कुन कलहरूले गेट पाउन योग्य छन् भन्ने प्रश्नको मापन गरिएको उत्तर पनि छ, र त्यो तपाईंको अन्तर्ज्ञानले दिने उत्तर होइन। SABER: साना कार्य, ठूला त्रुटि — LLM एजेन्टहरूमा परिवर्तनकारी चरणहरूको सुरक्षा, Alejandro Cuadron, Pengfei Yu, Yang Liu र Arpit Gupta द्वारा, 26 नोभेम्बर 2025 मा पेश गरिएको, ले कहाँ टुल प्रयोग गर्ने एजेन्टको ट्र्याजेक्टरी बिग्रँदा वास्तवमै तपाईंलाई खर्च पर्छ भन्ने अध्ययन गर्छ। यसले रिपोर्ट गर्छ कि "यसको विपरीत, नन-म्युटेटिङ कार्यहरूमा हुने विचलनको प्रभाव न्यून वा शून्य हुन्छ।" त्यो वाक्यभन्दा ठीक अघिल्लो वाक्यले अर्को पक्ष दिन्छ: प्रत्येक थप विचलनले म्युटेटिङ कार्यले सफलताको सम्भावना यसका दुई डोमेनमध्ये एकमा 92% सम्म र अर्कोमा 96% सम्म घटाउँछ, अत्याधुनिक मोडेलहरूका लागि। असफलता स्टेट परिवर्तन गर्ने कलहरूमा केन्द्रित हुन्छ।

डिजाइनको निष्कर्ष आकर्षक छैन र सस्तो छ: लेखाइहरूलाई गेट गर्नुहोस्, पढाइहरूलाई छोडिदिनुहोस्, र "human in the loop" लाई एउटै सेटिङ भएको एउटै डायलको रूपमा व्यवहार गर्न छोड्नुहोस्। Zealy को सर्भर संयोगवश त्यसरी नै काम गर्छ, र हामी स्पष्ट हुनुपर्छ कि हामीले यसलाई यो पेपरबाट व्युत्पन्न गरेका होइनौं — पेपर डिजाइनपछि आयो र यससँग सहमत छ, जुन प्रमाण-नेतृत्व इन्जिनियरिङभन्दा कमजोर कुरा हो र केही नभएकोभन्दा बलियो कुरा हो। उद्धरणसँग एउटा चेतावनी जान्छ: SABER ले आफूले आधार बनाएको बेन्चमार्कमा एनोटेसन त्रुटिहरू दस्तावेज गर्छ र सुधारिएको संस्करण प्रकाशित गर्छ, जुन पुराना टुल-एजेन्ट बेन्चमार्क स्कोरहरूलाई अझै पनि वर्तमान मोडेलहरूको वर्णन गरेझैं उद्धृत नगर्नुको राम्रो कारण हो। यहाँ एउटै संख्यासँग सावधान हुनुको अर्को कारण यो हो कि एजेन्ट असफलता धेरै हदसम्म भेरियन्सको समस्या हो — बहु-टर्न अनुसन्धानले गिरावटलाई क्षमताको सानो ह्रास र विश्वसनीयताको ठूलो वृद्धिमा विभाजन गर्छ, जुन मोडेल साधारण रूपमा पर्याप्त राम्रो नभएको भन्दा फरक व्यवस्थापन समस्या हो।

त्यही "कार्यान्वयनकर्तालाई छोडिएको" ढाँचा एक तह तल, हाम्रो परिभाषाको चौथो भागमा चल्छ। हामीले 18 अगस्ट 2026 मा सातवटा स्पेसिफिकेसन र सुरक्षा पृष्ठहरू डाउनलोड गर्यौं र खोज्यौं: स्पेसिफिकेसनको खतरा मोडेल एक अधिकार र यातायात खतरा मोडेल हो, जसले confused deputy, token passthrough, server-side request forgery र सम्झौता भएको स्थानीय सर्भरलगायत अन्य धेरैलाई समेट्छ, जबकि मोडेल-तह आक्रमण कार्यान्वयनकर्ताहरूलाई छोडिएको छ। हामीले डाउनलोड गरेका पृष्ठहरूमा "prompt injection" वाक्यांश देखिँदैन; सुरक्षा उत्तम-अभ्यास कागजातमा "injection" का चार मिलानहरू cross-site scripting, shell command injection र remote code execution हुन्। यो यातायात स्पेसिफिकेसनको गुनासो होइन, जसलाई आफ्नो दायरा तोक्ने अधिकार छ। यो कुन आधा समस्या तपाईंले केही जोड्ने बित्तिकै उत्तराधिकारमा पाउनुहुन्छ, र किन फर्काइएको डाटामा विश्वास सीमा प्रोटोकलको अनुमानित गुण नभई कसैको स्पष्ट जिम्मेवारी हुनुपर्छ भन्ने कुराको कथन हो।

Zealy आफ्नै परिभाषामा असफल हुन्छ, र यहीँ हो

यो पोस्टका कडा परिभाषाहरूअनुसार — Young Urban Project को "प्रत्येक व्यक्तिगत चरण मानिसले स्वीकृत नगरी" र Netcore को "प्रत्येक चरणमा मानव स्वीकृति आवश्यक नपारी" — Zealy एजेन्टिक मार्केटिङ गरिरहेको छैन। Zealy को एजेन्ट सतहमार्फत हुने प्रत्येक लेखाइ व्यक्तिका लागि रोकिन्छ, र अपरेटरले खोलेसम्म लेखाइहरू बन्द रहन्छन्।

पछि बहस हार्नुभन्दा हामी त्यो भन्न रुचाउँछौं। यहाँ हाम्रै चार भागविरुद्धको पूर्ण स्कोरकार्ड छ, प्रथम-पक्षीय र अलेखापरीक्षित।

चारैवटा उपस्थित छन्, जुन सजिलो भाग हो। तेस्रो भाग लेबलका लागि उल्टो दिशामा राखिएको छ। Zealy को सर्भरले स्वीकृति गेट सर्भर पक्षमा राख्छ, जुन प्रोटोकलले सर्भरबाट माग्नेभन्दा बढी र एजेन्टिक मार्केटिङको कडा परिभाषाले अनुमति दिनेभन्दा बढी हो। टुल सतह आफैँ अडिट गर्न लायक हुने गरी ठूलो छ — हामीले गन्दा 72 नामित टुलहरू — तर संख्या मुख्य कुरा होइन। सेटिङ मुख्य कुरा हो।

हामीले पूरै उत्पादनभर एकरूपताको दाबी पनि गर्न पाउँदैनौं। Zealy ले एउटा AI समीक्षक पनि चलाउँछ जसले आफैं quest claim बन्द गर्छ, त्यो बाटोमा कुनै व्यक्ति हुँदैन: एउटै कम्पनी, विपरीत सेटिङ, सदस्यलाई भुक्तानी मिल्ने वा नमिल्ने निर्णयमा। दुवै छनोट तर्कसंगत छन्; तर हामी इमानदारीपूर्वक भन्न सक्दैनौं कि कति स्वायत्तता उपयुक्त हुन्छ भन्ने एउटै कम्पनीव्यापी उत्तर छ।

त्यसैले लेबल हटाऔं। Zealy ले वास्तवमा दिने कुरा भनेको मानव commit चरणसहितको agent-ले बुझ्न सक्ने सतह हो, जुन अधिकांश टोलीले पहिले चाहनुपर्ने कुराको एउटा साधारण नाम हो। यसलाई जोड्ने mechanics चाहिए, MCP integration docs आधिकारिक हुन् र यो पोस्टले जानाजान तिनलाई दोहोर्याउँदैन; यदि तपाईंलाई तलको पुरानो, फराकिलो सतह चाहिए, API docs ले त्यो समेट्छ। र यदि तपाईंले उत्पादन कहिल्यै प्रयोग गर्नुभएको छैन भने, Zealy के हो मा छोटो मार्ग हो।

एजेन्टिक मार्केटिङ भनिने कुरा किन्नु अघि के सोध्ने

टुल सूची माग्नुहोस्। एजेन्टिक मार्केटिङ बेच्ने विक्रेताले एजेन्टले पाउने नामांकित अपरेसनहरू, तिनका अनुमतिहरूसहित देखाउन सक्छ, वा सक्दैन। बाँकी सबै—योजना भाषा, लक्ष्य-खोजी भाषा र डेमो—फारमसँग जोडिएको च्याटबोटसँग मिल्दछ, र Young Urban Project सँग त्यसको नाम छ।

कम्तीमा बैठक समयमा सबैभन्दा धेरै जानकारी दिने क्रममा पाँच प्रश्न:

1. "एजेन्टले नामले कुन अपरेसनहरू पाउँछ?" यदि जवाफ सूचीको सट्टा क्षमताको वाक्य हो भने, तपाईंले जवाफ पाउनुभयो। यदि सूची हो भने, क्रियापदका लागि पढ्नुहोस्। पढ्नु, लेख्नु, मेट्नु, पठाउनु, प्रकाशित गर्नु, भुक्तानी गर्नु।
2. "तिनीहरूमध्ये कुनले म बिना काम गर्न सक्छ?" "लूपमा मानिस छ?" भनेर नसोध्नुहोस्: त्यो प्रश्नको जवाफ सबैले हो भन्छन्। कुन विशेष कलहरूले व्यक्तिलाई छोड्छन्, र त्यो विभाजन कसले छान्यो भनेर सोध्नुहोस्।
3. "एजेन्टले पढ्दा ग्राहकले लेखेको पाठको के हुन्छ?" तपाईं सोध्दै हुनुहुन्छ कि उपकरणका नतिजाहरूलाई डेटाको रूपमा लिइन्छ वा सम्भावित निर्देशनको रूपमा। यसबारे सोचेको विक्रेताले तुरुन्तै जवाफ दिनेछ, किनकि यही असफलताको अवस्थाले उनीहरूका इन्जिनियरहरूलाई रातभर जागा राख्छ।
4. "तपाईंका जोखिम लेबलहरूको अर्थ के हो?" त्यसपछि जवाफलाई बिक्री प्रस्तुतिसँग होइन, विशिष्टतासँग भिडाएर जाँच्नुहोस्, र पूर्वनिर्धारित मानहरू के हुन् भनी सोध्नुहोस् — धेरैजसो मानिसहरूले ती उल्टो अनुमान गर्छन्।
5. "यसले के गर्न सक्दैन?" सीमाको सूची विश्वसनीयताको सबैभन्दा सस्तो सङ्केत हो र लगभग कसैले पनि त्यो प्रकाशित गर्दैन। यसको अनुपस्थिति केही कुराको प्रमाण होइन। यसको उपस्थिति धेरै मूल्यवान् हुन्छ।

अन्तिम कुरा क्रमबद्धताबारे भन्नुपर्छ, किनकि यहाँ खरिदको निर्णय सामान्यतया गलत समयमा हुन्छ। एजेन्टिक मार्केटिङ मूल्याङ्कन गर्ने धेरैजसो टोलीहरूले आफ्ना दोहोरिने काममध्ये कुन-कुन सुरक्षित रूपमा हस्तान्तरण गर्न मिल्छ र कुन मिल्दैन भनी अझै लेखेका छैनन् — र त्यो निर्णय त्यही हो, चाहे त्यो काम ठेकेदारको हातमा होस्, मोडरेटरको हातमा होस् वा मोडेलको हातमा। समुदायका कामहरू कसरी हस्तान्तरण गर्ने मानिसहरूसँग यसलाई काम गरेर हेर्छ, र विश्लेषण लगभग अपरिवर्तित रूपमा सर्छ। पहिले त्यही गर्नुहोस्। एजेन्ट त्यहीँ रहनेछ, र तपाईंलाई थाहा हुनेछ कि तपाईं वास्तवमा कुन उपकरणहरू यसमा राख्न चाहनुहुन्छ।