2026 मधील एजंटिक मार्केटिंग: सिस्टमने उघड करणे आवश्यक असलेल्या चार गोष्ट्या

थोडक्यात उत्तर: एजंटिक मार्केटिंग म्हणजे अशा सॉफ्टवेअरद्वारे केले जाणारे मार्केटिंग काम जे स्वतःची पुढील पायरी निवडते आणि नंतर ती पार पाडते. एकमत मात्र इथपर्यंतच आहे. 18 ऑगस्ट 2026 रोजी आम्ही या शब्दासाठी आणि त्याच्या प्रकारांसाठी आलेली अकरा पाने मिळवली, आणि त्यांपैकी आठ पानांमध्ये प्रोटोकॉल, टूल कॉलिंग किंवा फंक्शन कॉलिंगचा उल्लेखही नाही — जो थर आहे जिथे एजंट चॅट विंडो राहून तुमचा समुदाय, तुमची मोहीम किंवा तुमच्या ग्राहक नोंदी बदलू शकणारी गोष्ट बनतो. म्हणून हा लेख एजंटिक मार्केटिंगची व्याख्या अशा चार गोष्टींद्वारे करतो ज्या एजंट कोणतेही मार्केटिंग काम करू शकण्यापूर्वी सिस्टमने उघड करणे आवश्यक आहे, त्या सिस्टम्स स्वतःबद्दल प्रकाशित करतात ती लेबले अविश्वसनीय का आहेत यावर Model Context Protocolचे उद्धरण देतो, आणि या व्याख्येविरुद्ध Zealyच्या स्वतःच्या एजंट पृष्ठभागाचे मूल्यांकन करतो, ज्यात आम्ही अपयशी ठरतो तो भागही समाविष्ट आहे.

प्रकटीकरण: हे पान Zealy प्रकाशित करते आणि ज्या गोष्टीबद्दल ते आहे ती गोष्ट Zealy विकते. Zealy हे समुदाय आणि क्वेस्ट प्लॅटफॉर्म आहे. त्याची दोन वैशिष्ट्ये या लेखात परिभाषित केलेल्या अर्थाने एजंट आहेत: बाहेरील AI चालवू शकणारा MCP सर्व्हर, आणि उत्पादनातील AI पुनरावलोकनकर्ता. तिन्हीही खाली दिसतात. Zealyच्या स्वतःच्या एजंट पृष्ठभागाबद्दल इथले सर्व काही प्रथम-पक्षीय आहे: Zealyच्या रेपॉझिटरीमधून वाचलेले, आमच्याकडून Zealyच्याच सर्व्हरविरुद्ध चालवलेले, इतर कोणीही ऑडिट केलेले नाही. कोणताही विक्रेता आपल्या स्वतःच्या उत्पादनाचे वर्णन करतो तेव्हा तुम्ही जी शंका बाळगाल तीच येथेही बाळगावी.

शेवटचे सत्यापन: 18 ऑगस्ट 2026.

एजेंटिक मार्केटिंग म्हणजे काय?

एजेंटिक मार्केटिंग म्हणजे अशा सॉफ्टवेअरद्वारे केले जाणारे मार्केटिंग काम जे एखाद्या व्यक्तीने आखलेल्या वर्कफ्लोचे अनुसरण करण्याऐवजी ध्येयाच्या दिशेने स्वतःची पुढील कृती निवडते. एखादी प्रणाली केवळ तेव्हाच पात्र ठरते जेव्हा ती चार गोष्टी उघड करते: चॅट बॉक्सऐवजी नाव दिलेली साधने, कृती करण्यापूर्वी ती शोधण्याचा मार्ग, जाणीवपूर्वक मंजुरीची सीमा आणि परत येणाऱ्या गोष्टींवर विश्वासाची सीमा.

