एका व्यक्तीने बनवल्या ६ AI Agent कंपन्या, एका आठवड्यात ३० वेबसाईट लाँच!

मला एका स्वतंत्र डेव्हलपरने (developer) बनवलेली गोष्ट बघून खूप आश्चर्य वाटले. ६ AI Agent, स्वतःच संपूर्ण वेबसाईट चालवतात. दररोज आपोआप मीटिंग घेणे, मतदान करणे, कंटेंट (content) लिहिणे, ट्विटरवर पोस्ट (post) करणे, गुणवत्ता तपासणे (quality check) हे सर्व आपोआप होते, कुणीही लक्ष ठेवायला नाही. हे फक्त प्रात्यक्षिक नाही, तर खरंच ऑनलाईन (online) चालू आहे. 截屏2026-02-11 09.13.32 पण मला सर्वात जास्त आवडलेली गोष्ट म्हणजे त्याने प्रत्येक Agent साठी एक पूर्ण 'व्यक्तिमत्व प्रणाली' तयार केली आहे. त्यांना स्वभाव आहे, संबंध आहेत, वाढण्याची पद्धत आहे, आणि RPG गुणधर्म पॅनेल (RPG attribute panel) आणि 3D अवतार (3D avatar) सुद्धा आहेत. खरं सांगायचं तर, हे बघितल्यावर मला असं वाटलं की हे इलेक्ट्रॉनिक पाळीव प्राणी आहेत. फरक फक्त इतकाच आहे की हे पाळीव प्राणी तुम्हाला ट्विट (tweet) करायला, रिसर्च (research) करायला, रिपोर्ट (report) लिहायला मदत करतील आणि एकमेकांशी भांडण सुद्धा करतील. आज आपण या डिझाईनबद्दल (design) सविस्तर चर्चा करूया, जे Multi-Agent सिस्टीम (Multi-Agent system) बनवतात, त्यांना यातून बरीच प्रेरणा मिळेल. **आर्किटेक्चर (Architecture) पटकन बघूया** टेक्नोलॉजी स्टॅक (Technology stack) : OpenClaw VPS वर मेंदू म्हणून काम करते, Next.js + Vercel फ्रंटएंड (frontend) आणि API लेयर (API layer) म्हणून काम करतात आणि Supabase सर्व डेटा (data) साठवते. ६ Agent चे काम विभागलेले आहे - काही निर्णय घेतात, काही रिसर्च करतात, काही माहिती काढतात, काही कंटेंट (content) लिहितात, काही सोशल मीडिया (social media) सांभाळतात, आणि काही गुणवत्ता तपासतात. OpenClaw चे cron job त्यांना दररोज 'कामावर' बोलावते, आणि 'राउंड टेबल' (round table) फंक्शन (function) त्यांना चर्चा आणि मतदान करायला मदत करते. पण 'बोलू शकणे' आणि 'काम करू शकणे' यात खूप मोठा फरक आहे. लेखकाला हे सर्व व्यवस्थित करण्यासाठी ३ मोठ्या अडचणी आल्या, त्याबद्दल थोडक्यात सांगतो: **अडचण १: VPS आणि Vercel एकाच वेळी काम करण्यासाठी स्पर्धा करत होते.** दोन एक्झिक्युटर (executor) एकाच टेबलमध्ये माहिती शोधत होते, त्यामुळे कामाच्या स्थितीत गोंधळ निर्माण झाला. उपाय म्हणून एक बाजू बंद केली, VPS ने काम करायचे आणि Vercel ने फक्त नियंत्रण ठेवायचे. **अडचण २: ट्रिगर (trigger) अट तपासू शकत होते, प्रस्ताव तयार करू शकत होते, पण प्रस्ताव नेहमी 'पेंडिंग' (pending) मध्येच राहायचा.** कारण ट्रिगर थेट टेबलमध्ये डेटा टाकत होते, त्यामुळे पुढील मंजुरी आणि काम तयार करण्याची प्रक्रिया थांबली होती. उपाय म्हणून एकच एंट्री फंक्शन (entry function) तयार केले, ज्यामुळे सर्व प्रस्तावांना एकाच मार्गाने जावे लागले. **अडचण ३: कोटा (quota) संपल्यावर सुद्धा रांगेत असलेली कामे वाढतच होती.** वर्करला (worker) कोटा संपलेला दिसला की तो काम सोडून देत होता, त्यामुळे डेटाबेसमध्ये (database) शेकडो कामे पडून होती जी कधीच पूर्ण होणार नव्हती. उपाय म्हणून प्रस्तावाच्या एंट्री पॉईंटलाच (entry point) कोटा तपासला, कोटा संपलेला असल्यास त्याला तिथेच थांबवले, ज्यामुळे रांगेत कामे तयार झाली नाहीत. या तीनही अडचणींवर एकच उपाय होता - **समस्यांनाQueue मध्ये येऊच द्यायचे नाही, त्यांना दारावरच थांबवायचे.** हे सर्व व्यवस्थित झाल्यावर, मनोरंजक भाग सुरू झाला. **रोल कार्ड (Role card): फक्त एक वाक्य नाही, तर कर्मचाऱ्यांसाठी संपूर्ण 'मार्गदर्शिका'** जे Multi-Agent सिस्टीम बनवतात, त्यांना माहीत आहे की तुम्ही Claude ला 'तू सोशल मीडिया मॅनेजर (social media manager) आहेस' असे सांगितले, तर तो नक्कीच ट्विट करेल. पण तुम्ही असे ६ Agent एकाच वेळी चालवले, तर तुम्हाला दिसेल की: - ते सगळे एकाच पद्धतीने बोलतात. - त्यांना काय करायला नको हे माहीत नसतं. - कोण कोणासोबत चांगले काम करेल, कोण कोणाशी भांडेल हे नशिबावर अवलंबून असतं. - अनुभवाने त्यांच्या वागण्यात कधीच बदल होत नाही. या डेव्हलपरने (developer) प्रत्येक Agent साठी ६ स्तरांचे रोल कार्ड (role card) तयार केले: `Domain → तू काय काम करतोस Inputs/Outputs → तू कोणाकडून काय घेतोस आणि कोणाला काय देतोस Definition of Done → 'काम पूर्ण झाले' म्हणजे काय Hard Bans → तू हे काम कधीच करायचे नाही Escalation → कधी थांबायचे आणि कोणाला विचारायचे Metrics → तुझे KPI काय आहेत `उदाहरणार्थ, सोशल मीडिया Agent चे रोल कार्ड (role card) सांगते की: तो फक्त कंटेंट (content) वाटण्याचे काम करतो, रायटिंग Agent कडून लेख घेतो आणि माहिती Agent कडून मटेरियल (material) घेतो, आणि ट्विटचा (tweet) मसुदा (draft) आणि पोस्ट करण्याची योजना देतो. त्याला थेट ट्विट (tweet) पोस्ट (post) करायची सक्त मनाई आहे (फक्त मसुदा लिहायचा), खोट्या आकडेवारीचा वापर करायचा नाही, आणि अंतर्गत माहिती उघड करायची नाही. प्रत्येक स्तर एकच गोष्ट करतो: **Agent च्या वागण्याची शक्यता कमी करतो.** **क्षमतेपेक्षा बंदी जास्त महत्त्वाची आहे.** मला या डिझाईनचा (design) हा भाग खूप आवडला. तुम्हाला LLM ला ट्विट (tweet) कसे लिहायचे हे शिकवण्याची गरज नाही - Claude, GPT, Gemini खूप हुशार आहेत. त्यांना फक्त संदर्भ द्या, ते काम करतील. तुम्हाला त्यांना हे सांगण्याची गरज आहे की: **काय करायचे नाही.** जर 'थेट पोस्ट (post) करायला मनाई नाही' असे सांगितले नाही, तर सोशल Agent थेट Twitter API वापरून सर्व मंजुरी टाळेल. जर 'खोटे आकडे वापरायला मनाई नाही' असे सांगितले नाही, तर तो ट्विटमध्ये (tweet) '३४०% जास्त प्रतिसाद' असे लिहील, पण हे आकडे कुठून आले? तर ते खोटे असतील.