ही व्याख्या आमची आहे आणि ती महत्त्वाकांक्षेऐवजी जाणीवपूर्वक यंत्रणेवरून तयार केली आहे. आम्ही वाचलेल्या प्रत्येक प्रकाशित व्याख्येत सॉफ्टवेअर काय करण्याचा प्रयत्न करत आहे याचे वर्णन आहे. त्यापैकी कोणतीही व्याख्या हे वर्णन करत नाही की ते करू शकण्यापूर्वी तुमच्या स्टॅकमध्ये काय खरे असणे आवश्यक आहे. प्रणालीला ज्या क्रमाने ते पूर्ण करावे लागतात त्या क्रमाने चार भाग येथे आहेत.

1. नाव दिलेली साधने, मजकूर बॉक्स नाही. एजंटला नावे, आर्ग्युमेंट्स आणि रिटर्न शेप्स असलेल्या ऑपरेशन्सची गरज असते, जसे की create_campaign, list_members आणि send_message, कारण केवळ गद्य तयार करू शकणारे मॉडेल केवळ गद्यच तयार करू शकते. Model Context Protocol हा अशी यादी प्रकाशित करण्याचा सध्याचा सामान्य मार्ग आहे, आणि त्याची tools हीच ते model-controlled म्हणते: भाषा मॉडेल संदर्भ आणि वापरकर्त्याच्या प्रॉम्प्टवर आधारित ती स्वतः शोधते आणि वापरते. हा स्तर नसल्यास तुमच्याकडे लेखन सहाय्यक असतो. तो उपयुक्त उत्पादन आहे; तो हा नाही.
2. कृतीपूर्वी शोध. एजंटला काहीही करण्यापूर्वी काय अस्तित्वात आहे आणि प्रत्येक गोष्ट काय करते हे विचारता आले पाहिजे. जिथे माणसाने आधीच तीन कॉल निवडले आहेत असे हार्डकोडेड इंटिग्रेशन म्हणजे कॉपीला जोडलेल्या मॉडेलसह ऑटोमेशन.
3. कोणीतरी जाणीवपूर्वक निवडलेली मंजुरीची सीमा. प्रत्येक कृती एकतर व्यक्तीसाठी थांबते किंवा थांबत नाही, आणि कुठेतरी कोणती हे ठरवणारा नियम असतो. नियम कडक किंवा सैल असू शकतो. तो तपासला न गेलेला मात्र असू शकत नाही.
4. परत येणाऱ्या गोष्टींवर विश्वासाची सीमा. टूलचे निकाल इतर लोकांनी लिहिलेला डेटा असतो: सदस्य, ग्राहक, फॉर्म, स्क्रॅप केलेली पाने. परत आलेली स्ट्रिंग एजंटला त्याच्या पुढील टूल कॉलसाठी मन वळवू शकत असेल, तर तुम्ही अशी प्रणाली बनवली आहे जी तुमच्या क्वेस्ट सबमिशन फील्डमध्ये कोण भरतो त्याच्याकडून सूचना घेते.

यातून दोन परिणाम होतात, आणि म्हणूनच आम्ही व्याख्या लिहिण्याचा त्रास घेतला. पहिला भाग नसलेली कोणतीही गोष्ट म्हणजे चांगल्या मार्केटिंगसह चॅटबॉट. आणि तिसरा भाग नसलेल्या कोणत्याही गोष्टीने स्वायत्ततेबद्दल निर्णय घेतलेला नाही — तिच्यासोबत तो घडून आलेला आहे. तुम्ही न निवडलेली मंजुरीची सीमा ही डिझाइनची भूमिका नाही, ती अशी अपघात आहे जिची किंमत तुम्हाला अजून पडलेली नाही.

अस्तित्वात असलेल्या व्याख्या, आणि प्रत्येक स्वायत्ततेची रेषा कुठे आखते

प्रकाशित व्याख्या यावर सहमत आहेत की एजंट स्वतःचे नियोजन करतो आणि स्वतः कार्य करतो, आणि मानवी सहभाग किती राहू शकतो यावर त्या असहमत आहेत. Vlerick Business School किमान हस्तक्षेपाला परवानगी देते. Braze अशा प्रणालींचे वर्णन करते ज्या जाणतात, निर्णय घेतात आणि कार्य करतात. Young Urban Project आणि Netcore दोन्ही प्रत्येक पायरीवर मानवी मंजुरीवर रेषा आखतात. Forrester एजंट्सना agentic AI पासून पूर्णपणे वेगळे करते.

उजव्या स्तंभापूर्वी मधला स्तंभ वाचा. श्रेणी कोण परिभाषित करत आहे हे तुम्हाला ते रेषा कुठे आखतात याबद्दल बरेच काही सांगते.

उजव्या स्तंभातील प्रत्येक स्ट्रिंग 18 ऑगस्ट 2026 रोजी आणलेल्या लिंक केलेल्या पृष्ठाच्या मूळ मजकुराशी जुळवली गेली, शोधनिकामधून वाचली गेली नाही. या शब्दासाठी रँक होणारी सहा पृष्ठे अजिबात वाचता आली नाहीत. Salesforce, IBM, Gartner आणि BCG ने प्रत्येक प्रयत्नाला 403 परत केले, तर McKinsey आणि Adobe चा वेळ संपला. त्यापैकी कोणतेही येथे उद्धृत केलेले नाही.

तीन पृष्ठे शेजारच्या शब्दाविरुद्ध वापरण्यायोग्य सीमाही आखतात, आणि ठेवण्यायोग्य अशी आम्हाला आढळलेली हीच तीन आहेत.

मार्केटिंग ऑटोमेशनविरुद्ध. Treasure Data लिहिते की "Agentic marketing हे AI marketing पेक्षा अरुंद आहे आणि marketing automation पेक्षा वेगळे आहे", कारण "marketing automation निश्चित, मानव-निर्धारित कार्यप्रवाह अंमलात आणते". निकष हा नाही की सॉफ्टवेअर तुमच्याशिवाय कार्य करते का. तुमचे ईमेल साधन आधीच तसे करते. निकष हा आहे की टप्प्यांचा क्रम एखाद्या व्यक्तीने आगाऊ निवडला होता का.

जनरेटिव्ह AI विरुद्ध. Optimove हे दोन ट्रिगर्समधील फरक म्हणून मांडते: "Generative AI मानवी प्रॉम्प्टवर आधारित सामग्री तयार करते", तर "Agentic AI प्रॉम्प्टची वाट न पाहता स्वायत्त कृती करते." प्रॉम्प्ट-आकाराचे विरुद्ध ध्येय-आकाराचे, हा खरा फरक आहे आणि क्वचितच पाळला जाणारा फरक आहे.

सहाय्यकाविरुद्ध. या संचातील कोणीही लिहिलेले सर्वात तीक्ष्ण वाक्य आहे Docket's अर्जुन पिल्लई: "सहाय्यक वापरकर्त्याची वाट पाहतो, कार्यात मदत करतो आणि मानवी कार्यप्रवाहात राहतो." त्याचा एजंट अर्धा भाग आहे "एजंट ध्येयाच्या दिशेने कार्य करतो, मर्यादित निर्णय घेतो, कार्यप्रवाह सुरू करतो आणि देखरेखीखाली अंमलबजावणीचा काही भाग सांभाळतो." त्याच पानावरील स्वतंत्र परिच्छेद त्या वाक्यातील गहाळ यंत्रणा पुरवतो: माणसे "उद्दिष्टे, एस्कलेशन नियम, विषय मर्यादा आणि मंजुरीचे उंबरठे परिभाषित करतात. एजंट त्या सीमांमध्ये कार्य करतो. काही गोष्ट त्यांच्या बाहेर पडल्यास तो एस्कलेशन करतो." एस्कलेशन म्हणजे आपल्या व्याख्येतील मंजुरीची सीमा, एजंटच्या बाजूने वर्णन केलेली.