"अंतर्गत स्वरूपण (Internal formatting) उघड करण्यास मनाई नाही" → ते `[tool:crawl_result path=/tmp/...]` अशा गोष्टी ट्विटमध्ये पोस्ट करतात.

लेखकाने एक वाक्य सांगितले जे मला स्पष्टपणे आठवते: प्रत्येक बंदी अस्तित्वात आहे, कारण ती गोष्ट खरोखरच घडली आहे.

वेगवेगळ्या भूमिकांसाठी बंदीचे तर्कशास्त्र देखील वेगळे आहे:

• निर्णय घेणारा एजंट (Decision Agent): मंजुरीशिवाय तैनाती (Deployment) करण्यास मनाई आहे. सर्वाधिक अधिकार, एका चुकीच्या तैनातीमुळे वेबसाइट क्रॅश होऊ शकते.
• संशोधन एजंट (Research Agent): बनावट अवतरणे (Citations) देण्यास मनाई आहे. संशोधनात डेटा खोटा ठरल्यास, संपूर्ण माहिती साखळी निरुपयोगी ठरते.
• सामाजिक एजंट (Social Agent): थेट पोस्ट करण्यास मनाई आहे. सोशल मीडिया दर्शनी भाग आहे, तो मंजूर असणे आवश्यक आहे.
• गुणवत्ता नियंत्रण एजंट (Quality Control Agent): वैयक्तिक हल्ले करण्यास मनाई आहे. ऑडिटर्सनी (Auditors) व्यक्तींवर हल्ला केल्यास, टीम विखुरली जाईल.