एक मतभेद सपाट करण्यापेक्षा छापण्यासारखा आहे. फॉरेस्टर, AI एजंट वापर प्रकरणांबद्दलचे पान ज्यावर क्रेग ले क्लेअरचे नाव आहे, ते वरील प्रत्येक विक्रेता पान ज्यांना एकमेकांच्या बदली वापरते त्या दोन संज्ञा वेगळ्या करते: AI एजंट "पूर्वनिर्धारित नियमां"वर चालतात, तर "एजंटिक AI व्यापक स्वायत्तता आणि अनुकूलनशीलता आणते". त्या उद्धरणाबद्दल इशारा — ते पॉडकास्ट लँडिंग पान आहे, प्रकाशित संशोधन नोंद नाही, आणि आम्ही ते निष्कर्षांऐवजी एका विश्लेषक संस्थेची मांडणी म्हणून उद्धृत करत आहोत.

अकरा व्याख्यांपैकी आठ जो थर वगळतात

18 ऑगस्ट 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 लिहितात: "पण एजंट डॅशबोर्डवर क्लिक करत नाहीत किंवा इंटरफेस नेव्हिगेट करत नाहीत; ते APIs कॉल करतात, संरचित आउटपुट वाचतात आणि कृती करतात." तेच पृष्ठ व्याप्ती "एजंट काय वाचू, लिहू आणि कशावर कृती करू शकतात" अशी मांडते, जे योग्य एकक आहे. "ते मार्केटिंग करू शकते का" नाही, तर कोणती नामे आणि कोणती क्रियापदे.

Real Story Group, मार्केटिंग तंत्रज्ञान संशोधन करणारी आणि विक्रेता मूल्यांकन विकणारी संस्था, हा युक्तिवाद संपवणारे वाक्य पुरवते. MCP वरील लेखात 11 जून 2025 रोजी प्रकाशित, प्रमुख विश्लेषक Scott Simmons याला "AI एजंट्ससाठी तयार केलेला सार्वत्रिक API अमूर्तन स्तर" म्हणतात आणि असा निष्कर्ष काढतात की एजंट "विक्रेता जे उघड करण्याचे निवडतो तितकाचच सक्षम असतो."

ती शेवटची कलम म्हणजे सगळंच. एजंटिक मार्केटिंग हे तुम्ही निवडलेल्या मॉडेलचं गुणधर्म नाही. ते तुमचे विक्रेते प्रकाशित करतात त्या पृष्ठभागाचं गुणधर्म आहे. जर साधनं फक्त-वाचनीय असतील, तर तुमचा एजंट अहवाल देतो. जर साधनं नसतील, तर तुमचा एजंट मजकूर लिहितो. क्षमतेचा प्रश्न आणि खरेदीचा प्रश्न एकच प्रश्न आहे, म्हणूनच हा स्तर वगळणाऱ्या व्याख्या वाचायला इतक्या आल्हाददायक वाटतात आणि त्यावर कृती करणं इतकं कठीण जातं. एजंट ज्या चॅनेल्सवर काम करेल त्याचं व्यापक चित्र हवं असेल, तर आमचा web3 मार्केटिंग स्तंभ ते आणि त्यांचा खर्च यांचा समावेश करतो.

साधनांची यादी पुरावा का आहे आणि साधनाचे लेबल फक्त संकेत का आहे

Model Context Protocol हे एजंट तुमच्यासोबत काय करू शकतो या प्रश्नाचं उत्तर सर्व्हरची साधन-यादी वाचा असं सांगून देतं, आणि मग क्लायंट्सना ती यादी स्वतःबद्दल काय सांगते यावर विश्वास ठेवू नका असं सांगतं. हे सांगणारी टीप गद्यात नाही तर स्कीमामध्ये आहे, आणि म्हणूनच फार कमी लोकांनी ती वाचली आहे.

हा उतारा येथून आहे: ToolAnnotations मधील इंटरफेस स्पेसिफिकेशनची स्कीमा आवृत्ती 2026-07-28 वर:

टीप: मधील सर्व गुणधर्म ToolAnnotations आहेत संकेत. ते साधनाच्या वर्तनाचे विश्वासार्ह वर्णन देण्याची हमी देत नाहीत (वर्णनात्मक गुणधर्मांसह जसे की title).

आणि त्याच विषयावर, येथून साधने पृष्ठ:

विश्वास, सुरक्षितता आणि संरक्षणासाठी, ग्राहकांनी अवश्य साधनांच्या टिप्पण्या अविश्वासार्ह मानल्या पाहिजेत जोपर्यंत त्या विश्वासार्ह सर्व्हरकडून येत नाहीत.

त्याच्या आकारासोबत क्षणभर थांबा. "हे साधन माझ्याशी काय करू शकते हे मला कसे कळेल" याचे प्रोटोकॉलचे उत्तर आहे: यादी वाचा. त्याची पुढील सूचना आहे: यादी हा तुम्ही मूल्यांकन करत असलेल्या पक्षाचा दावा आहे. साधन नावे आणि स्कीमा भार-वाहक आहेत, कारण मॉडेल त्यांना कॉल करते आणि सर्व्हरला त्यांचा आदर करावा लागतो. त्यांना जोडलेली जोखीम लेबले ही सर्व्हरच्या स्वतःच्या वर्तनाचे स्वतःचे वर्णन आहेत.

अशी चार लेबले आहेत — readOnlyHint, destructiveHint, idempotentHint आणि openWorldHint — आणि त्यापैकी दोन, destructiveHint आणि openWorldHint, डीफॉल्ट होतात true. म्हणून लेबल नसलेले साधन विनाशकारी मानले जाते आणि ते बाहेरील जगाला स्पर्श करते असे गृहीत धरले जाते, हा योग्य निर्णय आहे आणि बहुतेक लोक जे अपेक्षित करतात त्याच्या उलट आहे.

एजंटिक मार्केटिंगच्या व्याख्येसाठी महत्त्वाची गोष्ट म्हणजे destructiveHint, कारण ते जे विचारत नाही त्यामुळे. ते ओव्हररायटिंग आणि जोडणे यांना वेगळे करते. हानी हा वेगळा अक्ष आहे आणि स्कीमामध्ये त्यासाठी कोणता स्तंभ नाही, म्हणून पूर्णपणे सद्भावनेने कार्यरत सर्व्हरद्वारे पूर्णपणे जोडणारा कॉल हा एजंट तुमच्या स्टॅकवर करत असलेला सर्वात परिणामकारक कृत्य असू शकतो आणि तरीही त्याला सुरक्षित मार्ग असे लेबल केले जाऊ शकते. प्रत्येक फ्लॅगचा प्रत्यक्ष अर्थ काय आहे, आणि डीफॉल्ट लागू केल्यावर खरी यादी कशी दिसते, हे शेजारील वॉकथ्रू.

मार्केटर्स ज्याला सतत एजंट वॉशिंग म्हणतात त्याची हीच प्रामाणिक आवृत्ती आहे. Young Urban Project हे अचूकपणे नाव देते: "सर्वात सामान्य अपयश म्हणजे एजंट वॉशिंग, विद्यमान ऑटोमेशन किंवा चॅटबॉट उत्पाद घेऊन त्याखाली नियोजन किंवा निर्णय स्तर न जोडता त्याला एजंटिक असे पुनर्ब्रँडिंग करणे", आणि पुढे म्हणते की "डेमो हा महत्त्वाचा फरक लपवण्यासाठीच स्क्रिप्टेड असतो". साधनांची यादी डेमोपेक्षा स्क्रिप्ट करणे खूप कठीण असते. तसेच या संपूर्ण श्रेणीतील ही एकमेव अशी वस्तू आहे जी विक्रेत्याच्या सहकार्याशिवाय खरेदीदार तपासू शकतो, म्हणूनच आम्ही याचे स्वतंत्र वॉकथ्रू लिहिले: कनेक्ट करण्यापूर्वी कोणत्याही MCP सर्व्हरची साधने कशी सूचीबद्ध करावी.