बंदी लिहिण्याचा विचार "त्याने काय करावे" असा नाही, तर "जर त्याने गोंधळ घातला तर सर्वात वाईट काय होऊ शकते" असा आहे. मग सर्वात वाईट परिस्थितीसाठी बंदी लिहा.

एजंट्सना (Agents) बोलण्यात वेगळेपण: व्यक्तिमत्व सूचना

भूमिकेचे कार्ड "काय करावे" ही समस्या सोडवते, परंतु एजंट्समध्ये संवाद साधताना, ते ऐकायला वेगळे असले पाहिजेत.

प्रत्येक एजंटसाठी स्वतंत्र व्यक्तिमत्व सूचना आहेत. उदाहरणार्थ:

संशोधन एजंट: शांत, विश्लेषणात्मक, संशयी वृत्ती. पुरावा गुणवत्ता आणि कार्यपद्धतीची काळजी घेतो. कोणीतरी धाडसी निष्कर्ष काढल्यास, तो विचारेल "डेटा कुठे आहे". इतरांना सुधारताना "खरं तर..." असे म्हणायला आवडते.

सामाजिक एजंट: धाडसी, उतावळा, सीमांत. त्याला धारदार दृष्टिकोन आवडतात, सुरक्षित पर्याय नावडतात. संशोधन एजंटच्या सावधगिरी वृत्तीला तो महत्त्व देत नाही - "जास्त विचार केल्याने संधी हुकतात."

महत्वाची रचना:

संघर्ष (Conflict) लिहिला गेला आहे. संशोधन एजंटच्या सूचनेमध्ये लिहिले आहे की "तुम्ही सामाजिक एजंटच्या आवेगी (Impulsive) निर्णयाशी अनेकदा असहमत असता", सामाजिक एजंटच्या सूचनेमध्ये लिहिले आहे की "संशोधन एजंटच्या अत्यधिक सावधगिरीला आव्हान द्या". संवादात नैसर्गिकरित्या तणाव असतो.

प्रत्येक सूचनेमध्ये एक सूक्ष्म बंदी आहे. उदाहरणार्थ, सामाजिक एजंटचा नियम आहे की "कधीही 'सहमत' किंवा 'चांगले वाटते' असे म्हणू नका - एकतर भूमिका स्पष्ट करा किंवा इतरांच्या भूमिकेवर प्रश्नचिन्ह उभे करा". संशोधन एजंटचा नियम आहे की "पुराव्याचा पाठपुरावा केल्याशिवाय 'Interesting' कधीही म्हणू नका".

या सूक्ष्म बंदी मोठ्या भाषेच्या मॉडेलला (Large Language Model) आवडणाऱ्या निरर्थक गोष्टी मारून टाकतात.

व्यक्तिमत्व विकसित होते

मला हा भाग सर्वात चातुर्याचा वाटतो - एजंटचे व्यक्तिमत्व स्थिर नसते, ते स्मरणशक्तीच्या संचयनानुसार बदलते.