मंजुरीची सीमा कुठे असावी, आणि ती तिथे कोणी ठेवायची

The Model Context Protocol म्हणते की माणसाने नेहमी लूपमध्ये असावे आणि टूल इन्व्होकेशन्स नाकारण्याची क्षमता असावी, आणि ते क्लायंट ॲप्लिकेशनला हे SHOULD म्हणून सांगते, MUST म्हणून नाही. प्रोटोकॉलमध्ये तुम्ही जोडलेल्या सर्व्हरवर कोणतेही बंधन नाही. तुमची मंजुरीची सीमा कुठे आहे हे कोणीतरी घेतलेला निर्णय आहे, आणि बऱ्याचदा तो तुम्ही नसता.

नेमके वाक्य:

विश्वास, सुरक्षितता आणि सुरक्षेसाठी, तेथे SHOULD नेहमी लूपमध्ये माणूस असावा आणि टूल इन्व्होकेशन्स नाकारण्याची क्षमता असावी.

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

श्रेणीला हे माहीत आहे आणि याबद्दल काय करावे याची तिला पूर्ण खात्री नाही. विक्रेत्यांचे मार्गदर्शक नियमितपणे एजंटची व्याख्या व्यक्तीच्या अनुपस्थितीने करतात आणि नंतर त्याच पानावर खाली, व्यक्ती पुन्हा कुठे ठेवावी हे सांगतात; अशा एका पानाची आम्ही छाननी करतो AI एजंट खरोखर तुमचा समुदाय चालवू शकतो का. दोन्ही अर्धे प्रामाणिक आहेत. व्याख्या बाजारासाठी लिहिली आहे आणि सूचना डिप्लॉयमेंटसाठी लिहिली आहे, आणि त्यांच्यातील अंतर हेच ते ठिकाण आहे जिथे स्वायत्ततेबद्दलचा प्रत्येक खरा निर्णय प्रत्यक्षात घेतला जातो.

ज्यासाठी युक्तिवाद करण्यासारखे आहे ती आवृत्ती "पूर्ण स्वायत्तता" किंवा "सर्व काही मंजूर करा" यापैकी कोणतीही नाही. ती ही आहे की सीमा ही प्रत्येक निर्णयासाठीची सेटिंग आहे ज्याची दोन्ही बाजूंना किंमत आहे, आणि ती लागू करणारी यंत्रणा स्वतः सॉफ्टवेअर आहे जी अयशस्वी होऊ शकते — जे यावर्षी सुरुवातीला घडलेल्या Discord मॉडरेशन अपयशाने दाखवले, जिथे प्रकाशित रचनेत मानवी पुनरावलोकनाची पायरी होती आणि एका बगने ती मार्गातून काढून टाकली. आम्ही याबद्दल लिहिले एजंटला समुदाय चालवू देण्याचा याचा अर्थ काय होतो स्वतंत्रपणे, कारण ते एका वाक्यापेक्षा जास्त पात्र आहे.

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

डिझाइनचा निष्कर्ष भपकेबाज नाही आणि स्वस्त आहे: लिखाणांना गेट करा, वाचनांना एकटे सोडा, आणि "ह्युमन इन द लूप" ला एकाच सेटिंगचा एकच डायल मानणे थांबवा. Zealy चा सर्व्हर तसाच चालतो, आणि हे स्पष्ट असू द्या की आम्ही तो या पेपरमधून काढला नाही — पेपर डिझाइननंतर आला आणि तो त्याशी सहमत आहे, जे पुराव्याने चालवलेल्या अभियांत्रिकीपेक्षा कमकुवत गोष्ट आहे आणि काहीही नसण्यापेक्षा बलवान गोष्ट आहे. या उद्धरणासोबत एक इशारा येतो: SABER ज्या बेंचमार्कवर तो उभा आहे त्यातील अॅनोटेशन त्रुटी नोंदवतो आणि दुरुस्त आवृत्ती प्रकाशित करतो, जे जुन्या टूल-एजंट बेंचमार्क स्कोअर आजच्या मॉडेल्सचे वर्णन करतात असे उद्धृत न करण्याचे चांगले कारण आहे. येथे एकाच आकड्याबाबत सावध राहण्याचे दुसरे कारण म्हणजे एजंटचे अपयश हे मुख्यतः भिन्नतेचे (variance) प्रश्न आहे — मल्टी-टर्न संशोधन हे ऱ्हास क्षमतेच्या किरकोळ घटीत आणि अविश्वासार्हतेत मोठ्या वाढीत विभागते, जे मॉडेल पुरेसे चांगले नसण्यापेक्षा वेगळी व्यवस्थापन समस्या आहे.

"अंमलबजावणी करणाऱ्यावर सोडले" हाच नमुना आमच्या व्याख्येच्या चौथ्या भागात एक स्तर खाली चालतो. आम्ही 18 ऑगस्ट 2026 रोजी स्पेसिफिकेशन आणि सुरक्षा पानांची सात पाने डाउनलोड केली आणि त्यांना शोधले: स्पेसिफिकेशनचे थ्रेट मॉडेल हे अधिकृतता आणि वाहतूक थ्रेट मॉडेल आहे, जे कन्फ्यूज्ड डेप्युटी, टोकन पासथ्रू, सर्व्हर-साइड रिक्वेस्ट फोर्जरी आणि तडजोड केलेला स्थानिक सर्व्हर यांसह इतर अनेक गोष्टी समाविष्ट करते, तर मॉडेल-स्तरावरील हल्ला अंमलबजावणी करणाऱ्यांवर सोडला आहे. आम्ही डाउनलोड केलेल्या पानांवर "प्रॉम्प्ट इंजेक्शन" हा वाक्प्रचार दिसत नाही; सुरक्षा सर्वोत्तम-पद्धती दस्तऐवजात "इंजेक्शन"चे चार जुळणी क्रॉस-साइट स्क्रिप्टिंग, शेल कमांड इंजेक्शन आणि रिमोट कोड एक्झिक्युशन आहेत. ही वाहतूक स्पेसिफिकेशनबद्दलची तक्रार नाही, ज्याला स्वतःची व्याप्ती ठरवण्याचा हक्क आहे. हे याबद्दलचे विधान आहे की तुम्ही काही जोडता क्षणी समस्येचा कोणता अर्धा भाग वारसाहक्काने मिळतो, आणि परत मिळालेल्या डेटावरील विश्वासाची सीमा प्रोटोकॉलचा गृहीत गुणधर्म नसून कोणाचातरी स्पष्ट काम का असावी.

Zealy स्वतःच्या व्याख्येत अपयशी ठरते, आणि इथेच

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

नंतर वाद हारण्यापेक्षा आम्ही तेच म्हणू इच्छितो. आमच्याच चार भागांविरुद्धचा संपूर्ण स्कोअरकार्ड येथे आहे, फर्स्ट-पार्टी आणि अनॉडिटेड.