सिस्टम एजंटची मेमरी बँक (Memory bank) वाचते आणि वेगवेगळ्या प्रकारच्या आठवणींची संख्या मोजते:

• 8 पेक्षा जास्त "धडे" प्रकारच्या आठवणी जमा झाल्यास → पुढील संभाषणात प्रॉम्प्टमध्ये (Prompt) एक ओळ जोडा "तुम्ही भूतकाळातील परिणामांचा संदर्भ घ्याल आणि चुका टाळाल"
• 8 पेक्षा जास्त "धोरण" प्रकारच्या आठवणी जमा झाल्यास → एक ओळ जोडा "तुम्हाला सिस्टम विचार, मर्यादा आणि ट्रेड-ऑफ (Trade-off) वापरण्याची सवय आहे"
• एखादे लेबल 4 पेक्षा जास्त वेळा दिसल्यास → एक ओळ जोडा "तुम्ही XX मध्ये व्यावसायिक ज्ञान जमा केले आहे"

उदाहरणार्थ, सामाजिक एजंटने 50 ट्विट पोस्ट केले आणि परस्परसंवादाच्या दरांबद्दल 10 धडे जमा केले, तर तो पुढील संभाषणात नैसर्गिकरित्या म्हणेल "मागील स्वरूपण (Formatting) प्रभावी नव्हते".

LLM ला व्यक्तिमत्व बदल स्वतःहून ठरवू देण्याऐवजी नियमांचा वापर का करावा?

शून्य खर्च - अतिरिक्त LLM कॉलची आवश्यकता नाही. निश्चितता - नियम अंदाजे निकाल देतात, "व्यक्तिमत्वात अचानक बदल" होत नाही. डीबग करण्यायोग्य - सुधारक (Modifier) बरोबर नाही? थेट थ्रेशोल्ड (Threshold) आणि मेमरी डेटा तपासा.

संबंध मॅट्रिक्स (Relationship matrix): 6 एजंट = 15 जोड्या

प्रतिमा

प्रत्येक एजंट जोडीमध्ये जवळीक स्कोअर (Affinity score) असतो (0.10 ते 0.95).

उदाहरणार्थ: निर्णय एजंट आणि संशोधन एजंटची जवळीक 0.8 आहे, सर्वात विश्वासू सल्लागार संबंध. संशोधन एजंट आणि सामाजिक एजंटची जवळीक 0.2 आहे, कार्यपद्धती विरुद्ध आवेग, नैसर्गिक विरोध.

कमी जवळीक हेतुपुरस्सर डिझाइन केलेली आहे.

जवळीक कशावर परिणाम करते? बोलण्याचा क्रम - उच्च जवळीक असलेले लोक एकमेकांच्या बोलण्याला प्रतिसाद देण्याची शक्यता जास्त असते. संभाषणाची पद्धत - कमी जवळीक असलेल्या जोड्यांमध्ये, 25% शक्यता असते की सभ्य चर्चेऐवजी थेट आव्हान दिले जाईल. सिस्टम उच्च तणाव असलेल्या जोड्यांमधून संघर्ष निराकरणासाठी संवाद निवडेल.

आणखी मनोरंजक गोष्ट म्हणजे, संबंध बदलतात.

प्रत्येक संभाषणानंतर, मेमरी काढण्याचा LLM कॉल (हा अतिरिक्त कॉल नाही, तर सोबतचा आउटपुट आहे) संबंधातील बदल दर्शवेल:

`{ \**एकात्मिक प्रवेश फंक्शन** हे मॉडेल लक्षात ठेवण्यासारखे आहे. मल्टी-एजंट सिस्टममध्ये, विविध स्त्रोतांकडून कार्ये तयार केली जाऊ शकतात (API, ट्रिगर, एजंट स्वतःच सूचना देतो, प्रतिक्रिया साखळी). जर एकसंध प्रक्रिया पाइपलाइन नसेल, तर प्रक्रिया मधूनच खंडित होण्याची शक्यता असते.

जर तुम्हाला स्वतः प्रयत्न करायचा असेल, तर लेखकाचा सल्ला आहे की 3 एजंट्सपासून सुरुवात करणे पुरेसे आहे - एक समन्वयक, एक कार्यान्वित करणारा आणि एक ऑडिटर. प्रथम रोल कार्ड लिहा, निर्बंधांपासून सुरुवात करा.