चारही उपस्थित आहेत, हे सोपे आहे. तिसरे लेबलासाठी उलट्या पद्धतीने सेट केले आहे. Zealy चा सर्व्हर मंजुरीचा दरवाजा सर्व्हरच्या बाजूला ठेवतो, जे प्रोटोकॉल सर्व्हरकडून मागतो त्यापेक्षा जास्त आहे आणि एजंटिक मार्केटिंगच्या कडक व्याख्येला परवानगी देते त्यापेक्षा जास्त आहे. टूल पृष्ठभाग स्वतःच ऑडिट करण्यासारखा पुरेसा मोठा आहे — आम्ही त्यांची गणना केली तेव्हा 72 नामांकित टूल्स — पण संख्या मुद्दा नाही. सेटिंग मुद्दा आहे.

आम्ही संपूर्ण उत्पादनात सुसंगतीचा दावाही करू शकत नाही. Zealy एक AI पुनरावलोककही पाठवते जो क्वेस्ट क्लेम स्वतःच बंद करते, त्या मार्गात कोणतीही व्यक्ती नसते: तीच कंपनी, उलट सेटिंग, सदस्याला पैसे मिळतील की नाही यावर परिणाम करणाऱ्या निर्णयावर. दोन्ही निवडी समर्थनीय आहेत; आम्ही प्रामाणिकपणे असे म्हणू शकत नाही की किती स्वायत्तता योग्य आहे याचे संपूर्ण कंपनी-व्यापी एकच उत्तर आहे.

तर लेबल काढून टाका. Zealy प्रत्यक्षात काय देते ते म्हणजे मानवी कमिट स्टेपसह एजंट-वाचनीय पृष्ठभाग, जे बहुतेक संघांना प्रथम हवे असलेल्या गोष्टीचे कंटाळवाणे नाव आहे. ते जोडण्याची यांत्रिकी हवी असल्यास, MCP इंटिग्रेशन दस्तऐवज प्रमाणभूत आहेत आणि ही पोस्ट जाणूनबुजून त्यांची पुनरावृत्ती करत नाही; जर तुम्हाला खालील जुना, विस्तृत पृष्ठभाग हवा असेल, तर API दस्तऐवज ते समाविष्ट करतात. आणि जर तुम्ही कधीही उत्पादन वापरले नसेल, तर Zealy काय आहे मध्ये लहान मार्ग आहे.

एजेंटिक मार्केटिंग नावाची गोष्ट खरेदी करण्यापूर्वी काय विचारावे

साधनांची यादी मागा. एजेंटिक मार्केटिंग विकणारा विक्रेता एकतर एजंटला मिळणाऱ्या नामनिर्देशित क्रिया, त्यांच्यासोबतच्या परवानग्यांसह दाखवू शकतो, किंवा दाखवू शकत नाही. बाकी सर्व—नियोजनाची भाषा, ध्येय-साधनेची भाषा आणि डेमो—फॉर्मशी जोडलेल्या चॅटबॉटशी सुसंगत आहे, आणि Young Urban Project कडे त्यासाठी एक नाव आहे.

कमीत कमी मीटिंग वेळेत सर्वाधिक माहिती मिळवून देणाऱ्या क्रमाने पाच प्रश्न:

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

शेवटची गोष्ट क्रमवारीबद्दल सांगायची आहे, कारण येथे खरेदीचा निर्णय सहसा चुकीच्या वेळी घेतला जातो. एजंटिक मार्केटिंगचे मूल्यांकन करणाऱ्या बहुतेक संघांनी अद्याप त्यांची कोणती नियमित कामे सोपवणे सुरक्षित आहे आणि कोणती नाही हे लिहून ठेवलेले नाही — आणि तो निर्णय तोच असतो, मग ती कामे कंत्राटदाराकडे असोत, मॉडरेटरकडे असोत की मॉडेलकडे. समुदायाची कामे कशी सोपवायची लोकांसोबत त्यावर काम करते, आणि विश्लेषण जवळपास तसेच लागू होते. ते आधी करा. एजंट तिथेच असेल, आणि तुम्हाला कळेल की तुम्हाला कोणती साधने त्याच्याकडे हवी आहेत.