# Alejandro Rioja — HI > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/hi/ Author: Alejandro Rioja Language: hi --- ## मानव निगरानी वाले AI एजेंट: अनुमोदन गेट कब बनाएं (और कब नहीं) Source: https://alejandrorioja.com/hi/human-in-the-loop-ai-agents-when-to-build-an-approval-gate/ Published: 2026-07-23 Tags: AI Agents, Operations TL;DR: अनुमोदन गेट तब समझ में आता है जब गलती महंगी, अपरिवर्तनीय या ग्राहक-सामना हो — और जब कोई इंसान इसे समय पर पकड़ सके। तब नहीं जब वॉल्यूम समीक्षा के लिए बहुत अधिक हो, गलती सुधारना सस्ता हो, या लोग बिना पढ़े अनुमोदन दे दें। मैं तय करने के लिए चार सवाल पूछता हूं, और मेरे 30 से अधिक प्रोडक्शन एजेंटों में से अधिकांश में कोई अनुमोदन गेट नहीं है। ## विषय सूची _जुलाई 2026 में प्रकाशित।_ **TL;DR:** अनुमोदन गेट तब समझ में आता है जब गलती महंगी, अपरिवर्तनीय या ग्राहक-सामना हो — और जब कोई इंसान इसे समय पर पकड़ सके। जब वॉल्यूम समीक्षा के लिए बहुत अधिक हो, गलतियां सस्ती हों, या लोग बिना पढ़े अनुमोदन दे दें, तब नहीं। मैं चार सवालों से तय करता हूं, और मेरे 30 से अधिक प्रोडक्शन एजेंटों में से अधिकांश पूरी तरह स्वचालित चलते हैं। **ऑपरेटर की टिप्पणी:** मैं दो व्यवसायों में एजेंट चलाता हूं — एक परामर्श ब्रांड और टेक्सास के पफ्लुगर्विल में पिकलेलैंड, एक पिकलबॉल सुविधा। शुरुआत में मैंने हर जगह अनुमोदन गेट लगाए क्योंकि यह "सुरक्षित" लगा। हफ्तों में, मेरे पास एक Slack चैनल था जो ऐसी सूचनाओं से भरा था जिन्हें कोई नहीं पढ़ता, और तकनीकी रूप से निगरानी में पर व्यावहारिक रूप से बिना निगरानी के एजेंट थे। यह गेट न होने से भी बुरा है: बिना सार के निगरानी का भ्रम। यह लेख बताता है कि मैं अब इस निर्णय के बारे में कैसे सोचता हूं। ## मानव निगरानी गेट वास्तव में क्या है सबसे सरल शब्दों में, अनुमोदन गेट एजेंट के वर्कफ्लो में एक रुकावट है जहां एजेंट आगे बढ़ने से पहले किसी इंसान को पुष्टि करनी होती है। एजेंट ईमेल का मसौदा तैयार करता है — एक इंसान भेजने से पहले इसे अनुमोदित करता है। एजेंट किसी लेन-देन को फ्लैग करता है — रिफंड प्रोसेस होने से पहले एक इंसान समीक्षा करता है। गेट सिंक्रोनस हो सकता है (एजेंट तब तक रुकता है जब तक कोई अनुमोदन नहीं करता) या एसिंक्रोनस (एजेंट कार्रवाई को कतार में डालता है, सूचना भेजता है, और कोई इंसान डैशबोर्ड या Slack संदेश से अपनी गति से अनुमोदन करता है)। समय-महत्वपूर्ण नहीं होने वाली हर चीज के लिए एसिंक्रोनस लगभग हमेशा बेहतर होता है। ## मेरे चार सवाल गेट जोड़ने से पहले, मैं चार सवालों पर विचार करता हूं। किसी एक पर "हां" एक की विचार करने का संकेत है। सभी चार पर "हां" का मतलब है कि गेट संरचनात्मक रूप से आवश्यक है। **1. क्या कार्रवाई अपरिवर्तनीय है (या वापस करना महंगा है)?** 10,000 लोगों को ईमेल भेजना वापस नहीं लिया जा सकता। भुगतान जमा करना आसानी से वापस नहीं बुलाया जा सकता। बिना बैकअप के डेटाबेस रिकॉर्ड हटाना स्थायी है। अपरिवर्तनीयता गेट के लिए सबसे मजबूत तर्क है। इसकी तुलना: किसी इनकमिंग क्वेरी को श्रेणी टैग लगाना। अगर टैग गलत है, दो क्लिक में ठीक कर लेते हैं। गेट की जरूरत नहीं। **2. अगर एजेंट गलत हो तो कौन भुगतान करता है?** आंतरिक लेबल गलत — कुछ सेकंड में ठीक करना पड़ता है। ग्राहक-सामना ईमेल गलत — ग्राहक बुरे अनुभव से और मैं विश्वास खोने से भुगतान करता हूं। वित्तीय लेन-देन गलत — असली पैसे और अनुपालन जोखिम से भुगतान करता हूं। **3. क्या कोई इंसान वास्तव में मायने पड़ने से पहले गलती पकड़ सकता है?** यह वह सवाल है जिसे ज्यादातर लोग छोड़ देते हैं। अगर एजेंट प्रति घंटे 500 आइटम प्रोसेस करता है और आपको प्रति आइटम एक Slack सूचना मिलती है, तो कोई सभी 500 नहीं पढ़ेगा। आप निगरानी नहीं, अलर्ट थकान पैदा कर रहे हैं। **4. क्या लोग एजेंट द्वारा प्रस्तुत सामग्री विश्वसनीय रूप से पढ़ते हैं?** अगर आपकी अनुमोदन कतार भर जाती है और लोग बिना पढ़े अनुमोदन करते हैं, तो गेट गेट न होने से बुरा है। ## गेट कब स्पष्ट रूप से समझ में आते हैं ये वे पैटर्न हैं जहां मैं हमेशा गेट जोड़ता हूं, बिना किसी अपवाद के: - **अपरिवर्तनीय बाहरी संचार** — असली लोगों को जाने वाले ईमेल, SMS, सोशल मीडिया पोस्ट। एजेंट मसौदा तैयार करता है; इंसान भेजता है। - **एक सीमा से ऊपर की वित्तीय कार्रवाइयां** — पैसे हिलाने वाली कोई भी चीज को गेट मिलता है अगर यह मेरे द्वारा संदर्भ के अनुसार निर्धारित न्यूनतम से ऊपर है। - **नए पैटर्न जो एजेंट ने पहले नहीं देखे** — अगर एजेंट का क्लासिफायर कुछ को "अज्ञात" के रूप में फ्लैग करता है, तो वह एक जबरदस्ती एस्केलेशन है। - **अनुपालन-संवेदनशील आउटपुट** — HIPAA, PCI, कानूनी नोटिस या विनियमित वित्तीय सामग्री को छूने वाली कोई भी चीज एक व्यक्ति द्वारा समीक्षा की जाती है। ## गेट उत्पाद को चुपचाप कब मार देते हैं ये वे पैटर्न हैं जहां गेट सुरक्षित लगता है लेकिन अपनाना चुपचाप तोड़ देता है: - **उच्च-मात्रा, प्रतिवर्ती संचालन** — अगर दो क्लिक में पूर्ववत किया जा सकता है और दिन में 200 बार होता है, तो समीक्षा थकान जीत जाएगी। - **समय-संवेदनशील वर्कफ्लो** — 30 सेकंड में आने वाली ग्राहक पूछताछ का जवाब देने वाले एजेंट का सिंक्रोनस गेट नहीं होना चाहिए। - **कार्य जहां इंसान के पास एजेंट से कम संदर्भ है** — अगर एजेंट ने वर्गीकरण के लिए 50 पेज का संदर्भ पढ़ा और समीक्षक को एक पंक्ति का सारांश मिलता है, तो समीक्षा नाटक है। - **आंतरिक समृद्धि और लेबलिंग** — CRM रिकॉर्ड टैग करना, खर्चों को वर्गीकृत करना, मीटिंग नोट्स सारांशित करना। दांव रुकावट को उचित नहीं ठहराता। ## मेरे वास्तव में लागू करने वाले तीन गेट पैटर्न जब गेट उचित हो, मैं तीन कार्यान्वयन में से एक चुनता हूं: **1. Slack/ईमेल के माध्यम से एसिंक्रोनस अनुमोदन** एजेंट मसौदा पूरा करता है, प्रस्तावित कार्रवाई और अनुमोदन/अस्वीकरण बटन के साथ निर्दिष्ट Slack चैनल में संदेश पोस्ट करता है, और रुक जाता है। मैं Cloudflare Queues का उपयोग करता हूं और एक अलग Worker जो फिर से शुरू करने से पहले अनुमोदन webhook सुनता है। किसके लिए अच्छा काम करता है: ईमेल मसौदे, सोशल सामग्री, महत्वपूर्ण CRM अपडेट। **2. विश्वास-आधारित एस्केलेशन** एजेंट उच्च-विश्वास आउटपुट के लिए पूरी तरह से स्वचालित रूप से चलता है (मान लीजिए, संरचित स्कीमा पर ≥0.85 विश्वास) और कम-विश्वास आइटम को मानव कतार में भेजता है। किसके लिए अच्छा काम करता है: वर्गीकरण, रूटिंग, ट्राइएज। **3. बैच अनुमोदन के साथ डैशबोर्ड समीक्षा** प्रति-आइटम गेट के बजाय, सभी एजेंट आउटपुट समीक्षा डैशबोर्ड में आते हैं। एक इंसान बैच में समीक्षा करता है — उदाहरण के लिए, हर सुबह — और समूह में अनुमोदन या सुधार करता है। किसके लिए अच्छा काम करता है: सामग्री निर्माण, रिपोर्ट मसौदे, निर्धारित सारांश। ## अलर्ट थकान का जाल आपके द्वारा जोड़ा गया हर गेट किसी के ध्यान पर एक स्थायी कर है। जोखिम केवल यह नहीं है कि एक गेट को नजरअंदाज किया जाए — यह है कि तीन गेट एक शोरगुल वाला Slack चैनल बनाते हैं। मेरी अनुशासन: हर गेट में एक स्पष्ट मालिक और एक स्पष्ट SLA है। अगर कोई SLA के भीतर लगातार समीक्षा नहीं करता, तो गेट हटा दिया जाता है और ऑडिट ट्रेल से बदल दिया जाता है। मैं सभी अनुमोदन कतारों की मासिक ऑडिट करता हूं। ## एजेंट विश्वसनीयता से जोड़ना एक गेट एक विश्वसनीयता स्टैक की एक परत है, पूरा स्टैक नहीं। प्रोडक्शन एजेंट के लिए मेरा पूरा विश्वसनीयता स्टैक: 1. **मूल्यांकन हार्नेस** — डिप्लॉय करने से पहले सही आउटपुट की पुष्टि। 2. **स्कीमा सत्यापन के साथ संरचित आउटपुट** — एजेंट का आउटपुट एक टाइप किए गए स्कीमा तक सीमित है। 3. **विश्वास सीमा** — कम-विश्वास आउटपुट मानव समीक्षा में जाते हैं। 4. **ऑडिट लॉग** — एजेंट की हर कार्रवाई रिकॉर्ड की जाती है। 5. **मानव अनुमोदन गेट** — केवल उन कार्यों के लिए जहां ऊपरी पर्याप्त नहीं है। ## मेरा अनुभव का नियम अगर मैं नहीं चाहूंगा कि कोई जूनियर कर्मचारी पहले मुझसे जांचे बिना यह करे, तो एजेंट को एक गेट चाहिए। अगर मैं एक जूनियर कर्मचारी को बिना सोचे यह करने दूंगा, तो एजेंट को बिना निगरानी के चलना चाहिए। ## अक्सर पूछे जाने वाले सवाल ### मैं उस एजेंट को कैसे संभालूं जिसे अनुमोदन की जरूरत है लेकिन वह उच्च-मात्रा में चलता है? आर्किटेक्चर बदलें: प्रति-आइटम अनुमोदन की मांग मत करें — प्रति-पैटर्न अनुमोदन की मांग करें। एजेंट को चलने दें, लेकिन उसे मानव समीक्षा के लिए सांख्यिकीय विसंगतियां प्रस्तुत करने दें। ### अगर एक गलती गंभीर नुकसान पहुंचा सकती है लेकिन मैं पूर्ण मानव समीक्षा नहीं कर सकता? यह आमतौर पर उस कार्रवाई के लिए अभी एजेंट तैनात न करने का संकेत है। वैकल्पिक रूप से, एक विश्वास सीमा का उपयोग करें। यदि आप [Claude](/recommends/claude) को मॉडल परत के रूप में उपयोग करते हैं, तो Anthropic SDK के टूल उपयोग पैटर्न एक "एस्केलेट" टूल को परिभाषित करना आसान बनाते हैं जिसे एजेंट तब बुला सकता है जब उसे विश्वास की कमी हो। --- ## Claude Tool Use: मैं अपने AI एजेंटों को वास्तविक क्षमताएं कैसे देता हूं Source: https://alejandrorioja.com/hi/claude-tool-use-production-agents/ Published: 2026-07-21 Tags: AI Agents, Claude TL;DR: Claude tool use आपके एजेंट को कार्य करने देता है — न कि केवल टेक्स्ट जनरेट करने देता है। आप टूल्स को JSON स्कीमा के रूप में परिभाषित करते हैं, Claude तय करता है कि उन्हें कब कॉल करना है, और आपका कोड वास्तविक कार्य को निष्पादित करता है। लूप तीन चरणों में है: संदेश भेजें → tool_use ब्लॉक प्राप्त करें → निष्पादित करें और परिणाम लौटाएं। मैंने यह Cloudflare Workers पर 15+ प्रोडक्शन एजेंटों में लागू किया है। विफलता बिंदु लगभग कभी AI में नहीं होता — यह टूल्स से लौटने वाले अस्पष्ट परिणामों में होता है। ## विषय सूची _जुलाई 2026 में अपडेट किया गया।_ **TL;DR:** Claude tool use आपके एजेंट को कार्य करने देता है — न कि केवल टेक्स्ट जनरेट करने देता है। आप टूल्स को JSON स्कीमा के रूप में परिभाषित करते हैं, Claude तय करता है कि उन्हें कब कॉल करना है, और आपका कोड वास्तविक कार्य को निष्पादित करता है। लूप तीन चरणों में है: संदेश भेजें → tool_use ब्लॉक प्राप्त करें → निष्पादित करें और परिणाम लौटाएं। मैंने यह Cloudflare Workers पर 15+ प्रोडक्शन एजेंटों में लागू किया है। विफलता बिंदु लगभग कभी AI में नहीं होता — यह टूल्स से लौटने वाले अस्पष्ट परिणामों में होता है। **[ऑपरेटर का दृष्टिकोण]** मैं एक कंसल्टिंग ब्रांड और Pickleland — टेक्सास के Pflugerville में एक पिकलबॉल सुविधा — में 30+ प्रोडक्शन AI एजेंट चलाता हूं। इनमें से लगभग आधे tool use का उपयोग करते हैं — Claude API की वह सुविधा जो मॉडल को आपके कोड में परिभाषित फ़ंक्शन कॉल करने देती है। प्रोडक्शन में तैनाती और पुनरावृत्ति के बाद मैंने जिस पैटर्न पर सहमति बनाई है, वह यहां है। ## Tool use एजेंट की क्षमताओं को क्यों बदलता है टूल्स के बिना, एजेंट केवल टेक्स्ट जनरेट कर सकता है। यह सारांश, ड्राफ्टिंग और वर्गीकरण के लिए उपयोगी है — लेकिन यह वह नहीं है जो अधिकांश व्यावसायिक स्वचालन को वास्तव में चाहिए। व्यावसायिक स्वचालन को जानकारी खोजनी होती है, डेटाबेस में लिखना होता है, API कॉल करनी होती है, संदेश भेजने होते हैं। Tool use वह तरीका है जिससे आप Claude को यह एक्सेस देते हैं। आप JSON स्कीमा के रूप में टूल्स का एक सेट परिभाषित करते हैं। Claude स्कीमा पढ़ता है, तय करता है कि किस टूल को किन तर्कों के साथ कॉल करना है, और एक संरचित `tool_use` कंटेंट ब्लॉक लौटाता है। आपका कोड वास्तविक फ़ंक्शन चलाता है। Claude परिणाम प्राप्त करता है और तय करता है कि आगे क्या करना है — जिसमें दूसरे टूल को कॉल करना या अंतिम टेक्स्ट रिस्पॉन्स देना शामिल है। मुख्य बात: **Claude तय करता है कि टूल कब और कैसे कॉल करना है।** क्षमताएं आप परिभाषित करते हैं। मॉडल तर्क करता है कि उन्हें कब उपयोग करना है। ## API फ्लो कैसे काम करता है Tool use लूप के तीन चरण हैं। आप इस लूप को एक या कई बार चलाएंगे — यह इस पर निर्भर करता है कि मॉडल कितने टूल कॉल करता है। **चरण 1: परिभाषित टूल्स के साथ अपना संदेश भेजें** ```typescript const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ { name: "check_court_availability", description: "Check if a court is available at a given date, time, and duration", input_schema: { type: "object", properties: { date: { type: "string", description: "Date in YYYY-MM-DD format", }, time: { type: "string", description: "Start time in HH:MM format (24h)", }, duration_minutes: { type: "number", description: "Duration of the booking in minutes", }, }, required: ["date", "time", "duration_minutes"], }, }, ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, ], }); ``` **चरण 2: जांचें कि क्या Claude टूल कॉल करना चाहता है** ```typescript if (response.stop_reason === "tool_use") { const toolUseBlock = response.content.find( (block): block is Anthropic.ToolUseBlock => block.type === "tool_use" ); if (!toolUseBlock) throw new Error("Expected tool_use block"); // Run your actual function const toolResult = await checkCourtAvailability( toolUseBlock.input as CourtAvailabilityInput ); // Step 3: Return the result to Claude const finalResponse = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ /* same tools as before */ ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, { role: "assistant", content: response.content }, { role: "user", content: [ { type: "tool_result", tool_use_id: toolUseBlock.id, content: JSON.stringify(toolResult), }, ], }, ], }); // finalResponse.content now has the text answer } ``` यही पूरा पैटर्न है। प्रत्येक टूल कॉल के लिए तीन API इंटरैक्शन: टूल्स परिभाषित करें → `tool_use` ब्लॉक प्राप्त करें → परिणाम लौटाएं। ## वास्तविक उदाहरण: Pickleland उपलब्धता जांचकर्ता Pickleland एक पिकलबॉल सुविधा है। हमें Facebook Messenger, कमेंट्स और चैटबॉट के माध्यम से बुकिंग पूछताछ मिलती है। सवाल लगभग हमेशा "क्या शनिवार को दोपहर 3 बजे आप खुले हैं?" या "क्या मैं 8 लोगों के अपने समूह के लिए कोर्ट बुक कर सकता हूं?" का कोई रूपांतर होता है। उपलब्धता जांचकर्ता एजेंट टूल use का उपयोग करके एक तैयार जवाब देने की बजाय वास्तविक समय में वास्तविक बुकिंग प्रणाली को क्वेरी करता है। यहां पूरा एजेंट है — सरलीकृत लेकिन प्रोडक्शन के प्रति वफादार: ```typescript // workers/availability-checker.ts import Anthropic from "@anthropic-ai/sdk"; const anthropic = new Anthropic(); const AVAILABILITY_TOOLS: Anthropic.Tool[] = [ { name: "check_availability", description: "Check court availability for a date, time, and group size. Returns available courts and their prices.", input_schema: { type: "object", properties: { date: { type: "string", description: "YYYY-MM-DD" }, start_time: { type: "string", description: "HH:MM (24h)" }, duration_minutes: { type: "number" }, players: { type: "number", description: "Number of players" }, }, required: ["date", "start_time", "duration_minutes"], }, }, { name: "get_pricing", description: "Get current pricing for court rentals and open play sessions", input_schema: { type: "object", properties: { session_type: { type: "string", enum: ["court_rental", "open_play", "clinics"], }, }, required: ["session_type"], }, }, ]; export async function handleInquiry( userMessage: string, env: Env ): Promise { const messages: Anthropic.MessageParam[] = [ { role: "user", content: userMessage }, ]; // Agentic loop — keep going until stop_reason is "end_turn" while (true) { const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 512, system: "You are the booking assistant for Pickleland, a pickleball facility in Pflugerville, TX. " + "Use the tools to look up real availability and pricing. Never make up availability or prices. " + "If the customer wants to book, direct them to pickleland.com/book.", tools: AVAILABILITY_TOOLS, messages, }); // Push the assistant's response into message history messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const textBlock = response.content.find( (b): b is Anthropic.TextBlock => b.type === "text" ); return ( textBlock?.text ?? "I wasn't able to answer that — please call us directly." ); } if (response.stop_reason === "tool_use") { // Process ALL tool calls in this response (Claude can request multiple at once) const toolResults: Anthropic.ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; let result: unknown; switch (block.name) { case "check_availability": result = await checkAvailability( block.input as AvailabilityInput, env ); break; case "get_pricing": result = await getPricing(block.input as PricingInput, env); break; default: result = { error: `Unknown tool: ${block.name}` }; } toolResults.push({ type: "tool_result", tool_use_id: block.id, content: JSON.stringify(result), }); } // Return all tool results in a single user message messages.push({ role: "user", content: toolResults }); } } } ``` यहां दो बातें ध्यान देने योग्य हैं। **एजेंटिक लूप।** मैं तब तक जारी रहता हूं जब तक `stop_reason === "end_turn"` नहीं हो जाता। Claude `check_availability` कॉल कर सकता है, तय कर सकता है कि उसे प्राइसिंग भी चाहिए, `get_pricing` कॉल कर सकता है, और फिर अंतिम उत्तर दे सकता है — यह एक उपयोगकर्ता संदेश के लिए तीन API कॉल हैं। लूप इसे बिना किसी विशेष तर्क के संभालता है। **प्रति टर्न कई टूल कॉल।** Claude एक ही रिस्पॉन्स में कई `tool_use` ब्लॉक लौटा सकता है। मैं उन सभी को प्रोसेस करता हूं और सभी परिणामों को एक ही `user` संदेश में लौटाता हूं। यदि आप उन्हें एक-एक करके प्रोसेस करते हैं और अलग-अलग लौटाते हैं, तो आप बातचीत का प्रवाह तोड़ देते हैं और टोकन बर्बाद करते हैं। ## वास्तविक उदाहरण: लीड रिसर्च एजेंट मेरा कंसल्टिंग ब्रांड एक रिसर्च एजेंट का उपयोग करता है जो इनबाउंड लीड को उनसे बात करने से पहले समृद्ध करता है। जब कोई संपर्क फ़ॉर्म भरता है, तो एजेंट उनकी कंपनी पर रिसर्च करता है और कॉल से पहले मुझे जो जानने की ज़रूरत है वह निकालता है। इसके टूल परिभाषाओं में एक राइट टूल शामिल है — और यहां पैटर्न दिलचस्प हो जाता है: ```typescript const RESEARCH_TOOLS: Anthropic.Tool[] = [ { name: "search_company", description: "Search for information about a company", input_schema: { type: "object", properties: { company_name: { type: "string" }, website: { type: "string", description: "Company website if known" }, }, required: ["company_name"], }, }, { name: "save_research", description: "Save the completed research summary to Airtable. Call this when all research is complete.", input_schema: { type: "object", properties: { company_summary: { type: "string" }, estimated_size: { type: "string", enum: ["1-10", "11-50", "51-200", "200+"], }, likely_use_case: { type: "string" }, priority: { type: "string", enum: ["high", "medium", "low"] }, notes: { type: "string" }, }, required: [ "company_summary", "estimated_size", "likely_use_case", "priority", ], }, }, ]; ``` `save_research` वह है जिसे मैं **राइट टूल** कहता हूं — इसका उद्देश्य जानकारी प्राप्त करना नहीं है, बल्कि Claude के आउटपुट को संरचित रूप में डेटाबेस में कमिट करना है। मैं टेक्स्ट रिस्पॉन्स से JSON पार्स करने की कोशिश करने के बजाय इस पैटर्न का उपयोग करता हूं। Claude जानता है कि रिसर्च कब पूरी होती है और सही टाइप वाले फील्ड के साथ `save_research` कॉल करता है। मुझे कभी पार्सर नहीं लिखना पड़ता। यह tool use का सबसे स्वच्छ अनुप्रयोग है: जो स्कीमा आप चाहते हैं उसके साथ एक "फाइनल एक्शन" टूल परिभाषित करें, और Claude टूल कॉल के माध्यम से संरचित आउटपुट देता है। कोई टेक्स्ट पार्सिंग नहीं, कोई regex नहीं, फ्रीफॉर्म टेक्स्ट आउटपुट का कोई JSONSchema वैलिडेशन नहीं। ## एक टूल बनाम कई Tool use शुरू करते समय स्वाभाविक प्रवृत्ति एक विशाल टूल बनाने की होती है जो सब कुछ करे। इस प्रवृत्ति का विरोध करें। छोटे, केंद्रित टूल्स तीन कारणों से बेहतर हैं: 1. **Claude छोटे टूल्स के बारे में बेहतर तर्क करता है।** `get_court_status` नाम का टूल जो उपलब्धता लौटाता है, मॉडल के लिए `manage_facility` टूल की तुलना में प्रसंस्करण करना आसान है जो `mode` पैरामीटर लेता है और आंतरिक रूप से शाखाएं करता है। 2. **छोटे टूल्स परीक्षण करना आसान है।** प्रत्येक टूल एक TypeScript फ़ंक्शन है जिसे आप LLM से स्वतंत्र रूप से यूनिट टेस्ट कर सकते हैं। आपको करना चाहिए — एक सक्रिय बातचीत के अंदर टूल बग्स को डीबग करना कठिन है। 3. **Claude छोटे टूल्स को समानांतर कर सकता है।** यदि दो टूल एक-दूसरे पर निर्भर नहीं हैं, तो Claude उन्हें एक ही रिस्पॉन्स में कॉल कर सकता है और आप उन्हें समानांतर में प्रोसेस करते हैं। यह तभी काम करता है जब टूल वास्तव में स्वतंत्र हों। अपवाद: टूल्स जिन्हें बहुत अधिक साझा आंतरिक स्थिति तक पहुंच की आवश्यकता होती है। यदि फ़ंक्शन को एक ही डेटा स्रोत से 10 वेरिएबल चाहिए, तो एक समृद्ध स्कीमा वाला एक टूल 10 टूल्स से बेहतर है जो प्रत्येक अलग से डेटाबेस तक पहुंचते हैं। मेरा व्यावहारिक नियम: प्रत्येक अलग क्षमता के लिए एक टूल से शुरू करें। केवल तब टूल्स को मर्ज करें जब आप देखें कि Claude उन्हें हर अनुरोध में एक साथ कॉल कर रहा है। ## लागत निहितार्थ Tool use टोकन जोड़ता है। प्रत्येक टूल परिभाषा सिस्टम प्रॉम्प्ट संदर्भ में जाती है। प्रत्येक `tool_use` और `tool_result` ब्लॉक बातचीत इतिहास में टोकन खपत करता है। मल्टी-टर्न एजेंटिक लूप के लिए, यह तेज़ी से बढ़ता है। Pickleland उपलब्धता जांचकर्ता के लिए, एक सामान्य बातचीत कुल 3-4 API कॉल चलाती है (प्रारंभिक संदेश + 1-2 टूल कॉल + अंतिम उत्तर), प्रत्येक 600-900 टोकन प्रोसेस करता है। Haiku मूल्य निर्धारण पर, यह प्रति पूछताछ $0.001 से कम चलता है। जैसा कि मैं [AI एजेंट लागत गणित पोस्ट](/ai-agent-cost-math-when-haiku-beats-sonnet/) में समझाता हूं, Haiku अच्छी तरह से परिभाषित टूल-कॉलिंग कार्यों को विश्वसनीय रूप से संभालता है और एक ही टोकन वॉल्यूम के लिए Sonnet से 10 गुना सस्ता है। लीड रिसर्च एजेंट Sonnet पर चलता है क्योंकि निर्णय — लीड को प्राथमिकता देना, फिट का अनुमान लगाना — के लिए Haiku की तुलना में अधिक तर्क क्षमता की आवश्यकता होती है जो ओपन इनपुट पर विश्वसनीय रूप से प्रदान करता है। गणना फिर भी काम करती है क्योंकि यह कम बार चलती है (प्रति दिन हजारों बार नहीं, सप्ताह में कुछ बार)। मॉडल चुनाव कार्य जटिलता का अनुसरण करता है, व्यक्तिगत प्राथमिकता का नहीं। ## विफलता बिंदु जिसके बारे में कोई बात नहीं करता प्रोडक्शन tool use में मैं जो सबसे आम विफलता बिंदु देखता हूं वह Claude का गलत टूल कॉल करना नहीं है। यह टूल का कुछ ऐसा लौटाना है जिसके बारे में Claude स्पष्ट रूप से तर्क नहीं कर सकता। यदि आपका टूल 40 फील्ड वाला रॉ डेटाबेस ऑब्जेक्ट लौटाता है, तो Claude को यह समझने में भ्रम होता है कि कौन से फील्ड महत्वपूर्ण हैं। यदि आपका टूल अपवाद फेंकता है (जो टूल परिणाम के बजाय Worker क्रैश के रूप में प्रकट होता है), तो लूप चुपचाप टूट जाता है। यदि आपका टूल `null` लौटाता है जब उसका मतलब "कोई परिणाम नहीं" है, तो Claude को नहीं पता कि पुनः प्रयास करना है या छोड़ देना है। टूल परिणामों के लिए तीन नियम: **संक्षिप्त, स्पष्ट परिणाम लौटाएं।** `{ available: true, courts: ["Court 3", "Court 5"], price_per_hour: 20 }` — पूरी डेटाबेस पंक्ति नहीं। **टूल फ़ंक्शन के अंदर त्रुटियों को पकड़ें और उन्हें संरचित परिणामों के रूप में लौटाएं।** `{ error: "booking system timeout", retry: true }` — फेंका गया अपवाद नहीं जो Worker को क्रैश करता है। **"कोई परिणाम नहीं" को स्पष्ट बनाएं।** `{ available: false, next_available: "2026-07-23T14:00:00Z" }` — बिना संदर्भ के `null` या खाली array नहीं। Claude अस्पष्ट रिटर्न वैल्यू की तुलना में स्पष्ट संकेतों के बारे में बहुत बेहतर तर्क करता है। प्रोडक्शन में tool use डिबग करने में मैंने जो भी समय बिताया है, वह मॉडल के तर्क के बारे में नहीं, अस्पष्ट परिणामों के बारे में था। ## ऑपरेटर का निष्कर्ष Tool use वह सुविधा है जो Claude को टेक्स्ट जनरेटर से ऑपरेटर में बदलती है। स्पष्ट इनपुट स्कीमा के साथ केंद्रित टूल्स परिभाषित करें। मॉडल को एकल रिस्पॉन्स में सभी `tool_use` ब्लॉक संभालें। `stop_reason === "end_turn"` होने तक एजेंटिक लूप चलाएं। अपने टूल फ़ंक्शन से स्वच्छ, संक्षिप्त परिणाम लौटाएं — रॉ डेटा ऑब्जेक्ट नहीं, फेंके गए अपवाद नहीं, अस्पष्ट null नहीं। मॉडल तर्क संभालता है। आपका कोड वास्तविक दुनिया की क्रियाएं संभालता है। इन दो कार्यों को स्पष्ट रूप से अलग रखें और आर्किटेक्चर बनाए रखने योग्य रहेगा, भले ही आप टूल्स जोड़ते रहें। यदि आप अपना पहला tool use एजेंट बना रहे हैं, तो ऊपर के उपलब्धता जांचकर्ता पैटर्न से शुरू करें — एक टूल, एक उद्देश्य, एक एजेंटिक लूप। उसे तैनात करें। फिर दूसरा टूल जोड़ें। --- **संबंधित:** [वह एजेंट स्टैक जो मैं 30+ प्रोडक्शन एजेंट चलाने के लिए उपयोग करता हूं](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Haiku बनाम Sonnet: एजेंट कार्यों के लिए लागत गणित](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [इवेंट-ट्रिगर बनाम शेड्यूल्ड एजेंट: किस काम के लिए कौन सा पैटर्न](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) **Tool use एजेंट बना रहे हैं और अटक गए हैं?** [संपर्क करें](/contact/) — मैं ऑपरेटर टीमों के लिए प्रोडक्शन एजेंट आर्किटेक्चर डिज़ाइन और बनाता हूं। ## अक्सर पूछे जाने वाले प्रश्न ### क्या Claude tool use सभी मॉडलों के साथ काम करता है? हां — tool use सभी वर्तमान Claude मॉडलों पर समर्थित है। [Claude](/recommends/claude) Haiku स्पष्ट स्कीमा वाले अच्छी तरह से परिभाषित टूल्स को विश्वसनीय रूप से संभालता है और उच्च-वॉल्यूम कार्य प्रकारों के लिए सबसे सस्ता विकल्प है। Sonnet अधिक अस्पष्ट या खुले टूल-कॉलिंग निर्णयों को बेहतर ढंग से संभालता है। Haiku से शुरू करें; यदि आउटपुट गुणवत्ता अपर्याप्त है तो ऊपर जाएं। ### Claude tool use और OpenAI फ़ंक्शन कॉलिंग में क्या अंतर है? यांत्रिक रूप से समान। OpenAI ने "function calling" बनाया; Anthropic इसे "tool use" कहता है। दोनों मामलों में: आप JSON स्कीमा परिभाषित करते हैं, मॉडल संरचित कॉल लौटाता है, आपका कोड फ़ंक्शन निष्पादित करता है। API का आकार अलग है लेकिन अवधारणा एक ही है। ### क्या Claude एकल रिस्पॉन्स में कई टूल्स कॉल कर सकता है? हां। Claude एकल `assistant` रिस्पॉन्स में कई `tool_use` ब्लॉक लौटा सकता है। उन सभी को प्रोसेस करें और एकल `user` संदेश में सभी परिणाम लौटाएं। ऊपर Pickleland उदाहरण में एजेंटिक लूप पैटर्न देखें — `response.content` पर `for` लूप इसे सही तरीके से संभालता है। ### मुझे प्रति एजेंट कितने टूल्स परिभाषित करने चाहिए? मैं प्रति एजेंट 8-10 टूल्स से कम रखता हूं। इससे परे, मैंने देखा है कि Claude कभी-कभी पहले प्रयास में गलत टूल चुनता है, जो सुधार लूप में टोकन बर्बाद करता है। यदि आपको 10 से अधिक क्षमताओं की आवश्यकता है, तो एजेंट को विशेष टूल सेट के साथ कई एजेंटों में विभाजित करें बजाय एक ऐसा एजेंट बनाने के जो सब कुछ जानता हो। ### क्या मुझे संरचित आउटपुट के लिए tool use का उपयोग करना चाहिए? हां — `save_research` राइट-टूल पैटर्न Claude से टेक्स्ट ब्लॉक में JSON लौटाने के लिए कहने और फिर उसे पार्स करने से अधिक स्वच्छ है। जो स्कीमा आप चाहते हैं उसके साथ एक "फाइनल एक्शन" टूल परिभाषित करें। Claude समाप्त होने पर सही टाइप वाले फील्ड के साथ उसे कॉल करेगा। कोई पार्सर आवश्यक नहीं। --- ## 2026 में सर्च इंजन असल में कंटेंट क्वालिटी का मूल्यांकन कैसे करते हैं Source: https://alejandrorioja.com/hi/how-search-engines-evaluate-content-quality/ Published: 2026-07-20 Tags: SEO, GEO ## विषय-सूची _जुलाई 2026 में प्रकाशित।_ **TL;DR:** सर्च इंजन और AI इंजन दोनों ने पेजों को अलग-थलग होकर स्कोर करना बंद कर दिया है। वे साइटों को स्कोर करते हैं — किसी विषय पर कवरेज की गहराई, जाँच में टिके रहने वाले ट्रस्ट सिग्नल्स, और महीनों तक बनी रहने वाली निरंतरता, न कि एक शानदार लेख। मैं 13 भाषाओं में 384 अंग्रेज़ी पोस्ट चलाता हूँ और साप्ताहिक रूप से ट्रैक करता हूँ कि मुझे ChatGPT, Perplexity और Google AI Overviews में साइट किया जा रहा है या नहीं। पैटर्न लगातार एक जैसा है: अलग-थलग पोस्ट पठार पर पहुँचकर रुक जाती हैं, क्लस्टर कंपाउंड होते हैं, और साइटेशन दरों को हिलाने वाले ट्रस्ट सिग्नल्स उबाऊ, संरचनात्मक और बनाने में सस्ते होते हैं। **ऑपरेटर का नज़रिया:** मैं कंटेंट क्वालिटी के बारे में सिद्धांत नहीं गढ़ रहा — मैं इस साइट का कंटेंट इंजन चलाता हूँ और जब मैं कुछ बदलता हूँ तो साइटेशन दरों पर क्या असर पड़ता है, यह देखता हूँ। यह पोस्ट पूरी तरह उन चीज़ों पर बनी है जो मैंने alejandrorioja.com पर मापी हैं: असली क्लस्टर साइज़, एक असली छह-हफ़्ते का साइटेशन एक्सपेरिमेंट, असली schema-markup टेस्ट। यहाँ कुछ भी इस बारे में अंदाज़ा नहीं है कि एल्गोरिदम "शायद" कैसे काम करते हैं। ## क्वालिटी काफ़ी पहले पेज-दर-पेज सवाल नहीं रही ज़्यादातर लोग अभी भी जो मानसिक मॉडल रखते हैं वह है: एक अच्छा लेख लिखो, वह रैंक करेगा। यह कभी पूरी तरह सच नहीं था, और अब यह किसी भी संकीर्ण लॉन्ग-टेल टर्म से आगे की चीज़ के लिए सक्रिय रूप से भ्रामक है। मेरे पास अपनी साइट पर यह सीधे देखने का तरीका है। मैं मुट्ठी भर असली क्लस्टर्स में पब्लिश करता हूँ — एक 29-पोस्ट वाला AI Agents और Claude क्लस्टर, एक "How Does X Make Money" बिज़नेस-मॉडल-एक्सप्लेनर क्लस्टर जो अब 20 पोस्ट तक पहुँच गया है (Google, OpenAI, Anthropic, Uber, Salesforce, और अन्य), और एक बड़ा SEO/GEO क्लस्टर जो टैग काउंट के हिसाब से साइट पर सबसे बड़ा एकल विषय है। जिस विषय को मैंने सिर्फ़ एक बार छुआ है उसमें एक स्टैंडअलोन पोस्ट, इनमें से किसी क्लस्टर के भीतर बैठी पोस्ट से पूरी तरह अलग व्यवहार करती है, भले ही स्टैंडअलोन पीस वस्तुनिष्ठ रूप से बेहतर लिखी गई हो। क्लस्टर वाली पोस्ट ज़्यादा साइट होती हैं, ज़्यादा स्थिरता से रैंक करती हैं, और एल्गोरिदम अपडेट के बाद तेज़ी से रिकवर करती हैं। अलग-थलग पोस्ट या तो उछाल मारती हैं या नहीं मारतीं, और जब नहीं मारतीं, तो सहारे के लिए आस-पास कोई अथॉरिटी नहीं होती। यही वह असली तंत्र है जिसे अक्सर [AI टॉपिकल अथॉरिटी स्ट्रैटेजी](https://www.linkbuildinghq.com/blog/how-to-build-topical-authority-for-ai/) के रूप में पेश किया जाता है — कोई रहस्यमय ट्रस्ट स्कोर नहीं, बल्कि यह सीधा तथ्य कि एक ही विषय पर 28 अन्य पेजों के बगल में बैठा पेज, Google के क्रॉलर और किसी LLM के रिट्रीवल स्टेप, दोनों को झुकने के लिए ज़्यादा पुष्टि करने वाला संदर्भ देता है। मैंने जानबूझकर [उस संरचना की पूरी कार्यप्रणाली](/pillar-content/) लिखी है — छोटा वर्ज़न यह है कि क्लस्टर तभी काम करता है जब उसमें हर पोस्ट पिलर से लिंक करे और पिलर वापस बाहर लिंक करे, ताकि टॉपिकल मैप स्पष्ट हो, न कि कुछ ऐसा जिसे क्रॉलर को खुद फिर से जोड़ना पड़े। कुछ भी नया पब्लिश करने से पहले मैं जो व्यावहारिक टेस्ट लगाता हूँ: क्या यह पोस्ट किसी ऐसे क्लस्टर को आगे बढ़ाती है जो मेरे पास पहले से है, या यह एक नया वन-ऑफ शुरू करती है? वन-ऑफ पर पाबंदी नहीं है — कुछ क्वेरीज़ को सचमुच सिर्फ़ एक पेज चाहिए — लेकिन मुझे शुरू से पता होता है कि वन-ऑफ सिर्फ़ पेज-लेवल सिग्नल्स पर मुक़ाबला कर रहा है, उस कंपाउंडिंग असर के बिना जो क्लस्टर पोस्ट को मुफ़्त में मिलता है। ## "असली वैल्यू, फ़िलर नहीं" एक टेस्ट करने लायक दावा है, कोई भावना नहीं इस सलाह का जेनेरिक वर्ज़न कहता है "गहराई और संदर्भ जोड़ो, आम तौर पर उपलब्ध जानकारी को मत दोहराओ।" सच है, पर इसे जाँचने का कोई तरीका न हो तो बेकार है। यहाँ मेरा असली टेस्ट है, असली स्केल पर चलाया गया: मेरे पास 384 अंग्रेज़ी पोस्ट हैं। हर एक का अनुवाद 12 अन्य भाषाओं में [ठीक इसी काम के लिए बनाए गए एक एजेंट](/how-to-translate-one-blog-post-into-13-languages-with-one-agent/) द्वारा होता है। अनुवाद सस्ता है — पूरे 341-पोस्ट के बैकलॉग की लागत Haiku पर API कॉल्स में करीब $1.70 आई। लिखना सस्ता नहीं है। अगर मैं एक ही आइडिया को दस अलग-अलग फ़्रेमिंग में हल्का-फुल्का फिर से लिखकर वॉल्यूम बढ़ा सकता, तो वह एजेंट मुझे डुप्लिकेशन को उतनी ही आसानी से स्केल करने देता जितनी आसानी से वह अनुवाद को स्केल करता है। मैं ऐसा नहीं करता, क्योंकि डुप्लिकेट फ़्रेमिंग असली टेस्ट में टिकती नहीं: क्या यह पेज किसी ऐसे सवाल का जवाब देता है जिसका जवाब मेरी साइट का कोई और पेज पहले से उतनी ही अच्छी तरह या बेहतर तरीके से नहीं देता? यही वह फ़िल्टर है जो किसी भी स्टाइल गाइडलाइन से ज़्यादा मायने रखता है। "फ़िलर" कोई टोन की समस्या नहीं है, यह रिडंडेंसी की समस्या है — एक पेज जो पड़ोसी पेज को बिना कोई नया एंगल, नंबर या उदाहरण जोड़े दोहराता है। पब्लिश करने से पहले मैं यह जाँचता हूँ कि क्या नई पोस्ट नई साइटेशन सतह जोड़ने के बजाय किसी मौजूदा पोस्ट के साइटेशन को कैनिबलाइज़ करेगी। अगर मेरी साइट पर दो पोस्ट एक ही क्वेरी को बराबर अच्छी तरह संतुष्ट करती हैं, तो उनमें से एक फ़िलर है, चाहे वह कितनी भी अच्छी तरह क्यों न लिखी गई हो। ## ट्रस्ट सिग्नल्स जो मैंने असल में बनाए और मापे हैं "Trustworthiness" (भरोसेमंदता) हर जेनेरिक SEO लेख में सबसे अस्पष्ट शब्द है, जिसके बाद आमतौर पर "स्रोत उद्धृत करो, विशेषज्ञता दिखाओ, चीज़ों को सटीक रखो" जैसी एक सूची आती है, यह जाँचने का कोई तरीका नहीं होता कि इनमें से किसी ने कुछ हिलाया भी या नहीं। मैं जो ठोस वर्ज़न चलाता हूँ वह है: schema markup, क्योंकि यह वह इकलौता ट्रस्ट सिग्नल है जिसे कोई AI इंजन अनुमान लगाने के बजाय यांत्रिक रूप से पार्स करता है। मैंने कहीं और [पूरा इम्प्लीमेंटेशन](/schema-markup-for-geo/) बताया है और [कौन-से टाइप असल में फ़ायदा देते हैं](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/) इस पर गहराई से गया हूँ। छोटा वर्ज़न: एक असली नामित लेखक और ईमानदार `dateModified` के साथ `Article`/`BlogPosting`, ऑथरशिप का एंकर है; `FAQPage` और `HowTo` सबसे ज़्यादा फ़ायदा देने वाले टाइप हैं क्योंकि वे मॉडल को गद्य से अनुमान लगवाने के बजाय पहले से जवाब दिया हुआ सवाल या पहले से संरचित प्रक्रिया थमा देते हैं; `Person` और `Organization` schema इसलिए मौजूद हैं ताकि मॉडल मुझे मेरे नाम वाले किसी और व्यक्ति से न उलझाए। मेरे लिए इनमें से कुछ भी अमूर्त नहीं है — यह एक असली नतीजे के पीछे का हस्तक्षेप है। पहले से Google AI Overviews को ट्रिगर कर रहीं 41 पिलर पोस्ट पर एक चार-भाग की स्ट्रक्चरल ओवरले (TL;DR ब्लॉक, नंबर वाले स्टेप्स, FAQ सेक्शन, प्राइमरी-सोर्स साइटेशन) लगाने से छह हफ़्तों में साइटेशन फ़्रीक्वेंसी 41 में से 4 से बढ़कर 41 में से 19 हो गई — [पूरा छह-हफ़्ते का टेस्ट यहाँ लिखा है](/google-ai-overview-citation-case-study/)। यह "ट्रस्ट सिग्नल जोड़ो और उम्मीद रखो" नहीं है। यह मेरे अपने पेजों पर मापा गया पहले/बाद का नतीजा है, इस चेतावनी के साथ जो पोस्ट खुद स्पष्ट रूप से बताती है: यह सिर्फ़ उन पेजों पर काम करता है जिनके पास पहले से ऑर्गैनिक रूप से टॉप-5 में रैंक करने से मिली अथॉरिटी की न्यूनतम सीमा थी। स्ट्रक्चर एक मौजूदा सिग्नल को बढ़ाता है; यह उसे कहीं से भी नहीं गढ़ता। ## निरंतरता कंपाउंड होती है, पर "निरंतरता" का मतलब लगातार अपडेट नहीं है यहाँ जेनेरिक दावा आमतौर पर "फ्रेशनेस मायने रखती है पर हर लेख को अपडेट करने की ज़रूरत नहीं" होता है, जिसके साथ कोई असली कैडेंस नहीं जुड़ी होती। यहाँ मेरी अपनी है। पब्लिश करने के बाद मैं ज़्यादातर पोस्ट को नहीं छूता। मैं पिलर पोस्ट का एक रोलिंग सेट ज़रूर मेंटेन करता हूँ और जब अंतर्निहित तथ्य बदलते हैं तो उन्हें हर 6-12 महीने में अपडेट करता हूँ — कोई नया मॉडल आता है, किसी टूल की कीमत बदलती है, कोई आँकड़ा पुराना पड़ जाता है। `dateModified` तभी बदलता है जब कंटेंट असल में बदलता है; मैंने इसे नकली तरीके से बदलकर टेस्ट किया है और यह काम नहीं करता — इंजन बिना किसी सारगर्भित बदलाव के बढ़ाई गई तारीख को पकड़ लेते हैं, ठीक यही बात AI Overview केस स्टडी में भी सामने आई थी। जिस निरंतरता सिग्नल पर मैं असल में साप्ताहिक नज़र रखता हूँ वह पब्लिशिंग कैडेंस नहीं, साइटेशन कवरेज है: मैं व्यवसाय-महत्वपूर्ण क्वेरीज़ की एक ट्रैक की गई सूची को हर हफ़्ते ChatGPT, Perplexity और Google के माध्यम से चलाता हूँ और दर्ज करता हूँ कि मुझे साइट किया जा रहा है या नहीं — [कार्यप्रणाली यहाँ है](/how-to-measure-ai-search-traffic/)। साइटेशन कवरेज एक अग्रणी संकेतक है — यह रेफ़रल ट्रैफ़िक या ब्रांडेड-सर्च उछाल से पहले हिलता है, इसलिए यही वह नंबर है जो मुझे बताता है कि कोई क्लस्टर समय के साथ असल में अथॉरिटी हासिल कर रहा है या बस पड़ा हुआ है। जो साइट एक बार पब्लिश करके चुप हो जाती है उसे उस साप्ताहिक जाँच से दूसरी नज़र नहीं मिलती; जो साइट किसी क्लस्टर को लगातार आगे बढ़ाती रहती है उसे मिलती है। ## "साइट-स्तरीय" मूल्यांकन असल में परत-दर-परत क्या इनाम देता है जिन तीन इंजनों को मैं ट्रैक करता हूँ, वे एक जैसे सिग्नल्स को एक जैसा वज़न नहीं देते। यह वह व्यावहारिक टेबल है जो मैं अपने दिमाग में रखता हूँ जब यह तय करना होता है कि मेहनत कहाँ लगानी है: | क्वालिटी लेयर | व्यवहार में यह असल में कैसी दिखती है | मैंने इसे कहाँ मापा | | --- | --- | --- | | टॉपिकल गहराई | एक विषय पर 20-30+ आपस में लिंक्ड पोस्ट, पिलर हर क्लस्टर पोस्ट से लिंक करता है और वापस लिंक होता है | AI Agents क्लस्टर (29 पोस्ट), "How Does X Make Money" क्लस्टर (20 पोस्ट) | | स्ट्रक्चरल एक्सट्रैक्टेबिलिटी | TL;DR ब्लॉक, नंबर वाले स्टेप्स, FAQ, असली यूज़र फ़्रेज़िंग से मेल खाता हुआ | 6 हफ़्तों में 4/41 → 19/41 AI Overview साइटेशन | | ऑथरशिप/ट्रस्ट | नामित लेखक + सटीक `dateModified` + Person/Organization schema | GEO के लिए schema markup, schema टाइप्स का ब्रेकडाउन | | समय के साथ निरंतरता | लगातार फिर से लिखने के बजाय इंजनों में साप्ताहिक साइटेशन ट्रैकिंग | AI-सर्च मापन कार्यप्रणाली | जेनेरिक सलाह में मैं जो सबसे आम फ़ेलियर मोड देखता हूँ वह इन्हें एक अविभेदित "क्वालिटी" स्कोर मानना है। ये वैसे नहीं हैं। एक पेज स्ट्रक्चरल एक्सट्रैक्टेबिलिटी में बिल्कुल सटीक हो सकता है और फिर भी ज़्यादा टॉपिकल गहराई वाले किसी प्रतियोगी से हार सकता है। एक पेज किसी गहरे क्लस्टर के भीतर बैठा हो सकता है और फिर भी किसी ज़्यादा ताज़ा, बेहतर-schema वाले प्रतियोगी से एक ख़ास साइटेशन गँवा सकता है। किसी दिए गए पेज के लिए असल में कौन-सी लेयर बॉटलनेक है, यह जानना ही ज़्यादातर काम है। ## यह कहाँ टूटता है — ईमानदार चेतावनियाँ मैं पैटर्न को बढ़ा-चढ़ाकर बेचने के बजाय इसकी सीमाएँ बताना बेहतर समझता हूँ: - **डोमेन अथॉरिटी अभी भी एक गेट है।** AI Overview वाला हस्तक्षेप सिर्फ़ उन पेजों पर काम करता था जो पहले से ऑर्गैनिक रूप से टॉप-5 में रैंक कर रहे थे। स्ट्रक्चर ने एक मौजूदा सिग्नल को बढ़ाया; उसने किसी ठंडे पेज से अथॉरिटी नहीं बनाई। - **इंजन इस बात पर अलग-अलग राय रखते हैं कि वे क्या इनाम देते हैं।** ChatGPT और Google में एक जैसे 50 हेड टर्म चलाने पर, मुझे पता चला कि किन स्रोतों को साइट किया गया, इसमें सिर्फ़ करीब 40% ओवरलैप था — [पूरा ब्रेकडाउन यहाँ है](/chatgpt-search-vs-google-50-term-test/)। "सर्च इंजन" को एक ही टारगेट मानकर ऑप्टिमाइज़ करना पहले से ही गलत फ़्रेम है; आप कई इंजनों के लिए ऑप्टिमाइज़ कर रहे हैं जो बुनियादी बातों पर सहमत होते हैं और बाकी पर अलग राय रखते हैं। - **कुछ श्रेणियों को सचमुच क्लस्टर की ज़रूरत नहीं होती।** मेरे सबसे बेहतरीन प्रदर्शन करने वाले कुछ पेज सच में वन-ऑफ हैं। गहराई एक लीवर है, कोई सार्वभौमिक ज़रूरत नहीं — जहाँ क्वेरी स्पेस इसे सपोर्ट नहीं करता वहाँ जबरन क्लस्टर बनाना ठीक वही पतला, भरा हुआ कंटेंट पैदा करता है जिससे बचना पूरे फ़्रेमवर्क का मक़सद है। ## अक्सर पूछे जाने वाले प्रश्न ### क्या एक शानदार लेख कभी किसी मामूली क्लस्टर को पछाड़ सकता है? हाँ, कम प्रतिस्पर्धा वाली पर्याप्त संकीर्ण क्वेरी के लिए। लेकिन असली प्रतिस्पर्धा वाले किसी भी हेड टर्म के लिए, जो पेज लंबे समय तक अपनी पोज़िशन बनाए रखते हैं वे लगभग हमेशा किसी क्लस्टर से समर्थित होते हैं। मैंने अलग-थलग पोस्ट को उस तरह उछलते और फीका पड़ते देखा है जैसे क्लस्टर वाली पोस्ट नहीं पड़तीं। ### किसी विषय को असली क्लस्टर गिने जाने से पहले कितनी पोस्ट चाहिए? कोई पक्का नंबर नहीं है, पर मेरे अपने डेटा में असर करीब 8-10 सचमुच अलग-अलग पोस्ट के आस-पास साफ़ दिखने लगता है, जो एक ही विषय के उप-विषयों पर हों — इतना कि पिलर सार्थक ढंग से बाहर लिंक कर सके और हर क्लस्टर पोस्ट के पास और गहराई चाहने वाले पाठकों को भेजने के लिए कोई ख़ास जगह हो। ### क्या schema markup सचमुच ज़रूरी है, या अच्छा लेखन ही काफ़ी है? अच्छा लेखन ज़रूरी है पर खासतौर पर AI-इंजन साइटेशन के लिए पर्याप्त नहीं है। इंजन अकेले गद्य से ज़्यादा भरोसे के साथ `FAQPage` और `HowTo` schema से संरचित तथ्य निकालते हैं, क्योंकि schema अनुमान लगाने वाला स्टेप हटा देता है। मैंने पहले schema-रहित पोस्ट में इसे जोड़ने से सिंगल-डिजिट से मिड-टीन्स तक के परसेंटेज-पॉइंट साइटेशन लिफ़्ट मापे हैं। ### नई पोस्ट पब्लिश करने के बजाय मुझे पुराने कंटेंट को कितनी बार अपडेट करना चाहिए? जब कोई असली तथ्य बदलता है तो मैं पिलर पोस्ट को हर 6-12 महीने में अपडेट करता हूँ, और बिना किसी सारगर्भित बदलाव के मैं कभी `dateModified` नहीं बढ़ाता। मेरे कंटेंट बजट का ज़्यादातर हिस्सा नई क्लस्टर-एक्सटेंडिंग पोस्ट में जाता है, दोबारा लिखने में नहीं — फ्रेशनेस मायने रखती है, पर टॉपिकल गहराई और स्ट्रक्चर के मुक़ाबले यह प्रमुख लीवर नहीं है। ### सबसे पहले ठीक करने वाली सबसे ऊँची-लिवरेज चीज़ क्या है? अगर कोई पेज पहले से ऑर्गैनिक रूप से ठीक-ठाक रैंक करता है पर AI इंजनों द्वारा साइट नहीं किया जा रहा, तो एक साफ़-सुथरा TL;DR ब्लॉक जोड़ें जो सीधे हेड क्वेरी का जवाब दे। मेरे अपने छह-हफ़्ते के टेस्ट में, यह अब तक का सबसे बड़ा इकलौता लीवर था — FAQ schema से बड़ा, प्राइमरी-सोर्स साइटेशन से बड़ा, नंबर वाले स्टेप्स से बड़ा। ## निचोड़ कंटेंट क्वालिटी का मूल्यांकन पेज से हटकर साइट पर आ गया है, और जो साइट-स्तरीय सिग्नल असल में सुई हिलाते हैं वे मापने योग्य हैं, रहस्यमय नहीं: क्लस्टर की गहराई जिसे आप गिन सकते हैं, स्ट्रक्चरल ओवरले जिन्हें आप A/B टेस्ट कर सकते हैं, schema जिसे आप वैलिडेट कर सकते हैं, और साइटेशन-कवरेज का एक नंबर जिसे आप साप्ताहिक ट्रैक कर सकते हैं। इनमें से किसी के लिए भी यह अंदाज़ा लगाने की ज़रूरत नहीं कि कोई एल्गोरिदम "क्या चाहता है"। इसके लिए ज़रूरत है एक असली टॉपिकल स्ट्रक्चर के भीतर पब्लिश करने की, इंजनों को अनुमान लगवाने के बजाय एक साफ़, निकाले जाने लायक जवाब देने की, और यह जानने के लिए कि यह काम कर रहा है या नहीं, नतीजे को इतनी बार जाँचने की। मैं इस साइट पर हर हफ़्ते इन चारों अनुशासनों को चलाता हूँ, और ऊपर दिए गए नंबर असल में वही हैं जो इन्होंने पैदा किए हैं — न कि जो किसी जेनेरिक गाइड का दावा है कि इन्हें पैदा करना चाहिए। --- ## 2026 में व्यवसाय के लिए Claude बनाम ChatGPT: एक ऑपरेटर का ईमानदार विचार Source: https://alejandrorioja.com/hi/claude-vs-chatgpt-for-business-2026/ Published: 2026-07-18 Tags: AI Agents, Productivity TL;DR: Claude एजेंट बनाने, लंबे संदर्भों के साथ काम करने, कोडिंग और स्केल पर प्रोडक्शन में चलने वाली हर चीज़ में जीतता है। ChatGPT कंज्यूमर इंटीग्रेशन, वॉयस मोड और व्यापक प्लगइन इकोसिस्टम में जीतता है अगर आपका वर्कफ्लो चैट इंटरफेस में रहता है। यदि आप स्वचालित वर्कफ्लो या AI एजेंट बना रहे हैं, तो Claude बेहतर आधार है। यदि आप अधिक थर्ड-पार्टी कनेक्शन वाले सक्षम चैट असिस्टेंट चाहते हैं, तो ChatGPT का लाभ है। अधिकांश व्यापारियों के लिए असली सवाल है: क्या आप AI से बात कर रहे हैं या AI के साथ बना रहे हैं? वह उत्तर टूल निर्धारित करता है। ## विषय-सूची _जुलाई 2026 में प्रकाशित।_ **TL;DR:** Claude एजेंट बनाने, लंबे संदर्भों के साथ काम करने, कोडिंग और स्केल पर प्रोडक्शन में चलने वाली हर चीज़ में जीतता है। ChatGPT कंज्यूमर इंटीग्रेशन, वॉयस मोड और व्यापक प्लगइन इकोसिस्टम में जीतता है अगर आपका वर्कफ्लो चैट इंटरफेस में रहता है। यदि आप स्वचालित वर्कफ्लो या AI एजेंट बना रहे हैं, तो Claude बेहतर आधार है। यदि आप अधिक थर्ड-पार्टी कनेक्शन वाले सक्षम चैट असिस्टेंट चाहते हैं, तो ChatGPT का लाभ है। अधिकांश व्यापारियों के लिए असली सवाल है: क्या आप AI से बात कर रहे हैं या AI के साथ बना रहे हैं? वह उत्तर टूल निर्धारित करता है। **[ऑपरेटर का दृष्टिकोण]** मैं दो व्यवसाय चलाता हूं — एक कंसल्टिंग ब्रांड और Pickleland, Pflugerville, TX में एक पिकलबॉल सुविधा — 30+ AI एजेंट प्रोडक्शन में सोशल मीडिया रिप्लाई, इवेंट प्रमोशन, बुकिंग फॉलो-अप, न्यूज़लेटर ड्राफ्ट और अधिक संभालते हैं। मेरा पूरा एजेंट स्टैक [Claude](/recommends/claude) पर बना है। मैंने ChatGPT का भी पर्याप्त उपयोग किया है यह जानने के लिए कि प्रत्येक कहाँ विफल होता है। यह बेंचमार्क समीक्षा नहीं है। यह एक प्रैक्टिशनर का दृष्टिकोण है। ## वह प्रश्न जो वास्तव में मायने रखता है अधिकांश तुलनाएं पूछती हैं "कौन सा मॉडल अधिक स्मार्ट है?" व्यावसायिक उपयोग के लिए यह गलत प्रश्न है। सही प्रश्न है: **आप क्या बना रहे हैं, और उसे स्केल पर विश्वसनीय रूप से क्या करना है?** एक मार्केटिंग मैनेजर जो AI से कॉपी ड्राफ्ट करने में मदद चाहता है, उसकी आवश्यकताएं एक फाउंडर से अलग हैं जो स्वचालित लीड क्वालिफिकेशन पाइपलाइन बना रहा है। एक सोलोप्रिनेयर जो मीटिंग की तैयारी के लिए AI का उपयोग करता है, उसकी जरूरतें एक ऑपरेटर से अलग हैं जो प्रति सप्ताह 500 ग्राहक अनुरोध प्रोसेस करने वाले एजेंट बना रहा है। एक के लिए जीतने वाला टूल अक्सर दूसरे के लिए गलत होता है। यह फ्रेमिंग नीचे आने वाली हर चीज को निर्धारित करती है। ## Claude कहाँ जीतता है ### 1. लंबे संदर्भों के साथ काम Claude की नेटिव कॉन्टेक्स्ट विंडो — 200K टोकन — ऐसी चीजें संभालती है जो अन्य मॉडलों को तोड़ देती हैं। मैं नियमित रूप से Claude को पूरे ग्राहक संवाद इतिहास, पूरे अनुबंध ड्राफ्ट या बहु-दस्तावेज़ शोध सारांश देता हूं और उसे संश्लेषित करने या क्रॉस-रेफरेंस करने के लिए कहता हूं। यह धागा पकड़े रहता है। प्रतिस्पर्धी मॉडल अब तकनीकी रूप से लंबे संदर्भ का समर्थन करते हैं, लेकिन जटिल कार्यों पर व्यावहारिक गिरावट अभी भी Claude से भी बदतर है। व्यावसायिक कार्यों के लिए जिनमें लंबे दस्तावेज़ पढ़ना, घने डेटा एक्सपोर्ट का विश्लेषण, या लंबे वर्कफ्लो में सुसंगतता बनाए रखना शामिल है, Claude का वास्तविक लाभ है। ### 2. प्रोडक्शन में एजेंट व्यवहार जब आप Claude को एजेंट के रूप में चलाते हैं — टूल कॉल करते हुए, एक लूप में निर्णय लेते हुए, डेटाबेस में लिखते हुए, त्रुटियों को संभालते हुए — यह मेरे अनुभव में ChatGPT की तुलना में अधिक सुसंगत रूप से व्यवहार करता है। यह सिस्टम प्रॉम्प्ट निर्देशों का अधिक विश्वसनीय रूप से पालन करता है, अधिक आसानी से पार्स करने योग्य संरचित आउटपुट उत्पन्न करता है, और जब संदर्भ लंबा होता है तो कार्य से भटकने की संभावना कम होती है। एजेंट के लिए यह बेहद मायने रखता है। एक मॉडल जो 95% समय बनाम 99% समय आपके सिस्टम प्रॉम्प्ट का पालन करता है, वह समान लगता है। प्रतिदिन 500 कॉल पर, यह प्रति दिन 25 बहाव मामले हैं जिन्हें पकड़ने और साफ करने की आवश्यकता है। [प्रोडक्शन में विफल न होने वाले AI एजेंट सिस्टम प्रॉम्प्ट लिखने](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/) पर मेरे लेख में यह विस्तार से शामिल है, लेकिन संक्षिप्त संस्करण यह है: सिस्टम प्रॉम्प्ट स्तर पर Claude का निर्देश पालन सबसे अच्छा है जिसे मैंने परीक्षण किया है। ### 3. कोडिंग और तकनीकी काम मैं लगभग सब कुछ Cloudflare Workers पर TypeScript में बनाता हूं। Claude Code मेरा दैनिक डेवलपमेंट टूल है — और यह वास्तव में उपयोगी है, सिर्फ "पर्याप्त अच्छा" नहीं। आर्किटेक्चरल प्रश्नों, डीबगिंग, रिफैक्टरिंग और स्क्रैच से एजेंट लॉजिक लिखने के लिए, Claude ChatGPT के समकक्ष पर जो मैंने उपयोग किया है उसे लगातार पार करता है। यह सिर्फ Claude Code बनाम ChatGPT Chat की तुलना नहीं है। API के माध्यम से रॉ Claude Opus 4.8 भी उन्हीं कार्यों पर GPT-4o समकक्ष की तुलना में कम हैलुसिनेटेड इम्पोर्ट के साथ क्लीनर कोड लिखता है। ### 4. API पर डेवलपर अनुभव यदि आप API के साथ बना रहे हैं — सिर्फ चैट नहीं — तो 2026 में Claude का डेवलपर अनुभव बेहतर है। Anthropic SDK साफ है, टोकन काउंटिंग एंडपॉइंट लागत अनुमान के लिए वास्तव में उपयोगी है, प्रॉम्प्ट कैशिंग अच्छी तरह से लागू है और दोहराए गए संदर्भों पर वास्तविक पैसे बचाती है, और त्रुटि हैंडलिंग पूर्वानुमानित है। API के माध्यम से एजेंट बनाने वाले किसी के लिए भी, API गुणवत्ता अंतर मायने रखता है। यह बड़ा नहीं है, लेकिन यह सुसंगत है। ### 5. जटिल प्रॉम्प्ट पर निर्देश निष्ठा Claude ChatGPT की तुलना में कई शर्तों के साथ सूक्ष्म सिस्टम प्रॉम्प्ट को बेहतर तरीके से संभालता है। जब मुझे एक नियम सेट का पालन करने वाले एजेंट की आवश्यकता होती है — "यदि टिप्पणी एक प्रश्न है, X करें; यदि यह शिकायत है, Y करें; यदि यह प्रतिस्पर्धियों का उल्लेख करती है, मानव समीक्षा के लिए फ्लैग करें" — Claude उन शाखाओं को अधिक सुसंगत रूप से पार्स और लागू करता है। सरल प्रॉम्प्ट के लिए, अंतर न्यूनतम है। सिस्टम प्रॉम्प्ट में एम्बेड की गई जटिल सशर्त तर्क के लिए, Claude अधिक विश्वसनीय है। ## ChatGPT कहाँ जीतता है ### 1. कंज्यूमर इंटीग्रेशन और प्लगइन ChatGPT का प्लगइन इकोसिस्टम और नेटिव इंटरफेस के माध्यम से उपलब्ध टूल की रेंज व्यापक है। यदि आपका वर्कफ्लो पहले से उन टूल में रहता है जिनके पास नेटिव ChatGPT इंटीग्रेशन हैं — कुछ CRM, प्रोडक्टिविटी ऐप, रिसर्च टूल — और आप मुख्य रूप से चैट इंटरफेस के माध्यम से काम करते हैं, तो ChatGPT के आउट-ऑफ-द-बॉक्स कनेक्शन घर्षण बचाते हैं। पावर यूज़र के लिए जो कस्टम इंटीग्रेशन बनाए बिना चैट UI से सब कुछ करना चाहते हैं, यह मायने रखता है। ### 2. वॉयस मोड ChatGPT का Advanced Voice Mode वास्तव में उत्कृष्ट है। मोबाइल उपयोग, मौखिक रूप से विचारों के माध्यम से काम करने, या ड्राइविंग करते समय कॉल की तैयारी के लिए, यह सबसे अच्छा वॉयस AI इंटरफेस है जिसका मैंने उपयोग किया है। Claude में वॉयस इनपुट है लेकिन मध्य 2026 तक GPT-4o के पूर्ण कन्वर्सेशनल वॉयस मोड के करीब कुछ भी नहीं है। यदि वॉयस आपके उपयोग के मामले के लिए प्राथमिक इंटरफेस है, तो ChatGPT स्पष्ट रूप से जीतता है। ### 3. इमेज जनरेशन (DALL-E के माध्यम से) ChatGPT Plus में उसी सब्सक्रिप्शन में DALL-E के माध्यम से इमेज जनरेशन शामिल है। Claude नेटिव रूप से इमेज जनरेट नहीं करता। यदि आप Midjourney या किसी अन्य सेवा को जोड़े बिना टेक्स्ट और इमेज काम के लिए एक ही टूल चाहते हैं, तो ChatGPT का लाभ है। ### 4. परिचितता और अपनाना अधिक लोगों ने ChatGPT का उपयोग किया है। यदि आप बिना किसी AI अनुभव वाली टीम को AI टूल पेश कर रहे हैं, तो ChatGPT से शुरू करना कम घर्षण पैदा करता है — अधिकांश लोगों ने इसे कम से कम एक बार खोला है। यह क्षमता लाभ नहीं है, लेकिन ऑनबोर्डिंग गति एक वास्तविक परिचालन कारक है। ## लागत तुलना यहीं पर चीजें सूक्ष्म हो जाती हैं, और जहां अधिकांश तुलनाएं भ्रामक होती हैं। दोनों प्लेटफॉर्म में स्तरीय मूल्य निर्धारण है। API स्तर पर: - **Claude Haiku 4.5** और **GPT-4o mini** उच्च-वॉल्यूम, सरल कार्यों के लिए सस्ते कार्यक्षमता हैं। वे मूल्य रेंज में तुलनीय हैं, विकल्प मुख्य रूप से कार्य आवश्यकताओं द्वारा संचालित है। - **Claude Sonnet/Opus** और **GPT-4o** मध्य से उच्च स्तर हैं। Claude में [प्रॉम्प्ट कैशिंग](/prompt-caching-cut-your-claude-costs-without-switching-models/) है जो दोहराए गए संदर्भ वर्कफ्लो पर लागत को महत्वपूर्ण रूप से कम करती है — यदि आपके एजेंट कॉल के बीच एक ही सिस्टम प्रॉम्प्ट और संदर्भ विंडो का पुन: उपयोग करते हैं, तो Claude का कैश्ड मूल्य बिना कैश वाली दर से 50–80% सस्ता हो सकता है। ChatGPT का कोई सीधा समकक्ष नहीं है। - सबसे ऊपरी स्तर पर, Claude Fable 5 और नवीनतम GPT-4 वेरिएंट एक ही कच्ची लागत सीमा में हैं, लेकिन टोकनाइज़र अंतर मायने रखता है — Fable 5 में एक टोकनाइज़र है जो पहले के मॉडल से अलग तरीके से टोकन गिनता है, इसलिए संदर्भ टोकन काउंट सीधे ट्रांसलेट नहीं होते। लागत पर निष्कर्ष: **उच्च कॉल वॉल्यूम वाले प्रोडक्शन एजेंट के लिए, Claude का प्रॉम्प्ट कैशिंग इसे संदर्भ पुन: उपयोग करने वाले वर्कलोड पर भौतिक रूप से सस्ता बनाती है।** ताजे संदर्भों पर शुद्ध पे-पर-कॉल के लिए, वे पर्याप्त करीब हैं कि प्रदर्शन को सूची मूल्य के बजाय विकल्प को निर्देशित करना चाहिए। इसका मूल्यांकन करने के लिए जो फ्रेमवर्क मैं उपयोग करता हूं वह [AI एजेंट लागत गणित लेख](/ai-agent-cost-math-when-haiku-beats-sonnet/) में है। ## निर्णय मैट्रिक्स | उपयोग का मामला | विजेता | |---|---| | प्रोडक्शन में AI एजेंट बनाना | Claude | | जटिल कोडिंग और आर्किटेक्चर | Claude | | लंबे संदर्भ दस्तावेज़ विश्लेषण | Claude | | प्लगइन इंटीग्रेशन के साथ चैट असिस्टेंट | ChatGPT | | वॉयस को प्राथमिक इंटरफेस के रूप में वर्कफ्लो | ChatGPT | | एक इंटरफेस में इमेज + टेक्स्ट | ChatGPT | | स्केल पर API-संचालित स्वचालन | Claude | | बिना AI अनुभव के टीम ऑनबोर्डिंग | ChatGPT | | प्रोडक्शन में ग्राहक-सामना करने वाले एजेंट | Claude | | उच्च-वॉल्यूम पाइपलाइन पर लागत दक्षता | Claude (कैशिंग के साथ) | ## मेरा वास्तविक उत्तर मैं प्रोडक्शन में सब कुछ के लिए [Claude](/recommends/claude) का उपयोग करता हूं। इसलिए नहीं कि यह हर बेंचमार्क जीतता है — यह नहीं जीतता — बल्कि इसलिए: 1. मेरे एजेंट सिस्टम प्रॉम्प्ट निर्देशों का पर्याप्त विश्वसनीय रूप से पालन करते हैं कि मैं हैलुसिनेटेड या ऑफ-टास्क आउटपुट साफ करने में लगभग कोई समय नहीं बिताता। 2. Cloudflare Workers + Claude API स्टैक मेरे संयुक्त वर्कलोड के लिए $100/माह से कम खर्च करता है, और प्रॉम्प्ट कैशिंग ने मेरे भारी वर्कफ्लो पर लागत आधे से अधिक कम कर दी है। 3. Claude Code मेरा प्राथमिक कोडिंग इंटरफेस बन गया है, और विकास और प्रोडक्शन दोनों के लिए एक ही मॉडल उपलब्ध होने से मानसिक मॉडल सरल हो जाता है। 4. लंबे संदर्भ कार्यों के लिए — PDF पढ़ना, दस्तावेजों में संश्लेषण करना, बहु-चरण वर्कफ्लो में सुसंगतता बनाए रखना — Claude पूरी 200K विंडो को बेहतर तरीके से संभालता है जितना मैंने कहीं और अनुभव किया है। यदि मैं एक ऐसी टीम चला रहा होता जिसे कोई भी कस्टम इंफ्रास्ट्रक्चर बनाए बिना AI-सहायता प्राप्त टूल की आवश्यकता है, तो मैं शायद उन्हें ChatGPT Plus पर रखता — आउट-ऑफ-द-बॉक्स प्लगइन ब्रेड्थ और वॉयस मोड कंज्यूमर स्तर पर वास्तव में उपयोगी हैं। लेकिन चीजें बनाने के लिए सिर्फ उन्हें उपयोग करने के बजाय, Claude सही आधार है। ## अक्सर पूछे जाने वाले प्रश्न ### क्या Claude ChatGPT से स्मार्ट है? कोई भी सार्वभौमिक रूप से स्मार्ट नहीं है। Claude लंबे संदर्भों के साथ तर्क, निर्देश पालन और कोडिंग में बेहतर है। ChatGPT (GPT-4o) छवियों और वॉयस के साथ मल्टीमोडल कार्यों में बेहतर है। विशिष्ट बेंचमार्क प्रत्येक मॉडल रिलीज के साथ उनके बीच उलट-पुलट होते हैं। अधिक उपयोगी प्रश्न यह है कि आपके विशिष्ट कार्य के लिए कौन सा मॉडल बेहतर है। ### क्या मैं Claude और ChatGPT दोनों का उपयोग कर सकता हूं? हां, और कुछ वर्कफ्लो के लिए आप ऐसा करना चाह सकते हैं। Claude API और OpenAI API दोनों इंटीग्रेट करने में सीधे हैं। कुछ टीमें एजेंट बैकएंड के लिए Claude और इंटीग्रेशन के साथ यूजर-फेसिंग चैट इंटरफेस के लिए ChatGPT का उपयोग करती हैं। उस ने कहा, दो AI प्रदाता चलाने से परिचालन जटिलता बढ़ती है — क्रेडेंशियल प्रबंधन, लागत ट्रैकिंग, व्यवहार अंतर प्रबंधित करने के लिए। एक से शुरू करें। ### कंटेंट लेखन के लिए कौन बेहतर है? Claude, मेरे अनुभव में। यह ऐसा आउटपुट उत्पन्न करता है जो कम जेनेरिक लगता है, उदाहरण दिए जाने पर एक विशिष्ट शैली को बेहतर बनाए रखता है, और लंबे-फॉर्म कंटेंट को अधिक सुसंगत रूप से संभालता है। छोटे सोशल कंटेंट या ईमेल के लिए जहां कोई भी काम करेगा, अंतर छोटा है। ### क्या Claude का कोई मुफ्त स्तर है? हां — Claude.ai में संदेश सीमाओं के साथ एक मुफ्त स्तर है। [Claude Pro और Max सब्सक्रिप्शन](/recommends/claude) सीमाएं हटाती हैं और प्राथमिकता पहुंच, फ़ाइल अपलोड और पूरी संदर्भ विंडो जोड़ती हैं। ChatGPT में भी उपयोग-सीमित GPT-4o एक्सेस के साथ एक मुफ्त स्तर है। ### क्या मुझे ChatGPT से Claude पर स्विच करना चाहिए? यदि आप मुख्य रूप से AI को चैट इंटरफेस के रूप में उपयोग करते हैं और ChatGPT से खुश हैं, तो स्विचिंग लागत इसके लायक नहीं हो सकती जब तक कि आपके पास एक विशिष्ट आवश्यकता न हो जिसे Claude बेहतर तरीके से संभालता है। यदि आप ऑटोमेशन, एजेंट बना रहे हैं या कोडिंग काम कर रहे हैं, तो मैं दृढ़ता से Claude को आजमाने की सिफारिश करूंगा — एजेंट व्यवहार और डेवलपर अनुभव प्रोडक्शन वर्कलोड के लिए महत्वपूर्ण अंतर बनाते हैं। --- ## प्रोडक्टाइज्ड सर्विस कैसे बनाएं: अपनी विशेषज्ञता को स्केलेबल आय में बदलने का मेरा फ्रेमवर्क Source: https://alejandrorioja.com/hi/productized-service-how-to-package-your-expertise/ Published: 2026-07-16 Tags: Entrepreneurship, Marketing TL;DR: प्रोडक्टाइज्ड सर्विस एक निश्चित स्कोप और निश्चित मूल्य की पेशकश है जिसे आप हर बार एक ही तरीके से डिलीवर करते हैं। चार चरण: वह काम खोजें जिसके लिए क्लाइंट पहले से बार-बार आपको हायर करते हैं, स्कोप की सीमाएं कठोरता से परिभाषित करें, घंटों के बजाय परिणाम के मूल्य के आधार पर कीमत तय करें, और अगले क्लाइंट को बेचने से पहले डिलीवरी सिस्टम बनाएं। अधिकांश कंसल्टेंट चौथे चरण को छोड़ देते हैं और समय को पैसे से बदलते रहते हैं। यही एकमात्र चरण है जो वास्तव में स्केल बनाता है। ## विषय-सूची _जुलाई 2026 में प्रकाशित।_ **TL;DR:** प्रोडक्टाइज्ड सर्विस एक निश्चित स्कोप और निश्चित मूल्य की पेशकश है जिसे आप हर बार एक ही तरीके से डिलीवर करते हैं। चार चरण: वह काम खोजें जिसके लिए क्लाइंट पहले से बार-बार आपको हायर करते हैं, स्कोप की सीमाएं कठोरता से परिभाषित करें, घंटों के बजाय परिणाम के मूल्य के आधार पर कीमत तय करें, और अगले क्लाइंट को बेचने से पहले डिलीवरी सिस्टम बनाएं। अधिकांश कंसल्टेंट चौथे चरण को छोड़ देते हैं और समय को पैसे से बदलते रहते हैं। यही एकमात्र चरण है जो वास्तव में स्केल बनाता है। **[ऑपरेटर की टिप्पणी]** मैंने सालों तक कस्टम कंसल्टिंग प्रोजेक्ट किए — हर एक अलग स्कोप, अलग कीमत, अलग डिलीवरी के साथ। परिणाम एक ऐसा व्यवसाय था जिसके लिए हर प्रोजेक्ट में मेरी सीधी भागीदारी जरूरी थी। प्रोडक्टाइजेशन ने यह बदल दिया: मेरे सबसे ज्यादा मांगे जाने वाले काम को स्पष्ट डिलीवरेबल्स, निश्चित मूल्य और दोहराने योग्य डिलीवरी प्लेबुक के साथ परिभाषित ऑफर में बदलकर। यहां सटीक फ्रेमवर्क और इसे बनाते समय की गई गलतियां हैं। ## प्रोडक्टाइज्ड सर्विस वास्तव में क्या है प्रोडक्टाइज्ड सर्विस रिटेनर नहीं है। यह सब्सक्रिप्शन नहीं है। यह एक परिभाषित, दोहराने योग्य ऑफर है जिसमें निश्चित स्कोप, निश्चित मूल्य और एक डिलीवरी प्रक्रिया है जो इतनी अच्छी तरह से दस्तावेजित है कि हर बार एक ही तरीके से काम करती है। कस्टम कंसल्टिंग से अंतर: "हम स्कोप के आधार पर $X-Y में AI ऑटोमेशन स्ट्रैटेजी करते हैं" के बजाय, आप बेचते हैं "एक AI ऑटोमेशन रोडमैप: 5 वर्कफ्लो का लिखित ऑडिट, प्राथमिकता से बिल्ड रेकमेंडेशन, और 30 मिनट की डिलीवरी कॉल, $2,500 में।" स्कोप तय। कीमत तय। टाइमलाइन तय। एकमात्र चर यह है कि क्लाइंट हां कहता है या नहीं। रिटेनर से अंतर यह है कि यह प्रोजेक्ट-आधारित है। स्पष्ट शुरुआत। स्पष्ट अंत। कोई खुली मासिक बिलिंग नहीं, कोई स्कोप ड्रिफ्ट नहीं, कोई "क्या आप इसे भी देख सकते हैं?" जैसी बातचीत नहीं। इसे स्केलेबल बनाने वाला: सिस्टम, ऑफर नहीं। निश्चित मूल्य ऑफर सिर्फ फिर से कीमत लगाया गया कस्टम काम है। प्रोडक्टाइज्ड सर्विस के पीछे डिलीवरी प्लेबुक होती है। ## चरण 1: वह काम खोजें जिसके लिए क्लाइंट पहले से आपको हायर करते हैं बनाने के लिए सबसे आसान प्रोडक्टाइज्ड सर्विस वह है जिसे आप पहले से बार-बार डिलीवर कर रहे हैं लेकिन हर बार कस्टम काम के रूप में मान रहे हैं। अपने पिछले 10-15 क्लाइंट या प्रोजेक्ट देखें और पैटर्न खोजें: - कौन सी समस्या सबसे ज्यादा बार आती है? - कौन सा डिलीवरेबल आप सबसे ज्यादा बार बनाते हैं? - किस तरह का एंगेजमेंट सबसे सुचारू चलता है और सबसे अच्छा क्लाइंट फीडबैक मिलता है? मेरे लिए पैटर्न स्पष्ट था: क्लाइंट हमेशा एक ही चीज मांगते रहते थे — प्रक्रियाओं की मैपिंग, किसे ऑटोमेट करना है का चयन, और निर्माण के लिए सही टूल चुनना। मैं इसे बार-बार कर रहा था लेकिन हर बार अलग स्कोप के साथ। यह पैटर्न आपका शुरुआती बिंदु है। कोई नई सर्विस नहीं जो आपको लगता है बाजार को चाहिए। जो आप पहले से कर रहे हैं वही। एक फिल्टर: केवल उस काम को प्रोडक्टाइज करें जहां सभी क्लाइंट के लिए आउटपुट काफी हद तक एक जैसा हो। अगर हर क्लाइंट को पूरी तरह अलग डिलीवरेबल मिलता है, तो काम अभी प्रोडक्टाइज करने योग्य नहीं है — यह अभी भी वास्तव में कस्टम है। ठीक है; इसका मतलब सिर्फ यह है कि पहले परिभाषा का काम करना होगा। ## चरण 2: स्कोप की सीमाएं परिभाषित करें — और उन्हें बनाए रखें यहीं पर अधिकांश कंसल्टेंट विफल होते हैं। वे ऑफर को अस्पष्ट रूप से परिभाषित करते हैं, स्कोप को व्याख्या के लिए खुला छोड़ देते हैं, और पहले जैसी ही स्कोप-क्रीप बातचीत में फंस जाते हैं। प्रोडक्टाइज्ड सर्विस को कठोर स्कोप सीमाओं की जरूरत है। पहली सेल्स कॉल से पहले लिखित रूप में परिभाषित करें कि क्या शामिल है और क्या नहीं। AI ऑटोमेशन स्ट्रैटेजी स्प्रिंट के लिए स्कोप परिभाषा का उदाहरण: **शामिल:** - 60 मिनट की संरचित इनटेक कॉल - 5 वर्कफ्लो तक का लिखित ऑडिट - टूल रेकमेंडेशन के साथ प्राथमिकता से ऑटोमेशन रोडमैप - शीर्ष 3 उम्मीदवारों के लिए बिल्ड बनाम खरीदें मूल्यांकन - 30 मिनट का डिलीवरी वॉकथ्रू कॉल **शामिल नहीं:** - कार्यान्वयन (एजेंट या इंटीग्रेशन बनाना) - डिलीवरी के बाद बदलाव - 5 से अधिक वर्कफ्लो - सहमत ऑटोमेशन स्कोप के बाहर काम "शामिल नहीं" सूची उतनी ही महत्वपूर्ण है जितनी "शामिल" सूची। जब कोई क्लाइंट सीमा के बाहर कुछ मांगे, आपके पास दो विकल्प हैं: कहें कि यह इस ऑफर के दायरे से बाहर है, या अपने मूल्य के साथ एक स्कोप किया हुआ ऐड-ऑन बनाएं। जो नहीं करना है वह है इसे अवशोषित करना। शुरुआत में यह असहज लगता है। आप क्लाइंट को खुश रखने के लिए हां कहने के आदी हैं। प्रोडक्टाइजेशन "यह एक अलग प्रोजेक्ट है" कहने की मांग करता है — और लगातार इसका मतलब रखना। ## चरण 3: अपने घंटों के बजाय परिणाम के मूल्य के आधार पर कीमत तय करें प्रति घंटे बिलिंग और प्रोडक्टाइज्ड सर्विस एक साथ नहीं चलतीं। जिस क्षण आप अपने समय के आधार पर गणना करने लगते हैं, आपने इसे फिर से कस्टम काम बना दिया। प्रोडक्टाइज्ड ऑफर की कीमत लगाने के लिए तीन इनपुट: 1. **क्लाइंट को समस्या हल न करने की लागत।** एक AI ऑटोमेशन रोडमैप जो हर महीने $4,000 की परिचालन दक्षता मुक्त करता है, खरीदार के लिए हजारों डॉलर की कीमत रखता है। आपके 8 घंटे का काम गलत मूल्य निर्धारण का एंकर है। 2. **खरीदार समान परिणामों पर क्या खर्च करते हैं।** प्रतिस्पर्धी क्या चार्ज करते हैं नहीं — क्लाइंट कंसल्टेंट, फ्रैक्शनल एग्जीक्यूटिव, या सॉफ्टवेयर जो समस्या आंशिक रूप से हल करता है, से समान परिणामों पर वास्तव में क्या खर्च करते हैं। यह आपकी ऊपरी सीमा निर्धारित करता है। 3. **आपकी न्यूनतम सीमा।** डिलीवरी समय, क्लाइंट प्रबंधन और ओवरहेड को ध्यान में रखते हुए, इस ऑफर पर आपको कितना कमाना होगा जो आपके ध्यान के लायक हो? यह आपकी निचली सीमा निर्धारित करता है। उस रेंज में अपनी कीमत तय करें। शुरुआती प्रोडक्टाइज्ड ऑफर के लिए बीच से शुरू करें। जैसे-जैसे आप टेस्टिमोनियल इकट्ठा करते हैं और डिलीवरी की गति सुधारते हैं, ऊपरी सीमा की ओर बढ़ें। डिस्काउंट न दें। अगर कोई ऑफर नहीं दे सकता, तो वे इसके सही क्लाइंट नहीं हैं। आप एक अलग सेगमेंट के लिए कम कीमत वाला ऑफर बना सकते हैं — लेकिन एड-हॉक डिस्काउंट से मुख्य ऑफर को पतला न करें, नहीं तो आप कस्टम प्राइसिंग पर वापस आ जाएंगे। ## चरण 4: अगली बिक्री से पहले डिलीवरी सिस्टम बनाएं यह चरण निर्धारित करता है कि आपके पास प्रोडक्टाइज्ड सर्विस है या सिर्फ एक निश्चित मूल्य का प्रोजेक्ट। पहली डिलीवरी के बाद — अगले को बेचने से पहले — यह करें: 1. **हर चरण को क्रम में दस्तावेजित करें।** कोई अस्पष्ट रूपरेखा नहीं। इतनी विस्तृत चेकलिस्ट कि डोमेन से परिचित कोई व्यक्ति उससे 80% प्रक्रिया चला सके। मैं इन्हें [Notion](/recommends/notion) में रखता हूं — प्रत्येक वर्कफ्लो चरण के लिए एक पेज, टेम्पलेट, आउटपुट उदाहरण और मुश्किल निर्णयों के लिए डिसीजन ट्री के साथ। 2. **पहचानें कि किसमें अपेक्षा से अधिक समय लगा।** हर पहली डिलीवरी आवश्यकता से अधिक धीमी होती है। बोतलनेक खोजें और उन्हें व्यवस्थित करें: इनटेक फॉर्म, डिलीवरेबल टेम्पलेट, पूर्व-निर्मित फ्रेमवर्क। 3. **संरचित इनटेक प्रक्रिया बनाएं।** कॉल से पहले मानकीकृत फॉर्म में क्लाइंट की जानकारी प्राप्त करना डिलीवरी को पूर्वानुमानित बनाता है। कॉल स्पष्टीकरण प्रश्नों के लिए है, जानकारी एकत्र करने के लिए नहीं। 4. **डिलीवरेबल टेम्पलेट बनाएं।** हर क्लाइंट को एक ही आउटपुट संरचना मिलती है। सामग्री बदल सकती है; संरचना नहीं। यह डिलीवरी को तेज और आउटपुट को हर बार सुसंगत और पेशेवर बनाता है। अगर आप इस चरण को छोड़ देते हैं और बस अगले को बेचते हैं, तो आप अभी भी कस्टम काम कर रहे हैं — आपने बस उसे एक निश्चित मूल्य दे दिया। सिस्टम ही वह है जो इसे वास्तव में स्केलेबल बनाता है। ## प्रोडक्टाइजेशन वास्तव में क्या खोलता है मुख्य लाभ अधिक राजस्व नहीं है। यह बेहतर राजस्व है: पूर्वानुमानित मांग, तेज डिलीवरी, कम बातचीत, और उन क्लाइंट को ना कहने की क्षमता जो ऑफर से बाहर कुछ चाहते हैं। दूसरा लाभ: डिलीवरी दस्तावेजीकरण बौद्धिक संपदा बन जाती है। प्रोडक्टाइज्ड कंसल्टिंग ऑफर के लिए जो प्लेबुक आप बनाते हैं, वह एक कोर्स या प्रशिक्षण कार्यक्रम की सामग्री का बड़ा हिस्सा है। मैंने यह AI ऑटोमेशन कंसल्टिंग के साथ किया — डिलीवरी प्लेबुक सीधे मेरे AI Agents for Beginners कोर्स की पाठ्यक्रम रीढ़ बन गई। तीसरा लाभ: लेवरेज। एक दस्तावेजीकृत सिस्टम के साथ, आप किसी को डिलीवरी के हिस्से — ऑडिट, रिसर्च, दस्तावेज ड्राफ्टिंग — चलाने के लिए प्रशिक्षित कर सकते हैं, जबकि आप इनटेक और डिलीवरी कॉल पर ध्यान केंद्रित करते हैं। यही एक-से-एक समय-से-पैसा ट्रेडमिल से उतरने की शुरुआत है। ## प्रोडक्टाइज्ड ऑफर प्रबंधित करने के लिए मेरे टूल **[Airtable](/recommends/airtable)** — प्रत्येक क्लाइंट प्रोजेक्ट के लिए एक पंक्ति, स्थिति, डिलीवरेबल लिंक और भुगतान ट्रैकिंग। एक से पचास क्लाइंट तक जटिलता के बिना स्केल होता है। **[Notion](/recommends/notion)** — डिलीवरी प्लेबुक और क्लाइंट-सामना करने वाले वर्कस्पेस। प्रत्येक क्लाइंट को एक शेयर किया गया Notion वर्कस्पेस मिलता है जो बार-बार की डिलीवरी के माध्यम से परिष्कृत टेम्पलेट से बनाया गया है। **[ConvertKit](/recommends/convertkit)** — वेटलिस्ट प्रबंधन और फॉलो-अप सीक्वेंस। जब कोई ऑफर भर जाए (निश्चित स्कोप काम के साथ क्षमता जल्दी भर जाती है), एक वेटलिस्ट सीक्वेंस अगले ओपनिंग तक गर्म लीड को संलग्न रखती है। ## सबसे आम गलतियां **पर्याप्त डिलीवर करने से पहले प्रोडक्टाइज करना।** अगर आपने यह काम 3-5 बार नहीं किया है, तो आप अभी भी वास्तविक स्कोप नहीं जानते। पहले इसे कस्टम काम के रूप में डिलीवर करें। जानें कि सीमाएं कहां हैं। फिर प्रोडक्ट परिभाषित करें। **स्कोप को अस्पष्ट छोड़ना।** अपरिभाषित स्कोप वाली प्रोडक्टाइज्ड सर्विस निश्चित मूल्य वाला कस्टम प्रोजेक्ट है — जो दोनों दुनियाओं में सबसे बुरा है। क्या शामिल है परिभाषित करें, क्या शामिल नहीं है परिभाषित करें, लिखित रूप में रखें, और सेल्स पेज पर डालें। **स्कोप से बाहर अनुरोधों पर हां कहना।** जब क्लाइंट अधिक मांगे, अपने स्कोप और मूल्य के साथ एक ऐड-ऑन बनाएं। इस बार बस इसे अवशोषित न करें। **डिलीवरी सिस्टम को छोड़ना।** पहली डिलीवरी के बाद आप समाप्त नहीं हुए हैं। दूसरे को बेचने से पहले प्लेबुक बनाएं। सिस्टम ही प्रोडक्ट को बनाता है। ## FAQ ### मुझे कितनी प्रोडक्टाइज्ड ऑफर से शुरुआत करनी चाहिए? एक। इसे बनाएं, डिलीवर करें, सिस्टम को परिष्कृत करें, टेस्टिमोनियल इकट्ठा करें, फिर दूसरे पर विचार करें। अधिकांश लोग जो एक साथ दो लॉन्च करते हैं, वे दो अधूरे सिस्टम और किसी के लिए भी कोई टेस्टिमोनियल नहीं के साथ समाप्त होते हैं। ### क्या बेचना शुरू करने से पहले मुझे लैंडिंग पेज चाहिए? नहीं। पहले 5-10 बिक्री के लिए, एक पेज का PDF या एक अच्छी तरह से लिखा गया ईमेल पर्याप्त है। वेबसाइट बनाना इसका कारण न बनने दें कि आपने अभी तक कुछ नहीं बेचा। ### अगर क्लाइंट स्कोप से बाहर कुछ चाहता है तो क्या करें? उन्हें बताएं कि यह एक अलग प्रोजेक्ट है। वहीं एक ऐड-ऑन का कोटेशन दें या उसके लिए एक स्कोपिंग कॉल शेड्यूल करें। इसे वर्तमान प्रोजेक्ट में अवशोषित न करें। स्कोप बनाए रखने का अनुशासन ही मॉडल को काम करवाता है। ### पहला क्लाइंट कैसे मिलेगा? 10 लोगों को बताएं जो आपका काम जानते हैं — उन लोगों से गर्मजोशी से बातचीत करें जो आप पर भरोसा करते हैं या किसी ऐसे को जानते हैं जिसे इसकी जरूरत है। पहली बिक्री लगभग हमेशा एक लैंडिंग पेज से नहीं, बल्कि एक सीधी बातचीत से आती है। एक बार जब आपके पास एक केस स्टडी हो, तो [फाउंडर-लेड सेल्स अप्रोच](/founder-led-sales-how-to-reach-decision-makers/) इसे स्केल करना शुरू करता है। ### क्या मैं कुछ ऐसा प्रोडक्टाइज कर सकता हूं जो मैंने केवल एक बार किया हो? नहीं। आप अभी भी वास्तविक स्कोप नहीं समझते। इसे कस्टम काम के रूप में दो-तीन बार और डिलीवर करें, फिर जो सीखा उसे प्रोडक्ट में औपचारिक रूप दें। --- **अगले कदम:** मेरा [AI Agents for Beginners कोर्स](/course/) उन ऑटोमेशन सिस्टम को कवर करता है जो प्रोडक्टाइज्ड डिलीवरी को स्केलेबल बनाते हैं। [Cowork प्रोग्राम](/cowork/) उन ऑपरेटर के लिए है जो सिस्टम-संचालित व्यवसाय बना रहे हैं और इसके लिए एक संरचित वातावरण चाहते हैं। --- ## LinkedIn लीड जनरेशन स्ट्रेटेजी: बिना पेड ऐड्स के B2B क्लाइंट कैसे पाएं Source: https://alejandrorioja.com/hi/linkedin-lead-generation-strategy/ Published: 2026-07-14 Tags: Marketing, Growth, Entrepreneurship TL;DR: LinkedIn B2B लीड जनरेशन के लिए सबसे ज़्यादा लीवरेज वाला फ्री चैनल है — अगर आप इसे ट्रस्ट इंजन मानें, न कि मास कोल्ड आउटरीच मशीन। अपनी प्रोफ़ाइल को लैंडिंग पेज की तरह ऑप्टिमाइज़ करें, अपनी एक्सपर्टाइज़ के एक एंगल पर लगातार पोस्ट करें, और एक छोटा संपर्क अनुक्रम बनाएं जो वैल्यू से शुरू हो। कंपाउंड इफ़ेक्ट 60-90 दिनों में महसूस होता है, फिर लगभग अपने आप चलता रहता है। पेड ऐड्स ऑप्शनल हैं; शार्प प्रोफ़ाइल और उपयोगी कंटेंट फ़ीड नहीं। ## विषय सूची _जुलाई 2026 में प्रकाशित।_ **TL;DR:** LinkedIn B2B लीड जनरेशन के लिए सबसे ज़्यादा लीवरेज वाला फ्री चैनल है — अगर आप इसे ट्रस्ट इंजन मानें, न कि मास कोल्ड आउटरीच मशीन। अपनी प्रोफ़ाइल को लैंडिंग पेज की तरह ऑप्टिमाइज़ करें, अपनी एक्सपर्टाइज़ के एक एंगल पर लगातार पोस्ट करें, और एक छोटा संपर्क अनुक्रम बनाएं जो वैल्यू से शुरू हो। कंपाउंड इफ़ेक्ट 60-90 दिनों में महसूस होता है, फिर लगभग अपने आप चलता रहता है। पेड ऐड्स ऑप्शनल हैं; शार्प प्रोफ़ाइल और उपयोगी कंटेंट फ़ीड नहीं। **ऑपरेटर का नज़रिया:** मैंने LinkedIn का उपयोग कंसल्टिंग इन्क्वायरी, कोर्स खरीदार और पार्टनरशिप बातचीत जनरेट करने के लिए किया है — सब कुछ बिना एक भी ऐड चलाए। जो काम करता है वह कोई हैक या टूल नहीं है; यह उस स्पेस में सच में उपयोगी व्यक्ति के रूप में प्रकट होना है जहां आपके खरीदार पहले से हैं। यह वही प्लेबुक है जो मैं उपयोग करता हूं और वह क्रम जिसमें मैं इसे चलाता अगर आज शून्य से शुरू करता। ## 2026 में LinkedIn क्यों LinkedIn का ऑर्गेनिक रीच लगभग हर दूसरे प्लेटफ़ॉर्म से बेहतर बना हुआ है। कुछ सौ प्रासंगिक फ़ॉलोअर वाले व्यक्ति का पोस्ट भी हज़ारों टार्गेटेड प्रोफेशनल्स तक पहुंच सकता है — जिसके लिए ज़्यादातर अन्य चैनलों पर असली पैसे लगते हैं। एल्गोरिदम उस कंटेंट को इनाम देता रहता है जो एक्सपर्टाइज़ से भरपूर हो और जो लाइक्स की बजाय सेव और शेयर करवाए। B2B के लिए विशेष रूप से, LinkedIn का कोई विश्वसनीय विकल्प नहीं है: - डिसीज़न मेकर्स यहां किसी भी अन्य प्लेटफ़ॉर्म से ज़्यादा पहुंच के योग्य हैं। - इंटेंट सिग्नल प्रोफेशनल है — लोग "वर्क मोड" में हैं, बेमकसद स्क्रॉल नहीं कर रहे। - एक कमेंट या पोस्ट आपकी सोच का पब्लिक रिकॉर्ड बनाता है जिसे प्रोस्पेक्ट हफ़्तों या महीनों बाद खोज सकते हैं। - InMail और कनेक्शन रिक्वेस्ट अभी भी उपलब्ध सबसे कम एक्विज़िशन कॉस्ट आउटरीच मेकेनिज़्म में से हैं। चेतावनी: वही खुलापन जो LinkedIn को मूल्यवान बनाता है, उसे मास आउटरीच, जेनेरिक थॉट लीडरशिप पोस्ट और पतले-से-छिपे पिचेज़ से भी भर देता है। अलग दिखने की बार कम है। ज़्यादातर लोग इसे पार ही नहीं कर पाते। ## स्टेप 1: कुछ भी पोस्ट करने से पहले अपनी प्रोफ़ाइल ठीक करें जब कोई प्रोस्पेक्ट आपकी कनेक्शन रिक्वेस्ट पाता है या आपके लिखे पोस्ट पर आता है, तो LinkedIn प्रोफ़ाइल सबसे पहले पढ़ता है। अगर यह तुरंत यह नहीं बताती कि आप किसकी मदद करते हैं और कैसे, तो आप जो भी और करते हैं, वह कमज़ोर पड़ जाता है। चार सबसे ज़रूरी जगहें: 1. **हेडलाइन** — आपकी जॉब टाइटल नहीं। जो फ़ॉर्मूला काम करता है: _[मैं क्या करता हूं] [किसके लिए] ताकि वे [परिणाम] कर सकें_। "मैं B2B SaaS फाउंडर्स को बिना सेल्स टीम के अपनी पहली 10 एंटरप्राइज़ डील बंद करने में मदद करता हूं" सर्च योग्य, स्पेसिफिक और तुरंत सेल्फ-क्वालिफाइंग है। 2. **बैनर इमेज** — इसे उसी संदेश को सुदृढ़ करने के लिए उपयोग करें। आपके निच या एक छोटे प्रूफ स्टेटमेंट वाला क्लीन विज़ुअल जेनेरिक ग्रेडिएंट से बेहतर है। 3. **अबाउट सेक्शन** — पहले व्यक्ति में लिखें। दो छोटे पैराग्राफ: आप क्या करते हैं और किसके लिए, फिर एक या दो प्रूफ पॉइंट (क्लाइंट, परिणाम, उपलब्धियां — असली)। एक स्पष्ट CTA से खत्म करें: "अगर आप X करने की कोशिश कर रहे हैं तो DM करें।" 4. **फ़ीचर्ड सेक्शन** — एक या दो चीज़ें पिन करें: एक लीड मैग्नेट, एक बेस्ट पोस्ट, एक केस स्टडी, एक बुकिंग लिंक। यह प्राइम रीयल एस्टेट है जिसे ज़्यादातर लोग खाली छोड़ देते हैं। टेस्ट: अपनी प्रोफ़ाइल किसी अजनबी की तरह पढ़ें। 10 सेकंड में, क्या वे जान सकते हैं कि आप क्या करते हैं, किसके लिए और आगे क्या करना है? अगर नहीं, तो एडिट करते रहें। ## स्टेप 2: एक एंगल से, लगातार पोस्ट करें LinkedIn की सबसे आम गलती है रैंडमली पोस्ट करना — सोमवार को मार्केटिंग टिप, बुधवार को मोटिवेशनल कोट, शुक्रवार को प्रोडक्ट पिच। एल्गोरिदम आपको इग्नोर करता है और आपका ऑडियंस भी। जो काम करता है वह है अपनी एक्सपर्टाइज़ का एक स्पेसिफिक एंगल चुनना और उसे अपना बनाना। उस एंगल से 90 दिनों तक हफ़्ते में तीन से चार बार पोस्ट करें। शुरुआती चरणों में वॉल्यूम और कंसिस्टेंसी इंस्पिरेशन और पॉलिश को हराते हैं। ### कंपाउंड इफ़ेक्ट बनाने वाला कंटेंट मिक्स | फ़ॉर्मेट | इसके लिए उपयोग करें | क्यों काम करता है | | --- | --- | --- | | शॉर्ट टेक्स्ट पोस्ट (3–5 लाइनें) | कंट्रेरियन टेक्स, क्विक फ्रेमवर्क, हाल के काम से सबक | हाई रीच, कंज़्यूम करने में कम फ्रिक्शन, कमेंट्स जनरेट करता है | | लिस्ट पोस्ट | स्टेप-बाय-स्टेप ब्रेकडाउन, तुलनाएं, टूल्स | सेव और शेयर; एल्गोरिदम फ्रेंडली | | स्टोरी पोस्ट | एक स्पेसिफिक सिचुएशन जिसका मैंने सामना किया, मैंने क्या किया, क्या हुआ | किसी भी अन्य फ़ॉर्मेट से तेज़ ट्रस्ट बनाता है | | लॉन्ग-फ़ॉर्म आर्टिकल | डीप गाइड्स, एवरग्रीन एक्सप्लेनर | सर्च द्वारा इंडेक्स; समय के साथ एक्सपर्ट के रूप में पोज़िशन | | कैरोसेल (डॉक्यूमेंट पोस्ट) | विज़ुअल फ्रेमवर्क, लंबे पोस्ट के सारांश | सभी फ़ॉर्मेट में सबसे ज़्यादा सेव रेट | मेरा रेशियो: 70% शॉर्ट पोस्ट और लिस्ट, 20% स्टोरीज़, 10% लॉन्ग-फ़ॉर्म या कैरोसेल। लॉन्ग-फ़ॉर्म पोस्ट ज़्यादा रीच नहीं पाते लेकिन महीनों में सर्च और DM शेयर में जमा होते हैं। ## स्टेप 3: जानबूझकर अपना कनेक्शन बेस बनाएं LinkedIn पर सही फ़ॉलोइंग बढ़ाना, केवल बड़ी फ़ॉलोइंग बढ़ाने से अलग है। एक हज़ार फ़ॉलोअर जो आपके एग्जैक्ट बायर हैं, दस हज़ार से ज़्यादा मूल्यवान हैं जो आपके पीयर्स या रैंडम ऑब्ज़र्वर हैं। मेरे टार्गेटिंग क्राइटेरिया: - उन इंडस्ट्री में डिसीज़न मेकर्स जिन्हें मैं सर्व करता हूं - उन रेवेन्यू रेंज में कंपनियों के फाउंडर्स और ऑपरेटर्स जिनके साथ मैं काम करता हूं - मौजूदा क्लाइंट्स और कोलैबोरेटर्स से सेकंड-डिग्री कनेक्शन (सबसे वार्म सोर्स) - मेरे स्पेस में कॉम्पिटिटर्स या पीयर्स के साथ एंगेज होने वाले लोग मैं प्रतिदिन 15-20 कनेक्शन रिक्वेस्ट भेजता हूं, हर एक के साथ एक लाइन का नोट जो स्पष्ट करे कि मैं क्यों कनेक्ट हो रहा हूं। पिच नहीं — बस कॉन्टेक्स्ट: "[टॉपिक] पर आपका कमेंट देखा, मैं जो काम करता हूं उससे संबंधित — कनेक्ट होकर खुशी होगी।" यह नोट अक्सेप्टेंस रेट को ~30% (जेनेरिक) से ~55-65% (स्पेसिफिक) तक बढ़ाता है। नोट अधिकतम दो वाक्यों का है। सभी से कनेक्ट न हों। अनक्वालिफाइड अकाउंट्स से भरी फूली हुई कनेक्शन लिस्ट वास्तव में नुकसान पहुंचाती है — LinkedIn का एल्गोरिदम आपके पोस्ट आंशिक रूप से आपके कनेक्शन तक डिस्ट्रिब्यूट करता है, इसलिए कम क्वालिटी ऑडियंस आपकी रीच दबाता है। ## स्टेप 4: अपना आउटरीच सीक्वेंस करें — तीन-टच अप्रोच एक बार जब कोई कनेक्ट हो जाए, लक्ष्य तुरंत पिच करना नहीं है। बल्कि एक ऐसी बातचीत शुरू करना है जो समय के साथ मीटिंग तक ले जा सके। जो लोग कनेक्शन को सेल्स डेक पेस्ट करने की अनुमति मानते हैं, वे इसके बाद हर टचपॉइंट को ज़हरीला कर देते हैं। मेरा सीक्वेंस: **टच 1 (दिन 1, कनेक्शन के 24 घंटे के भीतर):** एक छोटा, गर्मजोशी भरा वेलकम मैसेज भेजें। बताएं क्यों कनेक्ट हुए और एक उपयोगी रिसोर्स शेयर करें — पोस्ट, फ्रेमवर्क, आर्टिकल — जो उन्होंने शेयर किए किसी चीज़ से संबंधित हो। कोई रिक्वेस्ट नहीं। इसे एक स्टेटमेंट के रूप में खत्म करें, सवाल नहीं। **टच 2 (दिन 5-7):** उनके किसी पोस्ट के साथ सच्चे तरीके से एंगेज करें — केवल लाइक नहीं, एक असली सोचा-समझा कमेंट जो बातचीत में जोड़े। यह दूसरा DM भेजे बिना उनकी फ़ीड में आपका नाम दृश्यमान रखता है। **टच 3 (दिन 14-21):** एक नरम, स्पेसिफिक रिक्वेस्ट के साथ DM में फ़ॉलो अप करें। एक स्पष्ट, जवाब देने में आसान सवाल, उनके काम में देखी किसी प्रासंगिक चीज़ से जुड़ा। अगर टाइमिंग सही है और दर्द असली है, तो यहां मीटिंग बुक होती हैं। अगर नहीं, तो आगे बढ़ें — अकाउंट वार्म है और वे आपका नाम जानते हैं। जो गलती मैं लगातार देखता हूं: टच 1 और 2 को स्किप करना और जैसे ही कोई कनेक्ट होता है, सीधे CTA मैसेज पर कूदना। यह लीड जनरेशन नहीं है; यह रेपुटेशन पर टैक्स है। ## स्टेप 5: बातचीत को मीटिंग में बदलें DMs में एक अच्छी बातचीत को कैलेंडर इनवाइट की ओर एक साफ रास्ते की ज़रूरत है। जैसे ही कोई असली रुचि दिखाए — फ़ॉलो-अप सवाल पूछे, अपनी समस्या सीधे बताए, या आपके सोल्यूशन के साथ एंगेज करे — तभी रिक्वेस्ट करें। जो मैसेज कन्वर्ट करता है: > "[उन्होंने जो स्पेसिफिक चीज़ कही] आपके लिए असली लगती है। मैंने ऐसी ही स्थितियों में कुछ कंपनियों की मदद की है — 20 मिनट में बताने में खुशी होगी कि हमने इसे कैसे अप्रोच किया, कोई पिच नहीं, बस देखते हैं कि क्या प्रासंगिक है। [बुकिंग लिंक] — अगर उपयोगी हो तो स्लॉट लें।" छोटा, कम कमिटमेंट, हां कहना आसान। बुकिंग लिंक शेड्यूलिंग फ्रिक्शन हटाता है जो होनी चाहिए थीं आधी मीटिंग्स को मारता है। ## क्या नहीं करना चाहिए वे व्यवहार जो अकाउंट को इग्नोर, रिपोर्ट या बैन करवाते हैं: 1. **बिना कॉन्टेक्स्ट के मास कनेक्शन रिक्वेस्ट** — LinkedIn आपके अकाउंट को रेस्ट्रिक्ट करेगा और अक्सेप्टेंस रेट गिर जाएगी। 2. **पहले पिच DMs** — पहला मैसेज आपके प्रोडक्ट, प्राइसिंग या कैलेंडर लिंक को इंट्रोड्यूस करने की जगह नहीं है। 3. **एंगेजमेंट पॉड्स** — फ़ेक एंगेजमेंट वैनिटी मेट्रिक्स को फुलाता है और एल्गोरिदमिक रूप से पेनलाइज़ होता है। 4. **हर दिन बिना पॉइंट ऑफ व्यू के पोस्ट करना** — पर्स्पेक्टिव के बिना वॉल्यूम शोर है। हर हफ्ते एक असली इनसाइट वाली पोस्ट सात बिना सब्सटेंस "हॉट टेक्स" से बेहतर है। 5. **आउटरीच ऑटोमेट करना** — LinkedIn का बॉट डिटेक्शन एग्रेसिव हो गया है। बड़े स्केल पर ऑटोमेटेड कनेक्शन टूल्स और AI-लिखे DM सीक्वेंस फ़्लैग किए जाते हैं। स्टेप 4 का सीक्वेंस रोज़ लगभग 30 मिनट लेता है और इसका सिग्नल-टू-नॉइज़ रेशियो कोई टूल मैच नहीं कर सकता। ## जो वास्तव में मायने रखता है उसे मापें इग्नोर करने वाली वैनिटी मेट्रिक्स: इम्प्रेशन, प्रोफ़ाइल व्यूज़, फ़ॉलोअर काउंट। वे नंबर जो बताते हैं कि सिस्टम काम कर रहा है: - **कनेक्शन अक्सेप्टेंस रेट** — नोट के साथ 50%+ का लक्ष्य; अगर 30% से कम है, नोट फिर से लिखें। - **फ़ॉलो-अप मैसेज पर रिप्लाई रेट** — अच्छी तरह टार्गेटेड लिस्ट के लिए 20-30% हेल्दी है। - **प्रति माह इनबाउंड DMs** — आपके कंटेंट की वजह से आपसे संपर्क करने वाले लोग। महीने दर महीने ट्रैक करें। - **LinkedIn से प्रति माह बुक की गई कॉल्स** — एकमात्र नंबर जो रेवेन्यू के साथ कोरिलेट करता है। मैं इसे एक सरल Notion टेबल में ट्रैक करता हूं। पहले 90 दिनों का लक्ष्य LinkedIn से अकेले हफ़्ते में एक इनबाउंड DM और महीने में एक बुक की गई कॉल तक पहुंचना है। तीसरे महीने तक, अगर कंटेंट काम कर रहा है, तो वे नंबर आनुपातिक रूप से ज़्यादा मेहनत के बिना बढ़ते हैं। ## ऑपरेटर का निचला रेखा LinkedIn B2B लीड जनरेशन के लिए काम करता है क्योंकि यह एकमात्र प्रोफेशनल नेटवर्क है जहां ऑर्गेनिक रीच का अभी भी वज़न है और जहां आपकी रेपुटेशन समय के साथ सार्वजनिक रूप से जमा होती है। मैकेनिक्स सरल है: एक प्रोफ़ाइल जो बताए कि आप किसकी मदद करते हैं, कंटेंट जो साबित करे कि आप जानते हैं क्या कह रहे हैं, और एक कॉन्टैक्ट सीक्वेंस जो पिच के बजाय वैल्यू से लीड करे। 90 दिनों तक लगातार यह करें और इनबाउंड आना शुरू हो जाते हैं। एक साल तक करें और यह बिना ऐड बजट के आपके योग्य बातचीत के सबसे भरोसेमंद स्रोतों में से एक बन जाता है। --- **संबंधित:** [फाउंडर-लेड सेल्स](/founder-led-sales-how-to-reach-decision-makers/) · [पर्सनल ब्रांड कैसे बनाएं](/how-to-build-a-personal-brand/) · [आउटरीच स्ट्रेटेजी](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) --- ## मैंने Courtlines कैसे बनाया: Claude के साथ इंजीनियर किया गया एक क्लब-मैनेजमेंट SaaS Source: https://alejandrorioja.com/hi/how-i-built-courtlines-a-club-management-saas-with-claude/ Published: 2026-07-11 Tags: AI Agents, Case Study TL;DR: Courtlines रैकेट-स्पोर्ट क्लबों और स्टूडियो के लिए ऑपरेटिंग सिस्टम है — बुकिंग, मेंबरशिप, कोचिंग, पॉइंट-ऑफ-सेल और इवेंट, सब एक ही ब्रांडेड छत के नीचे। मैंने इसे एक अकेले ऑपरेटर के तौर पर Claude को अपने इंजीनियरिंग पार्टनर के रूप में लेकर बनाया। सबक: AI ने केवल मुझे तेज़ी से कोड करने में मदद नहीं की, बल्कि उस उत्पाद के आकार को बदल दिया जिसे एक अकेला इंसान भरोसेमंद तरीके से शिप और चला सकता है। ## विषय-सूची _जुलाई 2026 में अपडेट किया गया।_ **संक्षेप में:** Courtlines रैकेट-स्पोर्ट क्लबों और स्टूडियो के लिए ऑपरेटिंग सिस्टम है — बुकिंग, मेंबरशिप, कोचिंग, पॉइंट-ऑफ-सेल और इवेंट, सब एक ही ब्रांडेड छत के नीचे। मैंने इसे एक अकेले ऑपरेटर के तौर पर Claude को अपने इंजीनियरिंग पार्टनर के रूप में लेकर बनाया। सबक: AI ने केवल मुझे तेज़ी से कोड करने में मदद नहीं की, बल्कि उस उत्पाद के आकार को बदल दिया जिसे एक अकेला इंसान भरोसेमंद तरीके से शिप और चला सकता है। **[ऑपरेटर का नज़रिया]** मैं एक कंसल्टिंग ब्रांड और Pickleland — Austin, TX महानगर में मेरे द्वारा संचालित पिकलबॉल सुविधा — में 30 से अधिक प्रोडक्शन एजेंट चलाता हूँ। एक असली सुविधा चलाने से मुझे ठीक-ठीक समझ आया कि मेरे जैसे क्लबों के लिए सॉफ़्टवेयर कितना खराब है — तो मैंने वह सॉफ़्टवेयर बनाया जो मैं चाहता था कि मेरे पास होता। यह [Courtlines](https://courtlines.com) की कहानी है, यह क्या करता है, और कैसे Claude पर टेक लगाने से एक अकेले इंसान को कुछ ऐसा बनाने में मदद मिली जिसके लिए आम तौर पर एक पूरी टीम लगती है। ## क्लब को एक ऐप नहीं, बल्कि एक ऑपरेटिंग सिस्टम की ज़रूरत क्यों है अगर आपने कभी कोई स्पोर्ट्स सुविधा नहीं चलाई है, तो सॉफ़्टवेयर की समस्या अदृश्य रहती है। बाहर से देखने पर ऐसा लगता है कि "लोग कोर्ट बुक करते हैं।" अंदर से, एक क्लब एक छोटा, गड़बड़ बिज़नेस है जिसमें दर्जनों चलते-फिरते हिस्से होते हैं जिन्हें आपस में सहमत रहना ज़रूरी है। एक मेंबर कोर्ट बुक करता है। उस बुकिंग को यह जानना होता है कि वह किसी मेंबरशिप प्लान पर है या नहीं, उसके पास क्रेडिट हैं या नहीं, कोर्ट पहले से किसी क्लिनिक के लिए रोका गया है या नहीं, कोई कोच नियुक्त है या नहीं, और फ्रंट डेस्क ने कीमत बदली है या नहीं। जब वह आता है, तो कोई काउंटर पर बॉल का एक कैन बिल करता है — वह है पॉइंट-ऑफ-सेल। वह अपने बच्चे को किसी जूनियर प्रोग्राम में दाखिल कराता है — वह है इवेंट और फैमिली अकाउंट। वह 10 पाठों का पैकेज खरीदता है — वह है एक कोचिंग पैकेज जिसका अपना कोच को भुगतान करने का लॉजिक होता है। वह किसी दोस्त को रेफ़र करता है — वह है एक मेंबरशिप फ़नल। ज़्यादातर क्लब इसे तीन या चार अलग-अलग जुड़े हुए टूल्स, साथ में एक स्प्रेडशीट और एक ग्रुप टेक्स्ट पर चलाते हैं। बुकिंग सिस्टम को POS के बारे में पता नहीं होता। POS को मेंबरशिप के बारे में पता नहीं होता। महीने के अंत में किसी के भी आँकड़े मेल नहीं खाते। **Courtlines इस सवाल का जवाब है कि "अगर यह सब एक ही सिस्टम होता तो क्या होता?"** यह फ़ीचर जोड़-जोड़ कर बनाई गई कोई बुकिंग ऐप नहीं है — यह एक अकेला ऑपरेटिंग सिस्टम है जहाँ कैलेंडर, मेंबरशिप, रजिस्टर, कोचिंग भुगतान और सार्वजनिक इवेंट पेज सब एक ही अंतर्निहित डेटा हैं। यही पूरी थीसिस है, और यही साइट पर टैगलाइन भी है: क्लबों और स्टूडियो के लिए ऑपरेटिंग सिस्टम। ## Courtlines असल में क्या करता है मोटे तौर पर, [Courtlines](https://courtlines.com) एक क्लब को देता है: - **एक ड्रैग-एंड-ड्रॉप कोर्ट ग्रिड** फ्रंट डेस्क के लिए — हर रिज़र्वेशन, क्लिनिक और होल्ड एक ही स्क्रीन पर, जिसे एक एडमिन रियल टाइम में फिर से व्यवस्थित कर सकता है। - **बुकिंग और ओपन-प्ले** मेंबरों के लिए, जिसमें वे अटपटे-पर-ज़रूरी किनारे के मामले भी शामिल हैं: दोहराई जाने वाली रिज़र्वेशन, वेटलिस्ट, रद्दीकरण की समय-सीमाएँ और क्रेडिट। - **मेंबरशिप और बिलिंग** — प्लान, फैमिली अकाउंट, माता-पिता से जुड़े जूनियर/बच्चों के लॉगिन, और वह डनिंग जो राजस्व को चुपचाप रिसने से बचाती है। - **कोचिंग** — पाठ पैकेज, शेड्यूलिंग, और स्वतंत्र कोचों को स्वचालित भुगतान। - **पॉइंट-ऑफ-सेल** — प्रो शॉप और कैफ़े के लिए एक असली रजिस्टर, जो बाकी हर चीज़ की तरह उसी ग्राहक रिकॉर्ड से जुड़ा होता है। - **इवेंट और सार्वजनिक पेज** — क्लिनिक, लीग और टूर्नामेंट, जिनके सार्वजनिक पेज होते हैं जिन्हें लोग खोज सकें और साइन अप कर सकें। डिज़ाइन का लक्ष्य यह है कि प्लेटफ़ॉर्म गायब हो जाए। एक क्लब अपना खुद का ब्रांड ऊपर लगाता है, और उसके मेंबरों को यह बस "हमारे क्लब का ऐप" जैसा लगता है, न कि "कोई SaaS जिसके लिए हम पैसे देते हैं।" यह इस क्षेत्र के मौजूदा खिलाड़ियों — CourtReserve और Skedda जैसों — से एक जानबूझकर किया गया विरोधाभास है, जहाँ सॉफ़्टवेयर ही ब्रांड है और क्लब बस एक किरायेदार। Pickleland टेनेंट #1 है। मुझे किसी डेमो के पीछे छिपने की सहूलियत नहीं मिलती; इस चीज़ को असल में एक ऐसी सुविधा चलानी होती है जिसकी ज़िम्मेदारी व्यक्तिगत रूप से मुझ पर है। यह बाधा अब तक की मेरी सबसे बढ़िया प्रोडक्ट मैनेजर रही है। आप [Pickleland यहाँ देख सकते हैं](https://pickleland.com) — यह असल दुनिया की परख का मैदान है, और हर वह खुरदरा किनारा जिससे कोई मेंबर टकराता है, एक बग है जिसे मैं उसी दिन महसूस करता हूँ। ## जिस बात ने मुझे चौंका दिया: एक अकेला ऑपरेटर अब क्या शिप कर सकता है यह कहानी का ईमानदार संस्करण है, और यही वजह है कि मैं चुपचाप लॉन्च करने के बजाय यह पोस्ट लिख रहा हूँ। बिलिंग, POS, रोल-आधारित एक्सेस, कोचिंग भुगतान और एक सार्वजनिक इवेंट सिस्टम के साथ एक मल्टी-टेनेंट SaaS कोई वीकेंड प्रोजेक्ट नहीं है। दस साल पहले, यह एक साल के लिए पाँच से आठ इंजीनियरों की सीड-फंडेड टीम का काम था। यह उस तरह का दायरा है जहाँ एक अकेले संस्थापक से आम तौर पर, विनम्रता से, कहा जाता है कि इसे एक फ़ीचर तक सीमित करो और पैसा जुटाओ। मैंने इसे एक अकेले इंसान के तौर पर बनाया, **Claude को अपने मुख्य इंजीनियरिंग पार्टनर के रूप में लेकर।** यह नहीं कि "मैंने कभी-कभी ChatGPT से एक स्निपेट माँग लिया" — मेरा मतलब है कि Claude ने इस सिस्टम में अधिकांश कोड लिखा, उन विनिर्देशों और उत्पाद निर्णयों से काम करते हुए जो मेरे हैं। मेरा काम *इम्प्लीमेंटेशन टाइप करने* से बदलकर *यह तय करने* में बदल गया कि सच क्या है: डेटा मॉडल क्या होना चाहिए, किसी रोल को क्या करने की अनुमति है, किसी फ़ीचर के लिए "हो गया" का क्या मतलब है, और शिप करने के लिए क्या सुरक्षित है। दिलचस्प बदलाव गति नहीं है, हालाँकि यह तेज़ ज़रूर है। यह **दायरा** है। AI ने मुझे उसी आकार के उत्पाद पर 2× डेवलपर नहीं बनाया। इसने उस उत्पाद का आकार बदल दिया जिसे मैं भरोसेमंद तरीके से बना सकता हूँ और, उतना ही ज़रूरी, अकेले *चला और बनाए रख सकता हूँ*। जो कोडबेस केवल एक इंसान ने लिखा हो, वह अपने ही बोझ तले ढह जाता। एक ऐसा कोडबेस जहाँ एक AI पार्टनर इम्प्लीमेंटेशन का ब्योरा संभालता है और मैं आर्किटेक्चर और सुरक्षा-रेखाएँ संभालता हूँ, सचमुच एक अलग ही किस्म की चीज़ है — और यही वजह है कि एक अकेला ऑपरेटर अब उस श्रेणी के पीछे जा सकता है जिसके लिए पहले एक कंपनी की ज़रूरत होती थी। मैं जानबूझकर यहाँ Courtlines के लिए अपनी सटीक ऑपरेटिंग रणनीति प्रकाशित नहीं कर रहा — उसे मैं एक प्रतिस्पर्धी बढ़त मानता हूँ, और मैं चाहूँगा कि मेरे प्रतिस्पर्धी यही मानते रहें कि इसमें एक बड़ी टीम लगती है। लेकिन अगर आप देखना चाहते हैं कि मैं किसी असली प्रोजेक्ट पर Claude को कैसे चलाता हूँ, विस्तार से, तो मैंने यह सब एक बहुत छोटे बिल्ड के लिए लिख डाला: एक मोबाइल गेम जो मैंने ऐप स्टोर पर शिप किया। देखें [मैंने Quads, एक मोबाइल बोर्ड गेम, Claude के साथ कैसे बनाया](/how-i-built-quads-a-mobile-board-game-with-claude/) — वही काम करने का तरीका, कुछ भी छिपाने को नहीं, हर तरकीब मेज़ पर। ## वे सिद्धांत जिन पर मैं समझौता नहीं करूँगा रणनीति को निजी रखते हुए भी, कुछ सिद्धांत कहने लायक हैं क्योंकि वे किसी भी उस व्यक्ति पर लागू होते हैं जो AI के साथ गंभीर सॉफ़्टवेयर बना रहा है: **इंसान खतरनाक कलमें अपने हाथ में रखता है।** कुछ थोड़ी-सी क्रियाएँ ऐसी होती हैं जहाँ एक गलती महँगी और पलटने में मुश्किल होती है — स्कीमा बदलाव, डिप्लॉय, कुछ भी जो पैसे या प्रोडक्शन डेटा को छूता हो। वे पक्के तौर पर मेरे पास रहती हैं। AI उन्हें प्रस्तावित कर सकता है; उसे उन्हें अंजाम देने की इजाज़त नहीं। उस रेखा को साफ़ खींचना ही वह चीज़ है जो बाकी हर जगह AI को खूब ढील देना सुरक्षित बनाती है। **हरे टेस्ट ज़रूरी हैं, पर पर्याप्त नहीं।** एक बुकिंग फ़्लो जो हर यूनिट टेस्ट पास कर ले, फिर भी असली ब्राउज़र में साफ़ तौर पर टूटा हुआ हो सकता है। UI वाले किसी उत्पाद के लिए सबसे ज़रूरी सत्यापन एक इंसान — या एक निगरानी वाली प्रक्रिया — का असल में यथार्थवादी डेटा के ख़िलाफ़ उसमें से क्लिक करके गुज़रना है। टेस्ट एक ढलान हैं जो चीज़ों को और बिगड़ने से रोकते हैं; वे इस बात का सबूत नहीं कि कोई फ़ीचर काम करता है। यह मैंने महँगे तरीके से सीखा, और इसने हमेशा के लिए बदल दिया कि मैं "हो गया" को कैसे परिभाषित करता हूँ। **विनिर्देश ही असली इंटरफ़ेस हैं।** ताकत चतुर प्रॉम्प्टिंग में नहीं है — यह इस बात में है कि सिस्टम क्या है और उसका हर हिस्सा क्या करने वाला है, इसके बारे में साफ़, अद्यतन दस्तावेज़ बनाए रखे जाएँ। उन्हें सटीक रखने में लगाया गया समय हर भविष्य के सत्र में कई गुना लौटकर आता है। अगर आप इसका गहरा संस्करण चाहते हैं, तो यह वही अनुशासन है जिसका वर्णन मैं [प्रोडक्शन में विफल न होने वाले AI एजेंट सिस्टम प्रॉम्प्ट कैसे लिखें](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/) में करता हूँ। **वह चीज़ बनाओ जिसके साथ तुम्हें जीना पड़े।** सबसे बढ़िया एकमात्र निर्णय यह था कि Courtlines को मेरी अपनी एक सुविधा चलानी पड़े। एक ऐसा डेमो शिप करना आसान है जो प्रभावित कर दे; ऐसे सॉफ़्टवेयर से छिपना नामुमकिन है जिस पर आपके अपने मेंबर निर्भर हों। अगर आप AI के साथ बना रहे हैं, तो उसे किसी ऐसी समस्या पर लगाइए जिसे आप व्यक्तिगत रूप से महसूस करते हों — यथार्थ की यह परख किसी भी टेस्ट सूट से ज़्यादा कीमती है। ## यह मेरी बाकी बनाई जा रही हर चीज़ में कहाँ फ़िट बैठता है Courtlines अलग-थलग नहीं है। यह एक छोटे रैकेट-स्पोर्ट्स इकोसिस्टम का हिस्सा है जिसे मैं बना रहा हूँ: [The Court Scout](https://thecourtscout.com) पिकलबॉल कोर्टों की एक सत्यापित डायरेक्टरी है, जिसे उन स्क्रैप की गई डायरेक्टरियों से सचमुच ज़्यादा सटीक बनाने के लिए बनाया गया है जिनसे यह मुकाबला करती है, और Pickleland वह प्रमुख सुविधा है जिसके ख़िलाफ़ हर चीज़ की परख होती है। डायरेक्टरी खिलाड़ियों को कोर्ट खोजने में मदद करती है; Courtlines उन कोर्टों के पीछे के क्लबों को असल में चलने में मदद करता है। इन सब को जोड़ने वाली कड़ी एक ही ऑपरेटिंग मॉडल है: AI से सशक्त एक अकेला ऑपरेटर, जो एक अकेला ऑपरेटर ऐतिहासिक रूप से जितनी संभाल सकता था उससे ज़्यादा दायरा संभाल रहा है। Courtlines अब तक इस मॉडल की सबसे महत्वाकांक्षी अभिव्यक्ति है — एक पूरा SaaS प्लेटफ़ॉर्म जिसे कुछ साल पहले मैं अकेले करने की कोशिश ही नहीं करता। अगर आप कोई रैकेट-स्पोर्ट्स क्लब या स्टूडियो चलाते हैं और चार टूल्स को आपस में जोड़ते-जोड़ते थक गए हैं, तो [Courtlines](https://courtlines.com) पर एक नज़र डालिए। और अगर आप एक बिल्डर हैं जो सोच रहे हैं कि किसी असली उत्पाद पर आप AI को कितनी दूर तक धकेल सकते हैं, तो यही इस पोस्ट का पूरा मकसद है: शायद आपकी सोच से भी दूर। ## अक्सर पूछे जाने वाले सवाल ### Courtlines क्या है? Courtlines रैकेट-स्पोर्ट क्लबों और स्टूडियो के लिए एक मल्टी-टेनेंट ऑपरेटिंग सिस्टम है — पिकलबॉल, टेनिस, पैडल और उससे आगे। यह बुकिंग, मेंबरशिप, कोचिंग, पॉइंट-ऑफ-सेल और इवेंट प्रबंधन को एक ब्रांडेड प्लेटफ़ॉर्म में जोड़ता है, ताकि एक क्लब अपना पूरा बिज़नेस चार अलग-अलग जुड़े हुए टूल्स के बजाय एक ही सिस्टम से चलाए। आप इसे [courtlines.com](https://courtlines.com) पर देख सकते हैं। ### क्या Claude ने सचमुच ज़्यादातर कोड लिखा? हाँ। Claude मेरा मुख्य इंजीनियरिंग पार्टनर था और उसने अधिकांश इम्प्लीमेंटेशन लिखा, उन विनिर्देशों, आर्किटेक्चर और उत्पाद निर्णयों से काम करते हुए जो मेरे हैं और मेरे नियंत्रण में हैं। स्कीमा, डिप्लॉय और "हो गया" की परिभाषा मैं संभालता हूँ; इम्प्लीमेंटेशन का ब्योरा AI संभालता है। यही श्रम-विभाजन इस दायरे के एक अकेले-बनाए SaaS को बनाए रखने के लिहाज़ से टिकाऊ बनाता है। ### क्या एक अकेला इंसान सचमुच AI के साथ इतना बड़ा SaaS बना और चला सकता है? इसे बनाना अब सचमुच व्यवहार्य है — यही चौंकाने वाला हिस्सा है। बड़ी चुनौती इसे चलाना और बनाए रखना है, क्योंकि एक बड़े कोडबेस को किसी ऐसे इंसान की ज़रूरत होती है जो आर्किटेक्चर को समझता हो, भले ही ब्योरा AI ने लिखा हो। कुंजी है साफ़ विनिर्देश बनाए रखना और उन थोड़ी-सी ज़्यादा-जोखिम वाली क्रियाओं पर अडिग रहना जिन्हें इंसान को संभालना ज़रूरी है। इस तरह किया जाए, तो एक अकेले ऑपरेटर के लिए बनाए रखने लायक दायरा पहले से कहीं ज़्यादा बड़ा है। ### CourtReserve या Skedda इस्तेमाल करने के बजाय अपना खुद का क्लब सॉफ़्टवेयर क्यों बनाया? क्योंकि Pickleland चलाने से मुझे ठीक-ठीक दिखा कि मौजूदा टूल्स कहाँ कम पड़ते हैं: बुकिंग सिस्टम, रजिस्टर और मेंबरशिप एक ही सत्य के स्रोत को साझा नहीं करते, तो कुछ भी साफ़-सुथरे तरीके से मेल नहीं खाता। मुझे एक ऐसा सिस्टम चाहिए था जहाँ यह सब एक ही अंतर्निहित डेटा हो और जहाँ मेंबरों को क्लब का ब्रांड दिखे — न कि सॉफ़्टवेयर वेंडर का। यही वह खाई है जिसे पाटने के लिए Courtlines बनाया गया है। ### मैं यह कहाँ सीख सकता हूँ कि आप रोज़ाना Claude के साथ असल में कैसे काम करते हैं? मैं प्रतिस्पर्धी कारणों से विस्तृत Courtlines रणनीति निजी रखता हूँ, लेकिन मैंने ठीक वही काम करने का तरीका एक छोटे, पूरी तरह खुले प्रोजेक्ट पर दस्तावेज़ किया — Quads नाम का एक मोबाइल बोर्ड गेम। मैकेनिक्स के लिए पढ़ें [मैंने Quads, एक मोबाइल बोर्ड गेम, Claude के साथ कैसे बनाया](/how-i-built-quads-a-mobile-board-game-with-claude/), या हर चीज़ जिसे मैं शिप करता हूँ उसके पीछे की ROI सोच के लिए [मैं कैसे तय करता हूँ कि कोई ऑटोमेशन बनाने लायक है या नहीं](/ai-agent-roi-how-i-decide-whether-automation-worth-building/)। --- ## मैंने Quads, एक मोबाइल बोर्ड गेम, Claude के साथ कैसे बनाया — एक 2-घंटे के हैकाथॉन से App Store तक Source: https://alejandrorioja.com/hi/how-i-built-quads-a-mobile-board-game-with-claude/ Published: 2026-07-11 Tags: AI Agents TL;DR: Quads एक मोबाइल बोर्ड गेम है — क्लासिक अमूर्त खेल Quarto का एक साफ़-सुथरा रूप — जिसकी शुरुआत Colombia में एक दोस्त के साथ 2-घंटे के हैकाथॉन के रूप में हुई और जो ऐप स्टोर तक पहुँचा। यह Claude के साथ मेरे बनाने के तरीके का पूरी तरह खुला संस्करण है: समानांतर एजेंट worktrees, एक असली (गैर-LLM) गेम AI, ऑफ़लाइन-फ़र्स्ट डिज़ाइन, और वे खास अड़चनें जिन्होंने मेरे घंटे खर्च कराए। ## विषय-सूची _जुलाई 2026 में अपडेट किया गया।_ **संक्षेप में:** Quads एक मोबाइल बोर्ड गेम है — क्लासिक अमूर्त खेल Quarto का एक साफ़-सुथरा रूप — जिसकी शुरुआत Colombia में एक दोस्त के साथ 2-घंटे के हैकाथॉन के रूप में हुई और जो ऐप स्टोर तक पहुँचा। यह Claude के साथ मेरे बनाने के तरीके का पूरी तरह खुला संस्करण है: समानांतर एजेंट worktrees, एक असली (गैर-LLM) गेम AI, ऑफ़लाइन-फ़र्स्ट डिज़ाइन, और वे खास अड़चनें जिन्होंने मेरे घंटे खर्च कराए। **[ऑपरेटर का नज़रिया]** मैं एक कंसल्टिंग ब्रांड और Pickleland — Austin महानगर में मेरी पिकलबॉल सुविधा — में 30 से अधिक प्रोडक्शन एजेंट चलाता हूँ। मैं जो कुछ बनाता हूँ उसका ज़्यादातर गंभीर बिज़नेस सॉफ़्टवेयर है जहाँ मैं रणनीति निजी रखता हूँ। Quads इसके उलट है — एक मज़ेदार साइड प्रोजेक्ट जिसे मैं आपको ऊपर से नीचे तक दिखा सकता हूँ। अगर आप ठीक-ठीक देखना चाहते हैं कि मैं Claude के साथ कैसे काम करता हूँ, बिना कुछ भी घिसे-चमकाए, तो यही वह पोस्ट है। आप गेम को [playquads.com](https://playquads.com) पर पा सकते हैं। ## इसकी शुरुआत Colombia में एक 2-घंटे के हैकाथॉन के रूप में हुई इसकी शुरुआत लगभग शर्मनाक हद तक अनौपचारिक है। मैं Colombia की यात्रा पर था, और मैंने और एक दोस्त ने खुद को एक 2-घंटे का हैकाथॉन दिया: कुछ छोटा चुनो, उसे AI के साथ बनाओ, देखो कितनी दूर पहुँचते हैं। हम Quarto पर आ पहुँचे — एक सुंदर सा छोटा अमूर्त रणनीति खेल जो सीखने में आसान है और आश्चर्यजनक रूप से गहरा। दो घंटे बाद हमारे पास एक खेलने लायक प्रोटोटाइप था, और आइडिया इतना अच्छा था कि उसे एक लैपटॉप पर छोड़ा नहीं जा सकता था। जो एक समयबद्ध चुनौती के रूप में शुरू हुआ, वह iOS और Android पर एक असली, शिप किए गए मोबाइल ऐप में बदल गया। वही चाप — *मज़ाकिया प्रोटोटाइप से स्टोर लिस्टिंग तक* — पूरी वजह है कि मुझे लगता है यह प्रोजेक्ट लिखने लायक है। "मज़ेदार आइडिया" और "ऐसी चीज़ जिसे अजनबी डाउनलोड कर सकें" के बीच की दूरी सिमट गई है, और Quads इस बात का एक साफ़-सुथरा केस स्टडी है कि कैसे। पहले, नाम पर एक छोटा-सा घुमाव। यह गेम **Quarto** का एक फिर से किया गया इम्प्लीमेंटेशन है, जो Gigamic के स्वामित्व वाला एक ट्रेडमार्क किया गया खेल है। तो सबसे पहला गैर-कोड निर्णय यह था कि इसे कहीं भी *ऐसी जगह Quarto न कहा जाए* जहाँ कोई ग्राहक देखे। यह Quarto (मैकेनिक) से कुछ बीच के नामों से होते हुए **Quads** तक पहुँचा — एक ऐसा नाम जो इस्तेमाल करने के लिए मेरा अपना है। अगर आप किसी क्लासिक को फिर से इम्प्लीमेंट कर रहे हैं, तो किसी नाम से प्यार में पड़ने से पहले ट्रेडमार्क का सवाल सुलझा लीजिए। ## Quads असल में क्या है अनजान लोगों के लिए: Quads एक 4×4 बोर्ड पर 16 अनूठे मोहरों के साथ खेला जाता है। हर मोहरे के चार द्विआधारी गुण होते हैं — लंबा या नाटा, गहरा या हल्का, चौकोर या गोल, ठोस या खोखला — और 16 मोहरे हर संभव संयोजन को ठीक एक-एक बार कवर करते हैं। आप चार मोहरों की एक पंक्ति पूरी करके जीतते हैं जो *किसी एक* गुण को साझा करते हों। वह पेच जो इसे शानदार बनाता है: **आप वह मोहरा नहीं चुनते जो आप रखते हैं। आपका प्रतिद्वंद्वी आपको वह थमाता है।** फिर आप उसे उसका थमाते हैं। तो हर बारी एक दोहरा बंधन है — आप उस मोहरे को रखने की कोशिश कर रहे हैं जो आपको दिया गया, बिना किसी जीत का इंतज़ाम किए, जबकि देने के लिए एक ऐसा मोहरा चुन रहे हैं जो आपके प्रतिद्वंद्वी को खेल न थमा दे। यह सुंदर और सचमुच कठिन है। ऐप खेलने के चार तरीके देता है, सभी पूरी तरह ऑफ़लाइन: कंप्यूटर के ख़िलाफ़ पाँच कठिनाई स्तरों में, एक ही डिवाइस पर पास-एंड-प्ले, एक दैनिक पहेली, और एक अतुल्यकालिक "किसी दोस्त को चुनौती दो" मोड। कोई अकाउंट नहीं, कोई सर्वर नहीं, कोई लॉगिन नहीं। उस ऑफ़लाइन-फ़र्स्ट निर्णय ने काफ़ी सारी इंजीनियरिंग को दिशा दी, और यह एक बड़ी वजह है कि एक अकेले बिल्ड का करना संभव था। ## गेम लॉजिक: एक पूरा नियम-समूह जो बिट गणित से निकल आता है यह मेरा पसंदीदा हिस्सा है, क्योंकि यह उस तरह की चीज़ है जो संतोषजनक है चाहे इसे AI ने लिखा हो या नहीं। 16 में से हर मोहरा बस 0 से 15 तक का एक पूर्णांक है। चार बिट्स में से हर बिट एक गुण है। बस इतना ही — पूरा मोहरा-समूह 0–15 तक की संख्याएँ हैं, क्योंकि चार बिट्स आपको ठीक 16 संयोजन देते हैं। तब जीत का पता लगाना लगभग तुच्छ हो जाता है। चार मोहरों की किसी भी पंक्ति के लिए, आप दो चलते हुए संचायक रखते हैं: वे बिट्स जो *हर* मोहरे में `1` हैं, और वे बिट्स जो *हर* मोहरे में `0` हैं। अगर चारों के बाद कोई भी संचायक शून्येतर है, तो मोहरे कम-से-कम एक गुण पर सहमत हैं — वह एक जीत है। पूरा नियम-समूह कुछ बिटवाइज़ AND में सिमट जाता है। क्योंकि लॉजिक पूर्णांकों पर शुद्ध फ़ंक्शन है — कोई फ़्रेमवर्क नहीं, कोई UI नहीं, कोई स्टेट नहीं — यह सीधे यूनिट-टेस्टेबल है, और इसे बढ़ाना बहुत आसान है। Quads एक घर-नियम वाला रूप भी देता है जहाँ नौ 2×2 वर्ग भी जीतने वाली आकृतियाँ गिने जाते हैं, जो उसी बिट तरकीब के ऊपर दो-पंक्ति का जोड़ है। जब आप और एक AI पार्टनर मूल लॉजिक को इतना साफ़ रखते हैं, तो कोई फ़ीचर जोड़ना जोखिम के बजाय एक आनंद बन जाता है। ## AI प्रतिद्वंद्वी एक LLM नहीं है (और यही सही फ़ैसला है) यहाँ एक सिखाने वाला पल है जिसकी मुझे परवाह है: **हर "AI" को एक बड़ा भाषा मॉडल नहीं होना चाहिए।** Quads का प्रतिद्वंद्वी शुद्ध शास्त्रीय गेम AI है, और उसे होना ही चाहिए। हर बारी पर यह दो निर्णय लेता है — जो मोहरा उसे थमाया गया उसे कहाँ रखे, और कौन-सा मोहरा वापस थमाए — और कठिनाई इस बात को मापती है कि यह कितनी कड़ाई से सोचता है: - **Rookie** मूलतः बेतरतीब खेलता है और आपको जीत थमा देगा। - बीच के स्तर अनुमान-नियम जोड़ते हैं: अगर कोई तत्काल जीत मौजूद हो तो उसे ले लो, और ऐसा मोहरा देने से बचो जिससे प्रतिद्वंद्वी जीत सके, बल्कि उस मोहरे को तरजीह दो जो सबसे कम भविष्य के खतरों को हथियार देता है। - **Master और Grandmaster** एक बंधे हुए negamax खोज को चलाते हैं — असली गेम-ट्री खोज — पर एक कड़ी **नोड बजट** के साथ ताकि कोई चाल फ़ोन के मुख्य थ्रेड को कभी लटका न सके। खेल के शुरू में, जहाँ पूर्ण खोज असाध्य है, यह तेज़ अनुमान-नियमों पर लौट आता है; खेल के अंत में, जहाँ ट्री काफ़ी छोटा है, यह सचमुच खोज करता है। इससे चुराने लायक दो बातें। पहली, एक भाषा मॉडल यहाँ *बदतर* होता — धीमा, ज़्यादा महँगा, अनिश्चित, और हराया जाने लायक — पचास पंक्तियों के negamax की तुलना में। समस्या से टूल का मिलान करें। दूसरी, नोड बजट ही असली इंजीनियरिंग है: एक मोबाइल डिवाइस पर, "सही पर कभी-कभी चार सेकंड के लिए लटकने वाला" एक विफल फ़ीचर है। खोज को इतना बाँधना कि कोई चाल हमेशा तेज़ हो, भले ही कभी-कभी सर्वोत्तम न हो, एक खिलौने और एक उत्पाद के बीच का फ़र्क है। यह जानना कि *कब* किसी LLM की ओर हाथ बढ़ाना है, वही निर्णय है जो मैं हर ऑटोमेशन पर लगाता हूँ — यह [मैं कैसे तय करता हूँ कि कोई AI बिल्ड करने लायक है या नहीं](/ai-agent-roi-how-i-decide-whether-automation-worth-building/) का मूल है। ## मैं असल में Claude को कैसे चलाता हूँ: worktrees में समानांतर एजेंट अब वह हिस्सा जिसे मैं अपने बड़े उत्पादों पर निजी रखता हूँ पर यहाँ आपको पूरी तरह दिखा सकता हूँ। मैं एक बार में एक Claude सत्र के साथ नहीं बनाता। मैं **कई को समानांतर चलाता हूँ**, हर एक अपने खुद के git worktree में अपनी खुद की ब्रांच पर। एक एजेंट अंतर्राष्ट्रीयकरण जोड़ता है, दूसरा दैनिक-पहेली सिस्टम बनाता है, एक और कलरब्लाइंड मोड बनाता है, एक और ध्वनि को जोड़ता है — हर एक अपनी खुद की कार्यशील प्रति में अलग-थलग ताकि वे एक-दूसरे को न मिटा सकें, और हर एक हरा होने पर वापस मर्ज हो जाता है। Quads का git इतिहास `Merge branch 'worktree-agent-…'` कमिट्स की एक दीवार है, जो बाहर से ठीक वैसा ही दिखता है जैसा वह वर्कफ़्लो होता है। worktrees के मायने रखने की वजह सरल है: एक ही कार्यशील डायरेक्टरी को संपादित करने वाले समानांतर एजेंट तुरंत एक-दूसरे पर पैर रख देते हैं। हर एक को एक अलग-थलग चेकआउट दीजिए और आप सचमुच एक साथ चार फ़ीचर निर्माणाधीन रख सकते हैं, फिर उन्हें किसी भी अन्य ब्रांच की तरह मर्ज कर सकते हैं। यह मेरे काम करने के तरीके में सबसे ज़्यादा ताकत देने वाला अकेला बदलाव है — मैं एक बातचीत, एक फ़ीचर से बढ़कर एक छोटे बेड़े तक पहुँच गया। अगर आप उन प्रॉम्प्ट्स के पीछे का अनुशासन चाहते हैं जिन पर वे एजेंट चलते हैं, तो यह वही है जिसका वर्णन मैं [प्रोडक्शन में विफल न होने वाले AI एजेंट सिस्टम प्रॉम्प्ट कैसे लिखें](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/) में करता हूँ: ताकत साफ़, अद्यतन विनिर्देशों में है, चतुर शब्दावली में नहीं। ## वह अड़चन जिसने मेरा एक घंटा खर्च कराया (ताकि यह आपका न कराए) हर प्रोजेक्ट आपको एक बेवकूफ़ाना, महँगा सबक सिखाता है। Quads पर यह था: **प्रीव्यू टूल हमेशा वह ब्रांच नहीं दिखाता जो आपको लगता है कि वह दिखा रहा है।** जब आप कई एजेंट को कई worktrees में चलाते हैं और उनके काम का प्रीव्यू करते हैं, तो प्रीव्यू एक *अलग* डायरेक्टरी से लॉन्च हो सकता है, उससे जिसमें आपका मौजूदा सत्र है — तो आप ऐप का स्क्रीनशॉट लेते हैं, अपना कोई बदलाव नहीं देखते, और उस "गायब" UI को डीबग करना शुरू कर देते हैं जो कभी गायब था ही नहीं। फ़ीचर ठीक था; प्रीव्यू गलत चेकआउट पर इशारा कर रहा था। इससे पहले कि मैं समझ पाता कि क्या हो रहा है, मेरा असली समय बर्बाद हुआ, और मैंने इसे प्रोजेक्ट के अपने नोट्स में लिख डाला ताकि भविष्य का मैं (और कोई भी एजेंट जिसे मैं यह रेपो सौंपूँ) प्रेत बग डीबग करने से *पहले* प्रीव्यू लक्ष्य की जाँच कर ले। इससे जुड़ा जाल: वह कॉन्फ़िग फ़ाइल जो उन प्रीव्यू को परिभाषित करती है, समानांतर सत्रों में साझा होती है, तो एक साथ उसे संपादित करने वाले दो एजेंट चुपचाप एक-दूसरे की प्रविष्टियों को अधिलेखित कर सकते हैं। अगर आप एक बेड़ा चलाने जा रहे हैं, तो साझा कॉन्फ़िग को एक विवादित संसाधन की तरह मानिए — यह आपको ठीक एक बार काटेगी, और फिर कभी नहीं अगर आप सबक लिख लें। वह आदत — हर मुश्किल से जीती गई अड़चन को एक टिकाऊ फ़ाइल में पकड़ लेना जिसे अगला सत्र पढ़ेगा — किसी भी पैमाने पर AI के साथ बनाने की चुपचाप रीढ़ है। सत्रों के बीच संदर्भ भाप बनकर उड़ जाता है; लिखे हुए सबक नहीं उड़ते। ## वे ऑफ़लाइन-फ़र्स्ट तरकीबें जिन पर मुझे गर्व है क्योंकि Quads का कोई बैकएंड नहीं है, कुछ समस्याओं को चतुर, बिना-सर्वर के जवाब चाहिए थे: - **दैनिक पहेली** स्थानीय दिन के वर्ष-दिवस से नियतात्मक रूप से चुनी जाती है, ताकि दुनिया भर का हर खिलाड़ी शून्य सर्वर समन्वय के साथ वही पहेली पाए। (बोनस सबक: मैंने शिप किया, फिर तुरंत उस तिथि गणित में एक डेलाइट-सेविंग off-by-one ठीक किया। तिथियाँ हमेशा दिखने से ज़्यादा कठिन होती हैं।) - **"किसी दोस्त को चुनौती दो"** एक पहेली को एक छोटे टेक्स्ट कोड में एन्कोड करता है — कुछ ऐसा `QC1-01-03-3` — जिसे एक चेकसम से सुरक्षित किया गया है ताकि एक टाइपो एक वैध-पर-गलत चुनौती न बना दे। आपका दोस्त इसे ऐप की अपनी प्रति में टाइप करता है और ठीक वही स्थिति खेलता है, पूरी तरह ऑफ़लाइन। कोई अकाउंट नहीं, कोई मैचमेकिंग नहीं, कोई सर्वर नहीं। - **रिच लिंक प्रीव्यू** वह एक जगह है जहाँ मैंने थोड़ा-सा सर्वर कोड इस्तेमाल किया। जब आप कोई चुनौती लिंक साझा करते हैं, तो एक अकेला Cloudflare Pages Function प्रति-कोड Open Graph टैग रेंडर करता है ताकि लिंक iMessage या WhatsApp में अच्छी तरह खुले। सोशल क्रॉलर JavaScript नहीं चलाते, तो एक क्लाइंट-रेंडर किया गया प्रीव्यू हर लिंक के लिए एक जैसा दिखता — एक छोटा फ़ंक्शन इसे एक असली बैकएंड की ज़रूरत के बिना ठीक कर देता है। इनमें से कोई भी कठिन नहीं है एक बार जब आप इन्हें देख लें, पर हर एक ऐसी जगह है जहाँ आलसी जवाब है "एक सर्वर और एक डेटाबेस खड़ा कर दो," और बेहतर जवाब है "वह चतुर ऑफ़लाइन चीज़ करो।" बैकएंड को पूरी तरह टालना ही वजह है कि एक अकेला इंसान इसे शिप और बनाए रख सका। ## हैकाथॉन से स्टोर लिस्टिंग तक आखिरी दौर — वह हिस्सा जिसके बारे में कोई आपको किसी "2-घंटे के प्रोजेक्ट" के बारे में नहीं बताता — "यह मेरे फ़ोन पर काम करता है" और "अजनबी इसे डाउनलोड कर सकते हैं" के बीच का सब कुछ है। एक ही झटके में आठ भाषाओं में अंतर्राष्ट्रीयकरण। स्टोर कॉपी जो कभी ट्रेडमार्क किए गए नाम का इस्तेमाल न करे। ऐप-स्टोर बिल्ड टूलिंग, वर्ज़निंग, और वे प्लेटफ़ॉर्म-विशिष्ट अनुमति-सफ़ाई जो एक स्टोर समीक्षा को आपको लौटाने से रोकती हैं। यह बेरौनक है, और यहीं बहुत सारे साइड प्रोजेक्ट चुपचाप दम तोड़ देते हैं। इसे Claude के साथ करने से चेकलिस्ट छोटी नहीं हुई, पर इसने हर मद को इतना सस्ता बना दिया कि मैंने असल में इसे पूरा किया। यही Quads की असली कहानी है: यह नहीं कि AI ने एक बोर्ड गेम लिखा — बहुत सारे लोग एक को प्रोटोटाइप कर सकते हैं — बल्कि यह कि इसने *आखिरी मील* की लागत को इतना घटा दिया कि एक हैकाथॉन का मज़ाक एक शिप किया गया उत्पाद बन गया। अगर आपके पास कोई छोटा आइडिया है जिस पर आप बैठे हुए हैं, तो यही मेरी पूरी बात है। 2-घंटे वाला संस्करण शुरू कीजिए। आप हैरान होंगे कि समापन रेखा कितनी पास आ गई है। और अगर आप देखना चाहते हैं कि यही काम करने का तरीका पैमाने पर कितनी ऊँचाई तक जाता है, तो मैं इसे एक पूरे मल्टी-टेनेंट SaaS तक ले गया — [मैंने Courtlines, एक क्लब-मैनेजमेंट प्लेटफ़ॉर्म, Claude के साथ कैसे बनाया](/how-i-built-courtlines-a-club-management-saas-with-claude/)। Quads को [playquads.com](https://playquads.com) पर खेलिए। ## अक्सर पूछे जाने वाले सवाल ### Quads क्या है? Quads iOS और Android के लिए एक मोबाइल बोर्ड गेम है — क्लासिक अमूर्त रणनीति खेल Quarto का एक साफ़-सुथरा फिर से किया गया इम्प्लीमेंटेशन। आप एक 4×4 बोर्ड पर 16 अनूठे मोहरों के साथ खेलते हैं, और पेच यह है कि आपका प्रतिद्वंद्वी वह मोहरा चुनता है जो आपको रखना है। यह खेलने के लिए मुफ़्त है, जिसमें एकल, पास-एंड-प्ले, एक दैनिक पहेली और अतुल्यकालिक चुनौतियों के मोड हैं। इसे [playquads.com](https://playquads.com) पर पाइए। ### क्या Claude ने पूरा गेम लिखा? Claude ने अधिकांश कोड लिखा, उस डिज़ाइन और निर्णयों से काम करते हुए जो मेरे हैं। मैंने कई Claude सत्र समानांतर चलाए, हर एक अपने खुद के git worktree में, अलग-अलग फ़ीचर बनाते हुए जिन्हें मैंने आपस में मर्ज किया। गेम लॉजिक, AI प्रतिद्वंद्वी, अंतर्राष्ट्रीयकरण, ध्वनियाँ और पहेली सिस्टम बड़े पैमाने पर इसी तरह बनाए गए और मेरे द्वारा समीक्षित हुए। ### क्या इन-गेम AI प्रतिद्वंद्वी किसी LLM से चलता है? नहीं — और जानबूझकर ऐसा है। प्रतिद्वंद्वी शास्त्रीय गेम AI इस्तेमाल करता है: निचली कठिनाइयों पर अनुमान-नियम और शीर्ष स्तरों पर एक बंधी हुई negamax खोज, एक कड़ी नोड बजट के साथ ताकि कोई चाल डिवाइस को कभी न लटकाए। एक भाषा मॉडल इस काम के लिए धीमा, ज़्यादा महँगा और कमज़ोर होता। समस्या के लिए सही किस्म का AI चुनना हमेशा सबसे बड़े मॉडल की ओर हाथ बढ़ाने से ज़्यादा मायने रखता है। ### Quads को बनाने में कितना समय लगा? पहला खेलने लायक प्रोटोटाइप Colombia की एक यात्रा पर एक दोस्त के साथ 2-घंटे के हैकाथॉन से निकला। उस प्रोटोटाइप को दोनों ऐप स्टोर पर एक निखरे, शिप करने लायक ऐप में बदलना — अंतर्राष्ट्रीयकरण, एक असली AI प्रतिद्वंद्वी, ऑफ़लाइन चुनौतियों और स्टोर अनुपालन के साथ — में काफ़ी ज़्यादा समय लगा, पर हर अलग-अलग कदम AI के साथ इतना सस्ता था कि प्रोजेक्ट असल में समापन रेखा तक पहुँच गया। ### Quads को Claude के साथ बनाने का सबसे बड़ा सबक क्या है? दो बातें। पहली, एजेंट को अलग-थलग git worktrees में चलाइए ताकि आप कई फ़ीचर समानांतर बना सकें बिना उन्हें एक-दूसरे को मिटाए। दूसरी, हर अड़चन को एक टिकाऊ फ़ाइल में लिख डालिए जिसे अगला सत्र पढ़ेगा — सत्रों के बीच संदर्भ भाप बनकर उड़ जाता है, पर लिखे हुए सबक जुड़ते जाते हैं। इस काम करने के तरीके की बड़ी तस्वीर के लिए, देखें [मैंने Courtlines को Claude के साथ कैसे बनाया](/how-i-built-courtlines-a-club-management-saas-with-claude/)। --- ## AI एजेंट सिस्टम प्रॉम्प्ट कैसे लिखें जो प्रोडक्शन में फेल न हों Source: https://alejandrorioja.com/hi/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/ Published: 2026-07-11 Tags: AI Agents TL;DR: प्रोडक्शन सिस्टम प्रॉम्प्ट में पाँच परतें होती हैं: पहचान (एजेंट कौन है और क्या नहीं कर सकता), संदर्भ (पर्यावरण के बारे में क्या जानता है), कार्य (सफलता कदम-दर-कदम कैसी दिखती है), आउटपुट फॉर्मेट (सबसे कम आंका गया लेयर), और एज केस (जब इनपुट गलत हो तो क्या करें)। अधिकांश प्रॉम्प्ट इसलिए फेल होते हैं क्योंकि वे लेयर 4 और 5 छोड़ देते हैं। आउटपुट फॉर्मेट पहले लिखें — यह आपको वास्तव में जो चाहिए उसके बारे में सटीक होने के लिए मजबूर करता है। ## विषय सूची _जुलाई 2026 में अपडेट किया गया।_ **TL;DR:** प्रोडक्शन सिस्टम प्रॉम्प्ट में पाँच परतें होती हैं: पहचान (एजेंट कौन है और क्या नहीं कर सकता), संदर्भ (पर्यावरण के बारे में क्या जानता है), कार्य (सफलता कदम-दर-कदम कैसी दिखती है), आउटपुट फॉर्मेट (सबसे कम आंका गया लेयर), और एज केस (जब इनपुट गलत हो तो क्या करें)। अधिकांश प्रॉम्प्ट इसलिए फेल होते हैं क्योंकि वे लेयर 4 और 5 छोड़ देते हैं। आउटपुट फॉर्मेट पहले लिखें — यह आपको वास्तव में जो चाहिए उसके बारे में सटीक होने के लिए मजबूर करता है। **[ऑपरेटर का दृष्टिकोण]** मैं अपने कंसल्टिंग ब्रांड और Pickleland — टेक्सास के Pflugerville में एक पिकलबॉल सुविधा — के लिए प्रोडक्शन में 30 से अधिक AI एजेंट चला रहा हूँ। मैंने जितने सिस्टम प्रॉम्प्ट लिखे हैं उससे अधिक फिर से लिखे हैं — आमतौर पर इसलिए कि पहला वर्शन टेस्ट में अच्छा लगा और फिर प्रोडक्शन में चुपचाप खराब होता गया। यह वो है जो मैंने ऐसे प्रॉम्प्ट लिखने के बारे में सीखा जो टिके रहते हैं। ## वह सिस्टम प्रॉम्प्ट समस्या जिसे कोई स्वीकार नहीं करता अधिकांश एजेंट सिस्टम प्रॉम्प्ट लगभग 20 मिनट में लिखे जाते हैं, दो या तीन उदाहरणों पर परीक्षण किए जाते हैं, और फिर कभी छुआ नहीं जाता। मॉडल डिप्लॉय हो जाता है। कुछ समय के लिए काम करता है। फिर कुछ बदलता है — इनपुट अधिक गड़बड़ हो जाते हैं, मॉडल अपडेट होता है, एक नया एज केस सामने आता है — और एजेंट कचरा उत्पन्न करना शुरू कर देता है। चुपचाप। पैमाने पर। समस्या यह नहीं है कि मूल प्रॉम्प्ट खराब था। समस्या यह है कि अधिकांश प्रॉम्प्ट हैप्पी पाथ प्रदर्शित करने के लिए लिखे जाते हैं। ## प्रोडक्शन सिस्टम प्रॉम्प्ट की पाँच परतें मैं हर सिस्टम प्रॉम्प्ट को पाँच परतों में सोचता हूँ। उन्हें इस क्रम में नहीं होना चाहिए — लेकिन सभी मौजूद होने चाहिए। ### परत 1: पहचान पहचान मॉडल को बताती है कि वह कौन है और उसकी परिचालन बाधाएँ क्या हैं। रोलप्ले कैरेक्टर नहीं — इस एजेंट के क्या करने और न करने की कार्यात्मक परिभाषा। एक मजबूत पहचान परत तीन सवालों का जवाब देती है: - यह एजेंट किस चीज़ के लिए जिम्मेदार है? - यह स्पष्ट रूप से किसके लिए जिम्मेदार **नहीं** है (और इसे एस्केलेट या अस्वीकार करना चाहिए)? - यह किन मानकों को बनाए रखता है? स्पष्ट "नहीं करने" का दायरा वह हिस्सा है जिसे अधिकांश ऑपरेटर छोड़ देते हैं। ### परत 2: संदर्भ संदर्भ वह है जो एजेंट अपने पर्यावरण के बारे में जानता है जो यूज़र के संदेश में नहीं है। इसमें वर्तमान तारीख और समय (गतिशील रूप से इंजेक्ट करें — मॉडल के आंतरिक समय की भावना पर कभी भरोसा न करें), बाहरी सिस्टम से प्रासंगिक स्थिति, और व्यावसायिक नियम शामिल हैं। मान मत लो। इंजेक्ट करो। ### परत 3: कार्य कार्य परत वर्णन करती है कि एजेंट कदम-दर-कदम क्या करता है। "ग्राहकों की मदद करें" नहीं — वास्तविक निर्णय प्रवाह। इसे निर्देश के रूप में नहीं, फ्लोचार्ट के रूप में लिखें। ### परत 4: आउटपुट फॉर्मेट यह सबसे कम आंका गया लेयर है, और वह जो साइलेंट फेलियर के लिए सबसे अधिक जिम्मेदार है। आउटपुट फॉर्मेट पहले लिखें। संरचित आउटपुट के लिए सटीक स्कीमा निर्दिष्ट करें। गद्य आउटपुट के लिए संरचना, लंबाई और टोन बाधाएँ निर्दिष्ट करें। उच्च-जोखिम वाले एजेंट्स के लिए, मैं परिभाषित JSON स्कीमा के साथ [Claude](/recommends/claude) का संरचित आउटपुट उपयोग करता हूँ। ### परत 5: एज केस एज केस परत का जवाब: जब इनपुट अस्पष्ट, अपूर्ण, गलत भाषा में, शत्रुतापूर्ण, या स्पष्ट रूप से गलत हो तो एजेंट क्या करता है? प्रत्येक एज केस के लिए मॉडल को एक स्पष्ट प्रतिक्रिया पथ दें। ## मैं समय के साथ सिस्टम प्रॉम्प्ट कैसे बनाए रखता हूँ प्रोडक्शन सिस्टम प्रॉम्प्ट एक जीवित दस्तावेज है: 1. **साप्ताहिक स्पॉट-चेक।** मैं प्रत्येक उच्च-जोखिम वाले एजेंट के पाँच से दस यादृच्छिक आउटपुट की समीक्षा करता हूँ। 2. **मॉडल अपडेट के बाद समीक्षा।** जब भी बेस मॉडल संस्करण बदलता है, मैं अपने [मूल्यांकन ढांचे](/how-i-measure-whether-an-ai-agent-is-actually-working/) के पूर्ण गोल्डन सेट के विरुद्ध एजेंट चलाता हूँ। 3. **एज केस लॉग।** मैं उन इनपुट का चालू लॉग रखता हूँ जिन्हें एजेंट ने खराब तरीके से संभाला। 4. **प्रॉम्प्ट वर्शनिंग।** हर महत्वपूर्ण बदलाव को एक वर्शन कमेंट मिलता है। ## अक्सर पूछे जाने वाले सवाल ### प्रोडक्शन सिस्टम प्रॉम्प्ट कितना लंबा होना चाहिए? सभी पाँच परतों को कवर करने के लिए पर्याप्त लंबा। दो मिनट में पढ़ने और ड्रिफ्ट ढूंढने के लिए पर्याप्त छोटा। मेरे अधिकांश एजेंट्स के लिए यह 200-600 शब्द है। ### एक लंबे प्रॉम्प्ट के बजाय कई एजेंट्स में विभाजित कब करना चाहिए? जब कार्य के दो या अधिक अलग-अलग मोड हों जिनके लिए अलग संदर्भ, अलग आउटपुट फॉर्मेट, या अलग त्रुटि हैंडलिंग की आवश्यकता हो। ### टेस्ट में काम करने वाला प्रॉम्प्ट प्रोडक्शन में फेल होने का सबसे सामान्य कारण क्या है? टेस्ट इनपुट प्रोडक्शन वितरण का प्रतिनिधित्व नहीं कर रहे थे। कल्पना किए गए इनपुट से नहीं, वास्तविक प्रोडक्शन ट्रैफिक से टेस्ट सेट बनाएँ। --- ## AI एजेंट ROI: मैं कैसे तय करता हूं कि ऑटोमेशन बनाना उचित है या नहीं Source: https://alejandrorioja.com/hi/ai-agent-roi-how-i-decide-whether-automation-worth-building/ Published: 2026-07-09 Tags: AI Agents, Operations TL;DR: किसी भी AI एजेंट को बनाने से पहले, मैं चार-भाग ROI जांच करता हूं: मैन्युअल लागत का मात्रीकरण, निर्माण लागत का अनुमान, परिचालन लागत का अनुमान, और रखरखाव कर जोड़ना। परिणाम एक पेबैक अवधि है। यदि किसी गैर-रणनीतिक कार्य के लिए छह महीने से अधिक है, तो मैं उसे छोड़ देता हूं। अधिकांश एजेंट विचार इस परीक्षण में विफल होते हैं — और यही बात महत्वपूर्ण है। ## विषय सूची _जुलाई 2026 अपडेट।_ **TL;DR:** किसी भी AI एजेंट को बनाने से पहले, मैं चार-भाग ROI जांच करता हूं: मैन्युअल लागत का मात्रीकरण, निर्माण लागत का अनुमान, परिचालन लागत का अनुमान, और रखरखाव कर जोड़ना। परिणाम एक पेबैक अवधि है। यदि किसी गैर-रणनीतिक कार्य के लिए छह महीने से अधिक है, तो मैं उसे छोड़ देता हूं। गलत ऑटोमेशन बनाना कुछ भी न बनाने से बुरा है। **[ऑपरेटर का दृष्टिकोण]** मैं एक कंसल्टिंग ब्रांड और Pickleland, टेक्सास के प्फ्लुगर्विल में एक पिकलबॉल सुविधा में 30 से अधिक AI एजेंट प्रोडक्शन में चलाता हूं। मैंने जितने एजेंट लॉन्च किए उतने ही छोड़े भी हैं। जो छोड़े गए वे बुरे विचार नहीं थे — वे अच्छे विचार थे जो गणित में विफल रहे। ## वह प्रश्न जो कोई पहले नहीं पूछता 2026 में हर कोई पूछता है "मैं इसे कैसे स्वचालित करूं?" बेहतर प्रश्न है "क्या मुझे इसे स्वचालित करना चाहिए, और यह कब वापस मिलेगा?" एक AI एजेंट मुफ्त नहीं है। इसे बनाने में समय लगता है, चलाने में पैसा लगता है, और बनाए रखने में निरंतर ध्यान लगता है। यदि ऑटोमेशन मैन्युअल विकल्प की तुलना में उन लागतों को तेजी से वापस नहीं करता है, तो आपने अपने ऑपरेशन को अधिक जटिल और महंगा बनाया है — अधिक कुशल नहीं। ## चरण 1: मैन्युअल बेसलाइन का मात्रीकरण पहली संख्या यह है कि वर्तमान प्रक्रिया प्रति वर्ष कितना खर्च करती है। ``` वार्षिक_मैन्युअल_लागत = (प्रति_इंस्टेंस_समय × घंटे_की_दर × वार्षिक_आवृत्ति) + वार्षिक_त्रुटि_लागत ``` **प्रति इंस्टेंस समय** वास्तविक घड़ी का समय है जो कोई खर्च करता है। **घंटे की दर** काम करने वाले व्यक्ति की पूरी लागत है। यदि यह आपका अपना समय है, तो शून्य नहीं बल्कि अपनी कंसल्टिंग या अवसर लागत दर का उपयोग करें। **वार्षिक आवृत्ति** यह है कि यह कार्य वास्तव में कितनी बार चलता है। **त्रुटि लागत** वह है जिसे अधिकांश लोग भूल जाते हैं। Pickleland का वास्तविक उदाहरण: Facebook इवेंट प्रमोशन मैन्युअल रूप से भेजने में प्रति सप्ताह 45 मिनट लगते थे। मेरी अवसर लागत दर पर, यह $45/सप्ताह या $2,340/वर्ष है। यही बेसलाइन है। ## चरण 2: निर्माण लागत का ईमानदारी से अनुमान निर्माण लागत लगभग हमेशा कम आंकी जाती है। ``` निर्माण_लागत = (विकास_घंटे × घंटे_की_दर) + टूल_सेटअप_लागत + परीक्षण_और_पुनरावृत्ति_घंटे × घंटे_की_दर + एकीकरण_डीबगिंग_घंटे × घंटे_की_दर ``` Pickleland इवेंट प्रमोटर के लिए: मैंने निर्माण के लिए 6 घंटे, परीक्षण और ट्यूनिंग के लिए 3 घंटे, एकीकरण डीबगिंग के लिए 2 घंटे का अनुमान लगाया। मेरी दर पर, यह निर्माण लागत में $990 है। ## चरण 3: परिचालन लागत का अनुमान ``` वार्षिक_परिचालन_लागत = (वार्षिक_API_कॉल × प्रति_कॉल_लागत) + वार्षिक_इन्फ्रास्ट्रक्चर_लागत + मानव_समीक्षा_घंटे × घंटे_की_दर ``` **API कॉल** Claude/LLM कॉल और तृतीय-पक्ष API हैं। वास्तविक टोकन गिनती के आधार पर गणना करें। **इन्फ्रास्ट्रक्चर** Cloudflare Workers + Queues पर मध्यम मात्रा के लिए अक्सर $5/माह से कम है। **मानव समीक्षा** वह लागत है जिसे लोग सबसे अधिक भूलते हैं। Pickleland प्रमोटर के लिए: वार्षिक ~1,000 Claude API कॉल। मानव समीक्षा ~$800/वर्ष। कुल परिचालन लागत: ~$810/वर्ष। ## चरण 4: रखरखाव कर लागू करना यह हर एजेंट ROI गणना में सबसे कम आंका गया कारक है। एजेंट टूट जाते हैं। मैं निर्माण लागत का 20% प्रति वर्ष रखरखाव कर के रूप में लागू करता हूं। ``` वार्षिक_रखरखाव_लागत = निर्माण_लागत × रखरखाव_दर ``` Pickleland प्रमोटर के लिए: $990 × 20% = $198/वर्ष। ## वापसी फॉर्मूला ``` वार्षिक_शुद्ध_बचत = वार्षिक_मैन्युअल_लागत − वार्षिक_परिचालन_लागत − वार्षिक_रखरखाव_लागत पेबैक_महीने = (निर्माण_लागत ÷ वार्षिक_शुद्ध_बचत) × 12 ``` Pickleland इवेंट प्रमोटर के लिए: - मैन्युअल लागत: $2,340/वर्ष - परिचालन लागत: $810/वर्ष - रखरखाव: $198/वर्ष - वार्षिक शुद्ध बचत: $1,332/वर्ष - निर्माण लागत: $990 - **पेबैक: 8.9 महीने** यह सीमारेखा है। गैर-रणनीतिक ऑटोमेशन के लिए मेरी सीमा छह महीने है। ## मेरी पेबैक सीमाएं - **3 महीने से कम:** तुरंत बनाएं। ये दुर्लभ हैं। - **3–6 महीने:** दृढ़ हां। ये ऐसे ऑटोमेशन हैं जो चक्रवृद्धि होते हैं। - **6–12 महीने:** यदि रणनीतिक रूप से महत्वपूर्ण हो तो बनाएं। अन्यथा छोड़ें। - **12 महीने से अधिक:** लगभग हमेशा छोड़ें। ## कब ऑटोमेट नहीं करना चाहिए सबसे महंगी गलती जो मैं टीमों को करते देखता हूं वह है अस्थिर प्रक्रियाओं को स्वचालित करना। ऑटोमेट करने से पहले पूछें: क्या यह प्रक्रिया कम से कम तीन महीने से स्थिर रही है? दूसरी गलती कम-आवृत्ति उच्च-दांव वाले कार्यों को स्वचालित करना है। तीसरा: बातचीत से बचने के लिए ऑटोमेट न करें। ## इन ऑटोमेशन को चलाने वाला एजेंट स्टैक प्रोडक्शन में मेरे अधिकांश ऑटोमेशन Cloudflare Workers + Queues पर LLM के रूप में [Claude](/recommends/claude) के साथ हैं। ## अक्सर पूछे जाने वाले प्रश्न ### अपने समय के लिए किस घंटे की दर का उपयोग करना चाहिए? अपनी अवसर लागत का उपयोग करें। शून्य का उपयोग न करें। ### कुछ भी बनाने से पहले Claude API लागत का अनुमान कैसे लगाएं? अपने लक्षित मॉडल के साथ वास्तविक इनपुट के प्रतिनिधि नमूने के साथ Claude के टोकन-काउंटिंग एंडपॉइंट का उपयोग करें। ### "रणनीतिक" ऑटोमेशन क्या है? एक रणनीतिक ऑटोमेशन (1) ग्राहकों को सीधे इस तरह से सेवा करता है जो प्रतिधारण या रूपांतरण को प्रभावित करता है, (2) ऑपरेशन का एक पैमाना सक्षम करता है जो मैन्युअल रूप से असंभव होगा, या (3) बेहतर निर्णयों को संचालित करने वाला डेटा उत्पन्न करता है। ### क्या मुझे एजेंट की निगरानी में बिताए समय को गिनना चाहिए? हां। निगरानी समय एक वास्तविक चल रही लागत है। ### यदि कार्य वह है जिसे मैं बस करना नफरत करता हूं? किसी कार्य से नफरत करने की वास्तविक लागत होती है। मैं उन कार्यों के लिए लंबी पेबैक अवधि स्वीकार करूंगा जिन्हें मैं वास्तव में नापसंद करता हूं, लेकिन यह खुला चेक नहीं है। --- ## फाउंडर-लेड सेल्स: टीम बढ़ाने से पहले सही खरीदार को कैसे खोजें और उस तक कैसे पहुँचें Source: https://alejandrorioja.com/hi/founder-led-sales-how-to-reach-decision-makers/ Published: 2026-07-09 Tags: Entrepreneurship, Growth, Marketing TL;DR: सेल्स टीम रखने से पहले आपको यह साबित करना होता है कि आप बेच सकते हैं। फाउंडर-लेड सेल्स तीन चीज़ों पर टिकी है: उस एक व्यक्ति की पहचान करें जो सचमुच हाँ कह सकता है, इतनी रिसर्च करें कि जवाब मिलने का हक बने, और अपने चैनलों को क्रम में लगाएँ — पूछने के लिए email, समय-संवेदनशील फ़ॉलो-अप के लिए फ़ोन, और गर्म परिचय के लिए LinkedIn। ज़्यादातर सौदे इसलिए नहीं रुकते कि पिच कमज़ोर थी, बल्कि इसलिए कि वह गलत इनबॉक्स में गिर गई। इसे किनारे से पार कर लीजिए और आप ऐसी मीटिंगें बुक कर लेंगे जो कोई तनख़्वाह वाला रेप नहीं कर पाता। ## विषय-सूची _जुलाई 2026 में प्रकाशित।_ **संक्षेप में:** सेल्स टीम रखने से पहले आपको यह साबित करना होता है कि आप बेच सकते हैं। फाउंडर-लेड सेल्स तीन चीज़ों पर टिकी है: उस एक व्यक्ति की पहचान करें जो सचमुच हाँ कह सकता है, इतनी रिसर्च करें कि जवाब मिलने का हक बने, और अपने चैनलों को क्रम में लगाएँ — पूछने के लिए email, समय-संवेदनशील फ़ॉलो-अप के लिए फ़ोन, और गर्म परिचय के लिए LinkedIn। ज़्यादातर सौदे इसलिए नहीं रुकते कि पिच कमज़ोर थी, बल्कि इसलिए कि वह गलत इनबॉक्स में गिर गई। इसे किनारे से पार कर लीजिए और आप ऐसी मीटिंगें बुक कर लेंगे जो कोई तनख़्वाह वाला रेप नहीं कर पाता। **[ऑपरेटर की राय]** हर उस फाउंडर को जिसे मैंने असली कंपनी खड़ी करते देखा है, उसने पहले सौदे खुद बेचे — शुरू में आम तौर पर बुरी तरह, फिर अच्छे से। इसका कोई शॉर्टकट नहीं है। आप ऐसा सेल्स मोशन किसी और को नहीं सौंप सकते जिसे आपने खुद कभी चलाया ही नहीं, क्योंकि आपको अभी तक पता ही नहीं कि आपका खरीदार असल में किस चीज़ पर प्रतिक्रिया देता है। यह वही प्रक्रिया है जो मैं इस्तेमाल करता हूँ और फाउंडरों को सिखाता हूँ: सही व्यक्ति कैसे खोजें, जवाब पाने लायक बस उतनी रिसर्च कैसे करें, और अजनबियों पर छिड़काव किए बिना या स्क्रैपिंग टूल खरीदे बिना उन तक कैसे पहुँचें। ## फाउंडरों को पहले क्यों बेचना पड़ता है आप ऐसा मोशन नहीं सौंप सकते जिसे आपने खुद कभी चलाया ही नहीं। अगर आप कुछ सौदे खुद बंद करने से पहले ही कोई सेल्सपर्सन रख लेते हैं, तो आप किसी प्रक्रिया को स्केल नहीं कर रहे — आप उसकी खोज को आउटसोर्स कर रहे हैं, और वह सीखने के लिए तनख़्वाह दे रहे हैं जो आपको मुफ़्त में सीखना चाहिए था। फाउंडर-लेड सेल्स कोई ऐसा दौर नहीं जिसे आप तब तक झेलते हैं जब तक कि आप एक रेप का ख़र्च नहीं उठा सकते। यह वह तरीका है जिससे आप ठीक-ठीक वे शब्द सीखते हैं जो आपका खरीदार इस्तेमाल करता है, वह आपत्ति जो दस में से नौ सौदे मार देती है, और वह एक पंक्ति जो किसी को झुककर सुनने पर मजबूर कर देती है। यही ज्ञान आगे चलकर स्क्रिप्ट, प्लेबुक और भर्ती का मानक बनता है। इसे छोड़िए और आपका पहला सेल्स कर्मचारी बस एक अंदाज़े को विरासत में पाता है। अच्छी बात यह है: एक फाउंडर के नाते आपके पास एक ऐसा अनुचित फ़ायदा है जो किसी रेप के पास कभी नहीं होगा। आपने वह चीज़ बनाई है। आप कोई भी सवाल जवाब दे सकते हैं, कॉल पर रोडमैप मोड़ सकते हैं, और ऐसी विश्वसनीयता के साथ बात कर सकते हैं जिसका दिखावा कोई कोटा ढोने वाला अजनबी नहीं कर सकता। आपका काम है सही व्यक्ति के सामने इतनी बार पहुँचना कि वह फ़ायदा मायने रखे। ## चरण 1: उस एक व्यक्ति की पहचान करें जो हाँ कह सकता है आउटरीच के विफल होने का सबसे आम कारण यही है कि वह गलत भूमिका तक पहुँचती है। आपका संदेश ठुकराया नहीं जाता — वह ऐसे किसी के पास पहुँचता है जिसे उस पर कार्रवाई का अधिकार कभी था ही नहीं, और वह चुपचाप दम तोड़ देता है। ज़्यादातर कंपनियों में, आपके और सौदे के बीच तीन तरह के लोग बैठते हैं: - **चैंपियन** — जो उस दर्द को महसूस करता है जिसे आपका उत्पाद हल करता है और उसे ठीक करवाना चाहता है। अक्सर वरिष्ठ नहीं होता, पर वही आपका पक्ष अंदरूनी तौर पर आगे बढ़ाएगा। - **इकोनॉमिक बायर** — जो बजट नियंत्रित करता है और ख़र्च मंज़ूर कर सकता है। आख़िरकार यही व्यक्ति हाँ कहता है। - **ब्लॉकर / गेटकीपर** — प्रोक्योरमेंट, कोई EA, IT, या कोई शक्की सहायक जिसका काम शोर को छानना है। आपका दुश्मन नहीं, पर आपका निशाना भी नहीं। किसी से संपर्क करने से पहले तय कर लें कि आप किसकी ओर निशाना लगा रहे हैं और क्यों। पहली मीटिंग के लिए आमतौर पर आपको चैंपियन या इकोनॉमिक बायर चाहिए — कभी कोई भी ऐसा कर्मचारी नहीं जिसका नाम आपको इसलिए मिला कि वह आसानी से मिल गया। गलत व्यक्ति तक पहुँचना सिर्फ़ संदेश बर्बाद नहीं करता; यह पूरे अकाउंट को जला सकता है, क्योंकि अब आपका नाम एक गलत निशाने वाली ठंडी पिच से जुड़ चुका है। अगर आप यह नहीं बता सकते कि कोई ख़ास व्यक्ति सही संपर्क क्यों है, तो आप अभी संपर्क करने के लिए तैयार नहीं हैं। ## चरण 2: जवाब पाने लायक इतनी रिसर्च करें कॉन्टैक्ट रिसर्च का मतलब "कोई email पता खोजना" नहीं है। इसका मतलब है इतना संदर्भ जुटाना कि आपका संदेश सिर्फ़ उसी एक व्यक्ति के लिए ही लिखा जा सकता था। ऐसे इनबॉक्स में जहाँ हफ़्ते में पचास पिच आती हों, जवाब यही चीज़ दिलाती है। कुछ भी ड्राफ़्ट करने से पहले, यह जान लें: 1. **ट्रिगर** — अभी क्यों? कोई फ़ंडिंग राउंड, किसी प्रासंगिक भूमिका में नई भर्ती, कोई प्रोडक्ट लॉन्च, कोई सार्वजनिक शिकायत, कोई जॉब पोस्टिंग जो किसी कमी को उजागर करती है। एक ऐसा कारण जिससे टाइमिंग *उनके* लिए मायने रखे। 2. **विशिष्ट दर्द** — "आप जैसी कंपनियाँ X से जूझती हैं" नहीं, बल्कि इसका सबूत कि *यह* कंपनी जूझती है। 3. **जोड़ने वाली कड़ी** — कोई साझा संपर्क, उनके क्षेत्र का कोई ग्राहक, कुछ ऐसा जो आपने देखा हो और जिसका दिखावा कोई टेम्पलेट नहीं कर सकता। सार्वजनिक स्रोत आपको इसका ज़्यादातर हिस्सा बिना किसी ख़ास टूल के दिला देते हैं: कंपनी की अपनी साइट और करियर पेज, LinkedIn, हालिया प्रेस, पॉडकास्ट में मौजूदगी, सार्वजनिक कंपनियों के लिए अर्निंग कॉल, और वे समुदाय जहाँ आपका खरीदार वाकई मौजूद रहता है। अगर आपने बाज़ार को ठीक से मान्य किया है, तो इसमें से कुछ काम आप पहले ही कर चुके हैं — मांग और प्रतिस्पर्धी रिसर्च के लिए [किसी बिज़नेस आइडिया को बनाने से पहले उसे कैसे मान्य करें](/how-to-validate-a-business-idea/) देखें, जो सेल्स इंटेल का भी दुगुना काम करती है। आपने पर्याप्त कर लिया या नहीं, इसकी कसौटी: क्या आप संदेश के पहले दो वाक्य इस तरह लिख सकते हैं कि किसी और कंपनी को भेजने पर उनका *कोई मतलब ही न रहे*? अगर हाँ, तो आप तैयार हैं। अगर आपका शुरुआती वाक्य सौ कंपनियों के लिए काम कर जाए, तो रिसर्च जारी रखिए। ## चरण 3: अपने चैनलों को क्रम में लगाएँ — email, फ़ोन, LinkedIn कोई एक सर्वश्रेष्ठ चैनल नहीं होता। हर पल के लिए एक सर्वश्रेष्ठ चैनल होता है। गलती यह है कि कोई एक चुन लिया जाए और उसी पर पिटाई करते रहा जाए। हुनर यह है कि उन्हें इस तरह क्रम में लगाएँ कि हर चैनल वही काम करे जिसमें वह वाकई अच्छा है। | चैनल | सबसे अच्छा उपयोग | बुरी तरह इस्तेमाल पर जोखिम | | --- | --- | --- | | Email | मुख्य आग्रह, विस्तृत फ़ॉलो-अप, कुछ भी जिसे खरीदार अंदरूनी तौर पर आगे भेजना चाहे | अगर टेम्पलेट जैसा पढ़ा जाए तो तुरंत अनदेखा | | फ़ोन | समय-संवेदनशील फ़ॉलो-अप, बुक हो चुके पर सरकते सौदे की शेड्यूलिंग, कोई गर्म रेफ़रल जिसे कॉल करने को कहा गया हो | बिना किसी पूर्व संदर्भ या कारण के दख़लअंदाज़ी जैसा लगता है | | LinkedIn | नरम पहला संपर्क, किसी ठंडे संपर्क को गर्म करना, emails के बीच नज़र में बने रहना | भीड़भाड़ वाला, धीमा, हर दूसरी पिच जैसा दिखने का आसान ख़तरा | | गर्म परिचय | कुछ भी, जब आपको एक मिल जाए | रेफ़र करने वाले की साख दांव पर है — इसे बर्बाद मत कीजिए | व्यवहार में जो क्रम काम करता है: उस ट्रिगर से जुड़ा एक छोटा, विशिष्ट email से शुरुआत करें जो आपको मिला था। अगर जवाब न मिले, तो LinkedIn पर मूल्य जोड़ें — कोई सच्ची टिप्पणी, कोई उपयोगी संसाधन, संदर्भ के साथ कोई कनेक्शन रिक्वेस्ट — ताकि आपका नाम कोई ठंडा झटका न रहे। फ़ोन कॉल तक तभी बढ़ें जब कोई असली कारण हो: कोई समयसीमा, कोई रेफ़रल, कोई सौदा जो दिलचस्पी के बाद ख़ामोश हो गया। अचानक ऐसे किसी को की गई कॉल जिसने आपका नाम कभी सुना ही नहीं, स्पैम में दर्ज होने का सबसे तेज़ रास्ता है। और जब भी आप गर्म परिचय कमा सकें, हमेशा उसी को तरजीह दें। जिस पर खरीदार भरोसा करता है, उसका एक परिचय बीस बेहतरीन तरीके से गढ़े गए ठंडे emails से बेहतर काम करता है। ठंडा जाने से पहले असली मेहनत इस बात पर लगाइए कि आपके नेटवर्क में कौन कौन-सा दरवाज़ा खोल सकता है। ## चरण 4: वह संदेश लिखें जिसका जवाब मिले एक बार जब आप संपर्क करने का हक कमा लें, तो संदेश छोटा रखें और हाँ कहना आसान बनाएँ। अजनबियों की लंबी पिच पढ़ी नहीं जातीं; वे आर्काइव कर दी जाती हैं। एक अच्छा ठंडा email 90 शब्दों से कम में चार काम करता है: 1. **ट्रिगर का नाम लेता है** — साबित करता है कि आप ध्यान दे रहे हैं और यह कोई सामूहिक भेजा हुआ संदेश नहीं है। 2. **प्रासंगिक दर्द बताता है** — एक वाक्य, उनके नज़रिए से गढ़ा हुआ, आपके नहीं। 3. **एक छोटा-सा आग्रह करता है** — 15 मिनट की कॉल, न कि "आइए किसी साझेदारी को टटोलें"। 4. **आसान रास्ता देता है** — "अगर यह आपका काम नहीं है, तो क्या आप बता सकते हैं कि इसका ज़िम्मा किसके पास है?" यह इसका ढाँचा है: > "नमस्ते Priya — देखा कि आपने अभी RevOps टीम में दो पद खोले हैं, जिसका आमतौर पर मतलब होता है कि रिपोर्टिंग हेडकाउंट के ठीक कर पाने से तेज़ी से तकलीफ़देह होती जा रही है। हम Series-B टीमों को उनका स्टैक उखाड़े बिना मैनुअल रिपोर्टिंग का समय क़रीब 60% घटाने में मदद करते हैं। यह देखने के लिए कि क्या यह प्रासंगिक है, अगले हफ़्ते 15 मिनट देने लायक है? और अगर यह आपका क्षेत्र नहीं है, तो मैं आभारी रहूँगा अगर आप बता दें कि इसका ज़िम्मा किसके पास है।" यह विशिष्ट है, उनके समय का सम्मान करता है, और जवाब देना बेहद आसान है — यहाँ तक कि "ना" भी काम की है, क्योंकि यह आपको सही व्यक्ति तक पहुँचा देती है। यही अनुशासन सभी चैनलों पर लागू होता है; अगर आप बड़े पैमाने पर आउटरीच की गहरी बारीकियाँ बिना फ़्लैग हुए या अनदेखा हुए चाहते हैं, तो मैंने उसे [एक सफल आउटरीच रणनीति गढ़ना](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) में तोड़कर समझाया है। ## चरण 5: ऐसे तैयारी करें मानो यही एकमात्र मीटिंग है जो आपको मिलेगी पहुँच आपको शुरुआत दिलाती है। तैयारी अगला कदम कमाती है। फाउंडर अक्सर हफ़्तों जूझते हैं एक मीटिंग पाने के लिए, फिर खरीदार की दुनिया पर बिना सोचे-समझे अंदर चले जाते हैं — और सौदा दिलचस्पी की कमी से नहीं, तैयारी की कमी से मरता है। किसी भी कॉल से पहले, बिना अटके यह जवाब दे पाएँ: - इस व्यक्ति का दिन कैसा दिखता है, और मेरा उत्पाद उसमें कहाँ फ़िट होता है? - वह एक नतीजा क्या है जिसकी उन्हें परवाह है और जिसे मैं हिला सकता हूँ? - वे कौन-सी दो आपत्तियाँ उठाएँगे, और मेरा ईमानदार जवाब क्या है? - अगर उनकी दिलचस्पी है पर वे तैयार नहीं, तो सबसे छोटा अगला कदम क्या है जो मैं माँग सकता हूँ? आपने उत्पाद बनाया है, इसलिए डेमो आसान है। मुश्किल हिस्सा है खरीदार की प्राथमिकताओं को अपने सिर में रखना, अपनी प्राथमिकताओं के बजाय। जो फाउंडर आउटरीच को राजस्व में बदलते हैं, वे वही हैं जो ऐसे नज़र आते हैं मानो बिज़नेस को पहले से ही समझते हों — क्योंकि उन्होंने चरण 2 में मेहनत की थी। ## कब संपर्क न करें आक्रामक आउटरीच जितनी पाइपलाइन बनाती है, उससे ज़्यादा जला देती है। ठंडे संपर्क को छोड़ दें — या धीमे हो जाएँ — जब: - आप यह नहीं बता सकते कि यह ख़ास व्यक्ति सही संपर्क क्यों है। - आप बिना किसी जवाब के दो बार से ज़्यादा फ़ॉलो-अप कर चुके हैं। (आगे बढ़िए; बाज़ार बड़ा है।) - आपका शुरुआती वाक्य सौ दूसरी कंपनियों को भेजने पर भी काम कर जाए। - आप सामान्य कारोबारी घंटों के बाहर या बिना किसी पूर्व संदर्भ के कॉल कर रहे होंगे। - इस व्यक्ति को चुनने की एकमात्र वजह यह है कि उनकी संपर्क जानकारी आसानी से मिल गई। अच्छा आउटरीच किसी ऐसे व्यक्ति के सही समय पर भेजे गए, प्रासंगिक नोट जैसा लगता है जिसने अपना होमवर्क किया हो। बुरा आउटरीच बेहतर निशाने वाले स्पैम जैसा लगता है। यह फ़र्क पूरी तरह रिसर्च और संयम में है। ## फाउंडर-लेड सेल्स स्टैक इसके लिए जिन टूल और आदतों पर मैं टिका रहता हूँ, इनमें से किसी के लिए सेल्स टीम की ज़रूरत नहीं: - **रिसर्च:** कंपनी की अपनी साइट और करियर पेज, LinkedIn, हालिया प्रेस, और वे समुदाय जहाँ आपके खरीदार वाकई बातें करते हैं - **CRM:** कुछ भी जिसे आप वाकई अपडेट करेंगे — एक साधारण Notion बोर्ड या Airtable उस एंटरप्राइज़ CRM से बेहतर है जिसे आप अनदेखा कर देते हैं - **सीक्वेंसिंग:** एक हल्का-फुल्का ट्रैकर कि कौन किस चरण पर है और अगला संपर्क क्या है, ताकि कुछ भी न सरके - **Email:** एक असली, गर्म किया हुआ भेजने वाला पता और प्लेन-टेक्स्ट संदेश — कोई इमेज नहीं, कोई ट्रैकिंग पिक्सल नहीं, कुछ भी नहीं जो चिल्लाकर "कैंपेन" कहे - **कैलेंडर:** एक बुकिंग लिंक ताकि "हाँ" पाँच जवाबी emails के बजाय एक क्लिक में मीटिंग बन जाए ## ऑपरेटर की आख़िरी बात बेचना शुरू करने के लिए आपको सेल्स टीम की ज़रूरत नहीं। आपको ठीक-ठीक यह जानना है कि कौन हाँ कह सकता है, इतनी रिसर्च करनी है कि आपका संदेश सिर्फ़ उसी के लिए लिखा जा सकता था, और अपने चैनलों को इस तरह क्रम में लगाना है कि हर एक अपना काम करे। Email आग्रह ढोता है, LinkedIn ज़मीन गर्म करता है, फ़ोन किसी समय-संवेदनशील खाई को पाटता है, और गर्म परिचय इन सबसे बाज़ी मार ले जाता है। रेप खुद इतनी देर तक कीजिए कि सीख जाएँ कि असल में क्या असर करता है — और तब, और सिर्फ़ तब, वह मेहनत से कमाई प्लेबुक अपने पहले कर्मचारी को सौंपिए। --- **संबंधित:** [एक सफल आउटरीच रणनीति गढ़ना](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) · [किसी बिज़नेस आइडिया को कैसे मान्य करें](/how-to-validate-a-business-idea/) · [ग्रोथ मार्केटिंग रणनीतियों की गाइड](/growth-marketing-strategies-guide/) --- ## सोलोप्रेन्योर बिज़नेस कैसे बनाएं: 2026 की पूरी गाइड Source: https://alejandrorioja.com/hi/how-to-build-a-solopreneur-business/ Published: 2026-07-07 Tags: Entrepreneurship, Growth TL;DR: एक बिज़नेस मॉडल चुनें (कंटेंट, सर्विस, SaaS, या डिजिटल प्रोडक्ट्स), एक खास नीश के आसपास ऑडियंस बनाएं, और फिर प्राथमिक मॉडल के काम करने के बाद ही द्वितीयक आय स्रोत जोड़ें। गलती यह है कि चारों एक साथ शुरू करना — उस मॉडल को चुनें जो आपकी मौजूदा जानकारी से मेल खाए, न कि जो सबसे ज़्यादा पैसिव लगे। ## विषय-सूची _अपडेट किया गया जुलाई 2026._ **TL;DR:** एक बिज़नेस मॉडल चुनें (कंटेंट, सर्विस, SaaS, या डिजिटल प्रोडक्ट्स), एक खास नीश के आसपास ऑडियंस बनाएं, और फिर प्राथमिक मॉडल के काम करने के बाद ही द्वितीयक आय स्रोत जोड़ें। गलती यह है कि चारों एक साथ शुरू करना — उस मॉडल को चुनें जो आपकी मौजूदा जानकारी से मेल खाए, न कि जो सबसे ज़्यादा पैसिव लगे। **[ऑपरेटर की नज़र से]** मैंने इस साइट को चलाया है, कोर्स बेचे हैं, और सालों से बिना किसी पूर्णकालिक कर्मचारी के एफिलिएट इनकम मैनेज की है। इनमें से कुछ भी एक बड़ी योजना से शुरू नहीं हुआ — यह एक ऐसी चीज़ से शुरू हुआ जो काम किया, फिर जानबूझकर विस्तार किया। यह गाइड वही है जो मैं चाहता था कि मैंने सब कुछ एक साथ करने की कोशिश करने से पहले पढ़ा होता। ## सोलोप्रेन्योर बिज़नेस वास्तव में क्या है एक सोलोप्रेन्योर अकेले बिज़नेस चलाता है — न को-फाउंडर, न कर्मचारी, शायद कॉन्ट्रैक्टर जब वॉल्यूम की मांग हो। लक्ष्य एक ऐसा बिज़नेस है जो विशेषज्ञता और सिस्टम पर चलता हो, न कि हेडकाउंट पर। यह फ्रीलांसिंग से अलग है। एक फ्रीलांसर समय बेचता है। एक सोलोप्रेन्योर ऐसे सिस्टम बनाता है जो उसके समय की ज़रूरत के बिना हर कमाए गए रुपए के लिए राजस्व उत्पन्न करते हैं। ## सोलोप्रेन्योर के 4 बिज़नेस मॉडल हर वन-पर्सन बिज़नेस मोटे तौर पर इनमें से एक में फिट होता है: 1. **कंटेंट बिज़नेस।** आप प्रकाशित करते हैं (ब्लॉग, न्यूज़लेटर, YouTube, पॉडकास्ट) और विज्ञापन, एफिलिएट रेवेन्यू, स्पॉन्सरशिप और खुद के प्रोडक्ट्स के ज़रिए मोनेटाइज़ करते हैं। सबसे कम बाधा, सबसे लंबा रैंप। 2. **सर्विस बिज़नेस।** आप क्लाइंट्स को एक विशिष्ट परिणाम देते हैं — कंसल्टिंग, फ्रैक्शनल रोल, done-for-you सर्विसेज। $10K/महीने तक सबसे तेज़ रास्ता, सबसे कम स्केलेबल। 3. **डिजिटल प्रोडक्ट्स।** कोर्स, टेम्प्लेट, ईबुक, टूल्स। एक बार बनाने के बाद हाई लीवरेज, मौजूदा ऑडियंस के बिना ट्रैफिक लाना मुश्किल। 4. **Micro-SaaS।** एक छोटा सॉफ्टवेयर प्रोडक्ट जो एक विशिष्ट समस्या को हल करता है। सबसे ऊंची सीलिंग, सबसे ऊंचा टेक्निकल बार। सही मॉडल इस बात पर निर्भर करता है कि आपके पास पहले से क्या है: स्किल्स, ऑडियंस, या कैपिटल। ## स्टेप 1: असली गहराई वाली नीश चुनें व्यापक नीश (मार्केटिंग, फाइनेंस, हेल्थ) में ट्रैफिक होता है लेकिन भारी प्रतिस्पर्धा होती है। संकरी नीश (e-commerce फाउंडर्स के लिए AI टूल्स, नए नर्सों के लिए पर्सनल फाइनेंस) बेहतर कन्वर्ट करती हैं और तेज़ी से रैंक होती हैं। मैं जो टेस्ट इस्तेमाल करता हूं: क्या मैं इस विषय पर 50 वास्तव में उपयोगी कंटेंट पीस लिख सकता हूं बिना आइडियाज़ खत्म हुए? अगर हां, तो नीश में गहराई है। अगर 20 नाम लेने में मुश्किल हो रही है, तो यह बहुत संकरी है या मैं इसे पर्याप्त नहीं जानता। आपकी नीश इन तीनों के चौराहे पर होनी चाहिए: - कुछ जो आप अनुभव से जानते हों, केवल रिसर्च से नहीं - एक ऐसी ऑडियंस जिसके पास पैसा या समय खर्च करने के लिए हो - एक ऐसी समस्या जो बार-बार आए, न कि एक बार की फिक्स ## स्टेप 2: ज़रूरत पड़ने से पहले ऑडियंस बनाएं सबसे बड़ी गलती जो मैं देखता हूं: ज़ीरो ऑडियंस के लिए प्रोडक्ट लॉन्च करना। ऑडियंस पहले, प्रोडक्ट बाद में — यही नियम है। यहां बताया गया है कि वास्तव में क्या काम करता है: 1. **एक डिस्ट्रीब्यूशन चैनल चुनें और गहरे जाएं।** ब्लॉग + SEO धीमा है लेकिन टिकाऊ है। एक न्यूज़लेटर जल्दी मोनेटाइज़ होता है। शॉर्ट-फॉर्म वीडियो का सीलिंग ऊंचा है लेकिन एल्गोरिदम पर निर्भर है। पहले साल में चार प्लेटफॉर्म पर ध्यान न बांटें। 2. **बेचने के लिए कुछ होने से पहले लगातार प्रकाशित करें।** जो ऑडियंस आप तब बनाते हैं जब आपके पास बेचने के लिए कुछ नहीं होता, वह आप पर तब भरोसा करती है जब आप अंततः ऐसा करते हैं। 3. **पहले दिन से ईमेल लिस्ट बनाएं।** सोशल मीडिया फॉलोअर किराए की ज़मीन हैं। आपकी ईमेल लिस्ट आपकी है। मैं [ConvertKit](/recommends/convertkit) इस्तेमाल करता हूं — यह सीक्वेंस और ब्रॉडकास्ट को बिना रास्ते में आए संभालता है। एक उपयोगी बेंचमार्क: 1,000 सच्चे फैन्स (ईमेल सब्सक्राइबर जो हर ईमेल खोलते हैं) डिजिटल प्रोडक्ट्स से साल में 1 करोड़ रुपए कमाने के लिए पर्याप्त हैं। ## स्टेप 3: पहले अपने प्राथमिक राजस्व स्रोत को ऑप्टिमाइज़ करें एक बार जब आपके पास ऑडियंस हो (या किसी सर्विस का क्लाइंट), तो द्वितीयक स्रोत जोड़ने से पहले प्राथमिक राजस्व स्रोत पर पूरा ध्यान दें। **कंटेंट बिज़नेस के लिए:** एफिलिएट रेवेन्यू सबसे तेज़ पहला पैसा है। आप जो टूल्स इस्तेमाल करते हैं उनके बारे में लिखते हैं, अपने रेकमेंड पेज के ज़रिए लिंक करते हैं, और प्रतिशत कमाते हैं। कोई प्रोडक्ट नहीं बनाना, कोई कस्टमर सपोर्ट नहीं। सीलिंग असली है — एक लाभदायक नीश में हाई-ट्रैफिक साइट $5K–$30K/महीना कमा सकती है — लेकिन यह सबसे अच्छा बूटस्ट्रैप मैकेनिज्म है जो मैंने पाया है। **सर्विस बिज़नेस के लिए:** जितना आरामदायक लगे उससे ज़्यादा चार्ज करें। अंडरप्राइसिंग सोलोप्रेन्योर की सबसे आम गलती है। अगर आपकी क्लोज़ रेट 100% है, तो आप बहुत सस्ते हैं। **डिजिटल प्रोडक्ट्स के लिए:** स्कोप को टाइट रखें। एक फोकस्ड $97 कोर्स कन्वर्ज़न और कम्प्लीशन रेट में एक फैले हुए $497 कोर्स से बेहतर प्रदर्शन करता है। **Micro-SaaS के लिए:** उस दर्द के लिए बनाएं जो आपको व्यक्तिगत रूप से है। एम्पैथी का फायदा असली है जब आप खुद अपने टारगेट कस्टमर हों। ## स्टेप 4: द्वितीयक आय स्रोत जोड़ें एक बार जब आपका प्राथमिक मॉडल कन्वर्ट होने लगे, ऐसे आय स्रोत जोड़ें जिनके लिए आनुपातिक समय की ज़रूरत न हो: - **एफिलिएट इनकम** — यहां तक कि सर्विस बिज़नेस और SaaS ऑपरेटर भी अपने कंटेंट से एफिलिएट रेवेन्यू कमा सकते हैं - **डिजिटल प्रोडक्ट्स** — भले ही आप मुख्य रूप से सर्विस बिज़नेस हों, एक कोर्स या टेम्प्लेट सेट सोते समय कमा सकता है - **स्पॉन्सरशिप** — एक बार जब आपकी ऑडियंस ~5,000 एंगेज्ड सब्सक्राइबर से ऊपर हो - **लाइसेंसिंग** — अगर आपने एक सिस्टम या टूल बनाया है, तो इसे पड़ोसी नीश में दूसरों को लाइसेंस दें स्टैक एक परिणाम है, रणनीति नहीं। पहले एक स्ट्रीम को काम कराएं। ## सोलोप्रेन्योर टेक स्टैक मैं पूरे इस ऑपरेशन को छह टूल्स पर चलाता हूं: | टूल | क्या करता है | |---|---| | [Claude](/recommends/claude) | कंटेंट, ईमेल और कोड के पहले ड्राफ्ट | | [ConvertKit](/recommends/convertkit) | ईमेल लिस्ट, ऑटोमेशन और ब्रॉडकास्ट | | [Notion](/recommends/notion) | एडिटोरियल कैलेंडर, क्लाइंट डॉक्स और SOPs | | [Canva](/recommends/canva) | सोशल ग्राफिक्स और थंबनेल डिज़ाइन | | [Airtable](/recommends/airtable) | एफिलिएट ट्रैकिंग, CRM, कंटेंट डेटाबेस | | [SEMrush](/recommends/semrush) | कीवर्ड रिसर्च और रैंक ट्रैकिंग | कुल मासिक लागत: $300 से कम। इस स्टैक को रिप्लेस करने वाली एक टीम सैलरी में $15K+ प्रति माह खर्च करेगी। ## वे 3 गलतियां जो सोलोप्रेन्योर बिज़नेस को मार देती हैं 1. **जल्दी स्केलिंग।** बिज़नेस मॉडल साबित होने से पहले हायरिंग रिसोर्स जलाती है और दोहराने योग्य राजस्व से पहले मैनेजमेंट ओवरहेड जोड़ती है। 2. **बहुत जल्दी डायवर्सिफाई करना।** चार आधे काम करने वाले आय स्रोत एक पूरी तरह ऑप्टिमाइज़ स्रोत से कम कमाते हैं। पहले साल में व्यापक नहीं, गहरे जाएं। 3. **डिस्ट्रीब्यूशन के बिना बनाना।** बिना ऑडियंस का सबसे अच्छा प्रोडक्ट एक बड़ी एंगेज्ड लिस्ट वाले औसत प्रोडक्ट को नहीं हरा सकता। डिस्ट्रीब्यूशन ही खाई है। ## ऑपरेटर का निष्कर्ष सोलोप्रेन्योर बिज़नेस टीम की जटिलता को स्वामित्व और मार्जिन के लिए ट्रेड करने का एक जानबूझकर किया गया चुनाव है। जो बिज़नेस मैंने लगातार काम करते देखे हैं वे सभी एक ही पैटर्न साझा करते हैं: एक मॉडल, एक नीश, एक डिस्ट्रीब्यूशन चैनल, कम्पाउंड होने के लिए काफी देर तक रखा। उस मॉडल को चुनें जो आपकी मौजूदा स्किल्स से मेल खाए। ऑडियंस को ज़रूरत से पहले बनाएं। आय स्रोत केवल तब जोड़ें जब प्राथमिक स्रोत कन्वर्ट करने लगे। बाकी सब एग्जीक्यूशन है। --- **संबंधित:** [बिज़नेस आइडिया को कैसे वैलिडेट करें](/how-to-validate-a-business-idea/) · [न्यूज़लेटर से पैसे कैसे कमाएं](/how-to-monetize-a-newsletter/) · [पर्सनल ब्रांड कैसे बनाएं](/how-to-build-a-personal-brand/) --- ## AI एजेंट्स से अपने छोटे व्यवसाय को स्वचालित करें: एक व्यावहारिक गाइड Source: https://alejandrorioja.com/hi/how-to-automate-your-small-business-with-ai-agents/ Published: 2026-07-04 Tags: AI Agents, Entrepreneurship, Operations TL;DR: AI एजेंट्स से छोटे व्यवसाय को स्वचालित करना लोगों को प्रतिस्थापित करने के बारे में नहीं है — यह दोहराव वाले, नियम-आधारित काम को सौंपने के बारे में है ताकि आप अपना समय उन निर्णयों पर खर्च कर सकें जो केवल आप ही ले सकते हैं। एक कार्य से शुरू करें, सब कुछ लॉग करें, पैसे या ग्राहकों को सीधे प्रभावित करने वाली हर चीज में मनुष्यों को लूप में रखें, और वहाँ से विस्तार करें। मैं दो व्यवसायों में जो स्टैक उपयोग करता हूं वह कुल मिलाकर $100/माह से कम है। ## विषय-सूची _जुलाई 2026 में अपडेट किया गया।_ **TL;DR:** AI एजेंट्स से छोटे व्यवसाय को स्वचालित करना लोगों को प्रतिस्थापित करने के बारे में नहीं है — यह दोहराव वाले, नियम-आधारित काम को सौंपने के बारे में है ताकि आप अपना समय उन निर्णयों पर खर्च कर सकें जो केवल आप ही ले सकते हैं। एक कार्य से शुरू करें, सब कुछ लॉग करें, पैसे या ग्राहकों को सीधे प्रभावित करने वाली हर चीज में मनुष्यों को लूप में रखें, और वहाँ से विस्तार करें। मैं दो व्यवसायों में जो स्टैक उपयोग करता हूं वह कुल मिलाकर $100/माह से कम है। **ऑपरेटर का नोट:** मैं दो व्यवसाय चलाता हूं — टेक्सास के Pflugerville में नौ-कोर्ट इनडोर पिकलबॉल सुविधा (Pickleland) और एक परामर्श ब्रांड। दोनों मिलाकर, मेरे पास प्रोडक्शन में 30 से अधिक AI एजेंट्स हैं जो सोशल मीडिया टिप्पणी उत्तरों से लेकर इवेंट प्रमोशन, न्यूज़लेटर ड्राफ्ट और बुकिंग फॉलो-अप तक सब कुछ संभालते हैं। यह एक ईमानदार गाइड है जो वास्तव में काम करती है, समय बर्बाद करती है, और बिना डेवलपर किराए पर लिए कैसे शुरू करें। ईमानदार फ्रेमिंग: छोटे व्यवसाय के लिए AI एजेंट्स जादू नहीं हैं। वे ग्राहक संबंधों, उत्पाद गुणवत्ता, या रणनीतिक निर्णय के कठिन काम को प्रतिस्थापित नहीं करते। वे जो करते हैं वह प्रशासनिक दिनचर्या को समाप्त करता है जो हर ऑपरेटर के दिन के दो से तीन घंटे खाती है — इनबॉक्स सॉर्टिंग, कॉपी-पेस्ट रिपोर्ट, सोशल उत्तर, डेटा फॉर्मेटिंग। फर्क करने के लिए यही काफी है। ## 4 प्रकार के काम जो अच्छी तरह से स्वचालित होते हैं कुछ भी बनाने से पहले, अपने कार्यभार को चार श्रेणियों में मैप करें। उनमें से केवल एक AI एजेंट्स के लिए उपयुक्त है। ### 1. नियम-आधारित, दोहराव वाला, टेक्स्ट इन / टेक्स्ट आउट यह इष्टतम बिंदु है। एक ग्राहक ईमेल को वर्गीकृत करना, सोशल मीडिया टिप्पणी का उत्तर ड्राफ्ट करना, एक सप्ताह की बुकिंग को बुलेट सूची में सारांशित करना, CSV को रिपोर्ट में पुनः फॉर्मेट करना। इनपुट टेक्स्ट है; आउटपुट टेक्स्ट है; नियम सुसंगत हैं। ये कार्य एक सिंगल प्रॉम्प्ट और API के पतले रैपर के साथ स्वचालित होते हैं। **Pickleland के उदाहरण:** - आने वाले कोर्ट-इन्क्वायरी ईमेल को वर्गीकृत करना (सवाल / शिकायत / बुकिंग / अन्य) - आगामी इवेंट्स के लिए Facebook ग्रुप पोस्ट ड्राफ्ट करना - बुकिंग सिस्टम से साप्ताहिक अधिभोग सारांश उत्पन्न करना ### 2. स्पष्ट हैंडऑफ के साथ मल्टी-स्टेप पाइपलाइन एक कार्य जिसके तीन चरण हैं — डेटा प्राप्त करना, उसे बदलना, एक सूचना भेजना — जहां प्रत्येक चरण का स्पष्ट इनपुट और आउटपुट हो। यह हल्के ऑर्केस्ट्रेशन लेयर के साथ अच्छा काम करता है (मैं Cloudflare Workers Queues का उपयोग करता हूं)। मुख्य बात यह है कि प्रत्येक चरण स्वतंत्र रूप से विफल हो सकता है और पूरे काम को फिर से किए बिना पुनः प्रयास किया जा सकता है। **Pickleland के उदाहरण:** - नई बुकिंग → CRM अपडेट → पुष्टिकरण ईमेल → Slack सूचना - फॉर्म सबमिशन → वर्गीकरण → निर्देशित उत्तर ड्राफ्ट → मानव समीक्षा कतार ### 3. निगरानी और अलर्ट एजेंट जो एक स्थिति देखते हैं और जब यह होती है तो आपको सूचित करते हैं। ये कुछ उच्चतम ROI AI स्वचालन हैं क्योंकि ये डैशबोर्ड को मैन्युअली जांचने के संज्ञानात्मक बोझ को प्रतिस्थापित करते हैं। ये सबसे सरल भी हैं: तर्क सिर्फ "क्या X थ्रेशोल्ड से ऊपर है? अगर हाँ, तो अलर्ट करें।" **मेरे परामर्श ब्रांड के उदाहरण:** - Google Analytics असामान्यता अलर्ट (ट्रैफिक ड्रॉप, स्पाइक) - बुकिंग रद्दीकरण दर साप्ताहिक आधार रेखा से ऊपर - नई समीक्षा पोस्ट की गई — मानव उत्तर के लिए फ्लैग करें ### 4. सामग्री के पहले ड्राफ्ट (अंतिम उत्पाद नहीं) AI एजेंट्स उपयोगी गुणवत्ता में सोशल पोस्ट, ईमेल न्यूज़लेटर, ब्लॉग आउटलाइन और उत्पाद विवरण ड्राफ्ट कर सकते हैं। पकड़ यह है: वे आपके संपादकीय निर्णय को प्रतिस्थापित नहीं कर सकते। प्रत्येक ड्राफ्ट मानव समीक्षा चरण से गुजरता है। ROI खाली स्क्रीन के बजाय 70% पूर्णता से शुरू करने से आता है। **जो अच्छी तरह से स्वचालित नहीं होता:** ग्राहक संबंध प्रबंधन, मूल्य निर्धारण निर्णय, बिक्री वार्तालाप, भर्ती, और कुछ भी जहां गलत आउटपुट किसी वास्तविक व्यक्ति के लिए वास्तविक लागत हो। इन कार्यों के लिए मनुष्यों को रखें। ## मैं वास्तव में जो स्टैक उपयोग करता हूं इसके लिए आपको एंटरप्राइज सॉफ्टवेयर की जरूरत नहीं है। यह मेरे स्वचालन को शक्ति देता है: 1. **[Claude](/recommends/claude)** — सभी AI कार्यों के लिए मॉडल लेयर। मैं GUI नहीं, सीधे API का उपयोग करता हूं। डॉलर-प्रति-गुणवत्ता मेरे परीक्षण में सबसे अच्छा है, और [प्रॉम्प्ट कैशिंग](/prompt-caching-cut-your-claude-costs-without-switching-models/) सिस्टम प्रॉम्प्ट दोहराने पर लागत और कम करता है। 2. **Cloudflare Workers** — जहाँ एजेंट रहते हैं। सर्वरलेस, वैश्विक रूप से वितरित, और मुफ्त टियर अधिकांश छोटे व्यवसाय वर्कलोड को कवर करता है। `scheduled` हैंडलर cron कार्य चलाता है; `fetch` हैंडलर इवेंट-ट्रिगर फ्लो के लिए webhooks प्राप्त करता है। 3. **Airtable** — डेटा रीढ़। प्रत्येक एजेंट Airtable टेबल से पढ़ता और लिखता है। यहाँ जॉब स्टेटस, समीक्षा कतार, और परिचालन डेटा रहते हैं। गैर-डेवलपर कोड छुए बिना डेटा संपादित कर सकते हैं। 4. **Kit (पूर्व में ConvertKit)** — ईमेल और न्यूज़लेटर स्वचालन। मेरा न्यूज़लेटर-ड्राफ्टिंग एजेंट Kit ड्राफ्ट में लिखता है; मैं समीक्षा करता हूं और भेजता हूं। दो व्यवसायों में 30 से अधिक एजेंट्स के लिए कुल मासिक लागत: $100 से कम। सबसे बड़ी मद Claude API उपयोग है। बाकी सब मुफ्त टियर या लगभग मुफ्त है। ## वास्तविक उदाहरण: Pickleland के स्वचालन ### इवेंट प्रमोटर प्रत्येक रविवार, एक शेड्यूल्ड एजेंट अगले चार दिनों के इवेंट्स के लिए बुकिंग सिस्टम जाँचता है। वह प्रत्येक इवेंट को प्रासंगिक स्थानीय Facebook ग्रुप से मिलाता है और प्रत्येक के लिए वेन्यू-उपयुक्त प्रमो पोस्ट ड्राफ्ट करता है। ड्राफ्ट Airtable समीक्षा टेबल में जाते हैं। मैं पाँच मिनट समीक्षा करने और "अनुमोदित" क्लिक करने में बिताता हूं — एजेंट 40 मिनट का ड्राफ्टिंग काम करता है। मेरी स्वीकृति के बिना कुछ भी स्वचालित रूप से पोस्ट नहीं होता। यह [शेड्यूल्ड एजेंट पैटर्न](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) है — एक शेड्यूल पर चलता है, बैच काम करता है, और मानव समीक्षा के लिए ड्राफ्ट प्रस्तुत करता है। ### सोशल कमेंट क्लासिफायर जब एक निगरानी की गई Facebook पोस्ट पर नई टिप्पणी आती है, तो एक webhook ट्रिगर होता है और एजेंट इरादे को वर्गीकृत करता है: सवाल, शिकायत, तारीफ, या स्पैम। एक विश्वास थ्रेशोल्ड से ऊपर के सवालों और शिकायतों के लिए, यह एक उत्तर ड्राफ्ट करता है और समीक्षा के लिए फ्लैग करता है। तारीफों को लॉग किया जाता है। स्पैम को दबाया जाता है। टिप्पणी से ड्राफ्ट तक 30 सेकंड का चक्र। एजेंट के बिना, प्रत्येक टिप्पणी एक मैनुअल संदर्भ-स्विच था; अब पूर्व-ड्राफ्ट उत्तरों की कतार तीस के बजाय पांच मिनट लेती है। यह [इवेंट-ट्रिगर एजेंट पैटर्न](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) है — webhook द्वारा सक्रिय, तेजी से जवाब देना जरूरी है। ### साप्ताहिक परिचालन संक्षेप प्रत्येक सोमवार सुबह, एक एजेंट पिछले सप्ताह के बुकिंग डेटा, रद्दीकरण दर, कोर्ट प्रकार द्वारा अधिभोग, और कोई भी फ्लैग की गई विसंगतियाँ खींचता है। यह पाँच-बुलेट संक्षेप को फॉर्मेट करता है और एक Notion पेज में डाल देता है। मैं इसे कॉफी के साथ पढ़ता हूं और बीस के बजाय दो मिनट में सप्ताह के लिए आवश्यक परिचालन संदर्भ प्राप्त करता हूं। ## कहाँ से शुरू करें: 4 कदम ### कदम 1: हर हफ्ते करने वाला सबसे अधिक घर्षण वाला दोहराव कार्य चुनें सबसे आकर्षक नहीं, सबसे रणनीतिक नहीं — वह जो आपको सबसे ज्यादा परेशान करता है। साप्ताहिक रिपोर्ट जो आप तीन स्रोतों से कॉपी-पेस्ट करते हैं। सोशल उत्तर जिन पर आप एक घंटा खर्च करते हैं। फॉलो-अप ईमेल जो आप एक-एक करके भेजते हैं। यही आपका पहला एजेंट है। ### कदम 2: कार्य को इनपुट और आउटपुट में मैप करें लिखें: - क्या कार्य को ट्रिगर करता है (एक घड़ी, एक इवेंट, एक फॉर्म सबमिशन) - किन इनपुट की जरूरत है (डेटा स्रोत, टेक्स्ट, संदर्भ) - आउटपुट क्या है (एक ड्राफ्ट, एक सूचना, एक डेटाबेस पंक्ति) - मानव समीक्षा चरण क्या है (प्रत्येक पहले एजेंट में एक होना चाहिए) अगर आप इसे स्पष्ट रूप से मैप नहीं कर सकते, तो कार्य स्वचालित करने के लिए पर्याप्त रूप से परिभाषित नहीं है। पहले प्रक्रिया को मैन्युअली स्पष्ट करें। ### कदम 3: संभव सबसे छोटा संस्करण बनाएं एक सिस्टम नहीं। एक प्रॉम्प्ट, एक API कॉल, एक आउटपुट। एक TypeScript फ़ंक्शन जो इनपुट लेता है, Claude को कॉल करता है, और ड्राफ्ट लौटाता है। कोई डेटाबेस नहीं, कोई webhook नहीं, कोई कतार नहीं — सिर्फ कोर लॉजिक। इसे मैन्युअली पाँच बार चलाएं। क्या आउटपुट गुणवत्ता बनी रहती है? अगर हाँ, तो आपके पास एक काम करने वाला एजेंट है। फिर इंफ्रास्ट्रक्चर जोड़ें। ```typescript // सबसे सरल पहला एजेंट: इवेंट प्रमो ड्राफ्ट async function draftEventPromo(event: PadklelandEvent, env: Env): Promise { const msg = await env.ANTHROPIC.messages.create({ model: "claude-opus-4-8", max_tokens: 400, system: `You write Facebook event promo posts for Pickleland, an indoor pickleball facility in Pflugerville, TX. Tone: friendly, local, community-focused. Max 150 words.`, messages: [ { role: "user", content: `Write a promo post for this event: ${JSON.stringify(event)}`, }, ], }); return (msg.content[0] as { text: string }).text; } ``` ### कदम 4: अधिक सुविधाएं जोड़ने से पहले अवलोकनशीलता जोड़ें प्रत्येक रन को एक trace ID के साथ लॉग करें। इनपुट, आउटपुट, और टाइमस्टैम्प लॉग करें। आपको एक फैंसी टूल की जरूरत नहीं है — शुरुआत के लिए stdout पर संरचित JSON पर्याप्त है। कारण: आपका पहला एजेंट उन तरीकों से विफल होगा जो आपने नहीं सोचे थे। जब यह होता है, आपको यह देखने में सक्षम होना चाहिए कि बिना स्मृति से स्थिति को फिर से बनाए क्या हुआ। यह वह आदत है जो एजेंट स्टैक को स्केल करने वाले ऑपरेटरों को एक बुरे अनुभव के बाद हार मानने वाले ऑपरेटरों से अलग करती है। मैं इसे [प्रोडक्शन में AI एजेंट को डीबग करने के तरीके](/how-to-debug-an-ai-agent-in-production/) में गहराई से कवर करता हूं। ## सामान्य गलतियाँ (और उनसे कैसे बचें) **प्रक्रिया समझे बिना स्वचालित करना।** अगर आप खुद कार्य को लगातार तरीके से नहीं कर सकते, तो AI एजेंट बस इसे स्केल पर असंगत रूप से करेगा। पहले प्रक्रिया को मैन्युअली दस्तावेज करें, फिर स्वचालित करें। **मानव समीक्षा चरण बहुत जल्दी हटाना।** प्रत्येक एजेंट को human-in-the-loop समीक्षा के साथ शुरू करें। इसे दो सप्ताह चलने दें, प्रत्येक आउटपुट जाँचें, और कुछ भी पूरी तरह से स्वचालित चलाने की अनुमति देने से पहले विश्वास बनाएं। अपवाद कम जोखिम वाले, आसानी से उलटने योग्य क्रियाएं हैं (जैसे किसी फ़ोल्डर में ड्राफ्ट लिखना)। **कोर को मान्य करने से पहले पूरा सिस्टम बनाना।** पहले सबसे सरल संस्करण बनाएं। अगर एक प्रॉम्प्ट के साथ कोर गुणवत्ता नहीं है, तो अधिक इंफ्रास्ट्रक्चर इसे ठीक नहीं करेगा। **लागत की अनदेखी करना।** AI API लागत उपयोग के साथ बढ़ती है। वॉल्यूम पर डिप्लॉय करने से पहले प्रति-रन लागत जानें। जब आप प्रति सप्ताह हजारों रन कर रहे हों तो [Haiku vs Sonnet लागत गणित](/ai-agent-cost-math-when-haiku-beats-sonnet/) मायने रखता है। **विफलताओं को आपदा मानना।** एजेंट विफल होते हैं। प्रॉम्प्ट रिग्रेस करते हैं। API डाउन होती है। रिट्री लॉजिक बनाएं, [eval हार्नेस](/the-eval-harness-i-use-to-ship-ai-agents/) बनाएं, और विफलताओं को डेटा के रूप में मानें, न कि आपदाओं के रूप में। ## वह मानसिकता बदलाव जो सब कुछ बदलता है एक छोटे व्यवसाय में बाधा लगभग कभी पैसा नहीं होती — यह मालिक का समय और ध्यान है। प्रत्येक घंटा जो आप उन कार्यों पर बिताते हैं जो एजेंट संभाल सकता है, वह घंटा है जो आपने ग्राहकों, उत्पाद, या रणनीति पर नहीं बिताया। मैं जो फ्रेम उपयोग करता हूं: अगर एक कार्य को स्पष्ट इनपुट और आउटपुट के साथ एक दोहराव योग्य प्रक्रिया के रूप में लिखा जा सकता है, तो यह एक एजेंट के लिए उम्मीदवार है। जो कुछ भी निर्णय, रिश्ते, या रचनात्मकता की आवश्यकता है वह मेरे पास रहता है। एजेंट पूर्व को संभालता है ताकि मैं बाद पर ध्यान केंद्रित कर सकूं। AI एजेंट्स के साथ शुरुआत करने के लिए एक तकनीकी सह-संस्थापक, छह-अंकीय सॉफ्टवेयर बजट, या महीनों के निर्माण समय की जरूरत नहीं है। एक उच्च-घर्षण कार्य चुनना, सबसे छोटा संस्करण बनाना जो काम करता है, और आउटपुट से सीखना जरूरी है। अधिकांश ऑपरेटर एक सप्ताहांत में अपना पहला काम करने वाला एजेंट ढूंढते हैं। वहाँ से, दूसरे को एक दोपहर लगती है। ## अक्सर पूछे जाने वाले प्रश्न ### एक छोटे व्यवसाय के लिए AI एजेंट्स चलाने में कितना खर्च होता है? मेरा स्टैक $100/माह से कम में 30 से अधिक एजेंट्स चलाता है। सबसे बड़ी लागत AI API उपयोग (Claude) है। Cloudflare Workers 100,000 अनुरोधों/दिन तक मुफ्त है और उसके बाद $5/माह। Airtable का मुफ्त टियर है जो अधिकांश छोटे व्यवसाय डेटा जरूरतों को कवर करता है। लागत उपयोग के साथ बढ़ती है — एक अकेला एजेंट जो सप्ताह में कुछ बार चलता है नगण्य है। ### क्या मुझे AI एजेंट्स बनाने के लिए एक डेवलपर चाहिए? बुनियादी पैटर्न के लिए — एक शेड्यूल्ड cron, एक webhook हैंडलर, एक सरल प्रॉम्प्ट — थोड़े JavaScript और दस्तावेज पढ़ने की इच्छाशक्ति से काम हो जाता है। अधिक जटिल पाइपलाइन, ऑर्केस्ट्रेशन, और उत्पादन-ग्रेड अवलोकनशीलता के लिए, एक डेवलपर काम को तेज करता है। मेरा कोर्स ([शुरुआती लोगों के लिए AI एजेंट्स](/ai-agents-for-beginners-cowork-codex-guide/)) ऑपरेटरों के लिए नो-कोड और लो-कोड रास्ते सिखाता है। ### एक छोटे व्यवसाय के लिए सबसे अच्छा पहला AI एजेंट कौन सा है? साप्ताहिक परिचालन संक्षेप। यह एक शेड्यूल पर चलता है, स्पष्ट इनपुट (आपके डेटा स्रोत) हैं, एक सुसंगत आउटपुट (एक फॉर्मेटेड सारांश) उत्पन्न करता है, और शून्य नकारात्मक जोखिम है — अगर ड्राफ्ट गलत है, तो आप बस इसे नहीं पढ़ते। यह आपकी सहज समझ बनाता है कि एजेंट्स क्या कर सकते हैं और क्या नहीं, ग्राहकों या संचालन के लिए बिना जोखिम के। ### व्यवसाय स्वचालन के लिए किस AI मॉडल का उपयोग करना चाहिए? मैं अपने लगभग सभी एजेंट काम के लिए Claude का उपयोग करता हूं। API गुणवत्ता, विश्वसनीयता, और ऑपरेटर-अनुकूल मूल्य निर्धारण (विशेष रूप से [प्रॉम्प्ट कैशिंग](/prompt-caching-cut-your-claude-costs-without-switching-models/) के साथ) इसे उत्पादन उपयोग के लिए सही विकल्प बनाता है। सस्ते, उच्च-मात्रा वर्गीकरण कार्यों के लिए, Claude Haiku 4.5 तेज और किफायती है। ड्राफ्टिंग और सूक्ष्म कार्यों के लिए, Claude Sonnet या Opus। ### मैं AI एजेंट्स को ऐसी गलतियाँ करने से कैसे रोकूं जो मेरे व्यवसाय को नुकसान पहुंचाएं? तीन अभ्यास: ग्राहकों या पैसे को सीधे प्रभावित करने वाली हर चीज के लिए मनुष्यों को लूप में रखें; प्रत्येक रन लॉग करें ताकि आप ट्रैक कर सकें कि क्या गलत हुआ; और एक [eval हार्नेस](/the-eval-harness-i-use-to-ship-ai-agents/) बनाएं ताकि आपके प्रॉम्प्ट में बदलाव चुपचाप प्रोडक्शन न तोड़ें। कम जोखिम वाले आंतरिक कार्यों से शुरू करें और केवल आउटपुट गुणवत्ता पर भरोसा करने के बाद ही विस्तार करें। --- ## ऑनलाइन पर्सनल ब्रांड कैसे बनाएं: 2026 प्रैक्टिशनर का प्लेबुक Source: https://alejandrorioja.com/hi/how-to-build-a-personal-brand/ Published: 2026-07-02 Tags: Entrepreneurship, Growth TL;DR: पर्सनल ब्रांड एक विशिष्ट ऑडियंस को चुनकर, एक चैनल पर नियमित रूप से उपयोगी कंटेंट प्रकाशित करके और एक स्पष्ट दृष्टिकोण रखकर बनाया जाता है — न कि आपकी LinkedIn बायो को ऑप्टिमाइज़ करके। अपना निच संकरा करें, वास्तविक अनुभव से लिखें, ईमेल लिस्ट को अपने एकमात्र स्वामित्व वाले चैनल के रूप में बनाएं, और तब तक दोहराएं जब तक सही लोग आपको नज़रअंदाज़ न कर सकें। ## विषय सूची _जुलाई 2026 में अपडेट किया गया।_ **TL;DR:** पर्सनल ब्रांड एक विशिष्ट ऑडियंस को चुनकर, एक चैनल पर नियमित रूप से उपयोगी कंटेंट प्रकाशित करके और एक स्पष्ट दृष्टिकोण रखकर बनाया जाता है — न कि आपकी LinkedIn बायो को ऑप्टिमाइज़ करके। अपना निच संकरा करें, वास्तविक अनुभव से लिखें, ईमेल लिस्ट को अपने एकमात्र स्वामित्व वाले चैनल के रूप में बनाएं, और तब तक दोहराएं जब तक सही लोग आपको नज़रअंदाज़ न कर सकें। **[प्रैक्टिशनर का नोट]** मैंने कई व्यवसायों — Pickleland, AI एजेंट कंसल्टिंग, इस साइट — के जरिए सार्वजनिक रूप से निर्माण किया है। और मैं जो पैटर्न बार-बार देखता हूं वह हमेशा एक ही होता है: जो लोग पहचानने योग्य पर्सनल ब्रांड बनाते हैं वे सबसे प्रतिभाशाली नहीं होते। वे सबसे विशिष्ट और सबसे नियमित होते हैं। यहां वह फ्रेमवर्क है जिसे मैं उपयोग करता और सुझाता हूं। ## पर्सनल ब्रांड वास्तव में क्या है (और क्या नहीं) पर्सनल ब्रांड एक प्रश्न का उत्तर है: *जब आप कमरे में नहीं होते तो लोग आपके बारे में क्या कहते हैं?* यह आपका लोगो नहीं है। आपका कलर पैलेट नहीं है। आपके कितने फॉलोअर्स हैं यह नहीं है। पर्सनल ब्रांड वह मानसिक शॉर्टकट है जो लोग आपका नाम सुनते ही बनाते हैं — वह विशिष्ट समस्या जो वे सोचते हैं आप हल कर सकते हैं, वह परिप्रेक्ष्य जो वे आपसे उम्मीद करते हैं। अधिकांश लोग जो गलती करते हैं: वे दृष्टिकोण विकसित करने से पहले ब्रांड बनाने की कोशिश करते हैं। ब्रांड वास्तविक काम करके और उससे क्या सीखा उसके बारे में विशिष्ट होकर बनता है — यह पहले से बनाई हुई चीज़ नहीं है। शुरुआत से आप क्या नियंत्रित कर सकते हैं: 1. आप किससे बात करते हैं 2. आप उनके लिए कौन सी समस्या हल करते हैं 3. वे आपको कहां पाते हैं 4. आप कितनी नियमितता से दिखाई देते हैं समय के साथ क्या जमा होता है: - एक विशिष्ट प्रकार की विशेषज्ञता के लिए प्रतिष्ठा - एक ऑडियंस जो आपके निर्णय पर भरोसा करती है - इनबाउंड अवसर जिनका आपको पीछा नहीं करना पड़ा ## स्टेप 1: सबसे संकरा निच चुनें जिसके साथ आप जी सकते हैं पर्सनल ब्रांडिंग में सबसे आम विफलता का तरीका बहुत व्यापक होना है। "मार्केटिंग विशेषज्ञ।" "बिजनेस कंसल्टेंट।" "टेक एंटरप्रेन्योर।" ये ऐसी दुनिया में बेमानी लेबल हैं जहां सभी के पास हैं। आप जितना संकरा जाते हैं, उतनी जल्दी प्रतिष्ठा बनती है। इस फिल्टर से अपना निच टेस्ट करें: - **खोजे जाने के लिए पर्याप्त विशिष्ट।** क्या कोई आपके निच को Google पर खोज सकता है और उसके आसपास एक वास्तविक समुदाय पा सकता है? - **अनुशंसित किए जाने के लिए पर्याप्त विशिष्ट।** अगर कोई आपकी बिल्कुल वैसी समस्या वाले व्यक्ति से मिलता है, तो क्या वे पहले आपके बारे में सोचते हैं? - **2+ वर्षों तक कंटेंट बनाने के लिए पर्याप्त व्यापक।** [Semrush](/recommends/semrush) जैसे कीवर्ड टूल का उपयोग करके जांचें कि आपका निच खोजा जा रहा है या नहीं। ## स्टेप 2: एक प्राथमिक चैनल चुनें एक साथ हर जगह रहने की कोशिश करना हर जगह औसत दर्जे का होने का गारंटीशुदा तरीका है। शुरुआत में एक चैनल चुनें और गहराई से जाएं। - **लिखित कंटेंट (ब्लॉग/न्यूज़लेटर):** विश्लेषणात्मक, प्रैक्टिशनर ऑडियंस के लिए सबसे अच्छा। SEO के जरिए समय के साथ कंपाउंड होता है। - **LinkedIn:** B2B और पेशेवर ऑडियंस के लिए सबसे अच्छा। - **YouTube / वीडियो:** विजुअल डेमॉन्स्ट्रेशन से लाभ उठाने वाले विषयों के लिए सबसे अच्छा। - **X / Twitter:** फैलने वाले विचारों के लिए सबसे अच्छा। ## स्टेप 3: अपना दृष्टिकोण खोजें दृष्टिकोण के बिना कंटेंट शोर है। जो पर्सनल ब्रांड्स उद्धृत, अनुशंसित और मांगे जाते हैं उन्हें एक विशिष्ट परिप्रेक्ष्य अलग करता है — वास्तविक अनुभव से प्रेरित, दुनिया के काम करने के तरीके के बारे में एक राय। एक मजबूत POV में ये गुण होते हैं: - यह किसी ऐसी चीज़ पर आधारित है जो आपने वास्तव में की है, सिर्फ पढ़ी नहीं - यह आपकी ऑडियंस की कम से कम एक पारंपरिक धारणा को चुनौती देता है - यह इतना विशिष्ट है कि कुछ लोग असहमत होंगे ## स्टेप 4: स्वामित्व वाली ऑडियंस बनाएं हर वह प्लेटफॉर्म जिस पर आप बनाते हैं, अपना एल्गोरिदम बदल सकता है, आपके अकाउंट पर बैन लगा सकता है, या बंद हो सकता है। एकमात्र डिस्ट्रीब्यूशन चैनल जो आप वास्तव में स्वयं के हैं वह आपकी ईमेल लिस्ट है। पहले दिन से इसे बनाना शुरू करें। ईमेल के लिए मैं [ConvertKit](/recommends/convertkit) का उपयोग करता हूं — क्रिएटर न्यूज़लेटर के लिए विशेष रूप से बनाया गया। पर्सनल ब्रांड से ईमेल लिस्ट बढ़ाने का सबसे तेज़ तरीका: 1. **एक वास्तव में उपयोगी लीड मैगनेट बनाएं।** एक चेकलिस्ट, टेम्पलेट या छोटी गाइड जो एक विशिष्ट समस्या हल करे। 2. **हर कंटेंट पेज पर फोल्ड के ऊपर ऑप्ट-इन जोड़ें।** 3. **3-ईमेल वेलकम सीक्वेंस लिखें।** 4. **हर कंटेंट पीस में लिस्ट का उल्लेख करें।** ## स्टेप 5: नियमित रूप से प्रकाशित करें — कंपाउंडिंग का गणित यदि आप प्रति सप्ताह एक लंबा टुकड़ा प्रकाशित करते हैं: - **सप्ताह 1–8:** लगभग कोई नहीं पढ़ता। यह सामान्य है। - **महीने 3–4:** कुछ टुकड़ों को ऑर्गेनिक ट्रैफिक मिलना शुरू होता है। - **महीने 6–9:** सर्च ट्रैफिक कंपाउंड होता है। इनबाउंड पूछताछ आने लगती है। - **वर्ष 2:** आपके पास 100 कंटेंट टुकड़े हैं। आपका नाम सर्च और AI उत्तरों में आता है। मेरा नियम: यह काम कर रहा है या नहीं यह मूल्यांकन करने से पहले 6 महीने के लिए प्रतिबद्ध हों। ## विजुअल ब्रांड के बारे में मेरा सोच न्यूनतम व्यवहार्य विजुअल ब्रांड: - एक पेशेवर प्रोफाइल फोटो जिसमें आपका चेहरा स्पष्ट रूप से दिखाई दे - सभी प्लेटफॉर्म पर एक जैसी प्रोफाइल फोटो - स्पष्ट टैगलाइन और ईमेल ऑप्ट-इन के साथ सरल वेबसाइट [Canva](/recommends/canva) सोशल ग्राफिक्स और सरल डिजाइन के लिए ठीक है। ## सामान्य गलतियां 1. **सभी को खुश करने की कोशिश।** यदि आप "उद्यमियों" के लिए लिखते हैं, तो किसी के लिए नहीं लिख रहे। 2. **डिस्ट्रीब्यूशन के बिना प्रकाशित करना।** एक पोस्ट लिखना और ट्रैफिक का इंतजार करना कोई रणनीति नहीं है। 3. **हर तिमाही फोकस बदलना।** पर्सनल ब्रांड मोमेंटम का सबसे बड़ा हत्यारा। 4. **वैनिटी मेट्रिक्स मापना।** लाइक्स नहीं, लिस्ट साइज और कनवर्ज़न रेट मापें। 5. **"पर्याप्त विशेषज्ञ" होने तक इंतजार करना।** आपको अपने विषय में विश्व प्राधिकरण होने की जरूरत नहीं है। ## पर्सनल ब्रांड स्टैक - **ईमेल प्लेटफॉर्म:** [ConvertKit](/recommends/convertkit) - **SEO रिसर्च:** [Semrush](/recommends/semrush) - **कंटेंट क्रिएशन:** [Claude](/recommends/claude) - **डिजाइन:** [Canva](/recommends/canva) ## FAQ ### पर्सनल ब्रांड बनाने में कितना समय लगता है? यथार्थवादी रूप से, महत्वपूर्ण इनबाउंड मिलने से पहले 12–24 महीने की नियमित प्रकाशन की जरूरत है। ### क्या मुझे हर सोशल प्लेटफॉर्म पर रहना होगा? नहीं। एक प्लेटफॉर्म पर गहराई पांच पर सतही उपस्थिति से बेहतर है। ### कंटेंट क्वालिटी और प्रकाशन आवृत्ति में क्या अधिक महत्वपूर्ण है? दोनों, लेकिन समान रूप से नहीं। गुणवत्ता न्यूनतम स्तर निर्धारित करती है। आवृत्ति तय करती है कि क्या आपको सुधार के लिए आवश्यक अभ्यास मिलता है। ### असली नाम या ब्रांड नाम इस्तेमाल करना चाहिए? अपना असली नाम इस्तेमाल करें। वास्तविक व्यक्ति से जुड़े पर्सनल ब्रांड एल्गोरिदम परिवर्तनों में बेहतर जीवित रहते हैं। ### पर्सनल ब्रांड से पैसे कैसे कमाएं? चार विश्वसनीय रास्ते: (1) कोर्स / डिजिटल प्रोडक्ट, (2) कंसल्टिंग और एडवाइजरी, (3) एफिलिएट पार्टनरशिप, और (4) स्पॉन्सर्ड कंटेंट। --- **संबंधित:** [बनाने से पहले बिजनेस आइडिया को कैसे वैलिडेट करें](/how-to-validate-a-business-idea/) · [ईमेल लिस्ट को शून्य से कैसे बनाएं](/how-to-build-an-email-list/) · [न्यूज़लेटर को कैसे मोनेटाइज़ करें](/how-to-monetize-a-newsletter/) --- ## AI एजेंट में मेमोरी कैसे जोड़ें: प्रोडक्शन के लिए स्टेट पर्सिस्टेंस पैटर्न Source: https://alejandrorioja.com/hi/how-to-add-memory-to-an-ai-agent/ Published: 2026-06-30 Tags: AI Agents TL;DR: स्टेटलेस एजेंट — वे जो Worker बंद होने पर सब कुछ भूल जाते हैं — एक बार के काम के लिए ठीक हैं। जिस क्षण एजेंट को कल क्या हुआ याद रखना हो, लौटने वाले ग्राहक को पहचानना हो, या पिछले आउटपुट पर आधारित काम करना हो, आपको मेमोरी चाहिए। तीन पैटर्न हैं: वर्किंग मेमोरी (रन के दौरान का कॉन्टेक्स्ट, एक रन की अवधि के लिए KV में), एपिसोडिक मेमोरी (क्या और कब हुआ, एक क्वेरी करने योग्य लॉग) और सिमेंटिक मेमोरी (आप क्या जानते हैं, वेक्टर सर्च या स्ट्रक्चर्ड डेटा से प्राप्त)। सही पैटर्न को सही काम से जोड़ें। ## विषय-सूची _जून 2026 में अपडेट किया गया।_ **TL;DR:** स्टेटलेस एजेंट — वे जो Worker बंद होने पर सब कुछ भूल जाते हैं — एक बार के काम के लिए ठीक हैं। जिस क्षण एजेंट को कल क्या हुआ याद रखना हो, लौटने वाले ग्राहक को पहचानना हो, या पिछले आउटपुट पर आधारित काम करना हो, आपको मेमोरी चाहिए। तीन पैटर्न हैं: वर्किंग मेमोरी (रन के दौरान का कॉन्टेक्स्ट, एक रन की अवधि के लिए KV में), एपिसोडिक मेमोरी (क्या और कब हुआ, एक क्वेरी करने योग्य लॉग) और सिमेंटिक मेमोरी (आप क्या जानते हैं, वेक्टर सर्च या स्ट्रक्चर्ड डेटा से प्राप्त)। सही पैटर्न को सही काम से जोड़ें। **[ऑपरेटर का नजरिया]** मैं स्टेटलेस की दीवार से एक से अधिक बार टकराया हूँ। सोशल रिप्लाई एजेंट जो उन ग्राहकों से बार-बार अपना परिचय देता रहा जिनसे वह 20 बार बात कर चुका था। डेली ब्रीफ एजेंट जो चार दिन लगातार एक ही समस्या को फ्लैग करता रहा क्योंकि उसे याद नहीं था कि वह कल भी यही कर चुका है। सही प्रकार की मेमोरी जोड़ने से दोनों समस्याएँ हल हो गईं। यह है जो मैं उपयोग करता हूँ। ## स्टेटलेस एजेंट लगातार क्यों विफल होते हैं एक स्टेटलेस एजेंट हर रन केवल उसी से शुरू करता है जो आप उसे स्पष्ट रूप से देते हैं: सिस्टम प्रॉम्प्ट, यूज़र मैसेज, और इनवोकेशन के समय जो डेटा आप लाते हैं। उसे पिछले रन, पिछले यूज़र, या पिछले निर्णयों की कोई जानकारी नहीं होती। एक बार की क्लासिफिकेशन टास्क के लिए — एक कमेंट पढ़ें, कैटेगरी वापस करें — स्टेटलेस सही है। यह तेज़, सस्ता और अनुमानयोग्य है। जब आपको निरंतरता की जरूरत होती है, तब विफलता की सतह दिखाई देती है: - एक ग्राहक-सामना करने वाला एजेंट जो ग्राहक का इतिहास नहीं पहचानता - एक कंटेंट एजेंट जो एक लेख की सिफारिश करता है जो उसने पिछले सप्ताह भी की थी - एक मॉडरेशन एजेंट जो एक हल किए गए केस को फिर से एस्केलेट करता रहता है - एक डेली ब्रीफ जो हमेशा के लिए एक ही पुरानी अलर्ट दिखाता है ये सभी एक ही समस्या के लक्षण हैं: एजेंट के पास रनों के बीच कॉन्टेक्स्ट ले जाने का कोई तरीका नहीं है। ## तीन प्रकार की मेमोरी वह फ्रेमवर्क जो मुझे प्रोडक्शन में उपयोगी लगता है: 1. **वर्किंग मेमोरी** — एजेंट एक ही रन के दौरान _अभी_ क्या जानता है। इनवोकेशन के जीवनकाल के लिए KV या इन-मेमोरी में रखा जाता है। 2. **एपिसोडिक मेमोरी** — क्या और कब हुआ। एक स्ट्रक्चर्ड लॉग जिसे एजेंट हर रन की शुरुआत में खुद को ओरिएंट करने के लिए पढ़ता है। 3. **सिमेंटिक मेमोरी** — यह दुनिया, ग्राहकों, या एक नॉलेज बेस के बारे में क्या जानता है। प्रासंगिक होने पर स्ट्रक्चर्ड क्वेरी या वेक्टर सर्च के माध्यम से प्राप्त किया जाता है। आपको हमेशा तीनों की जरूरत नहीं होती। मेरे द्वारा चलाए जाने वाले अधिकांश एजेंटों को वर्किंग + एपिसोडिक की जरूरत होती है। सिमेंटिक मेमोरी बनाना सबसे कठिन है और तभी अपनी जगह कमाती है जब नॉलेज बेस इतना बड़ा हो कि कॉन्टेक्स्ट विंडो में नहीं आ सके। ## वर्किंग मेमोरी: रन-के-दौरान कॉन्टेक्स्ट वर्किंग मेमोरी वह स्टेट है जो एक एजेंट रन की अवधि के लिए रहती है। सबसे सरल रूप फंक्शन स्कोप में वेरिएबल्स हैं। अधिक दिलचस्प रूप एक शेयर्ड KV की है जिसे एक ही रन में सबटास्क पढ़ते और लिखते हैं। मेरा सोशल रिप्लाई एजेंट एक क्यू मैसेज में कमेंट्स का बैच प्रोसेस करते समय कॉन्टेक्स्ट जमा करने के लिए वर्किंग मेमोरी का उपयोग करता है। शुरुआत में यह KV से प्रत्येक ग्राहक की हालिया बातचीत का इतिहास पढ़ता है, प्रोसेसिंग के दौरान नया कॉन्टेक्स्ट जोड़ता है, और अंत में वापस लिखता है। ```typescript // workers/social-reply.ts async function processComment( comment: SocialCommentEvent, env: Env ): Promise { // इस ग्राहक का हालिया इतिहास KV से लोड करें (वर्किंग मेमोरी) const historyKey = `customer:${comment.userId}:history`; const rawHistory = await env.AGENT_KV.get(historyKey); const history: ConversationTurn[] = rawHistory ? JSON.parse(rawHistory) : []; // इतिहास से कॉन्टेक्स्ट-अवेयर सिस्टम प्रॉम्प्ट बनाएं const systemPrompt = buildSystemPrompt(history); const response = await anthropic.messages.create({ model: "claude-opus-4-8", max_tokens: 512, system: systemPrompt, messages: [{ role: "user", content: comment.text }], }); const reply = response.content[0].type === "text" ? response.content[0].text : ""; // इतिहास अपडेट करें — आखिरी 10 टर्न रखें, TTL 30 दिन const updatedHistory: ConversationTurn[] = [ ...history.slice(-9), { role: "assistant", content: reply, timestamp: comment.timestamp }, ]; await env.AGENT_KV.put(historyKey, JSON.stringify(updatedHistory), { expirationTtl: 60 * 60 * 24 * 30, }); await postReply(comment, reply, env); } ``` दो बातें ध्यान देने योग्य हैं। इतिहास 10 टर्न तक सीमित है — एक स्लाइडिंग विंडो इंजेक्ट करें, इसे असीमित रूप से न बढ़ने दें। TTL 30 दिन है: यदि एक ग्राहक एक महीने के लिए चुप रहता है, इतिहास समाप्त हो जाता है और एजेंट ताज़ा शुरू करता है। दोनों जानबूझकर हैं। ## एपिसोडिक मेमोरी: क्या और कब हुआ एपिसोडिक मेमोरी एजेंट का लॉग है। पिछले रनों का एक स्ट्रक्चर्ड रिकॉर्ड जिसे एजेंट हर नए रन की शुरुआत में खुद को दोहराने से बचाने के लिए पढ़ता है। मेरा डेली ब्रीफ एजेंट हर दिन एक ही पुरानी अलर्ट दिखाता था क्योंकि प्रत्येक रन को पता नहीं था कि पहले क्या फ्लैग किया गया था। समाधान: पिछली अलर्ट का एक स्ट्रक्चर्ड लॉग जिसे एजेंट ब्रीफ जनरेट करने से पहले पढ़ता है। ```typescript // workers/daily-brief.ts interface AlertLogEntry { id: string; surfacedAt: string; // ISO टाइमस्टैंप resolvedAt?: string; summary: string; } async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); // एपिसोडिक मेमोरी लोड करें: क्या पहले फ्लैग हो चुका है const rawLog = await env.AGENT_KV.get("brief:alert-log"); const alertLog: AlertLogEntry[] = rawLog ? JSON.parse(rawLog) : []; // केवल हालिया, अनसुलझी अलर्ट फ़िल्टर करें const sevenDaysAgo = new Date( Date.now() - 7 * 24 * 60 * 60 * 1000 ).toISOString(); const recentAlerts = alertLog.filter( (e) => e.surfacedAt > sevenDaysAgo && !e.resolvedAt ); const brief = await synthesizeBrief( { emails, calendar, tasks, recentAlerts }, env ); // इस रन में फ्लैग की गई नई अलर्ट से लॉग अपडेट करें const newAlerts: AlertLogEntry[] = brief.newAlerts.map((a) => ({ id: crypto.randomUUID(), surfacedAt: new Date().toISOString(), summary: a, })); const updatedLog = [...alertLog, ...newAlerts].slice(-100); // आखिरी 100 रखें await env.AGENT_KV.put("brief:alert-log", JSON.stringify(updatedLog)); await writeToWorkspace(brief.content, env); } ``` एजेंट को अब पता है कि वह पहले क्या कह चुका है। डुप्लिकेट अलर्ट ब्रीफ से तब तक बाहर रहती हैं जब तक अंतर्निहित समस्या नहीं बदलती। जब मैं किसी अलर्ट को हल के रूप में चिह्नित करता हूँ, तो वह सक्रिय सूची से गायब हो जाती है। यह पैटर्न सामान्यीकृत होता है: कोई भी एजेंट जो निर्णय, फ्लैग, या सिफारिशें उत्पन्न करता है, लॉग से लाभ उठाता है। लॉग सस्ता है (KV में कुछ KB), भुगतान अधिक है (कोई अनावश्यक आउटपुट नहीं)। ## सिमेंटिक मेमोरी: आप क्या जानते हैं सिमेंटिक मेमोरी नॉलेज बेस है। यह क्वेरी के समय "आप X के बारे में क्या जानते हैं?" का जवाब देती है, बजाय सब कुछ सिस्टम प्रॉम्प्ट में पहले से भरने के। सबसे सरल रूप KV या डेटाबेस में एक स्ट्रक्चर्ड लुकअप है। मेरा Pickleland बुकिंग एजेंट कन्फर्मेशन तैयार करने से पहले ग्राहक प्रोफाइल और कोर्ट प्राथमिकताएँ खोजता है: ```typescript // workers/booking-agent.ts interface CustomerProfile { userId: string; preferredCourts: string[]; experienceLevel: "beginner" | "intermediate" | "advanced"; specialNotes: string; } async function draftConfirmation( booking: BookingEvent, env: Env ): Promise { // KV से ग्राहक प्रोफाइल प्राप्त करें (सिमेंटिक मेमोरी — तथ्यात्मक ज्ञान) const profileKey = `customer:${booking.userId}:profile`; const rawProfile = await env.AGENT_KV.get(profileKey); const profile: CustomerProfile | null = rawProfile ? JSON.parse(rawProfile) : null; const systemPrompt = profile ? `आप व्यक्तिगत बुकिंग कन्फर्मेशन तैयार करते हैं। यह ग्राहक ${profile.preferredCourts.join(", ")} को प्राथमिकता देता है और ${profile.experienceLevel} स्तर का खिलाड़ी है। ${profile.specialNotes}` : "आप एक पिकलबॉल सुविधा के लिए बुकिंग कन्फर्मेशन तैयार करते हैं।"; const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 256, system: systemPrompt, messages: [ { role: "user", content: `इसके लिए कन्फर्मेशन तैयार करें: ${JSON.stringify(booking)}`, }, ], }); return response.content[0].type === "text" ? response.content[0].text : ""; } ``` बड़े नॉलेज बेस के लिए — प्रोडक्ट डॉक्यूमेंटेशन, एक सपोर्ट नॉलेज बेस, कॉन्टेक्स्ट विंडो में न आ सकने वाला कुछ भी — आपको वेक्टर स्टोर की जरूरत है। वर्कफ्लो है: क्वेरी एम्बेड करें, टॉप-k प्रासंगिक चंक्स प्राप्त करें, उन्हें कॉन्टेक्स्ट में इंजेक्ट करें। Cloudflare Vectorize इसे नेटिव रूप से हैंडल करता है यदि आप पहले से Workers पर हैं। बड़े इंडेक्स के लिए मैंने Upstash Vector का उपयोग किया है। चुनाव स्केल पर निर्भर करता है, सिद्धांत पर नहीं। सिमेंटिक मेमोरी के बारे में ईमानदार टिप्पणी: यह तीनों में बनाना और बनाए रखना सबसे कठिन है। इंडेक्स को अद्यतन रहना चाहिए। रिट्रीवल क्वालिटी भिन्न होती है। स्ट्रक्चर्ड लुकअप से शुरू करें — KV, D1 में एक टेबल — और वेक्टर सर्च तक तभी पहुँचें जब स्ट्रक्चर्ड दृष्टिकोण आपको जरूरी ज्ञान सतह को कवर न कर सके। ## मेमोरी निर्णय फ्रेमवर्क एजेंट में कोई मेमोरी जोड़ने से पहले, तीन सवालों के जवाब दें: 1. **क्या एजेंट को रनों के बीच याद रखने की जरूरत है?** यदि हर इनवोकेशन वास्तव में स्वतंत्र है — एक अनुवाद, एक वर्गीकरण, एक बार की पीढ़ी — मेमोरी छोड़ें। स्टेटलेस सरल और सस्ता है। 2. **क्या एजेंट खुद को दोहरा रहा है या अपने इतिहास से अंधा होकर काम कर रहा है?** यदि हाँ, तो पहले एपिसोडिक मेमोरी जोड़ें। यह सबसे कम प्रयास वाला समाधान है और अधिकांश "एजेंट X करता रहता है" शिकायतों को कवर करता है। 3. **क्या एजेंट हर यूज़र या इंटिटी को एक जैसा मान रहा है जबकि ऐसा नहीं करना चाहिए?** यदि हाँ, तो वर्किंग मेमोरी (ग्राहक इतिहास, यूज़र प्रोफाइल) या सिमेंटिक मेमोरी (एक सर्च या रिट्रीवल सिस्टम) जोड़ें। जो गलती मैं सबसे अधिक देखता हूँ: कोई एक विशाल नॉलेज बेस (सिमेंटिक मेमोरी) एक ऐसे एजेंट में जोड़ता है जो वास्तव में इसलिए विफल हो रहा था क्योंकि उसके पास एपिसोडिक मेमोरी नहीं थी — उसने क्या किया इसका कोई लॉग नहीं था। जटिलता समस्या से मेल नहीं खाती। ## प्रोडक्शन में मैं वास्तव में क्या उपयोग करता हूँ 30+ एजेंटों में: - **सभी** में कम से कम वर्किंग मेमोरी है — एक रन के भीतर कुछ न कुछ स्टेट, भले ही वह केवल कॉन्टेक्स्ट विंडो ही क्यों न हो। - **लगभग आधे** में एपिसोडिक मेमोरी है — पिछले रन, निर्णयों, या फ्लैग का एक लॉग। यह लगभग हमेशा जोड़ने लायक होता है। - **तीन या चार** में वेक्टर स्टोर द्वारा समर्थित वास्तविक सिमेंटिक मेमोरी है। ये वे एजेंट हैं जो एक बड़े, गतिशील नॉलेज बेस पर सवालों का जवाब देते हैं। Cloudflare KV वर्किंग और एपिसोडिक मेमोरी के लिए मेरा डिफ़ॉल्ट स्टोर है। यह तेज़, सस्ता और Workers में नेटिव रूप से एकीकृत है — कोई अतिरिक्त क्लाइंट नहीं, कोई अलग क्रेडेंशियल नहीं। सीमा: KV अंततः consistent है और उच्च-आवृत्ति लेखन के लिए उपयुक्त नहीं है। उन एजेंटों के लिए जो प्रति सेकंड कई बार स्टेट लिखते हैं, मैं इसके बजाय Durable Objects या D1 डेटाबेस का उपयोग करता हूँ। वेक्टर-समर्थित सिमेंटिक मेमोरी के लिए, मैं छोटे-से-मध्यम इंडेक्स (लगभग ~100K वेक्टर से कम) के लिए Cloudflare Vectorize और उससे बड़े के लिए Upstash Vector का उपयोग करता हूँ। दोनों में फर्स्ट-क्लास JavaScript क्लाइंट हैं। ## ऑपरेटर का निष्कर्ष एजेंट में मेमोरी तभी जोड़ें जब स्टेटलेस व्यवहार वास्तविक समस्याएँ पैदा कर रहा हो — दोहराए जाने वाले आउटपुट, ग्राहक इतिहास के अंधे धब्बे, पिछले निर्णयों की अनदेखी। फिर सही परत चुनें: रन के दौरान के कॉन्टेक्स्ट के लिए वर्किंग मेमोरी, ऐतिहासिक रूप से क्या हुआ इसके लिए एपिसोडिक, आप क्या जानते हैं इसके लिए सिमेंटिक। यदि अनिश्चित हैं तो एपिसोडिक से शुरू करें — यह सबसे कम जटिलता के साथ सबसे सामान्य विफलता मोड को ठीक करती है। स्ट्रक्चर्ड लुकअप समाप्त होने तक वेक्टर डेटाबेस तक न पहुँचें। सबसे अच्छी मेमोरी सिस्टम वह है जो सबसे सरल है और एजेंट को सही ढंग से व्यवहार करने देती है। --- **संबंधित:** [30+ प्रोडक्शन एजेंट चलाने के लिए मेरा एजेंट स्टैक](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [इवेंट-ट्रिगर्ड बनाम शेड्यूल्ड एजेंट](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [मैं कैसे मापता हूँ कि एक AI एजेंट वास्तव में काम कर रहा है](/how-i-measure-whether-an-ai-agent-is-actually-working/) **आपके उपयोग के मामले के लिए एजेंट मेमोरी डिज़ाइन करने में मदद चाहिए?** [संपर्क करें](/contact/) — मैं ऑपरेटर टीमों के लिए प्रोडक्शन एजेंट सिस्टम डिज़ाइन करता हूँ। --- ## ईमेल लिस्ट को शून्य से कैसे बनाएं: 2026 प्लेबुक Source: https://alejandrorioja.com/hi/how-to-build-an-email-list/ Published: 2026-06-27 Tags: Entrepreneurship, Growth TL;DR: ईमेल लिस्ट एकमात्र डिस्ट्रीब्यूशन चैनल है जिसे आप वास्तव में ओन करते हैं। एक लीड मैग्नेट से शुरुआत करें जो एक विशिष्ट समस्या हल करे, ऑप्ट-इन को ऊपर रखें, और सब्सक्राइब होते ही 3-ईमेल वेलकम सीक्वेंस भेजें। गुणवत्ता मात्रा से हमेशा जीतती है — 1,000 सक्रिय सब्सक्राइबर 10,000 ठंडे सब्सक्राइबरों से बेहतर हैं। ## सामग्री तालिका _जून 2026 में अपडेट किया गया।_ **संक्षेप:** ईमेल लिस्ट एकमात्र डिस्ट्रीब्यूशन चैनल है जिसे आप वास्तव में ओन करते हैं। एक लीड मैग्नेट से शुरुआत करें जो एक विशिष्ट समस्या हल करे, ऑप्ट-इन को ऊपर रखें, और सब्सक्राइब होते ही 3-ईमेल वेलकम सीक्वेंस भेजें। गुणवत्ता मात्रा से हमेशा जीतती है — 1,000 सक्रिय सब्सक्राइबर 10,000 ठंडे सब्सक्राइबरों से बेहतर हैं। **[ऑपरेटर का दृष्टिकोण]** हर उस बिजनेस में जिसमें मैं शामिल रहा और जिसने एक टिकाऊ रेवेन्यू इंजन बनाया, एक चीज़ समान थी: एक लिस्ट। फॉलोअर्स नहीं। इम्प्रेशन नहीं। उन लोगों की लिस्ट जिन्होंने आपसे सुनने की इच्छा जताई। यहाँ बताया गया है कि इसे शून्य से कैसे बनाएं। ## एकमात्र संपत्ति जो आप वास्तव में ओन करते हैं हर दूसरा डिस्ट्रीब्यूशन चैनल गायब हो सकता है। Google एल्गोरिदम अपडेट सर्च रैंकिंग मिटा देता है। प्लेटफॉर्म पॉलिसी बदलने से Facebook रीच खत्म हो जाती है। एड अकाउंट बिना चेतावनी के सस्पेंड हो जाता है। आपकी ईमेल लिस्ट इसका अपवाद है। जब आपके पास ईमेल लिस्ट होती है, तो डिलीवरी पर आपका कंट्रोल होता है। कोई एल्गोरिदम यह नहीं तय करता कि आपका कंटेंट कौन देखे। कोई प्लेटफॉर्म फीस हर बार टोल नहीं वसूलती जब आप अपनी ऑडियंस तक पहुंचना चाहते हैं। इसीलिए ईमेल लिस्ट बनाना पहली चीज़ है जो मैं हर फाउंडर को बताता हूं — SEO से पहले, पेड एड्स से पहले, सोशल मीडिया से पहले। ## चरण 1: एक ईमेल प्लेटफॉर्म चुनें एक भी एड्रेस कलेक्ट करने से पहले, आपको स्टोर करने और भेजने के लिए एक प्लेटफॉर्म चाहिए। Gmail का उपयोग न करें। अपने बिजनेस ईमेल का उपयोग न करें। उचित कंप्लायंस और डिलीवरेबिलिटी इंफ्रास्ट्रक्चर वाले एक उद्देश्य-निर्मित टूल का उपयोग करें। 2026 में मेरी दो पसंद: **[ConvertKit](/recommends/convertkit)** — क्रिएटर्स और सोलो ऑपरेटर्स के लिए सबसे अच्छा। सब्सक्राइबर टैगिंग और सेगमेंटेशन सिस्टम वाकई उत्कृष्ट है। 1,000 सब्सक्राइबर तक मुफ्त। **[Moosend](/recommends/moosend)** — उन छोटे बिजनेसों के लिए सबसे अच्छा जो ConvertKit की कीमत के बिना ऑटोमेशन चाहते हैं। मजबूत ड्रैग-एंड-ड्रॉप बिल्डर और लगातार अच्छी डिलीवरेबिलिटी। यदि आप शून्य से शुरू कर रहे हैं, तो दोनों के पास फ्री टियर हैं जो आपके पहले कुछ सौ सब्सक्राइबरों को कवर करते हैं। कुछ भी भेजने से पहले अपने डोमेन पर DKIM, SPF, और DMARC ऑथेंटिकेशन सेट करें — 2024 से वॉल्यूम सेंडर्स के लिए Gmail और Yahoo द्वारा यह अनिवार्य है, और यह पहले दिन से आपकी सेंडर रेपुटेशन की रक्षा करता है। ## चरण 2: डाउनलोड करने योग्य लीड मैग्नेट बनाएं लीड मैग्नेट वह है जो आप किसी के ईमेल एड्रेस के बदले में ऑफर करते हैं। अधिकांश लोग जो गलती करते हैं: वे कुछ सामान्य ऑफर करते हैं। "हमारे न्यूज़लेटर को सब्सक्राइब करें" लीड मैग्नेट नहीं है। यह बिना किसी बदले के ट्रस्ट की मांग है। आपके लीड मैग्नेट को एक विशिष्ट व्यक्ति की एक विशिष्ट समस्या हल करनी चाहिए। जितना अधिक विशिष्ट, उतना बेहतर कन्वर्ट होता है। **2026 में काम करने वाले फॉर्मेट:** 1. **चीट शीट और टेम्पलेट** — एक पेज का रिसोर्स जिसे कोई तुरंत उपयोग कर सके। जितना प्लग-एंड-प्ले, उतना बेहतर। 2. **मिनी-कोर्स (3–5 ईमेल)** — एक छोटी सीक्वेंस जो एक स्किल सिखाती है, स्वचालित रूप से डिलीवर होती है। एक साथ लिस्ट और रिलेशनशिप दोनों बनाती है। 3. **कैलकुलेटर या स्प्रेडशीट** — उच्च परसीव्ड वैल्यू। मार्केट साइजिंग टूल, प्राइसिंग मॉडल, बजट टेम्पलेट। ये कन्वर्ट होते हैं क्योंकि ये वास्तविक काम बचाते हैं। 4. **एक्सक्लूसिव डेटा या रिसर्च** — ओरिजिनल सर्वे रिजल्ट या बेंचमार्क रिपोर्ट। दोहराना मुश्किल, उच्च विश्वसनीयता। 5. **स्वाइप फाइल्स** — असली उदाहरणों का कलेक्शन (एड कॉपी, सब्जेक्ट लाइन्स, लैंडिंग पेज हेडलाइन)। प्रैक्टिशनर इनके लिए भुगतान करते हैं। 6. **वेबिनार या ट्रेनिंग रिप्ले** — एक मौजूदा रिकॉर्डिंग को ऑप्ट-इन के रूप में रीपर्पज़ करें। सेटअप में 20 मिनट लगते हैं। एक अनिवार्य शर्त: लीड मैग्नेट सीधे उससे संबंधित होना चाहिए जिसके बारे में आप ईमेल करेंगे। एक Facebook Ad टेम्पलेट जो B2B SaaS न्यूज़लेटर के लिए सब्सक्राइबर कैप्चर करता है, लिस्ट क्वालिटी की आपदा का इंतज़ार कर रहा है। ## चरण 3: ऑप्ट-इन फॉर्म वहाँ रखें जहाँ वे काम करते हैं फॉर्म प्लेसमेंट कॉपी से ज़्यादा कन्वर्जन ड्राइव करता है। ऑप्ट-इन फॉर्म वहाँ रखें जहाँ ध्यान पहले से मौजूद है: 1. **होमपेज पर फोल्ड के ऊपर** — फुटर में नहीं। साइडबार में नहीं। फोल्ड के ऊपर, इस बारे में स्पष्ट विवरण के साथ कि उन्हें क्या मिलेगा। 2. **हर ब्लॉग पोस्ट के अंत में** — जिसने आपकी पूरी पोस्ट पढ़ी वह पहले से क्वालिफाइड है। उसे तब पकड़ें जब वह अभी भी एंगेज हो। 3. **एग्जिट-इंटेंट पॉपअप** — तब ट्रिगर होता है जब विज़िटर टैब बंद करने वाला हो। विवादास्पद, लेकिन काम करता है। 4. **डेडिकेटेड लैंडिंग पेज** — बिना नेविगेशन के एक स्टैंडअलोन पेज। यहीं आप पेड ट्रैफिक भेजते हैं। 5. **कंटेंट अपग्रेड** — एक रिसोर्स जो एक विशिष्ट पोस्ट को बेहतर बनाता है। TAM/SAM/SOM गाइड के अंदर एक मार्केट साइजिंग स्प्रेडशीट उसी पेज पर एक सामान्य ऑफर से 3–5 गुना ज़्यादा कन्वर्ट करती है। कॉपी टिप: फॉर्मेट नहीं, आउटकम से शुरू करें। "5-पेज गाइड पाएं" कमज़ोर है बनाम "अपने मार्केट साइज़ को ऐसे जानें जैसे एक VC जानता है।" ## चरण 4: वेलकम सीक्वेंस लिखें जिस पल कोई सब्सक्राइब करता है, आपके पास उनका अधिकतम ध्यान होता है। इसे चुप्पी में बर्बाद न करें। कम से कम 3 ईमेल भेजें: **ईमेल 1 (तुरंत):** लीड मैग्नेट डिलीवर करें। कन्फर्म करें कि वे किसके लिए साइन अप किए। आगे क्या आएगा इसके लिए अपेक्षाएं सेट करें। **ईमेल 2 (दिन 2):** आपका सबसे अच्छा कंटेंट — एक पोस्ट, केस स्टडी, फ्रेमवर्क। कोई पिच नहीं। बस यह प्रमाण कि सब्सक्राइब करना सार्थक था। **ईमेल 3 (दिन 4–5):** आपकी ओरिजिन स्टोरी और पॉइंट ऑफ व्यू। आप इस विषय की परवाह क्यों करते हैं? आप क्या मानते हैं जो आपके क्षेत्र में अधिकांश लोग नहीं मानते? यहीं ट्रस्ट बनता है। उसके बाद, एक सुसंगत कैडेंस बनाए रखें। साप्ताहिक मानक है। द्वि-साप्ताहिक काम करता है अगर आप साप्ताहिक गुणवत्ता बनाए नहीं रख सकते। सबसे बड़ी गलती लॉन्च पर एक बार ईमेल करना है और फिर तीन महीने के लिए गायब हो जाना। ## चरण 5: अपने ऑप्ट-इन पर ट्रैफिक लाएं बिना ट्रैफिक के फॉर्म किसी को कन्वर्ट नहीं करता। सबसे भरोसेमंद ग्रोथ चैनल: **ऑर्गेनिक सर्च** — ब्लॉग पोस्ट जो आपके लीड मैग्नेट द्वारा हल की जाने वाली समस्याओं के लिए रैंक करती हैं। जो आपके विषय की खोज करता है और आपकी पोस्ट पाता है वह आपके ऑफर के लिए पहले से क्वालिफाइड है। यह सबसे कम लागत, उच्चतम रिटेंशन चैनल है। **सोशल मीडिया (ऑर्गेनिक)** — LinkedIn पोस्ट, Twitter/X थ्रेड, या शॉर्ट-फॉर्म वीडियो जो लोगों को आपके ऑप्ट-इन पेज तक ले जाएं। हर पोस्ट एक टीज़र होनी चाहिए, पूरी कहानी नहीं। **न्यूज़लेटर स्वैप और को-प्रमोशन** — आसन्न स्पेस में न्यूज़लेटर खोजें और मेंशन का आदान-प्रदान करें। आप उनकी लिस्ट को प्रमोट करते हैं; वे आपकी। 500 से 5,000 सब्सक्राइबर तक बढ़ने के सबसे तेज़ तरीकों में से एक। **पॉडकास्ट गेस्ट अपीयरेंस** — अक्सर नजरअंदाज किया जाता है। 2,000 निच लिस्नर्स को भेजा गया 30 मिनट का एपिसोड 50–100 गहरे रुचि रखने वाले सब्सक्राइबर जोड़ सकता है। **पेड एड्स** — अनवैलिडेटेड ऑफर के लिए एड्स न चलाएं। पहले अपने ऑप्ट-इन पेज को ऑर्गेनिक रूप से कन्वर्ट करवाएं, फिर पेड ट्रैफिक से स्केल करें। ## चरण 6: लिस्ट को साफ रखें ईमेल लिस्ट खराब होती है। लोग नौकरी बदलते हैं, ईमेल बदलते हैं, रुचियां बदलती हैं। अगर आप अपनी लिस्ट साफ नहीं करते, तो डिलीवरेबिलिटी प्रभावित होती है — मतलब एंगेज सब्सक्राइबर भी आपके ईमेल देखना बंद कर देते हैं। बेस्ट प्रैक्टिस: - **हर 6 महीने में री-एंगेजमेंट कैम्पेन** — किसी भी ऐसे व्यक्ति को ईमेल करें जिसने 90+ दिनों में कुछ भी नहीं खोला। उन्हें रुकने का कारण दें। अगर वे एंगेज नहीं होते, तो हटा दें। - **हार्ड बाउंस तुरंत हटाएं** — उच्च बाउंस रेट इनबॉक्स प्रोवाइडर्स को बताती है कि आपकी लिस्ट गंदी है। - **एंगेजमेंट के अनुसार सेगमेंट करें** — सक्रिय और ठंडे सब्सक्राइबरों को अलग-अलग टैग करें। टाइम-सेंसिटिव कैम्पेन केवल सक्रिय सेगमेंट को भेजें। सब्सक्राइबर डिलीट करना कुछ खोने जैसा लगता है। व्यवहार में, यह उन सब्सक्राइबरों की रक्षा करता है जिन्हें आप रखना चाहते हैं। ## ईमानदार चेतावनियां **बनाने में समय लगता है।** केवल ऑर्गेनिक तरीकों से शून्य से शुरू करके, 1,000 सब्सक्राइबर तक पहुंचने में 3–6 महीने का इंतज़ार करें। जो हफ्तों में हजारों का वादा करता है वह वैनिटी मेट्रिक्स या ठंडे, अनएंगेज्ड कॉन्टैक्ट बेच रहा है जो आप नहीं चाहते। **निच मायने रखती है।** B2B ऑडियंस डेटा और केस स्टडी पर प्रतिक्रिया देती है। कंज्यूमर ऑडियंस डिस्काउंट और एंटरटेनमेंट पर प्रतिक्रिया देती है। लीड मैग्नेट और कंटेंट कैडेंस ऑडियंस से मेल खाना चाहिए। **लीड मैग्नेट पुराने पड़ते हैं।** जो आज अच्छी तरह कन्वर्ट होता है वह 18 महीनों में पुराना हो सकता है जब प्रतिस्पर्धी फॉर्मेट कॉपी करते हैं। अपने लीड मैग्नेट को सालाना रिफ्रेश करने की योजना बनाएं। ## यथार्थवादी बेंचमार्क | मेट्रिक | उद्योग औसत | अच्छा | |--------|-----------------|------| | पॉपअप ऑप्ट-इन रेट | 2–4% | 5–8% | | लैंडिंग पेज ऑप्ट-इन रेट | 20–30% | 40–60% | | वेलकम ईमेल ओपन रेट | 50–60% | 70%+ | | चालू ओपन रेट | 20–25% | 35–45% | | क्लिक-थ्रू रेट | 2–3% | 5–10% | पहले 90 दिनों में इन नंबरों को ऑप्टिमाइज़ न करें। इंफ्रास्ट्रक्चर बनाएं, लीड मैग्नेट चलाएं, लगातार भेजें। फिर दोहराएं। ## जून 2026 के लिए अपडेट **AI-जनरेटेड लीड मैग्नेट** — Claude जैसे टूल मिनटों में 10-पेज PDF गाइड, स्वाइप फाइल, या टेम्पलेट तैयार कर सकते हैं। हाई-क्वालिटी लीड मैग्नेट बनाने की बाधा लगभग शून्य है। अब अंतर वादे की विशिष्टता और आपकी ऑडियंस के लिए प्रासंगिकता है। **Gmail और Yahoo ऑथेंटिकेशन** — 2024 से, प्रतिदिन 1,000 से अधिक एड्रेस को ईमेल करने वाले सेंडर्स के लिए DKIM, SPF, और DMARC अनिवार्य हैं। [ConvertKit](/recommends/convertkit) और [Moosend](/recommends/moosend) दोनों ऑनबोर्डिंग के दौरान सेटअप में आपका मार्गदर्शन करते हैं। इसे ज़रूरत पड़ने से पहले करें। **AI सर्च ट्रैफिक** — एक अच्छी तरह संरचित ऑप्ट-इन पेज जिसमें स्पष्ट TL;DR और सर्च क्वेरी का सीधा जवाब हो, ChatGPT, Perplexity, और Google AI Overviews में दिख सकती है। मैंने ऑप्ट-इन लैंडिंग पेजों को बिना किसी SEO काम के AI सर्च से लगातार ट्रैफिक मिलते देखा है — क्योंकि पेज सीधे एक विशिष्ट प्रश्न का उत्तर देती है। ## अक्सर पूछे जाने वाले प्रश्न **मोनेटाइज़ करने के लिए कितने सब्सक्राइबर चाहिए?** कोई यूनिवर्सल नंबर नहीं है। मैंने उच्च-इंटेंट निच में 500 गहरे एंगेज्ड सब्सक्राइबरों वाले न्यूज़लेटर को 20,000 जेनेरिक कॉन्टैक्ट की लिस्ट से बेहतर प्रदर्शन करते देखा है। सवाल यह है कि क्या आपके सब्सक्राइबरों के पास कोई समस्या है और क्या वे इसे हल करने के लिए आप पर भरोसा करते हैं। **क्या मुझे ईमेल लिस्ट खरीदनी चाहिए?** नहीं। खरीदी हुई लिस्ट में भयानक एंगेजमेंट होती है, आपको स्पैम के रूप में फ्लैग करेगी, और आपका अकाउंट सस्पेंड कर सकती है। कोई शॉर्टकट नहीं है। **कितनी बार ईमेल करना चाहिए?** जितनी बार गुणवत्ता बनाए रखते हुए कर सकते हैं। साप्ताहिक आपको मन में रखता है। सबसे बड़ी गलती महीनों चुप रहना और एक पिच के साथ वापस आना है। **डबल ऑप्ट-इन या सिंगल?** ज़्यादातर मामलों में डबल ऑप्ट-इन। कन्फर्मेशन लिस्ट साइज़ कम करती है लेकिन एंगेजमेंट और डिलीवरेबिलिटी में नाटकीय सुधार करती है। **शुरुआती लोगों के लिए सबसे अच्छा ईमेल प्लेटफॉर्म कौन सा है?** पर्सनल ब्रांड या कंटेंट बिजनेस बना रहे क्रिएटर्स के लिए [ConvertKit](/recommends/convertkit)। वहनीयता और ऑटोमेशन चाहने वाले छोटे व्यवसायों के लिए [Moosend](/recommends/moosend)। ## आगे कहाँ जाएंगे ईमेल लिस्ट अकेले नहीं रहती। आपकी सबसे अच्छी परफॉर्मिंग पोस्ट में कंटेंट अपग्रेड होना चाहिए। आपके ईमेल गहन गाइड से लिंक होने चाहिए। आपका लीड मैग्नेट उस सटीक समस्या को हल करना चाहिए जो आपके सबसे अधिक ट्रैफिक वाले पेज पर है। वह लूप — ट्रैफिक → ऑप्ट-इन → नर्चर → ट्रस्ट → ऑफर — हर उस टिकाऊ ऑनलाइन बिजनेस की नींव है जिसमें मैं शामिल रहा हूं। यदि आप अपनी विशिष्ट स्थिति के लिए इसे कैसे सेट करें इस बारे में बात करना चाहते हैं, तो [संपर्क पेज](/contact) शुरू करने के लिए सही जगह है। --- ## न्यूज़लेटर से पैसे कैसे कमाएं: 5 रेवेन्यू मॉडल जो सच में काम करते हैं Source: https://alejandrorioja.com/hi/how-to-monetize-a-newsletter/ Published: 2026-06-25 Tags: Entrepreneurship, Growth TL;DR: अधिकांश न्यूज़लेटर मोनेटाइज़ेशन में इसलिए फेल हो जाते हैं क्योंकि वे अपनी लिस्ट साइज़ के लिए गलत मॉडल का पीछा करते हैं। पांच मॉडल जो काम करते हैं: पेड सब्सक्रिप्शन (नीश अथॉरिटी के लिए सबसे अच्छा), स्पॉन्सरशिप (5,000+ सब्सक्राइबर के बाद सबसे अच्छा), एफिलिएट रेकमेंडेशन (किसी भी साइज़ पर सबसे कम रुकावट), कोर्स और प्रोडक्ट फ़नल (सबसे अधिक इनकम सीलिंग), और सर्विस अपसेल (असली पैसे का सबसे तेज़ रास्ता)। एक से शुरू करें। दूसरा तभी जोड़ें जब पहला काम कर रहा हो। ## Table of contents _जून 2026 में अपडेट किया गया।_ **TL;DR:** अधिकांश न्यूज़लेटर मोनेटाइज़ेशन में इसलिए फेल हो जाते हैं क्योंकि वे अपनी लिस्ट साइज़ के लिए गलत मॉडल का पीछा करते हैं। पांच मॉडल जो काम करते हैं: पेड सब्सक्रिप्शन (नीश अथॉरिटी के लिए सबसे अच्छा), स्पॉन्सरशिप (5,000+ सब्सक्राइबर के बाद सबसे अच्छा), एफिलिएट रेकमेंडेशन (किसी भी साइज़ पर सबसे कम रुकावट), कोर्स और प्रोडक्ट फ़नल (सबसे अधिक इनकम सीलिंग), और सर्विस अपसेल (असली पैसे का सबसे तेज़ रास्ता)। एक से शुरू करें। दूसरा तभी जोड़ें जब पहला काम कर रहा हो। **[ऑपरेटर का नज़रिया]** मैं तब से न्यूज़लेटर चला रहा हूं जब इसे "न्यूज़लेटर बिज़नेस" कहना फैशन नहीं था। सफर की ईमानदार कहानी: मैंने सब कुछ एक साथ करने की कोशिश की, लगभग कुछ नहीं कमाया, एक मॉडल पर फोकस किया और कमाना शुरू किया। यहाँ वो है जो मैंने सीखा और जो मैं अब उन ऑपरेटर्स में लगातार काम करते देख रहा हूं जिनके साथ मैं काम करता हूं। ## अधिकांश न्यूज़लेटर कभी एक रुपया क्यों नहीं कमाते मोनेटाइज़ेशन की समस्या आमतौर पर सीक्वेंसिंग की समस्या होती है। लोग न्यूज़लेटर लॉन्च करते हैं, उसे धीरे-धीरे बढ़ाते हैं, फिर एक साथ हर रेवेन्यू स्ट्रीम जोड़ने की कोशिश करते हैं — यहाँ एक पेड टियर, वहाँ एक स्पॉन्सर स्लॉट, हर इश्यू में एक एफिलिएट लिंक। नतीजा एक ऐसा न्यूज़लेटर होता है जो शॉपिंग मॉल जैसा लगता है: सब कुछ बिक्री पर है, कुछ भी असली नहीं लगता, और पाठक दूर हो जाते हैं। जो न्यूज़लेटर लगातार कमाते हैं वे पहले एक काम अच्छे से करते हैं। वे साबित करते हैं कि एक मॉडल उनके खास ऑडियंस के लिए काम करता है। फिर — और सिर्फ तभी — वे दूसरा जोड़ते हैं। आपकी लिस्ट साइज़ भी तय करती है कि कौन से मॉडल व्यावहारिक हैं। 500 सब्सक्राइबर की लिस्ट स्पॉन्सर खोजने के लिए गलत टूल है। 50,000 सब्सक्राइबर की लिस्ट काफी पैसा मेज़ पर छोड़ रही है अगर वो सिर्फ एफिलिएट लिंक चला रही है। मॉडल को लिस्ट के साथ मेल खाना चाहिए। ## मॉडल 1: पेड सब्सक्रिप्शन **सबसे अच्छा:** परिभाषित प्रोफेशनल या हाई-इंटरेस्ट ऑडियंस वाले नीश अथॉरिटी न्यूज़लेटर के लिए। पेड सब्सक्रिप्शन न्यूज़लेटर मोनेटाइज़ेशन का सबसे शुद्ध रूप है: पाठक सीधे कंटेंट के लिए भुगतान करते हैं। Beehiiv और Substack जैसे प्लेटफॉर्म इसे फ्री लिस्ट में जोड़ना आसान बनाते हैं। क्या इसे काम करता है: - एक विशिष्ट, हाई-वैल्यू नीश जहाँ जानकारी दुर्लभ है या समय बचाती है (फाइनेंशियल एनालिसिस, इंडस्ट्री इंटेलिजेंस, ऑपरेटर-लेवल टैक्टिक्स) - "भुगतान करने पर सब्सक्राइबर को क्या मिलता है जो उन्हें फ्री में नहीं मिलता?" का स्पष्ट जवाब - एक फ्री टियर जो वाकई मूल्यवान हो — पतला किया हुआ वर्जन नहीं, बल्कि पेड टियर के अप्रोच का एक स्वाद क्या इसे खत्म करता है: - कम अर्जेंसी वाले जनरल टॉपिक्स ("मार्केटिंग टिप्स", "पर्सनल डेवलपमेंट") - इस बात का सबूत होने से पहले पेड लॉन्च करना कि फ्री सब्सक्राइबर आपका कंटेंट लगातार पढ़ते हैं यथार्थवादी रेवेन्यू: $5–$20/माह प्रति सब्सक्राइबर। 2,000 लोगों की लिस्ट से 5% कन्वर्जन पर, यह 100 पेड सब्सक्राइबर $10/माह पर = $1,000 MRR है। छोटा, लेकिन असली, और यह बढ़ता जाता है। ## मॉडल 2: स्पॉन्सरशिप और नेटिव एडवर्टाइज़िंग **सबसे अच्छा:** परिभाषित ऑडियंस डेमोग्राफिक के साथ 5,000+ सब्सक्राइबर वाले न्यूज़लेटर के लिए। स्पॉन्सरशिप सबसे दिखाई देने वाला मॉडल है — आपके ऑडियंस के लिए प्रासंगिक ब्रांड को बेचा गया एक इश्यू स्लॉट। जब यह काम करता है, तो अच्छे से काम करता है: नीश B2B या हाई-इनकम ऑडियंस के लिए $100–$500+ CPM (प्रति हज़ार सब्सक्राइबर लागत) सामान्य है। ईमानदार बाधा: स्पॉन्सर स्केल और स्पेसिफिसिटी चाहते हैं। "मेरे पास मार्केटिंग में रुचि रखने वाले 1,000 सब्सक्राइबर हैं" डील बंद नहीं करता। "मेरे पास 6,000 सब्सक्राइबर हैं जो 10–500 एम्प्लॉयी वाली कंपनियों में मार्केटिंग मैनेजर हैं, 52% ओपन रेट के साथ" करता है। वहाँ कैसे पहुंचें: 1. **अपने ऑडियंस को परिभाषित करें** इंटरेस्ट टर्म्स में नहीं, डेमोग्राफिक टर्म्स में 2. **5,000 सब्सक्राइबर तक पहुंचें** स्पॉन्सर पिच करने से पहले न्यूनतम क्रेडिबिलिटी फ्लोर के रूप में 3. **एंगेजमेंट साबित करें** — 40% से ऊपर ओपन रेट असली डिफरेंशिएटर हैं 4. **एक मीडिया किट बनाएं** — सब्सक्राइबर काउंट, ओपन रेट, ऑडियंस प्रोफाइल और स्पॉन्सरशिप पैकेज के साथ एक पेज का PDF 5. **इनबाउंड से शुरू करें** — आउटबाउंड सेल्स प्रोसेस बनाने से पहले स्पॉन्सरशिप मार्केटप्लेस में लिस्ट करें CPM रियलिटी चेक: अगर आपकी लिस्ट 45% ओपन रेट पर कन्वर्ट होती है और आप $200 CPM पर प्रति इश्यू एक स्पॉन्सर स्लॉट बेचते हैं, तो 5,000 सब्सक्राइबर की लिस्ट प्रति स्पॉन्सर इश्यू $1,000 जनरेट करती है। चार इश्यू प्रति माह पर, यह एक स्पॉन्सर स्लॉट से $4,000/माह है। दो स्लॉट के साथ, $8,000/माह। गणित काम करती है — स्केल पर। ## मॉडल 3: एफिलिएट रेकमेंडेशन **सबसे अच्छा:** किसी भी लिस्ट साइज़, किसी भी नीश के लिए जहाँ आप वाकई टूल्स और सर्विसेज़ का उपयोग करते हैं। एफिलिएट मार्केटिंग शुरू करने के लिए सबसे कम रुकावट वाला मॉडल है: आप ऐसे प्रोडक्ट्स की सिफारिश करते हैं जो आप वास्तव में उपयोग करते हैं, पाठक क्लिक करते हैं, और आप खरीद पर कमीशन कमाते हैं। कोई स्पॉन्सर रिलेशनशिप मैनेज नहीं करनी, कोई प्रोडक्ट नहीं बनाना, कोई पेड टियर मेंटेन नहीं करना। मुख्य बाधा भरोसा है। एफिलिएट रेकमेंडेशन तभी कन्वर्ट होती हैं जब रेकमेंडेशन वाकई उपयोगी और विश्वसनीय स्रोत से हो। ऐसे प्रोडक्ट्स से भरी "टॉप पिक्स" सेक्शन जो आपने कभी इस्तेमाल नहीं किए, कम परफॉर्म करेगी — या बदतर, लिस्ट को नुकसान पहुंचाएगी। क्या काम करता है: - अपने खुद के स्टैक में उपयोग किए जाने वाले टूल्स की सिफारिश करें (मेरे लिए: ईमेल मैनेजमेंट के लिए [ConvertKit](/recommends/convertkit), SEO और कंटेंट रिसर्च के लिए [Semrush](/recommends/semrush)) - कॉन्टेक्स्चुअल प्लेसमेंट — टूल का ज़िक्र वहाँ करें जहाँ यह कंटेंट के लिए प्रासंगिक हो, किसी फिक्स्ड "इस इश्यू के स्पॉन्सर" ब्लॉक में नहीं जिसे पाठक स्किप करना सीख जाते हैं - असली राय दें: आपको क्या पसंद है, क्या नहीं, और यह किसके लिए नहीं है इनकम सीलिंग: एफिलिएट कमीशन अलग-अलग होती है — SaaS टूल्स आमतौर पर कन्वर्टेड सब्सक्राइबर पर 20–40% रिकरिंग देते हैं, जो अच्छी तरह बढ़ता है। 1,000 सब्सक्राइबर की लिस्ट जहाँ 2% पाठक $50/माह के SaaS पर 30% कमीशन पर कन्वर्ट होते हैं = $300/माह रिकरिंग, हर नए रजिस्ट्रेशन के साथ बढ़ती है जो बनी रहती है। ## मॉडल 4: कोर्स और डिजिटल प्रोडक्ट फ़नल **सबसे अच्छा:** किसी विशिष्ट डोमेन में टीचिंग अथॉरिटी वाले ऑपरेटर्स के लिए। न्यूज़लेटर फ़नल का शीर्ष है; कोर्स या डिजिटल प्रोडक्ट कन्वर्जन इवेंट है। जो पाठक आप पर इतना भरोसा करते हैं कि हर इश्यू खोलते हैं, वे एक पेड प्रोडक्ट के लिए सबसे योग्य लीड हैं जो उन्हें वो सिखाता है जो आप जानते हैं। यह मामूली लिस्ट के साथ भी सबसे अधिक इनकम सीलिंग वाला मॉडल है। $497 का कोर्स 5,000 लोगों की लिस्ट के 2% को बेचने पर = प्रति लॉन्च $49,700। लिस्ट ग्रोथ के साथ साल में तीन लॉन्च पर, यह आक्रामक रूप से जुड़ता है। क्या चाहिए: - किसी विशिष्ट डोमेन में असली टीचिंग अथॉरिटी — सिर्फ "मैं मार्केटिंग जानता हूं" नहीं बल्कि "मैंने इस विशिष्ट ग्रोथ प्लेबुक का उपयोग करके तीन B2B कंपनियां बढ़ाई हैं" - कंटेंट जो हफ्ते-दर-हफ्ते अथॉरिटी दर्शाता हो (सिर्फ क्यूरेटेड लिंक नहीं — आपके ओरिजिनल फ्रेमवर्क और केस स्टडीज़) - एक लॉन्च सीक्वेंस जिसके लिए लिस्ट तैयार की गई हो — किसी ऐसी लिस्ट से ठंडा "मेरा कोर्स खरीदें" ईमेल नहीं जो सिर्फ कंटेंट पाती है यह वह मॉडल है जिस पर मैं अपने खुद के काम में सबसे ज़्यादा निर्भर हूं। न्यूज़लेटर भरोसा बनाता है; कोर्स उसे कन्वर्ट करता है। ## मॉडल 5: सर्विस अपसेल **सबसे अच्छा:** अर्ली-स्टेज न्यूज़लेटर के लिए जहाँ ऑपरेटर कंसल्टिंग, कोचिंग या "आपके लिए किया" सर्विसेज़ ऑफर करता है। यह मॉडल छोटी लिस्ट साइज़ पर असली रेवेन्यू का सबसे तेज़ रास्ता है, और यह सबसे कम उपयोग किया जाने वाला है। न्यूज़लेटर आपको एक्सपर्ट के रूप में पोजिशन करता है; सर्विस काम पर एक्सपर्ट है। अगर 500 लोग ग्रोथ मार्केटिंग पर आपका न्यूज़लेटर पढ़ते हैं और आप महीने में एक इश्यू पब्लिश करते हैं जो आपकी सोच दर्शाता है, तो उन 500 पाठकों में से 1–2 समय-समय पर हाथ उठाएंगे और पूछेंगे कि क्या आप कंसल्टिंग करते हैं। अगर आप ऑफर नहीं करते, तो आपने रेवेन्यू मेज़ पर छोड़ दिया। इसे स्पष्ट कैसे बनाएं: - अपने न्यूज़लेटर के फुटर में एक लाइन जोड़ें: "मैं प्रति तिमाही कुछ क्लाइंट्स के साथ [विशिष्ट परिणाम] पर काम करता हूं। अगर आप यह एक्सप्लोर करना चाहते हैं तो इस ईमेल का जवाब दें।" - प्रासंगिक इश्यू में क्लाइंट रिज़ल्ट (अनामित) का उल्लेख करें — दिखावे के रूप में नहीं, बल्कि इस बात के प्रमाण के रूप में कि फ्रेमवर्क व्यवहार में काम करते हैं - कैपेसिटी को जानबूझकर सीमित रखें — कमी यहाँ बनावटी नहीं है, यह असली है; आपके पास सीमित समय है इनकम रियलिटी: $5,000/माह का एक कंसल्टिंग क्लाइंट और 200 लोगों का न्यूज़लेटर बिखरे हुए एफिलिएट इनकम में $0.01/सब्सक्राइबर कमाने वाले 50,000 सब्सक्राइबर से बेहतर इकोनॉमिक्स रखता है। यहाँ शुरू करने के लिए स्केल का इंतज़ार न करें। ## सही मॉडल कैसे चुनें डिसीज़न फ्रेमवर्क: | लिस्ट साइज़ | सबसे अच्छा शुरुआती मॉडल | दूसरा मॉडल जोड़ने के लिए | |------------|------------------------|-----------------------| | 0–1,000 | सर्विस अपसेल | एफिलिएट रेकमेंडेशन | | 1,000–5,000 | एफिलिएट + कोर्स वेटलिस्ट | पेड सब्सक्रिप्शन | | 5,000–20,000 | स्पॉन्सरशिप | कोर्स लॉन्च | | 20,000+ | स्पॉन्सरशिप + कोर्स | पेड टियर | एक बाधा जो किसी भी साइज़ पर नहीं बदलती: पहले एक चुनें। मॉडल स्प्रॉल एक साथ सभी मॉडल पर कन्वर्जन खत्म कर देता है। ## न्यूज़लेटर ऑपरेटर का स्टैक न्यूज़लेटर बिज़नेस बनाने के लिए मैं जो टूल्स उपयोग और सिफारिश करता हूं: - **ईमेल प्लेटफॉर्म:** [ConvertKit](/recommends/convertkit) — सब्सक्राइबर टैगिंग, सेगमेंटेशन और ऑटोमेशन सीक्वेंस जो खरीदारों को पाठकों से अलग करते हैं - **SEO और टॉपिक रिसर्च:** [Semrush](/recommends/semrush) — पहचानें कि आपका टार्गेट ऑडियंस उसके बारे में लिखने से पहले क्या खोजता है - **डिज़ाइन:** [Canva](/recommends/canva) — डिज़ाइनर के बिना मीडिया किट, कोर्स कवर एसेट्स और सोशल कंटेंट - **पेमेंट:** Stripe — पेड सब्सक्रिप्शन टियर या कोर्स चेकआउट के लिए ## ऑपरेटर की बॉटम लाइन न्यूज़लेटर 2026 में सबसे अधिक लेवरेज वाला कंटेंट एसेट है जिसे आप बना सकते हैं: ईमेल इनबॉक्स अटेंशन उस तरह से दुर्लभ और मूल्यवान है जैसे सोशल फीड नहीं हैं। लेकिन एसेट तभी रेवेन्यू में कन्वर्ट होता है जब आप एक ऐसा मॉडल चुनते हैं जो आपकी लिस्ट साइज़ के अनुकूल हो, इसे असली रेकमेंडेशन और वास्तविक अथॉरिटी के साथ एग्ज़ीक्यूट करते हैं, और एक साथ हर मोनेटाइज़ेशन मेथड पर बिखरने की इच्छा का विरोध करते हैं। उस मॉडल से शुरू करें जो आज आप जहाँ हैं उसके अनुकूल हो। जब यह काम करे — लगातार, संचित परिणामों के साथ — तो अगला जोड़ें। --- **संबंधित:** [बिज़नेस आइडिया को बनाने से पहले कैसे वैलिडेट करें](/how-to-validate-a-business-idea/) · [ग्रोथ मार्केटिंग स्ट्रैटेजी गाइड](/growth-marketing-strategies-guide/) · [छोटे व्यवसाय के लिए 6 सर्वश्रेष्ठ ईमेल मार्केटिंग सेवाएं](/6-best-email-marketing-services-for-small-business/) --- ## अपना पहला MCP सर्वर कैसे बनाएं: एक व्यावहारिक गाइड Source: https://alejandrorioja.com/hi/how-to-build-your-first-mcp-server/ Published: 2026-06-23 Tags: AI Agents TL;DR: MCP (Model Context Protocol) Claude को बाहरी टूल्स और डेटा तक संरचित पहुंच देने का तरीका है — डेटाबेस, फाइलें, API — बिना कॉन्टेक्स्ट विंडो को ओवरलोड किए। सर्वर उतना सरल है जितना दिखता नहीं: SDK इंस्टॉल करें, अपने टूल्स को JSON schema के रूप में परिभाषित करें, हैंडलर लागू करें, stdio के माध्यम से कनेक्ट करें। आप 30 मिनट से कम में Claude को अपने कस्टम टूल्स कॉल करवा सकते हैं। ## विषय-सूची _जून 2026 के लिए अपडेट किया गया।_ **TL;DR:** MCP (Model Context Protocol) [Claude](/recommends/claude) को बाहरी टूल्स और डेटा तक संरचित पहुंच देने का तरीका है — डेटाबेस, फाइलें, API — बिना कॉन्टेक्स्ट विंडो को ओवरलोड किए। सर्वर उतना सरल है जितना दिखता नहीं: SDK इंस्टॉल करें, अपने टूल्स को JSON schema के रूप में परिभाषित करें, हैंडलर लागू करें, stdio के माध्यम से कनेक्ट करें। आप 30 मिनट से कम में Claude को अपने कस्टम टूल्स कॉल करवा सकते हैं। **[ऑपरेटर का दृष्टिकोण]** मैं नियमित रूप से अपने एजेंट्स में नए टूल्स जोड़ता हूं, और MCP अब इसे साफ तरीके से करने का मानक तरीका है। एक बार सर्वर बन जाने के बाद, हर MCP-compatible क्लाइंट — Claude Desktop, Claude Code, Anthropic SDK उपयोग करने वाला कोई भी ऐप — बिना कॉलिंग कोड में बदलाव किए इसका उपयोग कर सकता है। यही मूल्य है: एक बार बनाएं, हर जगह पुनः उपयोग करें। ## MCP वास्तव में क्या है **Model Context Protocol** एक ओपन प्रोटोकॉल है जो AI मॉडल को बाहरी कॉन्टेक्स्ट और टूल्स से कनेक्ट करने के तरीके को मानकीकृत करता है। इसे AI इंटीग्रेशन के लिए USB-C मानक की तरह सोचें: इससे पहले, हर ऐप जो Claude को डेटाबेस पढ़ने या API कॉल करने देना चाहता था, उसे अपनी व्यवस्था बनानी पड़ती थी। इसके बाद, आप एक MCP सर्वर बनाते हैं और कोई भी अनुपालक होस्ट इसका उपयोग कर सकता है। MCP तीन चीजें परिभाषित करता है जो एक सर्वर ऑफर कर सकता है: - **टूल्स** — वे फंक्शन जो Claude कॉल कर सकता है (फाइल पढ़ना, DB क्वेरी करना, Slack संदेश भेजना) - **रिसोर्सेज** — वह डेटा जो Claude पढ़ सकता है (दस्तावेज, डेटाबेस रो, फाइल ट्री) - **प्रॉम्प्ट्स** — पुन: उपयोग योग्य प्रॉम्प्ट टेम्पलेट जिन्हें होस्ट इंजेक्ट कर सकता है अधिकांश ऑपरेटर उपयोग के मामलों के लिए, आप **टूल सर्वर** बना रहे हैं। रिसोर्सेज और प्रॉम्प्ट्स बाद में आते हैं जब बुनियादी बातें काम करने लगती हैं। आर्किटेक्चर क्लाइंट-सर्वर है, जिसमें क्लाइंट (Claude Desktop, Claude Code, आपका कस्टम ऐप) सब कुछ नियंत्रित करता है। सर्वर निष्क्रिय है — यह केवल टूल कॉल अनुरोधों को सुनता है और परिणाम लौटाता है। ## हर MCP सर्वर के तीन हिस्से आप जो भी MCP सर्वर बनाते हैं उसकी संरचना एक जैसी होती है: 1. **सर्वर ऑब्जेक्ट** — आपके सर्वर का नाम, संस्करण, और क्षमताएं घोषित करता है (टूल्स, रिसोर्सेज, प्रॉम्प्ट्स) 2. **टूल परिभाषाएं** — नामों, विवरणों और उनके इनपुट के लिए JSON schema के साथ टूल्स की सूची 3. **रिक्वेस्ट हैंडलर** — वे फंक्शन जो Claude किसी टूल को कॉल करने पर चलते हैं बस इतना ही। शुरू करने के लिए कोई डेटाबेस, HTTP स्टैक, या auth लेयर की जरूरत नहीं। न्यूनतम सर्वर 30 से कम TypeScript लाइनों का है। ## पूर्व-आवश्यकताएं (2 मिनट) - **Node.js 18+** — `node --version` से जांचें - **TypeScript 5+** (नीचे dev dependency के रूप में शामिल) - टेस्ट करने के लिए MCP क्लाइंट — Claude Desktop मुफ्त है और आपके सर्वर को काम करते देखने का सबसे आसान तरीका है MCP सर्वर चलाने के लिए Anthropic API की कुंजी की जरूरत नहीं है। API की कुंजी क्लाइंट में होती है, सर्वर में नहीं। ## चरण 1: प्रोजेक्ट सेट करें (3 मिनट) ```bash mkdir my-mcp-server && cd my-mcp-server npm init -y npm install @modelcontextprotocol/sdk npm install -D typescript tsx @types/node ``` `package.json` में जोड़ें: ```json { "type": "module", "scripts": { "build": "tsc", "dev": "tsx src/index.ts" } } ``` `tsconfig.json` बनाएं: ```json { "compilerOptions": { "target": "ES2022", "module": "Node16", "moduleResolution": "Node16", "outDir": "./build", "strict": true }, "include": ["src/**/*"] } ``` ## चरण 2: न्यूनतम सर्वर लिखें (5 मिनट) `src/index.ts` बनाएं: ```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { CallToolRequestSchema, ListToolsRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; const server = new Server( { name: "my-mcp-server", version: "1.0.0" }, { capabilities: { tools: {} } } ); // घोषित करें कि यह सर्वर कौन से टूल्स ऑफर करता है server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [ { name: "get_word_count", description: "टेक्स्ट के एक ब्लॉक में शब्दों की गिनती करता है।", inputSchema: { type: "object", properties: { text: { type: "string", description: "वह टेक्स्ट जिसमें शब्द गिने जाने हैं", }, }, required: ["text"], }, }, ], })); // क्लाइंट से टूल कॉल हैंडल करें server.setRequestHandler(CallToolRequestSchema, async (request) => { const { name, arguments: args } = request.params; if (name === "get_word_count") { const { text } = args as { text: string }; const count = text.trim().split(/\s+/).filter(Boolean).length; return { content: [{ type: "text", text: `शब्द गिनती: ${count}` }], }; } throw new Error(`अज्ञात टूल: ${name}`); }); // stdio के माध्यम से कनेक्ट करें — इस तरह Claude Desktop सर्वर से बात करता है const transport = new StdioServerTransport(); await server.connect(transport); ``` यह पूरा सर्वर है। यह एक टूल (`get_word_count`) रजिस्टर करता है और उसे लागू करता है। संरचना ही मायने रखती है। ## चरण 3: बिल्ड करें और Claude Desktop में रजिस्टर करें (5 मिनट) TypeScript बिल्ड करें: ```bash npm run build ``` अब Claude Desktop के कॉन्फिग फाइल में रजिस्टर करें। **macOS** पर: `~/Library/Application Support/Claude/claude_desktop_config.json` **Windows** पर: `%APPDATA%\Claude\claude_desktop_config.json` अगर फाइल नहीं है, बनाएं: ```json { "mcpServers": { "my-mcp-server": { "command": "node", "args": ["/absolute/path/to/my-mcp-server/build/index.js"] } } } ``` Absolute path उपयोग करें। सहेजने के बाद Claude Desktop रीस्टार्ट करें। मैसेज इनपुट में हथौड़े का आइकन (🔨) दिखेगा — इसका मतलब है Claude ने आपके टूल्स खोज लिए हैं। ## चरण 4: एक उपयोगी टूल बनाएं शब्द गिनना उदाहरण के लिए है। यहां एक अधिक उपयोगी टूल है: प्रोजेक्ट डायरेक्टरी से फाइलें पढ़ना, जिसका उपयोग मैं कॉन्टेक्स्ट इंजेक्शन एजेंट्स के लिए करता हूं जो कोडबेस, changelogs, या कॉन्फिग फाइलें सारांशित करते हैं। ```typescript import { readFileSync, readdirSync } from "fs"; import { join, extname } from "path"; const ALLOWED_EXTENSIONS = [".md", ".txt", ".ts", ".json", ".yaml"]; const PROJECT_DIR = process.env.PROJECT_DIR ?? process.cwd(); ``` तर्क समान है: सटीक JSON schema के साथ टूल्स परिभाषित करें, हैंडलर लागू करें, path traversal रोकने के लिए इनपुट validate करें, और क्लाइंट को टेक्स्ट लौटाएं। ## मैंने जो गलतियां कीं (ताकि आप न करें) **Path absolute होनी चाहिए।** Claude Desktop कॉन्फिग में Relative paths उस तरह resolve नहीं होती जैसी उम्मीद है। हमेशा पूरा path `/home/user/...` उपयोग करें। **Stdio का मतलब है अपने सर्वर में `console.log` नहीं।** Claude Desktop आपके सर्वर से stdin/stdout के माध्यम से communicate करता है। Debug `console.log` JSON-RPC stream को corrupt करता है। stderr पर log करें: ```typescript process.stderr.write(`Debug: ${message}\n`); ``` **हर कॉन्फिग बदलाव के बाद Claude Desktop रीस्टार्ट करें।** MCP सर्वर startup पर लोड होते हैं। एक edited कॉन्फिग फाइल तब तक कुछ नहीं करती जब तक आप ऐप बंद करके दोबारा न खोलें। **टूल विवरण ही उत्पाद है।** Claude तय करता है कि आपका टूल call करना है या नहीं `description` फील्ड के आधार पर। अस्पष्ट विवरण का मतलब है Claude नहीं जानेगा कब इसे उपयोग करना है। सटीक विवरण का मतलब है Claude इसे सही समय पर उपयोग करता है। विवरण पर implementation से ज्यादा समय लगाएं। ## मैं production में MCP सर्वर कैसे उपयोग करता हूं Stdio pattern Claude Desktop और Claude Code (local) के लिए बढ़िया काम करता है। Production एजेंट्स के लिए — [30+ जो मैं Cloudflare Workers पर चलाता हूं](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — मैं Anthropic SDK की tool-use API सीधे उपयोग करता हूं, क्योंकि मुझे प्रति चरण [Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet) को route करने की लचीलापन चाहिए। वे patterns जो मैं वास्तव में उपयोग करता हूं: 1. **Local dev tooling** — Claude Code के लिए MCP सर्वर जो project-specific टूल्स expose करते हैं 2. **Context injection** — MCP सर्वर जो manually copy किए बिना relevant docs preload करते हैं 3. **Prototype-to-API bridge** — मैं पहले MCP बनाता हूं (iterate करना तेज), फिर production के लिए logic को SDK tool-use में port करता हूं ## आगे क्या बनाएं एक बार सर्वर structure समझ आ जाए, उपयोगी टूल्स वे हैं जो Claude के external context तक पहुंचते हैं: - **Database reader** — read-only SQL query चलाएं और परिणाम JSON में लौटाएं - **Slack reader** — किसी channel से अंतिम N संदेश प्राप्त करें - **GitHub reader** — open PRs list करें, specific commit पर फाइल पढ़ें - **Internal API wrapper** — auth headers baked in के साथ अपनी REST API call करें ## अक्सर पूछे जाने वाले प्रश्न ### क्या MCP सर्वर बनाने के लिए Anthropic API key चाहिए? नहीं। आपका MCP सर्वर Anthropic API call नहीं करता। यह केवल client से tool call requests का जवाब देता है। API key client में होती है, सर्वर में नहीं। ### क्या मेरा MCP सर्वर external APIs call कर सकता है? हां — handler बस async TypeScript code है। Weather API fetch करें, database query करें, file में लिखें। सर्वर को परवाह नहीं कि handler अंदरूनी रूप से क्या करता है। ### stdio और HTTP transport में क्या अंतर है? Stdio local सर्वर के लिए है — Claude Desktop या Claude Code के समान machine पर। HTTP with SSE remote सर्वर के लिए है जिसे web service के रूप में deploy किया जा सकता है। stdio से शुरू करें; debug करना आसान है। ### Claude कैसे जानता है कि मेरा टूल कब call करना है? Claude टूल के `description` field और बातचीत के context के आधार पर तय करता है। अगर Claude आपके टूल को ignore करता रहता है, विवरण को और सटीक बनाएं। --- ## बिज़नेस आइडिया को बनाने से पहले कैसे वैलिडेट करें Source: https://alejandrorioja.com/hi/how-to-validate-a-business-idea/ Published: 2026-06-20 Tags: Entrepreneurship, Growth TL;DR: अधिकांश बिज़नेस आइडिया खराब निष्पादन की वजह से नहीं, बल्कि वैलिडेशन छोड़ने की वजह से फेल होते हैं। सबसे तेज़ रास्ता: सर्च डिमांड और फोरम सबूतों के ज़रिए पुष्टि करें कि समस्या वास्तव में मौजूद है, प्रतिस्पर्धियों की समीक्षा करें यह साबित करने के लिए कि कोई पहले से ही पैसा कमा रहा है, सबसे छोटा संभव स्मोक टेस्ट बनाएं, कुछ भी बनाने से पहले एक प्रतिबद्धता लें — जमा राशि, वेटलिस्ट साइनअप, या आशय पत्र। अगर आप एक भी व्यक्ति को प्रतिबद्ध नहीं करा सकते, तो आइडिया अभी तैयार नहीं है। ## Table of contents _जून 2026 में अपडेट किया गया।_ **TL;DR:** अधिकांश बिज़नेस आइडिया खराब निष्पादन की वजह से नहीं, बल्कि वैलिडेशन छोड़ने की वजह से फेल होते हैं। सबसे तेज़ रास्ता: सर्च डिमांड और फोरम सबूतों के ज़रिए पुष्टि करें कि समस्या वास्तव में मौजूद है, प्रतिस्पर्धियों की समीक्षा करें यह साबित करने के लिए कि कोई पहले से ही पैसा कमा रहा है, सबसे छोटा संभव स्मोक टेस्ट बनाएं, कुछ भी बनाने से पहले एक प्रतिबद्धता लें — जमा राशि, वेटलिस्ट साइनअप, या आशय पत्र। अगर आप एक भी व्यक्ति को प्रतिबद्ध नहीं करा सकते, तो आइडिया अभी तैयार नहीं है। **[ऑपरेटर का नज़रिया]** मैंने यह पैटर्न उन फाउंडर्स में दर्जनों बार देखा है जिनके साथ मैंने काम किया और अपने खुद के प्रोजेक्ट्स में: आइडिया आकर्षक लगता है, फाउंडर जोशीला है, निष्पादन मज़बूत है — और फिर वे लॉन्च करते हैं और सन्नाटे से सामना होता है। इसलिए नहीं कि उन्होंने गलत चीज़ बनाई, बल्कि इसलिए कि उन्होंने उस एक कदम को छोड़ दिया जो उन्हें छह महीने बर्बाद करने से पहले बता देता। यहाँ वह वैलिडेशन फ्रेमवर्क है जिसे मैं उपयोग करता और सुझाता हूँ। ## अधिकांश वैलिडेशन प्रयास क्यों फेल होते हैं स्पष्ट विफलता का तरीका है बिल्कुल भी वैलिडेशन न करना — पहले बनाओ, बाद में सवाल पूछो। लेकिन अधिक सूक्ष्म जाल है वैलिडेशन थिएटर: सर्वे चलाना, दोस्तों से बात करना, "बढ़िया आइडिया!" जैसे अस्पष्ट जवाब इकट्ठे करना, और उसे सिग्नल कहना। सर्वे झूठ बोलते हैं। लोग विनम्र होते हैं। काल्पनिक संदर्भ में "क्या आप इसके लिए 50 डॉलर देंगे?" पूछने पर जवाब लगभग हमेशा हाँ होता है। एकमात्र सिग्नल जो मायने रखता है वह है प्रतिबद्धता: कोई व्यक्ति वास्तव में आपको पैसा, समय, या लिखित आशय पत्र देना। बाकी सब शोर कम करना है, वैलिडेशन नहीं। ## चरण 1: पुष्टि करें कि समस्या वास्तव में बड़े पैमाने पर मौजूद है अपने समाधान को वैलिडेट करने से पहले, यह वैलिडेट करें कि समस्या वास्तविक है और लोग उसे खोज रहे हैं। **सर्च डिमांड सबसे तेज़ प्रॉक्सी है।** Google में अपनी समस्या टाइप करें। ऑटोकम्पलीट सुझाव देखें, "लोग यह भी पूछते हैं" सेक्शन, और सर्वोच्च रैंकिंग पेज। अगर कोई परिणाम नहीं है, तो कोई खोज नहीं रहा — और एक बिज़नेस जो ऐसी समस्या हल करता है जिसे कोई नहीं खोजता, वह रूपांतरण के बजाय शिक्षा पर सारी ऊर्जा खर्च करेगा। वास्तविक मासिक सर्च वॉल्यूम जांचने के लिए [Semrush](/recommends/semrush) जैसे कीवर्ड टूल का उपयोग करें। आपके टारगेट मार्केट में 1,000–10,000 मासिक खोजों वाली समस्या व्यवहार्य है। 20 खोजों प्रति माह वाली समस्या एक ऐसा निच प्रोडक्ट है जिसे वितरण की समस्या है। **फोरम सबूत एक अतिरिक्त गुणात्मक परत है।** अपनी समस्या के लिए Reddit, Quora, निच Facebook ग्रुप्स और Discord कम्युनिटीज़ में खोजें। क्या लोग इसके बारे में सक्रिय रूप से शिकायत कर रहे हैं? समाधान माँग रहे हैं? वर्कअराउंड? वास्तविक निराशा सोना है — इसका मतलब है कि दर्द इतना तेज़ है कि लोगों को सार्वजनिक रूप से मदद माँगने के लिए प्रेरित करे। अगर आपको समस्या का वर्णन करने वाले वास्तविक लोगों के 20 फोरम थ्रेड नहीं मिलते, तो संशयवादी रहें। ## चरण 2: प्रतिस्पर्धियों की समीक्षा करें — पैसे के अस्तित्व का प्रमाण एक सामान्य फाउंडर वृत्ति: "कोई प्रतिस्पर्धा नहीं है, तो मैं बाज़ार पर राज करूंगा।" यह लगभग हमेशा गलत होता है। कोई प्रतिस्पर्धा नहीं मतलब आमतौर पर कोई बाज़ार नहीं। प्रतिस्पर्धा इस बात का प्रमाण है कि ग्राहक मौजूद हैं और भुगतान करेंगे। Google पर अपनी समाधान श्रेणी खोजें। कौन रैंक कर रहा है? उनके लैंडिंग पेज क्या वादा करते हैं? वे क्या चार्ज करते हैं? उनकी प्रशंसापत्र और समीक्षाएं पढ़ें — खासकर नकारात्मक वाली। नकारात्मक समीक्षाएं एक प्रोडक्ट रोडमैप हैं: वे आपको बिल्कुल दिखाती हैं कि बाज़ार क्या चाहता है लेकिन नहीं पा रहा। अगर आपको वास्तविक उत्पादों और वास्तविक ग्राहकों के साथ 3–5 स्थापित प्रतिस्पर्धी मिलते हैं, तो यह स्वस्थ संकेत है। अगर शून्य मिलते हैं, तो यह निष्कर्ष निकालने से पहले और गहरी खोज करें कि बाज़ार मौजूद नहीं है — या इसे लाल झंडे के रूप में देखें। **उत्तर देने वाले मुख्य प्रश्न:** 1. शीर्ष 3–5 खिलाड़ी कौन हैं? 2. वे क्या चार्ज करते हैं? 3. समीक्षक क्या आलोचना कर रहे हैं? 4. क्या कोई पोजीशनिंग गैप है जिसे मैं भर सकता हूँ? ## चरण 3: सबसे छोटा संभव स्मोक टेस्ट बनाएं एक बार जब आप जान लें कि समस्या मौजूद है और बाज़ार में पैसा है, तो यह परखने के लिए न्यूनतम कलाकृति बनाएं कि *आपका* संस्करण ट्रैक्शन पाता है या नहीं। यह पूर्ण उत्पाद नहीं है। यह एक सिग्नल-कैप्चर मैकेनिज़्म है। **विकल्प A: ईमेल कैप्चर के साथ लैंडिंग पेज।** समस्या और समाधान का वर्णन करने वाला एक पेज का साइट, "वेटलिस्ट में शामिल हों" या "अर्ली एक्सेस पाएं" CTA के साथ। रूपांतरण दर आपको बताती है कि आपकी पोजीशनिंग गूंजती है या नहीं। Webflow, Carrd, या यहाँ तक कि एक सार्वजनिक Notion पेज जैसे टूल ठीक काम करते हैं — इसे ज़्यादा जटिल न बनाएं। **विकल्प B: प्री-सेल।** वास्तविक पैसे के साथ एक वास्तविक चेकआउट फ्लो। यह उच्चतम गुणवत्ता का सिग्नल है। अगर कोई आपको किसी ऐसी चीज़ के लिए पैसे देता है जो अभी तक मौजूद नहीं है, तो वे समाधान में विश्वास करते हैं। रिफंडेबल डिपॉज़िट भी काम करता है। **विकल्प C: कंसीयर्ज MVP।** इसे ऑटोमेट करने से पहले मैन्युअली करें। SaaS के बजाय कंसल्टिंग। सॉफ्टवेयर टूल के बजाय कस्टम स्प्रेडशीट। AI-जनित के बजाय मैन्युअली क्यूरेटेड न्यूज़लेटर। आप कुछ ग्राहकों की ब्रूट फोर्स से सेवा करते हैं, सीखते हैं कि वे वास्तव में क्या महत्व देते हैं, फिर उसके आसपास उत्पाद बनाते हैं। ## चरण 4: बनाने से पहले प्रतिबद्धता लें यह वह गेट है जो वास्तविक वैलिडेशन को इच्छापूर्ण सोच से अलग करता है। स्मोक टेस्ट चलाने से पहले परिभाषित करें कि आपके आइडिया के लिए "प्रतिबद्धता" का क्या अर्थ है: - **SaaS / सॉफ्टवेयर:** छूट मूल्य पर प्री-सेल, या हस्ताक्षरित आशय पत्र - **कंटेंट / मीडिया:** ईमेल सब्सक्राइबर जिन्होंने शामिल होने के लिए क्लिक किया (केवल फॉलोअर नहीं) - **सेवाएं / परामर्श:** एक पेड डिस्कवरी कॉल या हस्ताक्षरित प्रस्ताव - **भौतिक उत्पाद:** Kickstarter पर जमा राशि या प्री-ऑर्डर अगर आप कम से कम एक व्यक्ति को प्रतिबद्ध नहीं करा सकते — छूट के साथ भी, मनी-बैक गारंटी के साथ भी — तो आइडिया तैयार नहीं है। यह विफलता नहीं है; यह सिस्टम का काम करना है। इसने आपके महीनों की बिल्ड टाइम बचाई। ## चरण 5: शुरू करने से पहले पास/फेल थ्रेशोल्ड सेट करें जाल यह है: आप अपना स्मोक टेस्ट चलाते हैं, हल्के-फुल्के परिणाम पाते हैं, और खुद को वैसे भी आगे बढ़ने के लिए मनाते हैं। "लैंडिंग पेज कॉपी अच्छी नहीं थी।" "मैंने इसे पर्याप्त प्रमोट नहीं किया।" "इसे बस अधिक समय चाहिए।" रुकिए। टेस्ट चलाने से पहले, थ्रेशोल्ड लिखें: > "अगर मुझे 14 दिनों में 0 पेड विज्ञापनों के साथ 50 वेटलिस्ट साइनअप मिलते हैं, तो मैं बनाता हूँ। अगर मैं 50 नहीं पहुंचता, तो मैं नहीं बनाता — या तो पोजीशनिंग बदलूंगा या आइडिया बंद करूंगा।" इसे लिखें। किसी दोस्त को बताएं। अगर हो सके तो सार्वजनिक करें। फिर इसका सम्मान करें। संख्या मनमानी है; जो मायने रखता है वह यह है कि आप पहले से तय करें और डेटा ठंडे आने पर गोलपोस्ट न बदलें। ## सामान्य वैलिडेशन गलतियाँ 1. **लोगों से पूछना कि क्या वे खरीदेंगे।** वे विनम्र होने के लिए लगभग हमेशा हाँ कहते हैं। एकमात्र प्रश्न जो गिना जाता है: "क्या आप अभी खरीदेंगे?" 2. **दोस्तों और परिवार के साथ वैलिडेट करना।** वे आपका समर्थन कर रहे हैं। वे आपके ग्राहक नहीं हैं। 3. **यह जांचे बिना अपनी समस्या हल करना कि दूसरों के पास भी है।** आपकी समस्या आपके लिए अनूठी हो सकती है। फोरम जांचें। 4. **सर्वे प्रतिक्रियाओं को वैलिडेशन कहना।** सर्वे आइडिया उत्पन्न कर सकता है। यह मांग को वैलिडेट नहीं कर सकता। केवल पैसा या वास्तविक प्रतिबद्धता कर सकती है। 5. **सही जानकारी का इंतजार करना।** वैलिडेशन अगले कदम के लिए पर्याप्त सिग्नल पाने के बारे में है, अनिश्चितता को पूरी तरह समाप्त करने के बारे में नहीं। ## "आगे बढ़ो" के संकेत क्या हैं आप इनका संयोजन ढूंढ रहे हैं: 1. मुख्य समस्या कीवर्ड के लिए 1,000 मासिक खोजों से अधिक सर्च वॉल्यूम 2. प्रतिस्पर्धी गतिविधि — 3+ वास्तविक खिलाड़ी जो वास्तविक पैसा चार्ज कर रहे हैं 3. कम से कम 20 फोरम या समुदाय थ्रेड जो समस्या के प्रति सक्रिय निराशा दिखाते हैं 4. टार्गेटेड ट्रैफिक पर 5% से अधिक स्मोक टेस्ट रूपांतरण दर 5. कम से कम एक व्यक्ति प्रतिबद्ध होता है — भुगतान करता है, हस्ताक्षर करता है, या जमा करता है — बिना आपके भीख माँगे सभी पाँच पूरे करें और आपके पास एक व्यवहार्य दिशा है। दो या तीन पूरे करें और आपके पास परिष्कृत करने योग्य सिग्नल है। शून्य पूरे करें और आपको मूल रूप से अलग आइडिया या दर्शकों की ज़रूरत है। ## वैलिडेशन स्टैक इस प्रक्रिया के लिए मेरे द्वारा उपयोग किए जाने और सुझाए जाने वाले टूल: - **सर्च डिमांड:** [Semrush](/recommends/semrush) — एक जगह पर कीवर्ड वॉल्यूम, प्रतिस्पर्धी विश्लेषण, और कंटेंट गैप - **फोरम रिसर्च:** Reddit, Quora, निच Facebook ग्रुप्स, Discord कम्युनिटीज़ - **लैंडिंग पेज:** Carrd (मुफ़्त, तेज़) या Webflow अधिक डिज़ाइन नियंत्रण के लिए - **ईमेल कैप्चर / वेटलिस्ट:** Kit (ConvertKit) वैलिडेट करते समय सूची बनाना शुरू करने के लिए - **भुगतान:** Stripe — प्रोडक्ट बनाने से पहले सीधे चेकआउट से लिंक करें - **एनालिटिक्स:** वास्तविक व्यवहार ट्रैक करने के लिए स्मोक टेस्ट पेज पर Google Analytics ## ऑपरेटर का निष्कर्ष आप जो सबसे महंगी चीज़ बना सकते हैं वह एक ऐसा प्रोडक्ट है जिसे कोई नहीं चाहता। वैलिडेशन जोखिम को खत्म करने के बारे में नहीं है — यह प्रोडक्शन में धीरे-धीरे फेल होने के बजाय कागज़ पर तेज़ी से फेल होने के बारे में है। स्मोक टेस्ट चलाएं, प्रतिबद्धता लें, शुरू करने से पहले थ्रेशोल्ड सेट करें, और परिणाम का सम्मान करें। अगर सिग्नल वहाँ है, आप जानेंगे। अगर नहीं है, तो वह भी जानेंगे। --- **संबंधित:** [एक लाभदायक व्यवसाय कैसे बनाएं](/how-to-build-profitable-business/) · [ग्रोथ मार्केटिंग रणनीतियाँ गाइड](/growth-marketing-strategies-guide/) · [एक उद्यमी कैसे बनें](/how-to-become-an-entrepreneur/) --- ## Claude API के साथ Prompt Caching: मॉडल बदले बिना अपनी इनपुट लागत घटाएं Source: https://alejandrorioja.com/hi/prompt-caching-cut-your-claude-costs-without-switching-models/ Published: 2026-06-18 Updated: 2026-06-18 Tags: AI Agents, Operations TL;DR: Prompt caching बड़े और स्थिर इनपुट — आपका system prompt, tool definitions, few-shot examples — की लागत को दोहराए जाने वाले requests पर सामान्य इनपुट कीमत के लगभग 10% तक घटा देता है। इसका तंत्र एक prefix match है: अपनी स्थिर सामग्री के अंत में एक cache_control मार्कर लगाएं और उसके बाद सब कुछ बदलता हुआ (volatile) रखें। कैश हिट रेट को बर्बाद करने वाली गलती है किसी timestamp या UUID को prefix में घुसने देना। ## Table of contents _जून 2026 में अपडेट किया गया।_ **संक्षेप में (TL;DR):** Prompt caching बड़े और स्थिर इनपुट — आपका system prompt, tool definitions, few-shot examples — की लागत को दोहराए जाने वाले requests पर सामान्य इनपुट कीमत के लगभग 10% तक घटा देता है। इसका तंत्र एक prefix match है: अपनी स्थिर सामग्री के अंत में एक `cache_control` मार्कर लगाएं और उसके बाद सब कुछ बदलता हुआ (volatile) रखें। कैश हिट रेट को बर्बाद करने वाली गलती है किसी timestamp या UUID को prefix में घुसने देना। **[ऑपरेटर का नज़रिया]** मैं अपने कंसल्टिंग ब्रांड और Pickleland में 100 से ज़्यादा एजेंट्स चलाता हूं। सबसे बड़ा खर्च मॉडल टियर नहीं है — बल्कि यह है कि मैं कितनी बार हर request पर वही 4,000-टोकन वाला system prompt दोबारा भेजता हूं। Prompt caching ने मॉडल या आउटपुट की गुणवत्ता को छुए बिना, ज़्यादा बार चलने वाले एजेंट्स पर उस लागत को लगभग शून्य कर दिया। यहां बिल्कुल समझाया गया है कि यह कैसे काम करता है और जाल कहां छिपे हैं। ## Prompt caching असल में क्या करता है [Claude](/recommends/claude) API के हर कॉल में टोकन भेजे जाते हैं। caching के बिना, आपके request का हर टोकन — system prompt, tool definitions, few-shot examples, और user message — सामान्य इनपुट दर पर चार्ज होता है। caching के साथ, पहले request के बाद उन टोकन का एक prefix Anthropic के सर्वर पर संग्रहीत हो जाता है। आगे आने वाले उन requests पर जो उसी सटीक prefix को साझा करते हैं, आप उन्हें शुरू से दोबारा प्रोसेस करने के बजाय एक कैश *read* कीमत चुकाते हैं। लागत का अंतर असली है: - **Cache write:** ~1.25× बेस इनपुट कीमत (5-मिनट TTL) या ~2× (1-घंटा TTL) - **Cache read:** ~0.1× बेस इनपुट कीमत - **Break-even:** 5-मिनट TTL पर 2 requests, 1-घंटा TTL पर 3 requests एक बार जब आप break-even पार कर लेते हैं — जो किसी भी ऐसे एजेंट पर तेज़ी से होता है जो दिन में कुछ बार से ज़्यादा चलता है — तो हर अतिरिक्त कैश हिट उन टोकन पर ~90% की छूट है। ## Prefix-match का नियम (invariant) यही वह एक नियम है जिसका बाकी सब कुछ पालन करता है: **कैश की कुंजी आपके rendered prompt का एक prefix match होती है।** Anthropic के सर्वर आपके prompt की शुरुआत से लेकर `cache_control` मार्कर तक की rendered सामग्री संग्रहीत करते हैं। अगले request पर कैश हिट होने के लिए, prompt की शुरुआत से उस मार्कर तक का हर टोकन समान होना चाहिए — बाइट दर बाइट। prefix matching के लिए render का क्रम है: tools → system → messages। यानी आपका tools array सबसे पहले हैश होता है, फिर system block, फिर messages क्रम में। व्यवहार में इसका मतलब यह है: स्थिर सामग्री सबसे पहले आनी चाहिए। अगर आपका system prompt किसी गतिशील चीज़ का संदर्भ देता है — मौजूदा तारीख, एक user ID, एक request trace ID — और वह `cache_control` मार्कर से *पहले* दिखती है, तो हर request पर कैश मिस होगा क्योंकि prefix बदलता रहता है। ## कैश मार्कर किस पर लगाएं सबसे ज़्यादा फ़ायदा देने वाले लक्ष्य हैं: **1. आपका system prompt** System prompts आमतौर पर सबसे बड़े स्थिर block होते हैं। एक विस्तृत एजेंट persona, व्यवहार के नियमों की एक सूची, आउटपुट फ़ॉर्मैट निर्देशों का एक सेट — यह सब उसी एजेंट के हर invocation में समान रहता है। इसे मार्क करें: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, system: [ { type: "text", text: `You are a content operations agent for alejandrorioja.com. Your job is to draft blog posts in Alejandro's voice: direct, practitioner, first-person, numbered lists, honest caveats. No hedging. No filler. Every section must earn its place. [... 2000 more tokens of stable instructions ...]`, cache_control: { type: "ephemeral" }, }, ], messages: [ { role: "user", content: "Draft a post about prompt caching.", }, ], }); ``` system block पर `cache_control: { type: "ephemeral" }` Claude को बताता है कि उस block तक की हर चीज़ को कैश करे (उस block समेत)। `messages` array volatile है — हर request पर अलग — और कैश की सीमा से बाहर रहता है। **2. Tool definitions** अगर आपका एजेंट tools इस्तेमाल करता है, तो वे definitions काफ़ी बड़े हो सकते हैं। description, parameter names, और enum values वाला एक अच्छी तरह दस्तावेज़ किया गया tool schema प्रति tool 500–1,000 टोकन तक हो सकता है। 5 tools के साथ, यह 5,000 टोकन तक होते हैं जिन्हें आप हर कॉल पर दोबारा प्रोसेस करने के लिए चुका रहे हैं: ```typescript const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, tools: [ { name: "search_airtable", description: "Search the Airtable content queue...", input_schema: { type: "object", properties: { query: { type: "string" } } }, }, // ... more tools ... { name: "post_to_kit", description: "Schedule a broadcast via the Kit API...", input_schema: { /* ... */ }, // Mark the last tool to cache the entire tools array } as Anthropic.Tool & { cache_control: { type: "ephemeral" } }, ], system: "...", messages: [...], }); ``` array में *आख़िरी* tool को मार्क करें। prefix match उस बिंदु से पूरे tools array को कवर करेगा। **3. messages में few-shot examples** अगर आप `messages` array में शुरुआती messages के रूप में स्थिर few-shot examples पास करते हैं, तो उन्हें भी कैश किया जा सकता है। उन्हें पहले N messages के रूप में संरचित करें और आख़िरी example turn को मार्क करें: ```typescript const messages: Anthropic.MessageParam[] = [ { role: "user", content: [ { type: "text", text: "Here are examples of posts in my voice:\n\n[Example 1...]\n\n[Example 2...]", cache_control: { type: "ephemeral" }, } as Anthropic.TextBlockParam & { cache_control: { type: "ephemeral" } }, ], }, { role: "assistant", content: "Understood. I'll follow that voice.", }, // The actual user turn follows — this is volatile, no cache marker { role: "user", content: actualUserRequest, }, ]; ``` ## क्या कैश न करें (चुपके से कैश तोड़ने वाली चीज़ें) ये वे चीज़ें हैं जो स्थिर लगती हैं पर हैं नहीं — और ये चुपचाप आपका हिट रेट बर्बाद कर देंगी। API आपको चेतावनी नहीं देगा। आप बस हर request पर `cache_creation_input_tokens` देखेंगे और सोचते रहेंगे कि ऐसा क्यों है। **system prompt में timestamps।** सबसे आम गलती: ```typescript // This invalidates the cache on every request const system = `You are an agent. Current time: ${new Date().toISOString()}`; ``` timestamps को user message में ले जाएं, जहां उनकी जगह है: ```typescript // Stable system prompt — cacheable const system = `You are an agent. Use the current time provided by the user.`; // Volatile user message — not cached const userMessage = `Current time: ${new Date().toISOString()}. Run the daily brief.`; ``` **रैंडम UUIDs और trace IDs।** वही समस्या। अगर आप logging के लिए system block में एक trace ID डालते हैं, तो हर request को एक नया prefix मिलता है। **ग़ैर-निर्धारक (non-deterministic) JSON serialization।** अगर आप किसी object को system prompt में serialize करते हैं और key क्रम की गारंटी नहीं है, तो rendered string अलग हो सकती है, भले ही अंतर्निहित data वही हो। एक स्थिर key क्रम के साथ serialize करें या एक template string इस्तेमाल करें। **गतिशील few-shot चयन।** अगर आप मौजूदा query के आधार पर few-shot examples चुन रहे हैं और उन्हें कैश किए गए prefix में डाल रहे हैं, तो आपने "स्थिर" prefix को query पर निर्भर बना दिया है। या तो कैश लेयर के लिए तय examples पर टिके रहें, या गतिशील examples को बिना कैश वाले message turn में ले जाएं। ## अपना कैश हिट रेट सत्यापित करना हर response में usage metadata शामिल होता है। उसे जांचें: ```typescript const response = await client.messages.create({ /* ... */ }); console.log({ inputTokens: response.usage.input_tokens, cacheRead: response.usage.cache_read_input_tokens, cacheWrite: response.usage.cache_creation_input_tokens, outputTokens: response.usage.output_tokens, }); ``` पहले request पर: `cache_creation_input_tokens` शून्य से अधिक होगा, `cache_read_input_tokens` 0 होगा। यह write है। कैश हिट पर: `cache_read_input_tokens` शून्य से अधिक होगा, `cache_creation_input_tokens` 0 होगा। यह read है। अगर आप हर request पर `cache_creation_input_tokens` देख रहे हैं, तो आपका prefix बदल रहा है। एक log statement जोड़ें जो हर कॉल से पहले आपके rendered system prompt के पहले 200 अक्षर प्रिंट करे — एक बदलता हुआ timestamp तुरंत साफ़ नज़र आ जाएगा। ## 1-घंटा TTL: कब अतिरिक्त write लागत वसूल है डिफ़ॉल्ट TTL 5 मिनट है। अगर आपका एजेंट कम बार चलता है — हर 5 मिनट में एक बार से भी कम — तो आप ज़्यादातर requests पर बिना reads पाए cache write लागत चुकाते रहेंगे। ```typescript // Opt into a 1-hour TTL cache_control: { type: "ephemeral", ttl: "1h" } ``` 1-घंटा write की लागत 1.25× के बजाय बेस इनपुट कीमत का ~2× होती है। गणित यह है: अगर आप प्रति घंटे 3 या उससे ज़्यादा बार कैश हिट कर रहे हैं, तो 1-घंटा TTL पैसे बचाता है। अगर आपका एजेंट दिन में एक बार चलता है (मेरे daily brief की तरह), तो 1-घंटा TTL भी मदद नहीं करेगा — आप हर बार write लागत चुका रहे हैं। उस स्थिति में, caching का फ़ायदा मामूली होता है, बशर्ते system prompt बहुत बड़ा न हो। मेरे daily brief एजेंट का system prompt 3,000 टोकन का है पर यह दिन में एक बार चलता है। caching मदद नहीं करती। मेरा newsletter एजेंट draft करते समय प्रति session दर्जनों बार चलता है — caching काफ़ी बचत करती है। ## Pre-warming: पहले request को सस्ता बनाना अगर आपको पता है कि कोई traffic spike आने वाला है — एक batch job, एक API लॉन्च — तो आप एक कम लागत वाले डमी request से कैश को पहले से गर्म (pre-warm) कर सकते हैं: ```typescript // Pre-warm: write the cache at near-zero output cost await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1, // minimal output system: [{ type: "text", text: stableSystemPrompt, cache_control: { type: "ephemeral" } }], messages: [{ role: "user", content: "ping" }], }); // Now the real requests read from cache ``` यह ज़्यादातर batch processing के लिए उपयोगी है, जहां आप कई समानांतर requests शुरू कर रहे हैं और चाहते हैं कि हर एक कैश लिखने की होड़ करने के बजाय एक गर्म कैश को हिट करे। ## एजेंटिक लूप्स में prompt caching एक multi-turn एजेंटिक लूप में, conversation history हर turn पर बढ़ती है। कैश इसे संभालने के लिए काफ़ी समझदार है: यह एक 20-block lookback window इस्तेमाल करता है, और पिछले 20 content blocks के भीतर सबसे लंबा मेल खाता prefix ढूंढता है। व्यावहारिक निहितार्थ: अपनी स्थिर सामग्री (system prompt, tool definitions) को ऊपर ही टिकाए रखें। messages array के अंत में बढ़ती conversation history स्थिर blocks के prefix match को नहीं तोड़ेगी — वे volatile सामग्री से पहले हैं, और prefix match ऊपर से शुरू होता है। व्यवहार में, मेरे एजेंट्स turns को इस तरह संरचित करते हैं: ``` System (cached) → Tools (cached) → Few-shot (cached) → Turn 1 → Turn 2 → ... → Current turn ``` कैश few-shot मार्कर तक की हर चीज़ को कवर करता है। उसके बाद बढ़ती turn history हर बार दोबारा प्रोसेस होती है, पर यह ठीक है — वे टोकन session-विशिष्ट हैं और स्थिर prefix के मुकाबले छोटे हैं। ## बिल पर यह कैसा दिखता है एक ज़्यादा बार चलने वाला एजेंट लीजिए: प्रति दिन 100 कॉल, 4,000-टोकन वाला system prompt, Sonnet कीमत। caching के बिना: - 100 × 4,000 tokens × $3/1M = **$1.20/दिन** caching के साथ (5-मिनट TTL, मान लें peak पर 50 कॉल/घंटा): - प्रति 5 मिनट 1 write × $3.75/1M × 4,000 tokens = ~$0.02/दिन writes में - ~98 reads/दिन × $0.30/1M × 4,000 tokens = **$0.12/दिन reads में** यह उन इनपुट टोकन पर लगभग 90% की कमी है। बड़े पैमाने पर — प्रति दिन 1,000 कॉल — यह अंतर और भी बढ़ता जाता है। और यह [Haiku बनाम Sonnet के गणित](/ai-agent-cost-math-when-haiku-beats-sonnet) से होने वाली किसी भी model-routing बचत के ऊपर है: caching हर टियर पर काम करती है। ## ऑपरेटर का निष्कर्ष Prompt caching, Claude API में सबसे आसान लागत-अनुकूलन है: उन्हीं content blocks पर एक अतिरिक्त field जो आप पहले से लिख रहे हैं। बाधा है prefix की स्थिरता के इर्द-गिर्द अनुशासन — कैश मार्कर से पहले कुछ भी गतिशील न हो। अगर आप अपने system prompt, tools, और किसी भी स्थिर examples को volatile सामग्री से मुक्त रख सकते हैं, तो आप हर कैश हिट पर सामान्य इनपुट लागत का ~10% चुकाएंगे। बड़े और स्थिर prompts वाले ज़्यादा बार चलने वाले एजेंट्स के लिए, यह मॉडल टियर बदलने से बड़ा लीवर है। --- **संबंधित:** [AI Agent Cost Math: When Haiku Beats Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Event-Triggered vs Scheduled Agents](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [The 5 AI Tools I Actually Use to Run My Business](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) --- ## Claude Fable 5 के शुरुआती अनुभव: एक ऑपरेटर का नज़रिया Source: https://alejandrorioja.com/hi/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5 Anthropic का सबसे सक्षम मॉडल है और कठिन, लंबे-दौर वाले एजेंट काम में यह साफ़ झलकता है — लेकिन यह डिफ़ॉल्ट अपग्रेड नहीं है। यह प्रति टोकन ज़्यादा महंगा है, एक नया tokenizer इस्तेमाल करता है जो आपके टोकन काउंट को ~30% फुला देता है, हमेशा-ऑन thinking चलाता है जिसे आप बंद नहीं कर सकते, और classifier स्तर पर रिक्वेस्ट ठुकरा सकता है। ज़्यादातर वर्कलोड के लिए Opus 4.8 ही सही चुनाव है। Fable 5 तब उठाइए जब काम सचमुच कठिन हो। ## विषय-सूची _जून 2026 में अपडेटेड।_ **TL;DR:** Fable 5 Anthropic का सबसे सक्षम मॉडल है और कठिन, लंबे-दौर वाले एजेंट काम में यह साफ़ झलकता है — लेकिन यह डिफ़ॉल्ट अपग्रेड नहीं है। यह प्रति टोकन ज़्यादा महंगा है, एक नया tokenizer इस्तेमाल करता है जो आपके टोकन काउंट को ~30% फुला देता है, हमेशा-ऑन thinking चलाता है जिसे आप बंद नहीं कर सकते, और classifier स्तर पर रिक्वेस्ट ठुकरा सकता है। ज़्यादातर वर्कलोड के लिए Opus 4.8 ही सही चुनाव है। Fable 5 तब उठाइए जब काम सचमुच कठिन हो। **[ऑपरेटर का नज़रिया]** मैं एक कंसल्टिंग ब्रांड और एक पिकलबॉल फैसिलिटी के पार 30+ प्रोडक्शन एजेंट चलाता हूँ, तो मेरे लिए कोई नया फ्लैगशिप मॉडल कोई बेंचमार्क नहीं — यह एक खर्च की लाइन और एक माइग्रेशन है। यहाँ बताता हूँ कि जब मैंने सचमुच Fable 5 को उनमें से कुछ एजेंट्स में जोड़ा तो क्या बदला, और कहाँ मैंने Opus 4.8 को यथावत रहने दिया। ## Fable 5 असल में है क्या [Claude](/recommends/claude) Fable 5 सबसे सक्षम मॉडल है जिसे Anthropic ने व्यापक रूप से उतारा है। इसका निशाना स्पेक्ट्रम का सबसे मांगभरा सिरा है: गहरी तर्कक्षमता और लंबे-दौर वाला एजेंटिक काम — वे रन जहाँ एक एजेंट को दर्जनों tool calls के पार एक प्लान को थामे रखना होता है, बिना सूत्र खोए। API सरफेस लगभग Opus 4.7/4.8 जैसा ही है, जिसने इसे टेस्ट करना आसान बना दिया। डिफ़ॉल्ट रूप से 1M-token का कॉन्टेक्स्ट विंडो, प्रति रिक्वेस्ट 128K आउटपुट टोकन तक। अगर आपने हालिया Opus लाइन पर कुछ भी बनाया है, तो रिक्वेस्ट का ढाँचा जाना-पहचाना लगेगा। फ़र्क ब्योरों में है, और ब्योरे ही वहाँ हैं जहाँ पैसा और चौंकाने वाली बातें छिपी हैं। एक नामकरण नोट ताकि आप उलझें नहीं: **Mythos 5** वही मॉडल है — वही क्षमताएँ, वही कीमत, वही व्यवहार — जो सिर्फ़ Anthropic के Project Glasswing प्रोग्राम के ज़रिए उपलब्ध है। अगर आप उस प्रोग्राम में नहीं हैं, तो जो मॉडल आपको चाहिए वह है `claude-fable-5`। नीचे लिखी हर बात दोनों पर लागू होती है। ## जहाँ यह सचमुच बेहतर है मैंने सबसे पहले अपना सबसे कठिन एजेंट टास्क इस पर फेंका: एक मल्टी-स्टेप रिसर्च-और-संश्लेषण रन जो ढेर सारे स्रोत पढ़ता है, दावों को आपस में जाँचता है, और एक हवाला-सहित ब्रीफ़ लिखता है। यह ऐसा काम है जहाँ कमज़ोर मॉडल भटक जाते हैं — दस tool calls के बाद वे यह पकड़ खो देते हैं कि कौन-सा दावा किस स्रोत से आया। Fable 5 ने सूत्र थामे रखा। संश्लेषण ज़्यादा कसा हुआ था, हवाले सही दावों से जुड़े रहे, और इसने दो स्रोतों के बीच ऐसे दो विरोधाभास पकड़े जिन्हें मेरा Opus 4.8 वर्ज़न चुपचाप औसत में मिला रहा था। लंबी, संरचित तर्कक्षमता पर यह सचमुच एक कदम ऊपर है — कोई मामूली बेंचमार्क उछाल नहीं। यही इसका ईमानदार पक्ष है। अगर आपके एजेंट का फेल्योर मोड है "कठिन 10% पर बिखर जाना," तो Fable 5 उस फ़ासले को कम करता है। अगर आपका एजेंट न्यूज़लेटर सारांशित कर रहा है या सोशल पोस्ट ड्राफ़्ट कर रहा है, तो आपको फ़र्क महसूस नहीं होगा — और आप ऐसी क्षमता के पैसे चुकाएँगे जिसे आप इस्तेमाल ही नहीं कर रहे। ## वह कॉस्ट वाला झटका जिसके बारे में कोई आगाह नहीं करता यह वही चीज़ है जो आपको काटेगी अगर आप रिलीज़ नोट्स बस सरसरी तौर पर पढ़ते हैं। Fable 5 एक **नए tokenizer** के साथ आता है, और वही कॉन्टेंट Opus लाइन के मुक़ाबले लगभग **30% ज़्यादा टोकन** में टोकनाइज़ होता है। इसे दोबारा पढ़िए, क्योंकि यह कीमत के साथ मिलकर बढ़ता है। Fable 5 की कीमत शुरू से ही Opus-टियर से ऊपर है ($10 प्रति मिलियन input token, $50 प्रति मिलियन output)। अब हर प्रॉम्प्ट और कम्प्लीशन के ऊपर ~30% का टोकन फुलाव जोड़ दीजिए। एक अपरिवर्तित वर्कलोड — वही प्रॉम्प्ट, वही आउटपुट — माइग्रेशन के बाद काफ़ी ज़्यादा खर्च करा सकता है, इससे पहले कि आपने एजेंट के काम में एक भी चीज़ बदली हो। तो अपने पुराने आँकड़े दोबारा मत इस्तेमाल कीजिए। आपकी `max_tokens` सेटिंग्स, आपके कॉन्टेक्स्ट-विंडो बजट, आपके प्रति-रन कॉस्ट अनुमान — ये सब एक अलग tokenizer पर मापे गए थे। अच्छी ख़बर: token-counting endpoint **दोनों** tokenizers के तहत काउंट लौटाता है जब आप `model: "claude-fable-5"` पास करते हैं, तो कुछ भी पलटने से पहले आप अपने असली प्रॉम्प्ट पर डेल्टा माप सकते हैं। ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` मैंने यह सबसे पहले अपने सबसे भारी प्रॉम्प्ट पर चलाया। डेल्टा एकसमान नहीं था — यह कॉन्टेंट के हिसाब से बदलता है — पर "~30% ज़्यादा के लिए बजट रखो, फिर कीमत प्रीमियम जोड़ो" सही मानसिक मॉडल साबित हुआ। ## Thinking हमेशा ऑन रहता है — और आप इसे बंद नहीं कर सकते Fable 5 पर, adaptive thinking हमेशा चलता रहता है। Opus लाइन के मुक़ाबले एकमात्र नया ब्रेकिंग चेंज: अगर आप एक स्पष्ट `thinking: {type: "disabled"}` भेजते हैं, तो आपको 400 मिलता है। उपाय सरल है — बस `thinking` पैरामीटर को पूरी तरह छोड़ दीजिए — लेकिन अगर आपके पास ऐसा कोड था जो सस्ते, तेज़ कॉल के लिए thinking को स्पष्ट रूप से बंद करता था, तो वह कोड अब error देगा। आपको कच्ची chain of thought भी वापस नहीं मिलती। Fable 5 इसे सुरक्षित रखता है: आपको सामान्य `thinking` ब्लॉक मिलते हैं, और आप `display: "summarized"` के साथ एक पढ़ने योग्य सारांश माँग सकते हैं, पर बिना छने तर्क को कभी उजागर नहीं किया जाता। ज़्यादातर ऐप्स के लिए यह कोई मुद्दा नहीं — अगर आपको दृश्यता चाहिए तो सारांश पढ़ लीजिए। जहाँ यह मायने रखता है वह है **मल्टी-टर्न एजेंट**: जब आप उसी मॉडल पर बातचीत जारी रखते हैं, तो आपको thinking ब्लॉक **बिना बदले** वापस पास करने होते हैं। उन्हें हटाइए या एडिट कीजिए तो टर्न टूट जाता है। अगर आप एजेंट लूप बना रहे हैं, तो thinking ब्लॉक को ऐसे अपारदर्शी टोकन मानिए जिन्हें आप हू-ब-हू आगे ले जाते हैं। ## Refusals अब एक control-flow समस्या हैं यह वह बदलाव है जो सबसे ज़्यादा असर डालता है कि आप मॉडल के इर्द-गिर्द कोड कैसे लिखते हैं। Fable 5 आने वाली रिक्वेस्ट्स पर safety classifiers चलाता है, जो मुख्यतः रिसर्च बायोलॉजी और अधिकांश साइबरसिक्योरिटी कॉन्टेंट को निशाना बनाते हैं। जब कोई रिक्वेस्ट अस्वीकार होती है, तो आपको `stop_reason: "refusal"` के साथ एक **सफल HTTP 200** मिलता है — कोई error नहीं, कोई exception नहीं। `content` array खाली हो सकता है। अगर आपका कोड पहले `stop_reason` जाँचे बिना `response.content[0].text` करता है, तो जिस दिन कोई रिक्वेस्ट ठुकराई जाएगी, यह क्रैश कर जाएगा। और सौम्य आसपास के काम — वैध security tooling, लाइफ-साइंसेज़ टास्क — कभी-कभार false positive में फँस सकते हैं, तो यह सिर्फ़ संदिग्ध काम करने वालों की समस्या नहीं है। नियम यह है: **`stop_reason` पर ब्रांच करो, कभी `stop_details` पर नहीं।** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` प्रोडक्शन के लिए एक साफ़-सुथरा रास्ता है: एक सर्वर-साइड `fallbacks` पैरामीटर (बीटा में) जो किसी ठुकराई गई रिक्वेस्ट को उसी राउंड ट्रिप में `claude-opus-4-8` पर अपने-आप दोबारा कोशिश करता है, क्रेडिट-शैली री-प्राइसिंग लागू करके। अगर आप एजेंट बिना निगरानी के चला रहे हैं, तो इसे जोड़ दीजिए ताकि एक अकेला false-positive refusal पूरे रन को मृत-छोर तक न ले जाए। यह वही सबक है जो एजेंट्स के बारे में मैं बार-बार सीखता रहता हूँ जो [प्रोडक्शन में फेल होते रहते हैं](/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/): मॉडल का ज़्यादा स्मार्ट होना उसके edge cases को संभालने की ज़रूरत खत्म नहीं करता — यह बस edge cases को इधर-उधर खिसका देता है। ## माइग्रेशन के दो और ब्योरे कुछ छोटी चीज़ें जिन्होंने मेरा वक़्त खाया ताकि वे आपका न खाएँ: - **कोई assistant prefill नहीं।** अगर आप आख़िरी assistant टर्न को prefill करके आउटपुट को दिशा दे रहे थे, तो वह पैटर्न अब नहीं रहा। इसके बजाय structured outputs (`output_config.format`) या सिस्टम-प्रॉम्प्ट निर्देश इस्तेमाल कीजिए। - **30-दिन का डेटा रिटेंशन अनिवार्य है।** Fable 5 zero-data-retention के तहत उपलब्ध नहीं है। अगर आप अनुपालन कारणों से ZDR पर हैं, तो Fable 5 दायरे से बाहर है और Opus 4.8 आपकी सीमा बना रहता है। माइग्रेशन की योजना बनाने से *पहले* इसे जाँच लीजिए, बाद में नहीं। ## क्या आपको सचमुच स्विच करना चाहिए? इसके साथ रहने के बाद यह रहा मेरा ऑपरेटर वाला फ़ैसला। **Fable 5 डिफ़ॉल्ट "नवीनतम मॉडल पर अपग्रेड करो" लक्ष्य नहीं है — Opus 4.8 है।** यह लोगों को चौंकाता है, पर यही सही ढाँचा है। Opus 4.8, 4.7 से बस एक मॉडल-ID की अदला-बदली है जिसमें कोई नया ब्रेकिंग चेंज नहीं, यह सस्ता है, और एजेंट के अत्यधिक बहुसंख्यक काम के लिए आउटपुट गुणवत्ता में यह अप्रभेद्य है। Fable 5 सचमुच कठिन काम पर अपनी जगह अर्जित करता है: लंबे-दौर वाले एजेंट जिन्हें कई कदमों के पार सुसंगत रहना होता है, गहरा बहु-स्रोत तर्क, वे रन जहाँ जिस विफलता को आप मारने की कोशिश कर रहे हैं वह सूक्ष्म है। उनके लिए क्षमता असली है और प्रीमियम के लायक है। बाक़ी हर चीज़ के लिए — कॉन्टेंट ड्राफ़्टिंग, क्लासिफिकेशन, रूटिंग, सारांशीकरण — आप ऐसी गुणवत्ता के लिए ज़्यादा कीमत पर ज़्यादा टोकन चुका रहे हैं जिसे आप महसूस ही नहीं कर सकते। आख़िरकार मैं दोनों चलाने लगा। मेरा रिसर्च-और-संश्लेषण एजेंट Fable 5 पर चला गया। बाक़ी सब Opus 4.8 पर रहा। यही बँटवारा पूरा मुद्दा है: मॉडल हर काम के हिसाब से चुनिए, फ़ैशन के हिसाब से नहीं। अगर आप एजेंट्स का एक बेड़ा चलाते हैं, तो वही अनुशासन लागू होता है जिसके बारे में मैंने [मेरे 2026 ऑपरेटर स्टैक](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) में लिखा था — कठिन काम को महंगे मॉडल पर भेजिए और आसान काम के लिए ज़्यादा भुगतान करना बंद कीजिए। ## ऑपरेटर का अंतिम निचोड़ किसी और चीज़ को छूने से पहले Fable 5 को अपने एकमात्र सबसे कठिन काम पर टेस्ट कीजिए — वहीं यह कीमत वसूल करता है, और अगर यह वहाँ सुई नहीं हिलाता, तो कहीं नहीं हिलाएगा। token-counter को अपने असली प्रॉम्प्ट के ख़िलाफ़ चलाइए ताकि ~30% tokenizer फुलाव और कीमत प्रीमियम इनवॉइस पर आपको न चौंकाएँ। जहाँ कहीं Fable 5 प्रोडक्शन को छूता है वहाँ एक `stop_reason: "refusal"` जाँच (या Opus 4.8 की ओर सर्वर-साइड fallback) जोड़ दीजिए। फिर सोच-समझकर रूट कीजिए: कठिन 10% के लिए Fable 5, बाक़ी के लिए Opus 4.8। सबसे अच्छा मॉडल सबसे सक्षम वाला नहीं — वह है जो काम से मेल खाता हो। --- ## AI एजेंट्स के लिए शुरुआती गाइड: Cowork, Codex और वे टूल्स जो वाकई काम करते हैं Source: https://alejandrorioja.com/hi/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: AI एजेंट्स चैटबॉट्स से एक कदम आगे हैं: आप उन्हें सरल भाषा में लक्ष्य देते हैं और वे काम करते हैं — फाइलें पढ़ना, ड्राफ्ट बनाना, व्यवस्थित करना, कोड लिखना और चलाना। Cowork नो-कोड शुरुआती रास्ता है; Codex और Claude Code कोडबेस से काम करने वालों के लिए हैं। जरूरी कौशल प्रोग्रामिंग सीखना नहीं, बल्कि स्पष्ट और सीमित निर्देश लिखना है। ## Table of contents _जून 2026 को अपडेट किया गया।_ **TL;DR:** AI एजेंट्स चैटबॉट्स से एक कदम आगे हैं: आप उन्हें सरल भाषा में लक्ष्य देते हैं और वे काम करते हैं — फाइलें पढ़ना, ड्राफ्ट बनाना, व्यवस्थित करना, कोड लिखना और चलाना, और अपने नतीजे खुद जांचना। **Cowork** गैर-तकनीकी लोगों के लिए नो-कोड शुरुआती रास्ता है; **Codex** और **Claude Code** कोडबेस से काम करने वालों के लिए हैं। एकमात्र जरूरी कौशल प्रोग्रामिंग सीखना नहीं, बल्कि स्पष्ट और सीमित निर्देश लिखना है। **[लेखक की टिप्पणी]** मैं रोज 30 से ज्यादा कोडेड एजेंट्स चलाता हूं, लेकिन ज्यादातर लोगों को कोड के बिना भी 80% मूल्य मिल सकता है। उन्हें बस एक स्पष्ट निर्देश और उसे चलाने की जगह चाहिए। यह गाइड वह परिचय है जो मैं किसी ऐसे समझदार दोस्त को देता जिसने कभी एक लाइन कोड नहीं लिखी। ## "AI एजेंट" असल में क्या होता है चैटबॉट एक सवाल का जवाब देता है। **एजेंट** एक काम पूरा करता है। फर्क यह है कि एजेंट एक लूप में काम कर सकता है — दस्तावेज पढ़ना, यह तय करना कि आगे क्या करना है, फाइल लिखना, कमांड चलाना, नतीजा जांचना, जो गलत है उसे ठीक करना — बिना आपको हर कदम पर मार्गदर्शन किए। सीधे शब्दों में: आप नहीं पूछते "इस स्प्रेडशीट को कैसे साफ करूं?" आप कहते हैं "यह रही स्प्रेडशीट — डुप्लीकेट हटाओ, तारीखों का फॉर्मेट ठीक करो, और जिन पंक्तियों में ईमेल नहीं है उन्हें चिह्नित करो," और एजेंट यह करके साफ की हुई फाइल आपको दे देता है। *सलाह* से *पूरा काम* तक की यह बदलाव — यही पूरी बात है। ## टूल्स की दो फैमिली इस दुनिया में दो दरवाजे हैं, और आपको केवल वह चाहिए जो आपके काम से मेल खाता हो। ### दरवाजा 1: नो-कोड एजेंट्स (अगर आप कोड नहीं लिखते तो यहाँ से शुरू करें) **Claude Cowork** एक वर्कस्पेस है जहाँ आप Claude को एक लक्ष्य और सामग्री देते हैं — फाइलें, लिंक, नोट्स — और वह वह आउटपुट तैयार करता है जिसे आप समीक्षा करके इस्तेमाल करते हैं: एक ड्राफ्ट, सारांश, योजना, साफ की हुई स्प्रेडशीट। आप निर्देश लिखते हैं, कोड नहीं। इसे "एक बहुत काबिल सहायक जो तेज पढ़ता है और कभी थकता नहीं" मानें, न कि "प्रोग्रामिंग टूल।" मार्केटर्स, संस्थापकों, ऑपरेटर्स, लेखकों, विश्लेषकों — जिनका काम मुख्यतः दस्तावेज, रिसर्च और फैसले हैं — उनके लिए यही सही शुरुआती बिंदु है। ### दरवाजा 2: कोडिंग एजेंट्स (जब कोडबेस शामिल हो तो इनका उपयोग करें) **OpenAI Codex** और **Claude Code** ऐसे एजेंट हैं जो वहाँ रहते हैं जहाँ सॉफ्टवेयर बनाया जाता है — टर्मिनल, IDE या क्लाउड। आप एक बदलाव बताते हैं ("डार्क-मोड टॉगल जोड़ो," "यह फेल हो रहा टेस्ट ठीक करो," "इस फाइल को नए API पर माइग्रेट करो") और एजेंट कोड एडिट करता है, चलाता है, और तब तक दोहराता है जब तक काम हो जाए। आप फिर भी सब कुछ देखते हैं; एजेंट टाइपिंग करता है। इन्हें इस्तेमाल करने के लिए सीनियर इंजीनियर होने की जरूरत नहीं। बहुत से गैर-डेवलपर कोडिंग एजेंट्स का उपयोग छोटी वेबसाइट बनाने, स्प्रेडशीट को स्क्रिप्ट के रूप में ऑटोमेट करने और उन टूल्स के बग्स ठीक करने के लिए करते हैं जो उन्होंने नहीं लिखे। लेकिन एक असली लर्निंग कर्व है, इसलिए ज्यादातर शुरुआती लोगों के लिए दरवाजा 1 से शुरू करना और जब कोई ऐसा काम आए जिसमें सच में कोड चाहिए तभी दरवाजा 2 की तरफ जाना बेहतर है। ## आपकी पहली जीत (आज ही करें) कोई एक छोटा, परेशान करने वाला काम चुनें जो आप अक्सर करते हैं। अच्छे पहले विकल्प: - एक अव्यवस्थित मीटिंग ट्रांसक्रिप्ट को साफ नोट्स और एक एक्शन आइटम्स लिस्ट में बदलना। - एक लंबे PDF को 5 बुलेट पॉइंट्स और पूछने लायक 3 सवालों में सारांशित करना। - एक कच्चे ईमेल को दोबारा लिखना ताकि वह स्पष्ट, गर्मजोशी भरा और 120 शब्दों से कम हो। फिर वह स्ट्रक्चर इस्तेमाल करें जो एजेंट्स को भरोसेमंद बनाता है — **भूमिका → इनपुट → सटीक निर्देश → सीमा → एक जांच**: > आप मेरे सहायक हैं। नीचे एक [मीटिंग ट्रांसक्रिप्ट / PDF / ईमेल ड्राफ्ट] पेस्ट किया है। यह करें: [इसे बोल्ड \"एक्शन आइटम्स\" लिस्ट के साथ साफ नोट्स में बदलें / 5 बुलेट्स + 3 फॉलो-अप सवालों में सारांशित करें / इसे स्पष्ट, गर्मजोशी भरा और 120 शब्दों से कम करने के लिए दोबारा लिखें]। मेरी आवाज बनाए रखें। शुरू करने से पहले कोई एक सवाल पूछें अगर कुछ अस्पष्ट हो। > > [यहाँ अपनी सामग्री पेस्ट करें] बस। आपने एक काम डेलिगेट कर दिया। स्ट्रक्चर ही पूरा खेल है — और यह Cowork, ChatGPT, या किसी कोडिंग एजेंट में समान रूप से काम करता है। ## चार-भाग वाला प्रॉम्प्ट जो एजेंट्स को भरोसेमंद बनाता है शुरुआती लोग सोचते हैं कि रहस्य कोई जादुई वाक्यांश है। ऐसा नहीं है। रहस्य है विशिष्टता। हर भरोसेमंद एजेंट निर्देश के चार भाग होते हैं: 1. **भूमिका** — इस काम के लिए एजेंट कौन है ("आप मेरे रिसर्च सहायक हैं")। 2. **संदर्भ** — सामग्री और *क्यों* ("मैं एक फिनटेक संस्थापक के साथ सेल्स कॉल की तैयारी कर रहा हूं")। 3. **काम** — सटीक, सीमित कार्रवाई ("तीन हालिया फंडिंग राउंड के तथ्य निकालें और दो शुरुआती सवाल ड्राफ्ट करें")। 4. **सीमाएं + एक जांच** — फॉर्मेट, लंबाई, टोन, और अनुमान लगाने से पहले पूछने का निर्देश ("केवल बुलेट्स, स्रोत बताएं, अगर कंपनी अस्पष्ट हो तो एक स्पष्टीकरण प्रश्न पूछें")। अस्पष्ट इनपुट, अस्पष्ट आउटपुट। एजेंट जितना अधिक *कर सकता है*, आपकी स्पष्टता उतनी ही महत्वपूर्ण है — एक चैटबॉट जो गलत समझता है वह एक वाक्य बर्बाद करता है; एक एजेंट जो गलत समझता है वह एक दोपहर के काम को बर्बाद करता है जिसे आपको वापस करना पड़ता है। ## शुरुआती गलतियाँ जो छोड़ें - **इसे सर्च इंजन की तरह इस्तेमाल करना।** एक लाइन के सवाल मत पूछें। इसे असली फाइलों के साथ असली काम दें। - **सीमा छोड़ना।** "मुझे एक प्लान लिखो" आपको टेक्स्ट की दीवार देगा। "तीन फेज और हर काम के लिए जिम्मेदार व्यक्ति के साथ एक पेज का प्लान लिखो" आपको कुछ काम का देगा। - **जांच न मांगना।** "कुछ अस्पष्ट हो तो एक सवाल पूछें" जोड़ें और आप एजेंट के चलने से *पहले* गलतफहमियां पकड़ेंगे, बाद में नहीं। - **महत्वपूर्ण कोड पर कोडिंग एजेंट्स को बिना निगरानी चलने देना।** diff देखें। एजेंट तेज और अधिकतर सही होते हैं, लेकिन "अधिकतर" उस वाक्य में काम कर रहा है — जो कुछ भी शिप होता है उसमें इंसान को लूप में रखें। - **बहुत जल्दी दरवाजा 2 की तरफ जाना।** अगर आपका काम दस्तावेज और फैसले हैं, तो आपको कभी टर्मिनल खोलने की जरूरत नहीं। ## अपना पहला टूल कैसे चुनें - **आपका काम दस्तावेज, रिसर्च और लेखन है** → **Cowork** से शुरू करें (या जो चैट प्रोडक्ट आप पहले से पेमेंट करते हैं, उसे एजेंट मोड में इस्तेमाल करें)। - **आप सॉफ्टवेयर बनाना या ठीक करना चाहते हैं** → **Claude Code** या **OpenAI Codex**। - **आप नियमित, बिना हस्तक्षेप का काम चाहते हैं** (रोज का डाइजेस्ट, हफ्ते की रिपोर्ट) → एक बार प्रॉम्प्ट मैन्युअली सीख लें, फिर **[शेड्यूल्ड टास्क्स](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)** पर जाएं। ## AI एजेंट्स शुरुआती FAQ — 2026 ### क्या AI एजेंट्स इस्तेमाल करने के लिए कोडिंग जाननी चाहिए? नहीं। Claude Cowork जैसे नो-कोड एजेंट्स गैर-तकनीकी उपयोगकर्ताओं के लिए बने हैं — आप सरल भाषा में निर्देश लिखते हैं। Codex और Claude Code जैसे कोडिंग एजेंट्स में लर्निंग कर्व है, लेकिन उन्हें भी तेजी से ऐसे लोग इस्तेमाल कर रहे हैं जो खुद को प्रोग्रामर नहीं मानते। नो-कोड से शुरू करें, कोड की तरफ तभी जाएं जब काम को इसकी जरूरत हो। ### चैटबॉट और AI एजेंट में क्या फर्क है? चैटबॉट सवालों का जवाब देता है; एजेंट काम पूरा करता है। एजेंट एक लूप में क्रियाओं की श्रृंखला ले सकता है — पढ़ना, तय करना, करना, जांचना, ठीक करना — सलाह के बजाय पूरा काम तैयार करता है। व्यवहार में वही प्रोडक्ट अक्सर दोनों करता है; "एजेंट मोड" एजेंट का व्यवहार है। ### क्या Cowork Codex से बेहतर है? वे अलग-अलग कामों के लिए हैं, बेहतर या बुरे नहीं। Cowork दस्तावेजों, रिसर्च और ऑपरेशन के लिए नो-कोड वर्कस्पेस है। Codex (और Claude Code) सॉफ्टवेयर बनाने और ठीक करने के लिए कोडिंग एजेंट हैं। वह चुनें जो आपके काम से मेल खाता हो। ### AI एजेंट से अच्छे नतीजे कैसे मिलते हैं? विशिष्टता। चार-भाग वाला स्ट्रक्चर इस्तेमाल करें: भूमिका, संदर्भ, सटीक काम, और सीमाएं प्लस एक जांच। इसे असली सामग्री दें, बताएं आप कौन सा फॉर्मेट चाहते हैं, और शुरू करने से पहले अस्पष्टताएं बताने को कहें। स्पष्ट निर्देश किसी भी "जादुई प्रॉम्प्ट" से ज्यादा मायने रखते हैं। ### क्या AI एजेंट्स को अकेले चलने देना सुरक्षित है? कम जोखिम वाले, पलटे जा सकने वाले कामों के लिए (ड्राफ्टिंग, सारांश, व्यवस्थित करना), हाँ — आउटपुट की समीक्षा करें और आगे बढ़ें। जो कुछ भी असली सिस्टम बदलता है (कोड शिप करना, मैसेज भेजना, डेटा मिटाना), उसके लिए इंसान को लूप में रखें और एजेंट के काम करने से पहले समीक्षा करें। उलटाने की क्षमता सही पैमाना है: जितना आसान कुछ उलटना हो, उतनी ज्यादा स्वायत्तता वह सुरक्षित रूप से रख सकता है। **संबंधित पढ़ाई:** [ChatGPT के जवाबों में कैसे उद्धृत हों](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [llms.txt प्लेबुक](https://alejandrorioja.com/llms-txt-playbook/) · [Claude शेड्यूल्ड टास्क्स कैसे इस्तेमाल करें](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **क्या आप चाहते हैं कि एजेंट्स आपके बिजनेस में काम करें?** मैं ऑपरेटर टीमों के लिए AI एजेंट सिस्टम बनाता हूं — [संपर्क करें](https://alejandrorioja.com/contact/) या इस बारे में [मेरे सोचने के तरीके](https://alejandrorioja.com/seo-tips/) के बारे में और पढ़ें। --- ## Anthropic पैसे कैसे कमाता है? Claude का बिज़नेस मॉडल समझाया Source: https://alejandrorioja.com/hi/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropic अपने Claude AI मॉडलों तक पहुँच पाँच मुख्य चैनलों के माध्यम से बेचता है: एक उपयोग-आधारित API (आप प्रति टोकन भुगतान करते हैं), उपभोक्ता सदस्यताएँ (Claude Pro और Max), एंटरप्राइज़ प्लान (Team और Enterprise सीट), डेवलपर्स के लिए Claude Code, और Amazon Bedrock तथा Google Vertex जैसे क्लाउड मार्केटप्लेस के माध्यम से वितरण। API और एंटरप्राइज़ बिज़नेस — उपभोक्ता ऐप नहीं — सबसे बड़े राजस्व चालक हैं। ## Table of contents _जून 2026 में अपडेट किया गया।_ **TL;DR:** Anthropic अपने Claude AI मॉडलों तक पहुँच पाँच मुख्य चैनलों के माध्यम से बेचता है: एक **उपयोग-आधारित API** (आप प्रति टोकन भुगतान करते हैं), **उपभोक्ता सदस्यताएँ** (Claude Pro और Max), **एंटरप्राइज़ प्लान** (Team और Enterprise सीट), डेवलपर्स के लिए **Claude Code**, और Amazon Bedrock तथा Google Vertex AI जैसे **क्लाउड मार्केटप्लेस के माध्यम से वितरण**। उपभोक्ता चैट ऐप नहीं बल्कि API और एंटरप्राइज़ बिज़नेस — सबसे बड़े राजस्व चालक हैं। **[ऑपरेटर की टिप्पणी]** मैं हर दिन Anthropic के API पर विकास करता हूँ, इसलिए मैं बिज़नेस को मीटर के अंदर से देखता हूँ। समझने वाली बात यह है: Anthropic एक उपभोक्ता प्रवेश द्वार वाली B2B कंपनी है। आप जो चैट ऐप उपयोग करते हैं वह मार्केटिंग और एक राजस्व लाइन है; असली पैसा उन डेवलपर्स और उद्यमों में है जो API के माध्यम से टोकन मापते हैं और बड़े पैमाने पर सीट के लिए भुगतान करते हैं। ## Anthropic क्या है Anthropic एक AI सुरक्षा और अनुसंधान कंपनी है, जिसकी स्थापना 2021 में हुई, जो बड़े भाषा मॉडल के **Claude** परिवार का निर्माण करती है। यह उन मॉडलों को — और उनके आसपास के टूल्स को — उपभोक्ताओं, डेवलपर्स और उद्यमों को बेचती है। यह एक निजी कंपनी है, जिसे Amazon और Google सहित रणनीतिक निवेशकों का भारी समर्थन प्राप्त है, जो क्लाउड और वितरण भागीदारों के रूप में भी काम करते हैं। उत्पाद एक सेवा के रूप में बुद्धिमत्ता है: आप बॉक्स में सॉफ्टवेयर नहीं खरीदते, आप एक ऐसे मॉडल तक पहुँच किराये पर लेते हैं जो आपकी ओर से पढ़ता, लिखता, तर्क करता और कार्य करता है। नीचे दिया गया प्रत्येक चैनल उसी मूल संपत्ति के चारों ओर एक अलग आवरण है। ## Anthropic पैसे कैसे कमाता है? ### 1. API (उपयोग-आधारित, मुख्य इंजन) बिज़नेस की नींव। डेवलपर्स और कंपनियाँ API के माध्यम से Claude को कॉल करती हैं और **प्रति टोकन** भुगतान करती हैं — लगभग, इनपुट और आउटपुट में टेक्स्ट के प्रत्येक खंड के लिए। कीमत मॉडल की क्षमता के साथ बढ़ती है: - **Claude Opus** (सबसे सक्षम स्तर) सबसे महंगा है — प्रति मिलियन इनपुट टोकन कुछ डॉलर के क्रम में और आउटपुट के लिए उससे कई गुना अधिक। - **Claude Sonnet** (संतुलित कार्यशील मॉडल) बीच में है। - **Claude Haiku** (तेज, सस्ता स्तर) सबसे कम कीमत पर है, उच्च-मात्रा वाले सरल कार्यों के लिए। आउटपुट टोकन इनपुट टोकन से अधिक महंगे होते हैं, और लंबे संदर्भ, प्रॉम्प्ट कैशिंग और बैच प्रोसेसिंग जैसी सुविधाओं की अपनी कीमत होती है। मुख्य गतिशीलता: **राजस्व सीधे उपयोग के साथ बढ़ता है**। एक स्टार्टअप जो Claude को अपने उत्पाद में एम्बेड करता है और लाखों उपयोगकर्ताओं तक बढ़ता है, Anthropic द्वारा नया अनुबंध हस्ताक्षर किए बिना हर महीने अधिक API राजस्व उत्पन्न करता है। यह उपयोग-आधारित मॉडल ही कारण है कि AI लैब्स "रन-रेट राजस्व" के इतनी तेज़ी से बढ़ने की बात करते हैं — यह ग्राहकों की अपनी वृद्धि के साथ चक्रवृद्धि होती है। ### 2. उपभोक्ता सदस्यताएँ (Claude Pro और Max) Claude ऐप्स (वेब, डेस्कटॉप, मोबाइल) मुफ़्त में आज़माने के लिए उपलब्ध हैं, उन लोगों के लिए भुगतान वाले स्तर हैं जो इन्हें भारी मात्रा में उपयोग करते हैं: - **Claude Pro** — उच्च उपयोग सीमाओं, सर्वश्रेष्ठ मॉडलों तक पहुँच, और बड़े संदर्भ और प्राथमिकता पहुँच जैसी सुविधाओं के लिए एक निश्चित मासिक शुल्क। - **Claude Max** — उन पावर उपयोगकर्ताओं के लिए अधिक कीमत वाला स्तर जो Pro की सीमाओं तक पहुँचते हैं, जिसमें काफी अधिक उपयोग की गुंजाइश होती है। यह Anthropic का सबसे दृश्यमान हिस्सा है, लेकिन एक ऐसी कंपनी के लिए जिसके ग्राहक ज़्यादातर अन्य व्यवसाय हैं, यह API और एंटरप्राइज़ लाइनों की तुलना में छोटा हिस्सा है। इसका रणनीतिक मूल्य राजस्व स्रोत जितना ही एक फनल और ब्रांड सतह के रूप में है। ### 3. एंटरप्राइज़ (Team और Enterprise सीट) यहाँ बहुत सारा स्थायी पैसा है। कंपनियाँ संगठनों के लिए बनाए गए प्लान के साथ **प्रति-सीट** आधार पर अपने कर्मचारियों के लिए Claude खरीदती हैं: - **Team** — छोटी कंपनियों के लिए: पूल्ड उपयोग, केंद्रीय बिलिंग, सहयोग सुविधाएँ। - **Enterprise** — बड़े संगठनों के लिए: उच्च सुरक्षा और अनुपालन, एकल साइन-ऑन, बड़े संदर्भ विंडो, व्यवस्थापक नियंत्रण और उपयोग गारंटी। एंटरप्राइज़ सौदे आवर्ती होते हैं, समय के साथ विस्तार करते हैं (अधिक सीट, अधिक उपयोग), और उस तरह की स्विचिंग लागत के साथ आते हैं जो राजस्व को टिकाऊ बनाती है। यह मॉडल के ऊपर स्तरित क्लासिक SaaS गतिविधि है। ### 4. Claude Code (डेवलपर टूलिंग) **Claude Code** Anthropic का एजेंटिक कोडिंग टूल है — एक एजेंट जो आपके टर्मिनल, IDE या क्लाउड में कोड लिखता, संपादित करता और चलाता है। इसे उन्हीं सदस्यता और उपयोग रेल के माध्यम से मुद्रीकृत किया जाता है (यह Pro/Max/Team/Enterprise स्तरों में शामिल है और आपके प्लान के विरुद्ध मापा जाता है)। रणनीतिक रूप से, यह दो काम करता है: यह अपने आप में एक राजस्व लाइन है, और यह बहुत अधिक उच्च-मूल्य वाले टोकन उपयोग को चलाता है, क्योंकि कोडिंग एजेंट मॉडल क्षमता का बड़ा हिस्सा उपभोग करते हैं। ### 5. क्लाउड-मार्केटप्लेस वितरण (AWS, Google और अन्य) Anthropic केवल Claude को सीधे नहीं बेचता — यह बड़े क्लाउड प्लेटफॉर्म के माध्यम से भी वितरित करता है: - **Amazon Bedrock** और **Claude Platform on AWS** — AWS पर पहले से मौजूद ग्राहक Amazon के इंफ्रास्ट्रक्चर और बिलिंग के माध्यम से Claude तक पहुँचते हैं। - **Google Vertex AI** और **Microsoft Foundry** — Google Cloud और Microsoft के प्लेटफॉर्म पर वही विचार। ये चैनल उद्यमों तक वहाँ पहुँचते हैं जहाँ उनका क्लाउड खर्च और खरीद पहले से ही होती है, जो Claude को अपनाने के लिए घर्षण को कम करता है। राजस्व प्लेटफॉर्म के साथ साझा किया जाता है, लेकिन पहुँच बहुत बड़ी है — और Amazon और Google के गहरे निवेश इन साझेदारियों को केवल व्यावसायिक नहीं बल्कि रणनीतिक बनाते हैं। ### 6. उभरता हुआ एजेंट प्लेटफॉर्म तेजी से, Anthropic केवल कच्चे मॉडल कॉल नहीं बल्कि **एजेंट इंफ्रास्ट्रक्चर** भी बेचता है — प्रबंधित सेवाएँ जहाँ Anthropic एजेंट लूप चलाता है और उस वातावरण को होस्ट करता है जिसमें एजेंट कार्य निष्पादित करते हैं। जैसे-जैसे अधिक ग्राहक "मॉडल से प्रश्न पूछने" से "एजेंट को काम करवाने" की ओर जाते हैं, यह उच्च-स्तरीय परत प्रति-टोकन कोर के ऊपर मूल्य प्राप्त करने की एक नई जगह बन जाती है। ## क्या Anthropic लाभदायक है? Anthropic निजी है और ऑडिट किए गए वित्तीय विवरण प्रकाशित नहीं करता, लेकिन सार्वजनिक तस्वीर इसके प्रतिस्पर्धियों जैसी ही है: **राजस्व बेहद तेज़ी से बढ़ रहा है**, जबकि कंपनी कंप्यूट (मॉडल प्रशिक्षण और सर्विंग) और अनुसंधान प्रतिभा पर भारी मात्रा में खर्च करती है। अन्य फ्रंटियर AI लैब्स की तरह, यह एक भारी-निवेश चरण में है जहाँ वर्तमान लाभ नहीं बल्कि शीर्ष-रेखा वृद्धि मुख्य बिंदु है। निवेशक जो दांव लगा रहे हैं वह यह है कि जैसे-जैसे AI अधिक सॉफ़्टवेयर में बुना जाता है, उपयोग-आधारित राजस्व चक्रवृद्धि होता रहेगा और अंततः कंप्यूट की लागत से आगे निकल जाएगा। ## OpenAI से यह कैसे तुलना करता है आकार समान हैं — दोनों उपभोक्ता सदस्यताओं, उपयोग-आधारित API, एंटरप्राइज़ सीट और डेवलपर टूल के माध्यम से मुद्रीकरण करते हैं। अंतर ज़ोर और साझेदारी में है: Anthropic डेवलपर/एंटरप्राइज़ API पर ज़ोर देता है और Amazon और Google द्वारा समर्थित है; OpenAI का उपभोक्ता आधार बड़ा है और Microsoft के साथ गहरी साझेदारी है। यदि आप तुलना का दूसरा पक्ष देखना चाहते हैं, तो देखें [OpenAI पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-openai-make-money/)। ## Anthropic का राजस्व मॉडल — 2026 FAQ ### Anthropic का मुख्य राजस्व स्रोत क्या है? **उपयोग-आधारित API** और **एंटरप्राइज़ अनुबंध** सबसे बड़े चालक हैं। डेवलपर्स और कंपनियाँ Claude को कॉल करने के लिए प्रति टोकन भुगतान करती हैं, और संगठन अपनी टीमों के लिए प्रति-सीट प्लान खरीदते हैं। उपभोक्ता Claude सदस्यता सबसे दृश्यमान उत्पाद है लेकिन बिज़नेस लाइनों की तुलना में राजस्व का छोटा हिस्सा है। ### Claude API मूल्य निर्धारण कैसे काम करता है? आप प्रति टोकन भुगतान करते हैं — इनपुट और आउटपुट टेक्स्ट के खंडों में मापे जाते हैं। अधिक सक्षम मॉडल (Opus) संतुलित (Sonnet) या तेज़ (Haiku) मॉडल की तुलना में प्रति टोकन अधिक महंगे होते हैं, और आउटपुट टोकन इनपुट से अधिक महंगे होते हैं। लंबे संदर्भ, प्रॉम्प्ट कैशिंग और बैच प्रोसेसिंग जैसी सुविधाओं की अपनी कीमत होती है। राजस्व सीधे इस बात से बढ़ता है कि ग्राहक मॉडलों का कितना उपयोग करते हैं। ### क्या Anthropic सार्वजनिक रूप से कारोबार करता है? नहीं। Anthropic Amazon और Google सहित रणनीतिक और उद्यम निवेशकों द्वारा समर्थित एक निजी कंपनी है। इसके शेयर सार्वजनिक शेयर बाजारों पर उपलब्ध नहीं हैं, और कोई पुष्टि किया गया IPO नहीं है। ### क्या Anthropic मुफ्त Claude ऐप से पैसे कमाता है? मुफ्त उपयोगकर्ताओं से सीधे नहीं — मुफ्त स्तर एक फनल है। पैसा तब आता है जब मुफ्त उपयोगकर्ता **Pro** या **Max** में अपग्रेड करते हैं, जब टीमें **एंटरप्राइज़ सीट** खरीदती हैं, और विशेष रूप से जब डेवलपर्स **API** पर निर्माण करते हैं। मुफ्त ऐप का काम पहुँच और ब्रांड है; भुगतान किए गए स्तर और API वह जगह हैं जहाँ यह रूपांतरित होता है। ### Anthropic के सबसे बड़े ग्राहक कौन हैं? मुख्य रूप से अन्य व्यवसाय: सॉफ्टवेयर कंपनियाँ जो API के माध्यम से अपने उत्पादों में Claude को एम्बेड करती हैं, और उद्यम जो Claude को कर्मचारियों के लिए रोल आउट करते हैं। AWS, Google और Microsoft के माध्यम से क्लाउड-मार्केटप्लेस वितरण बड़े एंटरप्राइज़ ग्राहकों को भी आकर्षित करता है जो अपने मौजूदा क्लाउड प्रदाताओं के माध्यम से खरीदते हैं। **संबंधित पठन:** [OpenAI पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-openai-make-money/) · [AI एजेंट के लिए शुरुआती मार्गदर्शिका](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [ChatGPT उत्तरों में कैसे उद्धृत किया जाए](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## संक्षिप्त संस्करण Anthropic अपने Claude मॉडलों तक पहुँच किराये पर देता है। डेवलपर्स API के माध्यम से प्रति टोकन भुगतान करते हैं, उपभोक्ता Pro और Max के लिए मासिक भुगतान करते हैं, कंपनियाँ Team और Enterprise के लिए प्रति सीट भुगतान करती हैं, इंजीनियर उन्हीं प्लान पर Claude Code का उपयोग करते हैं, और क्लाउड दिग्गज (AWS, Google, Microsoft) अपने मार्केटप्लेस के माध्यम से उद्यमों को Claude पुनः बेचते हैं। यह एक उपभोक्ता प्रवेश द्वार वाला B2B बिज़नेस है — और मीटर, न कि चैट ऐप, वह जगह है जहाँ पैसा है। --- ## OpenAI पैसे कैसे कमाता है? ChatGPT और API बिज़नेस मॉडल Source: https://alejandrorioja.com/hi/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAI चार मुख्य तरीकों से पैसे कमाता है: ChatGPT सब्सक्रिप्शन (Plus, Pro, Team, Enterprise, Edu), एक उपयोग-आधारित API जहाँ डेवलपर्स प्रति टोकन भुगतान करते हैं, बड़े एंटरप्राइज़ अनुबंध, और Microsoft साझेदारी (वितरण के साथ-साथ राजस्व-साझाकरण समझौता)। अधिकांश AI लैब्स के विपरीत, OpenAI का उपभोक्ता सब्सक्रिप्शन व्यवसाय उसका सबसे बड़ा एकल राजस्व स्रोत है — ChatGPT का विशाल पैमाना ही इसका इंजन है। ## Table of contents _जून 2026 में अपडेट किया गया।_ **TL;DR:** OpenAI चार मुख्य तरीकों से पैसे कमाता है: **ChatGPT सब्सक्रिप्शन** (Plus, Pro, Team, Enterprise, Edu), एक **उपयोग-आधारित API** जहाँ डेवलपर्स प्रति टोकन भुगतान करते हैं, बड़े **एंटरप्राइज़ अनुबंध**, और **Microsoft साझेदारी** (वितरण के साथ-साथ राजस्व-साझाकरण समझौता)। अधिकांश AI लैब्स के विपरीत, OpenAI का उपभोक्ता सब्सक्रिप्शन व्यवसाय उसका सबसे बड़ा एकल राजस्व स्रोत है — ChatGPT का विशाल पैमाना ही इसका इंजन है। **[ऑपरेटर की नज़र]** OpenAI एक विशिष्ट एंटरप्राइज़ AI कंपनी का उलटा है: इसने पहले एक उपभोक्ता घटना बनाई और उसके बाद डेवलपर/एंटरप्राइज़ व्यवसाय खड़ा किया। ChatGPT के सैकड़ों करोड़ उपयोगकर्ता ब्रांड भी हैं और पैसे बनाने की मशीन भी। इस क्षेत्र में बाकी सभी चाहते हैं कि उनके पास भी ऐसा ही टॉप-ऑफ-फनल हो। ## OpenAI क्या है? OpenAI वह AI रिसर्च कंपनी है जिसने **ChatGPT** और **GPT** मॉडल परिवार बनाए, साथ ही Sora वीडियो मॉडल, इमेज जनरेशन, और Codex कोडिंग एजेंट जैसे उत्पाद भी। 2015 में स्थापित, इसने मुख्यधारा में पहचान तब बनाई जब 2022 के अंत में ChatGPT लॉन्च हुआ और इतिहास में सबसे तेज़ी से बढ़ने वाले उपभोक्ता उत्पादों में से एक बन गया। इसकी संरचना असामान्य है: यह एक गैर-लाभकारी संस्था के रूप में शुरू हुई और फिर फ्रंटियर मॉडल प्रशिक्षण के लिए आवश्यक भारी पूंजी जुटाने हेतु एक सीमित-लाभ वाली व्यावसायिक शाखा बनाई। यह सार्वजनिक रूप से सूचीबद्ध नहीं है और **Microsoft** के साथ एक गहरी, बहु-वर्षीय साझेदारी है जो कम्प्यूट, वितरण और पूंजी प्रदान करती है। उत्पाद, हर AI लैब की तरह, इंटेलिजेंस-ऐज़-ए-सर्विस है — उपभोक्ता, डेवलपर और एंटरप्राइज़ चैनलों के ज़रिए बेचा जाता है। ## OpenAI पैसे कैसे कमाता है? ### 1. ChatGPT सब्सक्रिप्शन (सबसे बड़ी लाइन) यही वो चीज़ है जो OpenAI को अपने प्रतिस्पर्धियों से अलग करती है। ChatGPT मुफ़्त में उपयोग किया जा सकता है, लेकिन पेड टियर्स इसके विशाल उपयोगकर्ता आधार के एक हिस्से को आवर्ती राजस्व में बदलते हैं: - **ChatGPT Plus** — सर्वश्रेष्ठ मॉडल्स तक पहुँच, उच्च सीमाएँ और प्रीमियम सुविधाओं के लिए मासिक फ्लैट शुल्क। मास-मार्केट टियर। - **ChatGPT Pro** — उन पावर यूज़र्स के लिए उच्च-मूल्य टियर जो अधिकतम उपयोग और सबसे शक्तिशाली मॉडल सेटिंग्स चाहते हैं। - **ChatGPT Team** — साझा वर्कस्पेस और एडमिन टूल्स के साथ छोटे व्यवसायों के लिए प्रति-सीट प्लान। - **ChatGPT Enterprise** — बड़े संगठनों के लिए: उन्नत सुरक्षा, अनुपालन, SSO, बड़ा संदर्भ, और उपयोग गारंटी। - **ChatGPT Edu** — विश्वविद्यालयों और स्कूलों के लिए तैयार किया गया संस्करण। चूँकि ChatGPT साप्ताहिक सैकड़ों करोड़ उपयोगकर्ताओं तक पहुँचता है, यहाँ तक कि पेड प्लान में एकल अंक कम रूपांतरण दर भी एक विशाल सब्सक्रिप्शन व्यवसाय बनाती है। यह उपभोक्ता पैमाना OpenAI का परिभाषित लाभ है, और सब्सक्रिप्शन को उसके सबसे बड़े राजस्व स्रोत के रूप में रिपोर्ट किया जाता है। ### 2. API (उपयोग-आधारित, डेवलपर्स के लिए) डेवलपर्स और कंपनियाँ OpenAI के मॉडल्स को अपने उत्पादों में शामिल करती हैं और **प्रति टोकन** — संसाधित टेक्स्ट (या इमेज, या ऑडियो) के प्रत्येक हिस्से के लिए भुगतान करती हैं। कीमतें मॉडल क्षमता के साथ बढ़ती हैं: फ्लैगशिप रीज़निंग मॉडल्स छोटे, तेज़, सस्ते मॉडल्स की तुलना में प्रति टोकन अधिक महंगे होते हैं, और आउटपुट की कीमत इनपुट से अधिक होती है। API GPT पर निर्माण करने वाली हर कंपनी को एक मीटर्ड ग्राहक में बदल देता है जिसका बिल उसके अपने उपयोग के साथ बढ़ता है। यह वही संयोजन गतिशीलता है जिस पर हर AI लैब निर्भर करती है: एक स्टार्टअप जो OpenAI को एम्बेड करता है और लाखों उपयोगकर्ताओं तक बढ़ता है, बिना किसी नए अनुबंध के हर महीने अधिक API राजस्व उत्पन्न करता है। ### 3. एंटरप्राइज़ अनुबंध सेल्फ-सर्व API और Team प्लान से परे, OpenAI बड़ी कंपनियों के साथ बड़े, कस्टम सौदे करता है — बल्क उपयोग, समर्पित क्षमता, कस्टम समर्थन, और सुरक्षा/अनुपालन प्रतिबद्धताएँ। ये आवर्ती हैं, समय के साथ विस्तारित होते हैं, और एक बार जब कोई कंपनी मॉडल्स के ऊपर महत्वपूर्ण वर्कफ़्लो बनाती है तो ये स्थायी हो जाते हैं। यह एंटरप्राइज़ मोशन उपभोक्ता व्यवसाय के साथ-साथ बैठता है और एक प्रमुख विकास क्षेत्र है। ### 4. Microsoft साझेदारी Microsoft OpenAI का सबसे बड़ा रणनीतिक भागीदार है। यह रिश्ता कई अक्षों पर काम करता है: - **कम्प्यूट** — Microsoft का Azure क्लाउड उस अधिकांश इन्फ्रास्ट्रक्चर प्रदान करता है जिस पर OpenAI मॉडल्स को ट्रेन और सर्व करता है। - **वितरण** — OpenAI के मॉडल्स Microsoft के प्लेटफ़ॉर्म (Azure के AI सेवाएँ, Copilot उत्पाद) के ज़रिए पेश किए जाते हैं, जो GPT को Microsoft के विशाल एंटरप्राइज़ ग्राहक आधार के सामने रखते हैं। - **राजस्व साझाकरण** — दोनों कंपनियाँ अपने व्यावसायिक समझौते के तहत राजस्व साझा करती हैं, और Microsoft ने OpenAI में भारी निवेश किया है। यह साझेदारी आंशिक रूप से पूंजी है और आंशिक रूप से गो-टू-मार्केट: यह OpenAI को उन एंटरप्राइज़ तक पहुँच देती है जिन तक सीधे बेचने में वर्षों लग जाते। ### 5. नए और समीपवर्ती उत्पाद OpenAI उस सतह का विस्तार करता रहता है जिसे वह मोनेटाइज़ कर सकता है: - **Codex** — इसका एजेंटिक कोडिंग टूल, सब्सक्रिप्शन और API उपयोग के ज़रिए मोनेटाइज़ किया गया (और भारी टोकन खपत का एक चालक)। - **Sora** — वीडियो जनरेशन, पेड टियर्स के अंदर और एक स्वतंत्र उत्पाद के रूप में पेश किया गया। - **इमेज जनरेशन और अन्य मोडैलिटी** — सब्सक्रिप्शन में बंडल और API के ज़रिए मीटर्ड। - **एक डेवलपर/एजेंट इकोसिस्टम** — कस्टम GPTs, एक एजेंट्स प्लेटफ़ॉर्म, और टूल्स जो व्यवसायों को OpenAI के मॉडल्स के ऊपर निर्माण करने देते हैं। इनमें से हर एक उसी मूल संपत्ति के आसपास एक और आवरण है, जिसका उद्देश्य उपयोगकर्ताओं और डेवलपर्स की भुगतान इच्छा का अधिक हिस्सा पकड़ना है। ## क्या OpenAI लाभदायक है? OpenAI निजी है और ऑडिटेड वित्तीय विवरण प्रकाशित नहीं करता। व्यापक रूप से रिपोर्ट की गई तस्वीर: **राजस्व बहुत बड़ा है और तेज़ी से बढ़ रहा है**, लेकिन लागत भी है — फ्रंटियर मॉडल्स को ट्रेन करना और सैकड़ों करोड़ उपयोगकर्ताओं की सेवा करने में चौंका देने वाली मात्रा में कम्प्यूट की खपत होती है। अपने समकक्षों की तरह, OpenAI भारी-निवेश के चरण में है जहाँ प्राथमिकता विकास और क्षमता है, न कि अल्पकालिक लाभ। दांव यह है कि पैमाना और बढ़ता एंटरप्राइज़ अपनाना अंततः कम्प्यूट लागत से आगे निकल जाएगा। ## Anthropic से तुलना निर्माण खंड समान हैं — उपभोक्ता सब्सक्रिप्शन, उपयोग-आधारित API, एंटरप्राइज़ सौदे, कोडिंग टूल्स — लेकिन जोर अलग है। OpenAI का परिभाषित किनारा **उपभोक्ता पैमाना** (ChatGPT) और उसकी **Microsoft** साझेदारी है; Anthropic **डेवलपर/एंटरप्राइज़ API** पर अधिक ध्यान देता है और Amazon और Google द्वारा समर्थित है। तुलना के दूसरे पक्ष के लिए, देखें [Anthropic पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-anthropic-make-money/)। ## OpenAI राजस्व मॉडल — 2026 FAQ ### OpenAI का सबसे बड़ा राजस्व स्रोत क्या है? **ChatGPT सब्सक्रिप्शन।** चूँकि ChatGPT सैकड़ों करोड़ उपयोगकर्ताओं तक पहुँचता है, इसके पेड टियर्स (Plus, Pro, Team, Enterprise, Edu) OpenAI की सबसे बड़ी एकल राजस्व लाइन बनाते हैं — एक AI लैब के लिए असामान्य प्रोफ़ाइल, जिनमें से अधिकांश उपभोक्ताओं की तुलना में API और एंटरप्राइज़ से अधिक कमाते हैं। ### OpenAI का API पैसे कैसे कमाता है? डेवलपर्स अपने ऐप्स में OpenAI के मॉडल्स का उपयोग करने के लिए **प्रति टोकन** भुगतान करते हैं — संसाधित प्रत्येक टेक्स्ट, इमेज या ऑडियो के हिस्से के लिए। अधिक सक्षम मॉडल्स प्रति टोकन अधिक लागत लेते हैं, और आउटपुट की कीमत इनपुट से अधिक होती है। ग्राहकों का अपना उपयोग बढ़ने के साथ राजस्व स्वचालित रूप से बढ़ता है। ### क्या OpenAI सार्वजनिक रूप से कारोबार करता है? क्या मैं OpenAI स्टॉक खरीद सकता हूँ? नहीं। OpenAI निजी तौर पर आयोजित है और इसके शेयर सार्वजनिक एक्सचेंजों पर उपलब्ध नहीं हैं। अधिकांश लोग सीधे निवेश नहीं कर सकते। Microsoft अपनी साझेदारी के माध्यम से एक बड़ी हिस्सेदारी रखता है, लेकिन यह OpenAI के सार्वजनिक होने जैसा नहीं है। ### Microsoft साझेदारी OpenAI को पैसे कैसे कमाती है? Microsoft Azure कम्प्यूट प्रदान करता है, अपने उत्पादों और क्लाउड के माध्यम से एक विशाल एंटरप्राइज़ आधार को OpenAI के मॉडल्स वितरित करता है, और दोनों अपने व्यावसायिक समझौते के तहत राजस्व साझा करते हैं। Microsoft ने OpenAI में भारी निवेश भी किया है। यह एक वित्तपोषण स्रोत और एक वितरण चैनल दोनों है। ### क्या OpenAI मुफ़्त ChatGPT उपयोगकर्ताओं से पैसे कमाता है? सीधे तौर पर नहीं — मुफ़्त टियर एक फनल है। राजस्व तब आता है जब मुफ़्त उपयोगकर्ता **Plus** या **Pro** में अपग्रेड करते हैं, जब व्यवसाय **Team** या **Enterprise** सीटें खरीदते हैं, और जब डेवलपर्स **API** पर निर्माण करते हैं। मुफ़्त उत्पाद की भूमिका पहुँच है; पेड टियर्स और API उसे परिवर्तित करते हैं। **संबंधित पठन:** [Anthropic पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-anthropic-make-money/) · [SpaceX पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-spacex-make-money/) · [AI एजेंट्स के लिए शुरुआती गाइड](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## संक्षिप्त संस्करण OpenAI ChatGPT के विशाल उपयोगकर्ता आधार को सब्सक्रिप्शन राजस्व (Plus, Pro, Team, Enterprise) में बदलता है, API के माध्यम से डेवलपर्स से प्रति टोकन शुल्क लेता है, बड़े एंटरप्राइज़ सौदे करता है, और कम्प्यूट, वितरण और साझा राजस्व के लिए Microsoft पर निर्भर करता है। इसकी परिभाषित विशेषता उपभोक्ता पैमाना है — अधिकांश AI लैब्स पहले डेवलपर्स को मोनेटाइज़ करती हैं; OpenAI ने पहले एक उपभोक्ता घटना बनाई और उसके पीछे एक व्यवसाय। --- ## SpaceX पैसा कैसे कमाता है? लॉन्च, Starlink और IPO का सवाल Source: https://alejandrorioja.com/hi/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceX तीन तरीकों से पैसा कमाता है: लॉन्च सेवाएं (पुन:उपयोगी Falcon रॉकेट पर ऑर्बिट की सीटें बेचना), Starlink (उपभोक्ता, एंटरप्राइज़, समुद्री/विमानन और सरकारी सैटेलाइट इंटरनेट) और सरकारी अनुबंध (NASA क्रू और कार्गो, चंद्र लैंडर, राष्ट्रीय सुरक्षा लॉन्च)। Starlink अब सबसे बड़ा राजस्व चालक है। SpaceX निजी रहता है; SpaceX का खुद का IPO जल्द नहीं आने वाला, हालांकि Starlink का भविष्य में स्पिन-ऑफ लंबे समय से चर्चा में है। ## Table of contents _जून 2026 में अपडेट किया गया।_ **TL;DR:** SpaceX तीन तरीकों से पैसा कमाता है: **लॉन्च सेवाएं** (पुन:उपयोगी Falcon रॉकेट पर ऑर्बिट की सीटें बेचना), **Starlink** (उपभोक्ता, एंटरप्राइज़, समुद्री/विमानन और सरकारी सैटेलाइट इंटरनेट) और **सरकारी अनुबंध** (NASA क्रू और कार्गो, चंद्र लैंडर, राष्ट्रीय सुरक्षा लॉन्च)। Starlink अब सबसे बड़ा राजस्व चालक है। SpaceX निजी रहता है; SpaceX का खुद का IPO जल्द नहीं आने वाला, हालांकि Starlink का भविष्य में स्पिन-ऑफ लंबे समय से चर्चा में है और बार-बार ठंडा पड़ा है। **[ऑपरेटर का नजरिया]** SpaceX आधुनिक समय का सबसे स्पष्ट उदाहरण है — एक ऐसी कंपनी जिसने हार्ड-टेक की खाई (पुन:उपयोगी रॉकेट) का उपयोग करके उसके ऊपर सॉफ़्टवेयर-अर्थव्यवस्था वाला व्यवसाय (सैटेलाइट इंटरनेट) खड़ा किया। लॉन्च व्यवसाय अस्तित्व का अधिकार कमाता है; Starlink वह जगह है जहां नियमित, स्केलेबल पैसा है। यही एक वाक्य में पूरी कहानी है। ## SpaceX क्या है SpaceX (स्पेस एक्सप्लोरेशन टेक्नोलॉजीज कॉर्प.) रॉकेट और अंतरिक्ष यान डिज़ाइन करता, बनाता और उड़ाता है, और Starlink सैटेलाइट इंटरनेट नेटवर्क संचालित करता है। 2002 में मानवता को बहु-ग्रहीय बनाने के दीर्घकालिक लक्ष्य के साथ स्थापित, यह कुछ ऐसा करके दुनिया का प्रमुख लॉन्च प्रदाता बन गया जो किसी और ने इस पैमाने पर नहीं किया: एक कक्षीय रॉकेट की पहली स्टेज को उतारना और फिर से उपयोग करना, जिसने अंतरिक्ष तक पहुंचने की लागत को ध्वस्त कर दिया। यह लागत लाभ हर चीज़ का इंजन है। सस्ते, बार-बार और भरोसेमंद लॉन्च ही वह चीज़ है जो 7,000 से अधिक सैटेलाइट के नक्षत्र को आर्थिक रूप से संभव बनाते हैं — और यह नक्षत्र ही एक असमान, परियोजना-आधारित लॉन्च व्यवसाय को नियमित-राजस्व व्यवसाय में बदलता है। ## SpaceX पैसा कैसे कमाता है? ### 1. लॉन्च सेवाएं मूल व्यवसाय। SpaceX तीन प्रकार के ग्राहकों को लॉन्च बेचता है: - **वाणिज्यिक सैटेलाइट ऑपरेटर** — जिन कंपनियों को कक्षा में पेलोड चाहिए, वे समर्पित लॉन्च के लिए या **राइडशेयर** मिशन में एक स्लॉट के लिए भुगतान करती हैं (एक रॉकेट पर कई छोटे सैटेलाइट, प्रति किलोग्राम कीमत पर)। - **सरकार और सैन्य** — राष्ट्रीय सुरक्षा पेलोड और विज्ञान मिशन, अक्सर विश्वसनीयता और आश्वासन के लिए प्रीमियम पर। - **अन्य अंतरिक्ष कंपनियां** — जिनमें तेजी से प्रतिस्पर्धी भी शामिल हैं जो अभी भी SpaceX पर निर्भर हैं क्योंकि यह सबसे सस्ती और सबसे उपलब्ध सवारी है। यूनिट अर्थव्यवस्था **पुन:उपयोगिता** के कारण काम करती है: एक ही फर्स्ट-स्टेज बूस्टर कई बार उड़ता है, इसलिए एक लॉन्च की सीमांत लागत कीमत से काफी कम होती है। Falcon 9 वर्कहॉर्स है; Falcon Heavy सबसे भारी पेलोड संभालता है। ### 2. Starlink (नियमित-राजस्व मशीन) Starlink हजारों निम्न-पृथ्वी-कक्षा सैटेलाइट का एक नक्षत्र है जो उन जगहों पर हाई-स्पीड इंटरनेट पहुंचाता है जहां स्थलीय ब्रॉडबैंड नहीं पहुंच पाता। यह अब SpaceX का वह हिस्सा है जो एक वास्तविक सदस्यता व्यवसाय जैसा दिखता है, कई परतों के साथ: - **उपभोक्ता** — परिवार एक डिश (हार्डवेयर) और मासिक सदस्यता के लिए भुगतान करते हैं। - **एंटरप्राइज़ और मोबिलिटी** — व्यवसायों, समुद्री (जहाज, नौका) और **विमानन** (एयरलाइनों के साथ इन-फ्लाइट Wi-Fi सौदे) के लिए उच्च-कीमत वाली योजनाएं। - **सरकार** — **Starshield** सहित, जो सैन्य और सरकारी ग्राहकों को बेचा जाने वाला रक्षा-उन्मुख वेरिएंट है। - **डायरेक्ट-टू-सेल** — मोबाइल कैरियर के साथ साझेदारी जो डेड ज़ोन में सामान्य फोन पर सीधे सैटेलाइट कनेक्टिविटी प्रदान करती है। Starlink लाखों ग्राहकों के बीच हार्डवेयर बिक्री (टर्मिनल) को मासिक नियमित राजस्व (सदस्यता) के साथ जोड़ता है — ग्रहीय पैमाने पर क्लासिक रेजर-एंड-ब्लेड आकार। इसीलिए अधिकांश अनुमान अब Starlink को लॉन्च से आगे SpaceX की सबसे बड़ी राजस्व लाइन के रूप में रखते हैं। ### 3. सरकारी अनुबंध एक अलग, बहुत बड़ा बकेट जो लॉन्च के साथ ओवरलैप करता है लेकिन अलग करने लायक है: - **NASA** — SpaceX **Commercial Crew** कार्यक्रम (Crew Dragon) के तहत अंतर्राष्ट्रीय अंतरिक्ष स्टेशन पर अंतरिक्ष यात्री उड़ाता है और **Cargo Dragon** से उसे आपूर्ति करता है। इसने NASA की चंद्र महत्वाकांक्षाओं के लिए **Starship**-आधारित मानव लैंडिंग सिस्टम बनाने का अनुबंध भी जीता। - **राष्ट्रीय सुरक्षा** — रक्षा और खुफिया पेलोड के लिए नियमित लॉन्च अनुबंध। ये अनुबंध उच्च-मूल्य, बहु-वर्षीय हैं और बहुत सारे विकास को वित्त पोषित करते हैं जो वाणिज्यिक पक्ष को लाभ देता है। ### 4. Starship (भविष्य का इंजन, अभी तक लाभ केंद्र नहीं) Starship SpaceX का पूरी तरह से पुन:उपयोगी, सुपर-हेवी-लिफ्ट वाहन है — Falcon का दीर्घकालिक प्रतिस्थापन और चंद्र/मंगल मिशन और Starlink सैटेलाइट की अगली, बड़ी पीढ़ी दोनों के लिए महत्वपूर्ण। आज यह अन्य तीन व्यवसायों द्वारा वित्त पोषित एक लागत केंद्र है। यदि यह नियमित उड़ान तक पहुंचता है, तो यह लॉन्च लागत को फिर से नाटकीय रूप से कम करता है और बहुत बड़ी Starlink तैनाती को अनलॉक करता है — निवेशक वास्तव में यही दांव लगा रहे हैं। ## क्या SpaceX लाभदायक है? SpaceX निजी है और ऑडिटेड वित्तीय रिपोर्ट प्रकाशित नहीं करता, इसलिए कोई भी सटीक बात एक अनुमान है। व्यापक रूप से रिपोर्ट की गई तस्वीर: पुन:उपयोगिता के कारण प्रति-मिशन आधार पर लॉन्च लाभदायक है, और जैसे-जैसे इसका ग्राहक आधार बढ़ा, Starlink कैश-फ्लो-पॉजिटिव क्षेत्र में आ गया। कंपनी Starship विकास में वापस भारी रकम डालती है, इसलिए "लाभ" काफी हद तक इस बात पर निर्भर करता है कि आप उस R&D को कैसे मानते हैं। प्रगति की दिशा — एक प्रमुख लॉन्च व्यवसाय के ऊपर बढ़ता हुआ Starlink नियमित राजस्व — कंपनी के विशाल निजी मूल्यांकन का समर्थन करती है। ## IPO का सवाल यही वह हिस्सा है जो सभी पूछते हैं, तो यहां ईमानदार संस्करण है। **SpaceX का जल्द IPO होने की उम्मीद नहीं है।** Elon Musk ने बार-बार कहा है कि जब तक Starship और मंगल कार्यक्रम पूंजी-गहन और दीर्घकालिक हैं, वे SpaceX को निजी रखना पसंद करते हैं — सार्वजनिक बाजार का तिमाही दबाव दशकों लंबे मिशन के साथ फिट नहीं बैठता। इसके बजाय, SpaceX आवधिक **टेंडर ऑफर** (कंपनी एक निर्धारित कीमत पर शेयर बिक्री की सुविधा देती है) के माध्यम से कर्मचारियों और शुरुआती निवेशकों को तरलता प्रदान करती है, जो लोगों को सार्वजनिक लिस्टिंग के बिना कैश आउट करने देता है। ये द्वितीयक बिक्री ही हेडलाइन मूल्यांकन आंकड़े उत्पन्न करती है — SpaceX को हाल के राउंड में सैकड़ों अरब डॉलर पर मूल्यांकित किया गया है। **Starlink स्पिन-ऑफ IPO लंबे समय से चर्चा में है** — Musk ने खुद वर्षों पहले सुझाव दिया था कि एक बार Starlink का राजस्व सुचारू और अनुमानित हो जाए तो यह अंततः सार्वजनिक हो सकता है। लेकिन उन्होंने निकट-अवधि के समय-सीमा पर बार-बार ठंडा पानी डाला है। 2026 तक, Starlink का IPO नहीं हुआ है, और कोई पुष्टि की गई तारीख नहीं है। किसी भी "Starlink IPO तारीख" की हेडलाइन को संदेह से देखें जब तक कि यह कंपनी से न आए। ## निष्कर्ष SpaceX का मॉडल एक स्टैक है: पुन:उपयोगी लॉन्च एक लागत खाई बनाता है, वह खाई Starlink को आर्थिक रूप से संभव बनाती है, Starlink पूरी चीज़ को एक नियमित-राजस्व व्यवसाय में बदलती है, और सरकारी अनुबंध अग्रिम कार्य (Starship) को वित्त देते हैं जो फिर से लागत वक्र को रीसेट करता है। यह अपनी पसंद से निजी रहता है, IPO के बजाय टेंडर ऑफर का उपयोग करते हुए — और सार्वजनिक बाजारों का सबसे संभावित रास्ता एक भविष्य की Starlink लिस्टिंग है, न कि समग्र रूप से SpaceX, जब कंपनी तय करे कि समय सही है। ## SpaceX राजस्व मॉडल — 2026 FAQ ### SpaceX का सबसे बड़ा राजस्व स्रोत क्या है? अधिकांश अनुमान अब **Starlink** को लॉन्च सेवाओं से आगे SpaceX की सबसे बड़ी राजस्व लाइन के रूप में रखते हैं, जो लाखों उपभोक्ता, एंटरप्राइज़, मोबिलिटी और सरकारी सदस्यता के साथ-साथ टर्मिनल हार्डवेयर बिक्री द्वारा संचालित है। लॉन्च सेवाएं बड़ी और प्रति-मिशन अत्यधिक लाभदायक बनी हुई हैं, लेकिन Starlink का नियमित मॉडल तेज़ी से स्केल होता है। ### क्या SpaceX सार्वजनिक रूप से कारोबार करता है? क्या मैं SpaceX स्टॉक खरीद सकता हूं? नहीं। SpaceX एक निजी कंपनी है और इसके शेयर सार्वजनिक स्टॉक एक्सचेंज पर उपलब्ध नहीं हैं। अधिकांश लोग सीधे निवेश नहीं कर सकते; पहुंच आम तौर पर निजी राउंड या टेंडर ऑफर में भाग लेने वाले कर्मचारियों और मान्यता प्राप्त निवेशकों तक सीमित है। ऐसे "SpaceX स्टॉक" प्रस्तावों से सावधान रहें जो अन्यथा सुझाते हैं। ### क्या SpaceX या Starlink IPO करेंगे? SpaceX के निकट भविष्य में सार्वजनिक होने की उम्मीद नहीं है — Musk ने कहा है कि वे Starship/मंगल पूंजी-गहन चरण के दौरान इसे निजी रखना चाहते हैं। **Starlink** IPO को वर्षों से एक संभावना के रूप में चर्चा में लाया गया है जब इसका राजस्व अनुमानित हो जाए, लेकिन 2026 तक कोई पुष्टि की गई तारीख नहीं है। किसी भी विशिष्ट "IPO तारीख" दावे को संदेह के साथ माना जाना चाहिए जब तक कि यह कंपनी से न हो। ### Starlink पैसा कैसे कमाता है? Starlink ग्राहकों से एक सैटेलाइट डिश (हार्डवेयर) और एक मासिक सदस्यता शुल्क लेता है, उपभोक्ता, व्यवसाय, समुद्री, विमानन और सरकारी स्तर पर — रक्षा-केंद्रित Starshield और डायरेक्ट-टू-सेल कैरियर साझेदारी सहित। यह रेजर-एंड-ब्लेड मॉडल है: पहले हार्डवेयर, फिर नियमित राजस्व। ### पुन:उपयोगिता SpaceX के लाभ में कैसे मदद करती है? एक ही रॉकेट बूस्टर को कई बार उतारना और फिर से उड़ाना प्रत्येक लॉन्च की सीमांत लागत को वसूले गए मूल्य से काफी नीचे कर देता है। यह लागत लाभ ही SpaceX को सबसे सस्ता लॉन्च प्रदाता बनाता है और कई हजार सैटेलाइट के Starlink नक्षत्र को तैनात करना आर्थिक रूप से व्यवहार्य बनाता है। **संबंधित पठन:** [Uber पैसा कैसे कमाता है](https://alejandrorioja.com/how-does-uber-make-money/) · [Shopify पैसा कैसे कमाता है](https://alejandrorioja.com/how-shopify-makes-money/) · [PayPal पैसा कैसे कमाता है](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## संक्षिप्त संस्करण SpaceX सस्ते में ऑर्बिट की सीटें बेचता है क्योंकि यह अपने रॉकेट को फिर से उपयोग करता है, फिर उस लागत लाभ का उपयोग Starlink चलाने के लिए करता है — एक सैटेलाइट इंटरनेट सदस्यता व्यवसाय जो अब इसका सबसे बड़ा कमाई करने वाला है — जबकि सरकारी अनुबंध अगली पीढ़ी के Starship को वित्त देते हैं। यह जानबूझकर निजी रहता है; SpaceX का नहीं बल्कि Starlink का IPO सार्वजनिक बाजारों तक की सबसे संभावित अंतिम राह है। --- ## Claude के शेड्यूल्ड टास्क कैसे उपयोग करें: cron के साथ दोहराए जाने वाले काम को स्वचालित करें Source: https://alejandrorioja.com/hi/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: शेड्यूल्ड टास्क एक बार के Claude प्रॉम्प्ट को दोहराए जाने वाले काम में बदल देते हैं: यह cron-स्टाइल शेड्यूल पर चलता है, काम करता है और नतीजा देता है। व्यक्तिगत दोहराए जाने वाले प्रॉम्प्ट (सुबह का डाइजेस्ट, साप्ताहिक सारांश) के लिए Claude ऐप और क्लाउड में चलने वाले डेवलपर ऑटोमेशन के लिए Claude Code रूटीन या Managed Agents डिप्लॉयमेंट का उपयोग करें। फायदा उस काम को स्वचालित करने में है जो आप अन्यथा हर दिन या हर हफ्ते हाथ से करते। ## Table of contents _जून 2026 में अपडेट किया गया।_ **TL;DR:** शेड्यूल्ड टास्क एक बार के Claude प्रॉम्प्ट को दोहराए जाने वाले काम में बदल देते हैं: यह cron-स्टाइल शेड्यूल पर चलता है, काम करता है और नतीजा देता है। व्यक्तिगत दोहराए जाने वाले प्रॉम्प्ट (सुबह का डाइजेस्ट, साप्ताहिक सारांश) के लिए **Claude ऐप** और क्लाउड में चलने वाले डेवलपर ऑटोमेशन के लिए **Claude Code रूटीन** या **Managed Agents डिप्लॉयमेंट** का उपयोग करें। फायदा उस काम को स्वचालित करने में है जो आप अन्यथा हर दिन या हर हफ्ते हाथ से दोहराते। **[ऑपरेटर्स के लिए]** सबसे अधिक लीवरेज वाले ऑटोमेशन चकाचौंध नहीं करते — ये वो छोटे दोहराए जाने वाले काम हैं जो चुपचाप हर दिन 20 मिनट खा जाते हैं। शेड्यूल्ड टास्क इन्हें एक बार Claude को सौंपने और कभी न सोचने का तरीका है। मैं कई चलाता हूँ: सुबह प्रतिस्पर्धी स्कैन, रात में PR स्टेटस चेक, साप्ताहिक कंटेंट-पाइपलाइन ड्राफ्ट। किसी को सेट करने में 10 मिनट से ज़्यादा नहीं लगे। ## शेड्यूल्ड टास्क क्या है एक सामान्य Claude सेशन सिंक्रोनस होता है: आप टाइप करते हैं, वो जवाब देता है, आप वहाँ होते हैं। **शेड्यूल्ड टास्क** असिंक्रोनस और दोहराया जाने वाला होता है: आप एक प्रॉम्प्ट (या पूरा एजेंट वर्कफ्लो) प्लस एक शेड्यूल परिभाषित करते हैं, और Claude इसे खुद से चलाता है — हर कार्यदिवस सुबह 7 बजे, हर सोमवार, हर घंटे — और जब हो जाए तो नतीजा आपको देता है। अंदर से यह एक cron जॉब है जिसके केंद्र में एक LLM है। APIs जोड़ने के लिए आपको कोड लिखने की ज़रूरत नहीं; आप सामान्य भाषा में नतीजा बताते हैं और एजेंट हर बार चलने पर खुद कदम तय करता है। ## तीन जगहें जहाँ आप इन्हें सेट करेंगे एक बटन नहीं है — तीन सतहें हैं, इस पर निर्भर कि आप कौन हैं। ### 1. Claude ऐप (सभी के लिए) कंज्यूमर Claude ऐप दोहराए जाने वाले टास्क सपोर्ट करते हैं: आप प्रॉम्प्ट और कैडेंस सेव करते हैं, Claude इसे शेड्यूल पर चलाता है और नतीजे के साथ नोटिफाई करता है। यह नो-कोड रास्ता है — रोज़ाना ब्रीफिंग, बार-बार रिसर्च पुल, "हर सुबह मेरे अनपढ़े न्यूज़लेटर सारांशित करो" जैसे काम के लिए आदर्श। अगर आप डेवलपर नहीं हैं, यहीं से शुरू करें। ### 2. Claude Code रूटीन (टर्मिनल में रहने वालों के लिए) अगर आप **Claude Code** उपयोग करते हैं, तो आप एक प्रॉम्प्ट या स्लैश कमांड को cron कैडेंस पर क्लाउड एजेंट के रूप में चलाने के लिए शेड्यूल कर सकते हैं — एक "रूटीन"। यह आपके रेपो या वर्कस्पेस पर सर्वर-साइड चलता है, इसलिए जब लैपटॉप बंद हो तब भी काम करता है। सामान्य उपयोग: खुले pull requests देखना, रात का lint-और-fix पास चलाना, हर सुबह रिव्यू के लिए एक ड्राफ्ट पोस्ट बनाना। आप शेड्यूल और टास्क परिभाषित करते हैं; Claude Code फायरिंग और रन रिकॉर्ड संभालता है। ### 3. Managed Agents डिप्लॉयमेंट (प्रोडक्ट बनाने वाले डेवलपर्स के लिए) Claude API पर बनाने वाली टीमों के लिए, **शेड्यूल्ड डिप्लॉयमेंट** एक एजेंट को बार-बार cron शेड्यूल पर चलाते हैं — हर फायरिंग एक सेशन शुरू करती है जो स्वायत्त रूप से काम करती है (रात का कंप्लायंस स्कैन, साप्ताहिक रिपोर्ट, हर घंटे की निगरानी)। आपको सफलताओं और विफलताओं की ऑडिट के लिए प्रति-फायरिंग रन रिकॉर्ड मिलता है। यह उसी विचार का प्रोग्रामेटिक, प्रोडक्शन-ग्रेड वर्शन है। ## शेड्यूल के बारे में कैसे सोचें तीनों एक ही मानसिक मॉडल उपयोग करते हैं — **कौन सा टास्क, कितनी बार, आउटपुट के साथ क्या करें**: 1. **टास्क** — इसे ऐसे लिखें जैसे आप कोई भी अच्छा एजेंट प्रॉम्प्ट लिखते: भूमिका, संदर्भ, सटीक कार्य, बाधाएं और एक जांच। शेड्यूल्ड टास्क रन के बीच में स्पष्टीकरण नहीं पूछ सकता, इसलिए इसे *पहले से पूरी तरह निर्दिष्ट* होना चाहिए। यह इंटरेक्टिव उपयोग से सबसे बड़ा अंतर है। 2. **कैडेंस** — दैनिक, साप्ताहिक, प्रति घंटे, केवल कार्यदिवस, आपके टाइमज़ोन में एक विशिष्ट समय। इसे मिलाएं कि असली चीज़ कितनी तेज़ी से बदलती है; साप्ताहिक-अपडेट स्रोत का "दैनिक" डाइजेस्ट बर्बाद रन हैं। 3. **डिलीवरी** — नतीजा कहाँ पहुँचता है (नोटिफिकेशन, फाइल, मैसेज, ड्राफ्ट)। यह पहले से तय करें ताकि आउटपुट आते ही उपयोगी हो। ## ऐसे पैटर्न जो वाकई फायदेमंद हैं - **सुबह का डाइजेस्ट।** "हर कार्यदिवस सुबह 7 बजे, [विषयों] पर नवीनतम जानकारी लो, तीन महत्वपूर्ण बातें सारांशित करो और मुझे 5-बुलेट ब्रीफ भेजो।" 20 मिनट के मैनुअल स्कैनिंग की जगह लेता है। - **साप्ताहिक रिपोर्ट।** "हर सोमवार, [मेट्रिक्स] को एक पेज के सारांश में संकलित करो जिसमें क्या बदला और क्यों शामिल हो।" बार-बार की उबाऊ काम को रिव्यू में बदलता है। - **रात का कार्यकर्ता।** एक कोडिंग रूटीन जो सोते समय एक लंबा, अच्छी तरह से निर्दिष्ट काम चलाता है — रिफैक्टर, टेस्ट स्वीप, डेटा क्लीनअप — ताकि आप एक समीक्षा योग्य नतीजे के साथ जागें। - **मॉनिटर।** "हर घंटे [चीज़] जांचो; मुझे केवल तब संदेश करो जब [शर्त] सच हो।" सबसे अच्छे ऑटोमेशन ज़्यादातर चुप रहते हैं और केवल तब बोलते हैं जब मायने रखता है। ## प्रोडक्शन में चलाने से मिले सेटअप टिप्स - **प्रॉम्प्ट अत्यधिक विस्तृत लिखें।** रन के बीच में स्पष्टीकरण के सवाल संभव नहीं हैं। फ़ॉर्मैट, स्रोत, बाधाएं और एज केस में क्या करना है, बताएं। - **मैनुअल टेस्ट से शुरू करें।** एक बार हाथ से सटीक प्रॉम्प्ट चलाएं। अगर यह इंटरेक्टिव रूप से वो देता है जो आप चाहते हैं, तो शेड्यूल करें। नहीं तो पहले प्रॉम्प्ट ठीक करें — एक बुरे प्रॉम्प्ट को शेड्यूल करना बस विश्वसनीय रूप से बुरा आउटपुट देता है। - **कैडेंस को परिवर्तन दर से मिलाएं।** ऐसी चीज़ पर प्रति घंटे न चलाएं जो साप्ताहिक अपडेट होती है। - **जब दांव ऊँचे हों तो आउटपुट को ड्राफ्ट रखें।** दुनिया में बाहर जाने वाली किसी भी चीज़ के लिए — एक पब्लिश्ड पोस्ट, भेजा गया ईमेल — टास्क को लाइव एक्शन के बजाय आपकी समीक्षा के लिए *ड्राफ्ट* बनाने दें। पूरी तरह स्वायत्त "बस करो" को कम-दांव, पलटने योग्य काम के लिए रखें। - **पहले कुछ रन देखें।** शेड्यूल्ड जॉब ड्रिफ्ट होते हैं — एक स्रोत फ़ॉर्मैट बदलता है, एक फीड शांत हो जाता है। शुरुआती रन रिकॉर्ड जांचें, फिर भरोसा करें। ## Claude शेड्यूल्ड टास्क — 2026 FAQ ### Claude के शेड्यूल्ड टास्क क्या हैं? ये दोहराए जाने वाले काम हैं: आप एक प्रॉम्प्ट या एजेंट वर्कफ्लो प्लस cron-स्टाइल शेड्यूल परिभाषित करते हैं, और Claude इसे स्वचालित रूप से चलाता है — दैनिक, साप्ताहिक, प्रति घंटे — बिना आपके कीबोर्ड पर होने के नतीजा देता है। ये कंज्यूमर Claude ऐप (व्यक्तिगत दोहराए जाने वाले प्रॉम्प्ट के लिए), Claude Code (क्लाउड रूटीन के रूप में) और Claude API (Managed Agents डिप्लॉयमेंट के रूप में) में मौजूद हैं। ### क्या मुझे इन्हें उपयोग करने के लिए डेवलपर होना चाहिए? नहीं। Claude ऐप बिना कोड के दोहराए जाने वाले टास्क सपोर्ट करता है — बस एक सेव किया प्रॉम्प्ट और एक कैडेंस। Claude Code रूटीन और Managed Agents डिप्लॉयमेंट कोड और प्रोडक्ट वर्कफ्लो को स्वचालित करने के लिए डेवलपर-फेसिंग वर्शन हैं। ### शेड्यूल्ड टास्क एक सामान्य Claude चैट से कैसे अलग है? एक सामान्य चैट इंटरेक्टिव है — आप फॉलो-अप सवालों का जवाब देने के लिए वहाँ हैं। शेड्यूल्ड टास्क स्वायत्त और दोहराया जाने वाला है, इसलिए प्रॉम्प्ट पहले से पूरी तरह निर्दिष्ट होना चाहिए; Claude रन के बीच में आपसे सवाल पूछने के लिए रुक नहीं सकता। यह शेड्यूल पर फायर होता है, काम पूरा करता है और नतीजा आपको देता है। ### पहला शेड्यूल्ड टास्क क्या होना चाहिए? एक सुबह का डाइजेस्ट। "हर कार्यदिवस सुबह 7 बजे, [आपके विषयों] पर नवीनतम जानकारी पाँच बुलेट में सारांशित करो।" यह कम-दांव है, जांचना आसान है, और तुरंत एक दोहराई जाने वाली मैनुअल चोर की जगह लेता है — कुछ बड़ा स्वचालित करने से पहले वर्कफ्लो सीखने का परफेक्ट टेम्पलेट। ### क्या शेड्यूल्ड टास्क वास्तविक क्रियाएं कर सकता है, जैसे ईमेल भेजना? हाँ, लेकिन सोच-समझकर करें। पलटने योग्य, कम-दांव वाले काम के लिए, इसे करने दें। बाहर की ओर मुख करने वाली या पलटने में मुश्किल चीज़ों के लिए, स्वचालित रूप से फायर करने के बजाय टास्क को आपके अप्रूवल के लिए ड्राफ्ट बनाने दें — खासकर बिना निगरानी के रन पर। पलटने की क्षमता ही यह तय करने का सही टेस्ट है कि कितनी स्वायत्तता दें। **संबंधित पठन:** [AI एजेंट्स के लिए शुरुआती गाइड](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Anthropic पैसे कैसे कमाता है](https://alejandrorioja.com/how-does-anthropic-make-money/) · [ChatGPT के जवाबों में उद्धृत कैसे हों](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **अपने दोहराए जाने वाले काम को चलाने वाला शेड्यूल्ड एजेंट सिस्टम चाहते हैं?** यही वो है जो मैं बनाता हूँ — [संपर्क करें](https://alejandrorioja.com/contact/)। --- ## AI एजेंट की लागत का गणित: Haiku कब Sonnet को मात देता है (और कब नहीं) Source: https://alejandrorioja.com/hi/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Sonnet के बजाय Claude Haiku चुनने से प्रति-कॉल लागत में नाटकीय कटौती हो सकती है, पर केवल तब जब टास्क कम सफलता-दर को सह सके। असली मापदंड प्रति-कॉल लागत नहीं है — यह प्रति-सफल-परिणाम लागत है, जिसमें रीट्राई और मानव सफ़ाई शामिल है। मैं डिफ़ॉल्ट से नहीं, टास्क के हिसाब से राउट करता हूँ। ## विषय-सूची _जून 2026 में अपडेट किया गया।_ **सारांश:** Sonnet के बजाय Claude Haiku चुनने से प्रति-कॉल लागत एक परिमाण-कोटि (order of magnitude) तक घट सकती है, पर केवल तब जब टास्क Haiku की कम सफलता-दर को सह सके। जो मापदंड मायने रखता है वह है **प्रति-सफल-परिणाम लागत** — कॉल लागत जोड़ रीट्राई जोड़ मानव सफ़ाई — न कि प्रति-टोकन का दिखावटी दाम। मैं हर टास्क के हिसाब से राउट करता हूँ, और मेरे उच्च-मात्रा वाले चरणों का एक बड़ा हिस्सा Haiku पर चलता है जबकि निर्णय वाले काम Sonnet पर रहते हैं। **ऑपरेटर का नज़रिया:** मैं 100 से ज़्यादा एजेंट चलाता हूँ, और इन्फ़रेंस एक असली ख़र्च-मद है। पर मैंने ऐसी टीमें देखी हैं जो हर चीज़ को सबसे सस्ते मॉडल पर ठूँसकर "पैसा बचातीं" और फिर वह लागत रीट्राई, एस्केलेशन और नाराज़ ग्राहकों के रूप में चुकातीं। लागत-गणित तभी काम करता है जब आप पूरे फ़नल को मापें। सबसे सस्ता मॉडल वह नहीं है जिसका प्रति-टोकन दाम सबसे कम हो। वह है जिसकी काम को सही ढंग से पूरा करने की कुल लागत सबसे कम हो। ये अलग-अलग आँकड़े हैं, और इनके बीच का फ़ासला ही वह जगह है जहाँ एजेंट की ज़्यादातर लागत-संबंधी निर्णय गड़बड़ा जाते हैं। ## टोकन की अर्थव्यवस्था, सीधे शब्दों में Anthropic, Claude के लिए प्रति दस लाख टोकन शुल्क लेता है, इनपुट और आउटपुट अलग-अलग बिल होते हैं, और आउटपुट की लागत इनपुट से कई गुना ज़्यादा होती है। सटीक आँकड़े समय के साथ बदलते हैं, इसलिए Anthropic की मौजूदा क़ीमत देखें — पर निर्णय को जो चलाता है वह है **संरचना**: - **Haiku** सस्ता, तेज़ स्तर है — परिवार में अब तक की सबसे कम प्रति-टोकन लागत। - **Sonnet** बीच में बैठता है — Haiku से काफ़ी महँगा, Opus से काफ़ी सस्ता। - **Opus** सबसे कठिन तर्क के लिए प्रीमियम स्तर है। इससे दो बातें निकलती हैं। पहली, जनरेटिव टास्क में आउटपुट टोकन लागत पर हावी रहते हैं, इसलिए एक बातूनी मॉडल समान प्रति-टोकन दर पर भी ज़्यादा महँगा पड़ता है। दूसरी, Haiku और Sonnet के बीच प्रति-टोकन फ़ासला इतना बड़ा है कि उच्च-मात्रा वाले चरण पर वह बिल में ज़रूर दिखता है। यह Haiku के *पक्ष* में तर्क है। अब इसके ख़िलाफ़ तर्क। ## असल में जो मापदंड मायने रखता है: प्रति-सफल-परिणाम लागत प्रति-कॉल लागत एक दिखावटी आँकड़ा है। यह रहा वह सूत्र जो मैं सचमुच इस्तेमाल करता हूँ: ``` प्रति_सफलता_लागत = (कॉल_लागत × प्रयास) + सफ़ाई_लागत ÷ सफलता_दर ``` जहाँ `प्रयास` रीट्राई को गिनता है, और `सफ़ाई_लागत` वह अपेक्षित लागत है जो किसी इंसान द्वारा छूटी हुई विफलताओं को ठीक करने में लगती है। देखिए यह तुलना के साथ क्या करता है। मान लीजिए Haiku प्रति कॉल Sonnet की लगभग दसवें हिस्से की लागत है। अगर किसी टास्क पर Haiku 80% बार सफल होता है और Sonnet 98% बार, तो प्रति-कॉल बचत बहुत बड़ी दिखती है। पर अगर Haiku की हर विफलता एक रीट्राई छेड़ती है और 10 में से 1 को अब भी एक इंसान की ज़रूरत होती है जिसका असली पैसा लगता है, तो सफ़ाई वाला पद टोकन की बचत को निगल सकता है। कम-जोखिम, उच्च-मात्रा वाले टास्क पर गणित ज़बरदस्त ढंग से Haiku के पक्ष में है। ऐसे टास्क पर जहाँ एक विफलता ग़लत ग्राहक को ईमेल भेज दे, यह पूरी तरह पलट सकता है। आप यह निर्णय हर मॉडल की सफलता-दर मापे बिना नहीं ले सकते — और ठीक यही [eval हार्नेस](/the-eval-harness-i-use-to-ship-ai-agents/) आपको देता है। वही eval सेट दोनों मॉडलों पर चलाइए और एक ही पैमाने पर सफलता-दरें पढ़िए। ## जहाँ Haiku निर्णायक रूप से जीतता है Haiku तब सही चुनाव है जब टास्क **सीमित, संरचित और सत्यापन-योग्य** हो: - **वर्गीकरण और राउटिंग** — "क्या यह आने वाला संदेश बुकिंग है, शिकायत है, या स्पैम?" तीन ख़ाने, सत्यापन आसान, लगातार चलता है। दिन भर Haiku। - **स्कीमा के साथ निष्कर्षण** — किसी टेक्स्ट से एक तारीख़, एक नाम, एक राशि निकालना, Zod से सत्यापित। अगर आउटपुट पार्स हो जाता है, तो वह लगभग निश्चित रूप से सही है। - **छोटे री-राइट और फ़ॉर्मेटिंग** — लहजे में फेरबदल, ज्ञात-अच्छे इनपुट का सारांश, डेटा का सामान्यीकरण। - **पहली-छँटाई फ़िल्टरिंग** — Haiku ट्राइएज करता है, और केवल अस्पष्ट मामले ही Sonnet तक एस्केलेट होते हैं। यह सबसे ज़्यादा लीवरेज वाला पैटर्न है। साझा सूत्र: Haiku की ग़लती की लागत कम है और ग़लती पकड़ना सस्ता है। जब सत्यापन सस्ता हो और जोखिम कम हो, तो सस्ता मॉडल जीतता है। ## जहाँ Sonnet अपनी क़ीमत वसूल करता है Sonnet (और कभी-कभी Opus) तब सार्थक है जब टास्क **खुला, बहु-चरणीय, या ग़लत होने पर महँगा** हो: - **मल्टी-टूल एजेंट लूप** जहाँ एक ग़लत टूल कॉल झड़ी की तरह फैल जाती है। उच्च तर्क-विश्वसनीयता चरणों में जुड़ती जाती है — [मल्टी-एजेंट ऑर्केस्ट्रेशन](/multi-agent-orchestration-patterns-queues-state-handoffs/) में जिन ऑर्केस्ट्रेशन पैटर्न की मैं बात करता हूँ, वे इस पर टिके हैं कि मॉडल कहानी का सिरा न खोए। - **ग्राहक-सामना करने वाला जनरेशन** जहाँ ख़राब आउटपुट भरोसे की क़ीमत वसूलता है, सिर्फ़ एक रीट्राई की नहीं। - **हर वह चीज़ जहाँ सत्यापन ख़ुद ही कठिन हो।** अगर आप सस्ते में नहीं बता सकते कि आउटपुट सही है या नहीं, तो आप ऐसे मॉडल का जोखिम नहीं उठा सकते जो अक्सर ग़लत हो। यहाँ एक विफलता की क़ीमत एक रीट्राई नहीं है — इसकी क़ीमत है एक रिफ़ंड, एक छिटका हुआ ग्राहक, या मेरा समय। उसके सामने, प्रति-टोकन का अधिभार राउंडिंग की मामूली त्रुटि है। ## वह राउटिंग नियम जो मैं सचमुच लागू करता हूँ मैं हर एजेंट के लिए एक मॉडल नहीं चुनता। मैं एजेंट के भीतर हर **टास्क** के हिसाब से राउट करता हूँ, आम तौर पर एक सस्ता क्लासिफ़ायर तय करता है कि नीचे का कौन-सा मॉडल काम सँभालेगा: ```typescript function pickModel(task: Task): string { // सस्ता, सत्यापन-योग्य, उच्च-मात्रा → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // खुला या ग्राहक-सामना करने वाला → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // डिफ़ॉल्ट रूप से सुरक्षित विकल्प } ``` यहाँ दो सिद्धांत कूटबद्ध हैं। **डिफ़ॉल्ट सुरक्षित मॉडल रखें**, सस्ता नहीं — आप लागत को एक चलते-फिरते आधार से *नीचे* की ओर अनुकूलित करते हैं, कभी विश्वसनीयता को एक टूटे आधार से *ऊपर* की ओर नहीं। और **एस्केलेट करें, जुआ न खेलें**: आसान 80% Haiku को सँभालने दें और कठिन 20% Sonnet को सौंप दें। यह संकर तरीक़ा लगभग हमेशा हर चीज़ को किसी एक मॉडल पर अकेले चलाने को मात देता है। इसके ऊपर लगाने के लिए प्रॉम्प्ट कैशिंग भी है: अगर आपका सिस्टम प्रॉम्प्ट बड़ा है और दोबारा इस्तेमाल होता है, तो कैशिंग स्तर की परवाह किए बिना इनपुट लागत को काफ़ी घटा देती है, जो कभी-कभी Sonnet को इतना सस्ता बना देता है कि Haiku वाला सवाल ही बेमानी हो जाता है। ## मेरे अपने स्टैक से एक हल किया हुआ उदाहरण एक उच्च-मात्रा वाले इनबाउंड ट्राइएज चरण को लीजिए। यह हज़ारों बार चलता है, टास्क तीन-तरफ़ा वर्गीकरण है, और एक चूक का बस इतना मतलब है कि आइटम एक समीक्षा क़तार में जा गिरता है — पकड़ना सस्ता, जोखिम कम। यह पाठ्यपुस्तक जैसा Haiku टास्क है, और इसे Sonnet से हटाने पर उस चरण की लागत में उल्लेखनीय कटौती हुई, बिना उस परिणाम पर किसी मापे-जाने-योग्य असर के जो मायने रखता था। अब वह चरण लीजिए जो ग्राहक को असली जवाब का मसौदा तैयार करता है। कम मात्रा, खुला, और एक ख़राब मसौदा बाहर जाने पर भरोसे की क़ीमत वसूलता है। वह Sonnet पर ही रहता है। वही एजेंट, दो मॉडल, जोखिम के हिसाब से राउट किए गए। मैं दोनों के प्रति-रन लागत और सफलता मापदंडों पर नज़र रखता हूँ, जैसा मैं [मैं कैसे मापता हूँ कि कोई AI एजेंट सचमुच काम कर रहा है या नहीं](/how-i-measure-whether-an-ai-agent-is-actually-working/) में बताता हूँ — और मैं किसी चरण को एक स्तर नीचे तभी धकेलता हूँ जब eval कहे कि सस्ता मॉडल सफलता-दर बनाए रखता है। ## अक्सर पूछे जाने वाले सवाल ### क्या व्यवहार में Claude Haiku हमेशा Sonnet से सस्ता होता है? प्रति टोकन, हाँ — बड़े अंतर से। प्रति सफल-परिणाम, हमेशा नहीं। अगर Haiku की कम सफलता-दर रीट्राई और मानव सफ़ाई छेड़ती है, तो उन टास्क पर जहाँ ग़लतियाँ पकड़ना या ठीक करना महँगा हो, कुल लागत Sonnet से ज़्यादा हो सकती है। ### किसी दिए गए टास्क के लिए मैं Haiku और Sonnet के बीच कैसे तय करूँ? टास्क को दो धुरियों पर अंक दीजिए: आउटपुट कितना सत्यापन-योग्य है और एक ग़लती कितनी महँगी है। सत्यापन में सस्ता, कम-जोखिम, उच्च-मात्रा वाला काम Haiku को जाता है; खुला, ग्राहक-सामना करने वाला, या सत्यापन में कठिन काम Sonnet को जाता है। एजेंट के हिसाब से नहीं, टास्क के हिसाब से राउट कीजिए। ### वह एकमात्र लागत-मापदंड क्या है जिस पर मुझे नज़र रखनी चाहिए? प्रति-सफल-परिणाम लागत — कॉल लागत गुणा प्रयास जोड़ अपेक्षित सफ़ाई लागत, भाग सफलता-दर। अकेले प्रति-कॉल दाम रीट्राई और मानव समय को छिपा देता है, और वहीं सस्ते मॉडल चुपके से महँगे पड़ने लगते हैं। ### क्या मैं एक ही एजेंट में दोनों मॉडल इस्तेमाल कर सकता हूँ? हाँ, और आम तौर पर आपको करना चाहिए। सबसे मज़बूत पैटर्न एक सस्ता पहला दौर है (Haiku वर्गीकृत करता है या फ़िल्टर करता है) जो केवल अस्पष्ट मामलों को Sonnet तक एस्केलेट करता है। यह संकर तरीक़ा आम तौर पर हर चीज़ को एक ही स्तर पर चलाने को मात देता है। --- ## प्रोडक्शन में AI एजेंट को डीबग कैसे करें (एक फील्ड गाइड) Source: https://alejandrorioja.com/hi/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: प्रोडक्शन AI एजेंट को डीबग करना ज़्यादातर यह पहचानने के बारे में है कि कौन-सी लेयर फेल हुई — प्रॉम्प्ट, टूल, मॉडल, या ऑर्केस्ट्रेशन। मैं हर स्टेप को एक ट्रेस ID के साथ लॉग करता हूँ, बिल्कुल वही इनपुट रिप्ले करता हूँ, और बाइसेक्ट करता हूँ। मेरे एजेंट्स में, ~70% 'AI बग' दरअसल प्लंबिंग के बग निकलते हैं, मॉडल के नहीं। ## विषय-सूची _जून 2026 में अपडेटेड।_ **TL;DR:** प्रोडक्शन AI एजेंट को डीबग करना ज़्यादातर यह पहचानने के बारे में है कि कौन-सी लेयर फेल हुई — प्रॉम्प्ट, टूल कॉल, मॉडल आउटपुट, या ऑर्केस्ट्रेशन। मैं हर स्टेप को एक ट्रेस ID के साथ लॉग करता हूँ, बिल्कुल वही इनपुट रिप्ले करता हूँ, और वहीं से बाइसेक्ट करता हूँ। मेरे एजेंट्स में, जो "AI बग" जैसा दिखता है उसका करीब 70% प्लंबिंग निकलता है: एक खराब फ़ॉर्मेट वाला टूल रिज़ल्ट, एक कटा हुआ इनपुट, एक चुपचाप निगल लिया गया एक्सेप्शन। **ऑपरेटर की नज़र:** मैं 100 से ज़्यादा प्रोडक्शन एजेंट चलाता हूँ — Pickleland के लिए बुकिंग फ्लो, कंटेंट पाइपलाइन, इनबॉक्स ट्रायाजर। वे वैसे ही टूटते हैं जैसे हर सॉफ़्टवेयर टूटता है, साथ में कुछ नए तरीकों से भी। यह वही फील्ड गाइड है जो काश मेरे पास होती: टोकन की दीवार को घूरे बिना गड़बड़ करने वाली लेयर को कैसे ढूँढें। जब कोई एजेंट प्रोडक्शन में गलत व्यवहार करता है, तो प्रवृत्ति होती है मॉडल को दोष देने की। "Claude ने हैल्युसिनेट किया।" कभी-कभी सच। आमतौर पर नहीं। मॉडल पाँच या छह की स्टैक में एक लेयर है, और बग कहीं ज़्यादा बार उस लेयर में होता है जो आपने लिखी, बजाय उसके जो Anthropic ने भेजी। यह पोस्ट वह व्यवस्थित तरीका है जिससे मैं इसे ढूँढता हूँ। ## कुछ भी डीबग करने से पहले हर रन को ट्रेस करने योग्य बनाएँ जो आप देख नहीं सकते, उसे आप डीबग नहीं कर सकते। सबसे ज़्यादा लाभ देने वाली चीज़ जो आप कर सकते हैं — किसी भी खास बग के सामने आने से पहले — वह है हर एजेंट रन में एक ट्रेस ID जोड़ना और उसके उठाए गए हर स्टेप को लॉग करना। एक "स्टेप" वह सब कुछ है जो किसी सीमा को पार करता है: आने वाला ट्रिगर, हर मॉडल कॉल (पूरे मैसेज ऐरे के साथ), हर टूल कॉल (आर्गुमेंट्स के साथ), हर टूल रिज़ल्ट, और अंतिम आउटपुट। इन्हें ट्रेस ID से कीड स्ट्रक्चर्ड JSON के रूप में लॉग करें। ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` Cloudflare Workers पर मैं इन्हें एक क्यू में और एक टेबल में भेजता हूँ; लोकल में ये stdout पर जाते हैं। नियम अटल है: अगर कोई स्टेप लॉग नहीं हुआ, तो डीबगिंग की दृष्टि से वह हुआ ही नहीं। यह उस इंस्ट्रुमेंटेशन को दर्शाता है जिसका वर्णन मैं [जिस एजेंट स्टैक का मैं इस्तेमाल करता हूँ](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) में करता हूँ — ट्रेस ID वह रीढ़ है जिस पर बाकी सब कुछ टँगा होता है। ## लेयर को अलग करें: प्रॉम्प्ट, टूल, मॉडल, या ऑर्केस्ट्रेशन एक बार आपके पास ट्रेस हो, तो डीबगिंग एक बाइसेक्शन बन जाती है। चार लेयर हैं और बग ज़्यादातर समय उनमें से ठीक एक में रहता है। ### 1. इनपुट लेयर (सबसे आम दोषी) फेल हुई मॉडल कॉल में गया हुआ बिल्कुल वही `messages` ऐरे निकालें। पुनर्निर्माण नहीं — लॉग से अक्षरशः पेलोड। फिर इसे ऐसे पढ़ें जैसे कोई अजनबी पढ़ता। मेरे "मॉडल ने निर्देश नज़रअंदाज़ किए" वाले आधे बग दरअसल ये होते हैं: - एक टूल रिज़ल्ट जो `"[object Object]"` के रूप में वापस आया क्योंकि कुछ गलत तरीके से स्ट्रिंगिफ़ाई हो गया। - एक इनपुट जो वाक्य के बीच में कट गया क्योंकि उसने कॉन्टेक्स्ट विंडो को फोड़ दिया और एक भोली स्लाइस ने उसे काट दिया। - एक वैरिएबल जो `undefined` के रूप में इंटरपोलेट हुआ और चुपचाप प्रॉम्प्ट को ज़हरीला कर गया। अगर इनपुट गलत है, तो मॉडल ने कचरे पर अपना काम बखूबी किया। प्लंबिंग ठीक करें। ### 2. टूल लेयर अगर इनपुट साफ़ दिखता है, तो जाँचें कि कहीं किसी टूल ने ऐसी कोई एरर तो नहीं लौटाई जिसे एजेंट ने सफलता मान लिया। एक क्लासिक: एक API `{ "error": "rate limited" }` बॉडी के साथ `200` लौटाती है, आपका टूल रैपर बॉडी की जाँच नहीं करता, और एजेंट आत्मविश्वास से एक एरर मैसेज पर कार्रवाई कर देता है। टूल रिज़ल्ट को कच्चा लॉग करें और उनके आकार को असर्ट करें। ### 3. मॉडल लेयर 1 और 2 को खारिज करने के बाद ही मैं मॉडल पर शक करता हूँ। तब भी, "मॉडल बग" का आमतौर पर मतलब होता है "मेरा प्रॉम्प्ट अस्पष्ट है।" बिल्कुल वही फेल हुआ इनपुट लें, उसे उसी मॉडल और टेम्परेचर के विरुद्ध एक बार-इस्तेमाल स्क्रिप्ट में डालें, और देखें कि क्या यह दोहराता है। अगर दोहराता है, तो समाधान प्रॉम्प्ट का काम है या एक [कसी हुई eval](/the-eval-harness-i-use-to-ship-ai-agents/), न कि घबराहट में मॉडल बदलना। ### 4. ऑर्केस्ट्रेशन लेयर अगर कोई एकल स्टेप अकेले में ठीक है पर मल्टी-स्टेप रन फेल हो जाता है, तो बग हैंडऑफ़ में है — स्टेप्स के बीच खोई हुई स्टेट, एक रेस कंडीशन, एक रीट्राई जिसने किसी नॉन-आइडेम्पोटेंट एक्शन को दोबारा चला दिया। ये सबसे घातक होते हैं और मैं इनके पैटर्न [मल्टी-एजेंट ऑर्केस्ट्रेशन पैटर्न](/multi-agent-orchestration-patterns-queues-state-handoffs/) में कवर करता हूँ। ## नॉन-डिटर्मिनिज़्म से लड़ने के बजाय उसे दोहराएँ जो चीज़ एजेंट्स को अनडीबगेबल महसूस कराती है वह है नॉन-डिटर्मिनिज़्म: एक ही इनपुट अलग-अलग रन में अलग आउटपुट देता है। आप इसे काबू कर सकते हैं। पहला, **जो फिक्स कर सकते हैं, करें।** डीबग करते समय `temperature: 0` सेट करें। यह Claude को पूरी तरह डिटर्मिनिस्टिक नहीं बनाएगा, पर वैरिएंस को इतना तेज़ी से संकरा कर देता है कि आप असली बग को सैंपलिंग नॉइज़ से अलग बता सकें। दूसरा, **इसे N बार चलाएँ।** अगर कोई फ़ेल्योर हर 20 रन में 1 बार दोहराता है, तो बिल्कुल वही इनपुट 50 बार लूप करें और हर आउटपुट कैप्चर करें। अब आपके पास एक सैंपल है, एक किस्सा नहीं। एक बग जो 5% बार चलता है, वह असली बग है — आपको उसे देखने के लिए बस वॉल्यूम चाहिए। ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # फिर फ़ेल्योर गिनें grep -c '"status":"fail"' runs.jsonl ``` तीसरा, **पास और फेल हुए रन का डिफ़ करें।** टेम्परेचर फिक्स और इनपुट समान होने पर, आउटपुट में अंतर का मतलब है इनपुट में कोई अंतर जिसे आपने अभी तक नहीं पकड़ा — प्रॉम्प्ट में कोई टाइमस्टैम्प, कोई टूल रिज़ल्ट जो बदलता है, कोई रिट्रीव किया गया डॉक्यूमेंट जो बदल गया। ## एक रिप्ले हार्नेस बनाएँ ताकि आप प्रोडक्शन में डीबग करना बंद कर दें लाइव एजेंट को फिर से ट्रिगर करके डीबग करना धीमा और जोखिम भरा है — यह असली ईमेल भेजता है, असली कोर्ट बुक करता है। इसके बजाय, ट्रेस कैप्चर करें और उसे ऑफ़लाइन रिप्ले करें। रिप्ले हार्नेस एक लॉग किया हुआ ट्रेस लोड करता है, किसी भी स्टेप के लिए बिल्कुल वही इनपुट दोबारा बनाता है, और सिर्फ़ उसी स्टेप को मॉडल के विरुद्ध फिर से चलाता है। चूँकि आपने पूरा `messages` ऐरे लॉग किया, इसलिए आपको अपस्ट्रीम सिस्टम की बिल्कुल ज़रूरत नहीं। यह प्रोडक्शन के 10 मिनट के राउंड-ट्रिप को 2 सेकंड के लोकल लूप में बदल देता है, और यह मेरे डीबगिंग वर्कफ़्लो में सबसे बड़ी तेज़ी है। एक अच्छा रिप्ले हार्नेस आपको **म्यूटेट और री-रन** करने भी देता है: सिस्टम प्रॉम्प्ट की एक लाइन बदलें, वही 50 फेल हुए ट्रेस रिप्ले करें, और देखें कि अब कितने पास होते हैं। यही डीबगिंग से eval तक का पुल है — एक बार आपके पास फेल हुए ट्रेस का एक कॉर्पस हो, तो आपके पास एक रिग्रेशन सूट की शुरुआत है। ## उन मेट्रिक्स पर नज़र रखें जो वाकई टूटने की भविष्यवाणी करते हैं कुछ फ़ेल्योर कभी एक्सेप्शन नहीं फेंकते। एजेंट चलता है, कुछ विश्वसनीय लौटाता है, और चुपचाप गलत काम कर जाता है। उन्हें पकड़ने के लिए आप सिर्फ़ एरर रेट नहीं, बल्कि व्यवहारगत मेट्रिक्स पर नज़र रखते हैं: - **टूल-कॉल सक्सेस रेट** प्रति टूल। यहाँ गिरावट अक्सर एक दिखाई देने वाली फ़ेल्योर से पहले आती है। - **आउटपुट स्कीमा वैलिडिटी** — कितने % आउटपुट अपेक्षित स्ट्रक्चर के विरुद्ध पार्स होते हैं। मैं हर आउटपुट को Zod से वैलिडेट करता हूँ और जब वैलिडिटी गिरती है तो अलर्ट देता हूँ। - **लूप लंबाई** — प्रति रन स्टेप्स की औसत संख्या। अचानक स्पाइक आमतौर पर मतलब होता है कि एजेंट रीट्राई में फँस गया है। - **प्रति रन लागत** — एक बेकाबू लूप शिकायत के रूप में दिखने से पहले लागत स्पाइक के रूप में दिखता है। (जब लागत मायने रखती है, तो [Haiku बनाम Sonnet का गणित](/ai-agent-cost-math-when-haiku-beats-sonnet) जानने लायक है।) मैं इन्हें वैसे ही ट्रैक करता हूँ जैसे बाकी सब कुछ — देखें [मैं कैसे मापता हूँ कि कोई AI एजेंट वाकई काम कर रहा है या नहीं](/how-i-measure-whether-an-ai-agent-is-actually-working/)। एक मूक फ़ेल्योर को पकड़ने वाला मेट्रिक, शोरगुल वाली फ़ेल्योर पकड़ने वाले दस मेट्रिक्स के बराबर है। ## 5-मिनट का ट्राएज चेकलिस्ट जब कोई एजेंट टूटता है और मैं समय की दौड़ में होता हूँ, तो मैं यह क्रम में चलाता हूँ: 1. फेल हुए रन का **ट्रेस ID हासिल करें।** 2. फेल हुए स्टेप का **बिल्कुल वही इनपुट पढ़ें।** क्या यह सुगठित है? (यहाँ ~50% मामले हल हो जाते हैं।) 3. उस ट्रेस में **टूल रिज़ल्ट्स की जाँच करें** कि कहीं सफलता के भेस में कोई एरर तो नहीं। 4. `temperature: 0` पर **स्टेप को ऑफ़लाइन रिप्ले करें।** क्या यह दोहराता है? 5. **अगर दोहराता है,** तो यह प्रॉम्प्ट/मॉडल का मसला है — ठीक करें और ट्रेस कॉर्पस फिर से चलाएँ। **अगर नहीं,** तो यह नॉन-डिटर्मिनिज़्म या कोई स्टेट/ऑर्केस्ट्रेशन बग है — इसे 50× लूप करके इसकी विशेषता पहचानें। अनुशासित आइसोलेशन हर बार चतुर प्रॉम्प्टिंग को हरा देता है। मॉडल शायद ही कभी समस्या होता है; उसके इर्द-गिर्द का सिस्टम आमतौर पर होता है। ## अक्सर पूछे जाने वाले प्रश्न ### मैं ऐसे AI एजेंट को कैसे डीबग करूँ जो सिर्फ़ कभी-कभी फेल होता है? एक लॉग किए हुए ट्रेस से बिल्कुल वही इनपुट कैप्चर करें और उसे टेम्परेचर 0 पर 50+ बार रिप्ले करें। रुक-रुक कर होने वाले फ़ेल्योर कम फायरिंग-रेट वाले असली बग हैं — वॉल्यूम किस्से को एक पुनरुत्पाद्य सैंपल में बदल देता है जिसे आप डिफ़ करके ठीक कर सकते हैं। ### बग आमतौर पर मॉडल में होता है या मेरे कोड में? मेरे प्रोडक्शन एजेंट्स में, दिखने वाले "AI बग" का करीब 70% प्लंबिंग होता है: खराब फ़ॉर्मेट वाले टूल रिज़ल्ट, कटे हुए इनपुट, निगले गए एक्सेप्शन, या स्टेप्स के बीच खोई हुई स्टेट। मॉडल पर शक करने से पहले इनपुट और टूल लेयर को खारिज करें। ### एजेंट्स डीबग करने के लिए मुझे न्यूनतम कितनी लॉगिंग चाहिए? हर रन पर एक ट्रेस ID, साथ ही ट्रिगर, हर मॉडल कॉल (पूरा मैसेज ऐरे), हर टूल कॉल और उसका कच्चा रिज़ल्ट, और अंतिम आउटपुट के स्ट्रक्चर्ड लॉग। अगर कोई स्टेप लॉग नहीं है, तो आप उसे डीबग नहीं कर सकते। ### मैं लाइव प्रोडक्शन के विरुद्ध डीबग करना कैसे बंद करूँ? एक रिप्ले हार्नेस बनाएँ जो एक लॉग किया हुआ ट्रेस लोड करे और कैप्चर किए गए इनपुट का इस्तेमाल करके किसी भी एकल स्टेप को ऑफ़लाइन फिर से चलाए। यह एक धीमे, जोखिम भरे प्रोडक्शन राउंड-ट्रिप को एक तेज़ लोकल लूप में बदल देता है और आपके रिग्रेशन सूट का बीज बन जाता है। --- ## कैसे मापें कि AI सर्च सचमुच आपको ट्रैफ़िक भेज रहा है या नहीं Source: https://alejandrorioja.com/hi/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: अधिकांश AI-सर्च ट्रैफ़िक chatgpt.com, perplexity.ai और claude.ai से रेफ़रल की एक पतली धारा के रूप में दिखता है — लेकिन बड़ा असर डार्क है: लोग AI का जवाब पढ़ते हैं और कभी क्लिक नहीं करते। मैं दोनों मापता हूँ, क्लिक के लिए रेफ़रर और प्रभाव के लिए ब्रांड-सर्च में उछाल का उपयोग करते हुए। ## विषय-सूची _जून 2026 में अपडेटेड।_ **TL;DR:** अधिकांश AI-सर्च ट्रैफ़िक `chatgpt.com`, `perplexity.ai` और `claude.ai` से रेफ़रल की एक पतली धारा के रूप में आता है — जब आप जान लें कि कहाँ देखना है तो गिनना आसान है। लेकिन बड़ा असर **डार्क** है: लोग AI का जवाब पढ़ते हैं, आपके ब्रांड को आत्मसात करते हैं, और कभी क्लिक नहीं करते। मैं क्लिक को रेफ़रर सेगमेंट से और प्रभाव को ब्रांड-सर्च उछाल, डायरेक्ट-ट्रैफ़िक बदलाव और साइटेशन निगरानी से ट्रैक करता हूँ। केवल क्लिक गिनना AI सर्च को बुरी तरह कम आँकता है। **ऑपरेटर का नज़रिया:** मैं एक कंटेंट इंजन चलाता हूँ और रोज़ इसके एनालिटिक्स पर नज़र रखता हूँ। "क्या AI सर्च ट्रैफ़िक भेज रहा है?" इस सवाल का एक निराशाजनक जवाब है: हाँ, लेकिन अधिकांश मूल्य आपकी सेशन रिपोर्ट में नहीं दिखता। यहाँ मैं बताता हूँ कि जो हिस्सा दिखता है उसे कैसे मापें और जो नहीं दिखता उसका अनुमान कैसे लगाएँ। हर कोई एक नंबर चाहता है — "ChatGPT मुझे कितना ट्रैफ़िक भेज रहा है?"। ईमानदार जवाब यह है कि AI सर्च दो बहुत अलग प्रभाव पैदा करता है, और आपको दो अलग मापों की ज़रूरत है। इन्हें गड्डमड्ड कर दें तो या तो आप घबरा जाएँगे (क्लिक बहुत छोटे दिखते हैं) या खुद को धोखा देंगे (आप असली असर चूक जाएँगे)। ## प्रभाव 1: सीधे रेफ़रल — गिनने योग्य, और जितना आप उम्मीद करते हैं उससे छोटे जब कोई ChatGPT, Perplexity, या Claude के जवाब के भीतर किसी साइटेशन पर क्लिक करता है, तो आपका एनालिटिक्स एक रेफ़रर दर्ज करता है। ये असली, श्रेय-योग्य सेशन हैं। GA4 या किसी भी एनालिटिक्स टूल में, एक सेगमेंट बनाएँ जो AI इंजनों को पकड़ ले: ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` इसे "AI सर्च" चैनल के रूप में सहेजें और समय के साथ देखें। कुछ चेतावनियाँ जो लोगों को मात देती हैं: - **रेफ़रर रिसते हैं।** कुछ AI सतहें रेफ़रर को हटा देती हैं या बिगाड़ देती हैं, इसलिए असली AI क्लिकों का एक हिस्सा इसके बजाय "डायरेक्ट" में आ गिरता है। आपकी रेफ़रल गिनती एक न्यूनतम सीमा है, सच्चाई नहीं। - **जवाब के इंप्रेशन के मुकाबले वॉल्यूम कम है।** AI इंजन सवाल का जवाब पेज पर ही दे देते हैं; केवल जिज्ञासु अल्पसंख्यक ही क्लिक करके आता है। रोज़ के मुट्ठी भर रेफ़रल उन कहीं ज़्यादा लोगों के अनुरूप हो सकते हैं जिन्होंने आपको साइट किया हुआ देखा। तो रेफ़रल सेगमेंट ज़रूरी है पर पर्याप्त नहीं। यह आपको बताता है कि AI सर्च *कुछ* ट्रैफ़िक भेज रहा है। यह प्रभाव को बुरी तरह कम गिनता है। ## प्रभाव 2: डार्क प्रभाव — बड़ा, और देखने में मुश्किल आधा हिस्सा असली कार्रवाई ज़ीरो-क्लिक है। कोई ChatGPT से एक सवाल पूछता है, आपका ब्रांड जवाब में एक अनुशंसित स्रोत के रूप में आता है, और वह कभी क्लिक नहीं करता — वह बस आपको याद रखता है। यह बाद में एक **ब्रांडेड सर्च** या एक **डायरेक्ट विज़िट** के रूप में दिखता है, जिसका श्रेय किसी को नहीं मिलता। यह वही गतिशीलता है जिसने फ़ीचर्ड स्निपेट्स को मापना निराशाजनक बना दिया था, बस बढ़ी हुई। आप डार्क प्रभाव को सीधे नहीं माप सकते, पर आप इसका त्रिकोणीयन कर सकते हैं: 1. **ब्रांडेड सर्च वॉल्यूम।** Google Search Console में अपने नाम/ब्रांड की खोजों को समय के साथ ट्रैक करें। यदि आप AI इंजनों द्वारा साइट किए जाने लगते हैं और बिना किसी मेल खाते अभियान के आपके ब्रांडेड इंप्रेशन बढ़ते हैं, तो वह उछाल AI प्रभाव की उँगलियों की छाप है। 2. **डायरेक्ट-ट्रैफ़िक प्रवृत्ति।** "डायरेक्ट" सेशनों में लगातार उछाल जो किसी अभियान का अनुसरण नहीं करता, अक्सर अपने रेफ़रर से वंचित AI रेफ़रल को, साथ ही AI उल्लेख के बाद आपको सीधे टाइप करने वाले लोगों को दर्शाता है। 3. **सहायक रूपांतरण।** देखें कि क्या AI-सर्च सेशन, भले ही दुर्लभ हों, रूपांतरण यात्राओं में *पहले* स्पर्श के रूप में दिखते हैं। एक चैनल जो लास्ट-क्लिक से छोटा है, फ़र्स्ट-टच से सार्थक हो सकता है। इनमें से कोई भी साफ़ नंबर नहीं है। मिलकर वे आपको बताते हैं कि डार्क आधा हिस्सा हिल रहा है या नहीं। ## क्लिक ही नहीं, साइटेशन ट्रैक करें यहाँ वह मीट्रिक है जिसकी मुझे AI सर्च के लिए सबसे ज़्यादा परवाह है, और यह आपके एनालिटिक्स में बिल्कुल नहीं है: **क्या मुझे साइट किया जा रहा है, और किन क्वेरीज़ के लिए?** अपने व्यवसाय के लिए मायने रखने वाली 20-40 क्वेरीज़ की एक सूची बनाए रखें और उन्हें एक शेड्यूल पर ChatGPT, Perplexity और Claude के माध्यम से चलाएँ — साप्ताहिक पर्याप्त से अधिक है। हर क्वेरी और इंजन के लिए दर्ज करें: क्या आप साइट किए गए हैं, और किस स्थान पर? यह रैंक ट्रैकिंग का GEO समकक्ष है, और यह अग्रणी संकेतक है। साइटेशन डाउनस्ट्रीम ट्रैफ़िक और ब्रांड उछाल से *पहले* हिलते हैं, इसलिए यहीं आप देखते हैं कि आपका [स्थानीय व्यवसाय के लिए GEO कार्य](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/) असर कर रहा है या नहीं। मैंने एक छोटा एजेंट बनाया जो ये जाँचें चलाता है और परिणाम दर्ज करता है — एक बार जब आपके पास एजेंट स्टैक हो तो यह मामूली काम है। यदि आप हाथ से करना पसंद करें, तो एक स्प्रेडशीट और साप्ताहिक 30-मिनट का दौर शुरुआत के लिए ठीक काम करता है, या यदि आप खुद एजेंट बनाना नहीं चाहते तो [mentioned.at](https://mentioned.at) जैसे किसी विशेष चेकर का उपयोग करें। यह कार्यप्रणाली मेरे [ChatGPT बनाम Google साइटेशन टेस्ट](/chatgpt-search-vs-google-50-term-test/) को प्रतिबिंबित करती है, बस एक बार के बजाय लगातार चलाई जाती है। ## डैशबोर्ड बनाएँ: चार नंबर, साप्ताहिक मैं मीट्रिक्स में नहीं डूबता। AI सर्च के लिए मैं चार चीज़ें देखता हूँ और उन्हें साप्ताहिक रूप से समीक्षा करता हूँ: 1. **AI रेफ़रल सेशन** — रेफ़रर सेगमेंट से गिनने योग्य क्लिक। प्रवृत्ति, निरपेक्ष मान नहीं। 2. **साइटेशन कवरेज** — मेरी ट्रैक की गई क्वेरीज़ का % जहाँ मैं तीनों इंजनों में साइट किया जाता हूँ। अग्रणी संकेतक। 3. **ब्रांडेड सर्च इंप्रेशन** — Search Console से, डार्क-प्रभाव प्रॉक्सी के रूप में। 4. **AI-स्रोत रूपांतरण** — भले छोटे हों, क्या AI सेशन कभी कोई रूपांतरण यात्रा शुरू करते हैं। यदि साइटेशन कवरेज बढ़ रहा है जबकि रेफ़रल सेशन सपाट रहते हैं, तो यह *असफलता नहीं* है — आमतौर पर इसका मतलब है कि डार्क आधा हिस्सा बढ़ रहा है और ब्रांडेड-सर्च नंबर को इसके पीछे आना चाहिए। यदि साइटेशन कवरेज गिर रहा है, तो यह एक शुरुआती चेतावनी है जिस पर किसी भी ट्रैफ़िक नंबर के हिलने से पहले कार्रवाई करनी चाहिए। यह वही "अग्रणी संकेतक मापें" अनुशासन है जो मैं एजेंटों पर लागू करता हूँ [मैं कैसे मापता हूँ कि एक AI एजेंट सचमुच काम कर रहा है](/how-i-measure-whether-an-ai-agent-is-actually-working/) में। ## नंबरों का क्या करें मापन तभी उपयोगी है जब वह बदले कि आप क्या करते हैं। प्लेबुक: - **किसी क्वेरी के लिए साइटेशन कवरेज कम है जिसकी आपको परवाह है?** यह एक कंटेंट + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/) समस्या है। पेज या तो मौजूद ही नहीं है, या निष्कर्षण के लिए संरचित नहीं है, या जवाब में खींचे जाने लायक पर्याप्त आधिकारिक नहीं है। - **साइट किए गए पर कोई रेफ़रल ट्रैफ़िक नहीं?** अपेक्षित और ठीक है — AI सर्च ब्रांड का काम कर रहा है, क्लिक का नहीं। क्लिक के पीछे भागकर इसे "ठीक" न करें; साइट किया गया स्रोत बनने पर दाँव लगाएँ। - **एक इंजन से रेफ़रल पर दूसरों से नहीं?** इंजन स्रोतों पर ज़ोरदार ढंग से भिन्न होते हैं (मैंने ChatGPT और Google के बीच ~40% ओवरलैप मापा)। एक द्वारा साइट किया जाना आपको दूसरे नहीं दिलाता — हर इंजन की कवरेज पर अलग से काम करें। ## श्रेय की ईमानदारी पर एक नोट जो परिशुद्धता आपके पास नहीं है उसका दावा करने के आग्रह का विरोध करें। 2026 में AI-सर्च मापन त्रिकोणीयन है, श्रेय नहीं। जो भी आपको "ChatGPT ने आपको X डॉलर भेजे" जैसा एक साफ़ नंबर बेच रहा है, वह जो जाना जा सकता है उसे बढ़ा-चढ़ाकर बता रहा है, क्योंकि रेफ़रर रिसते हैं और सबसे बड़ा असर डिज़ाइन से ही ज़ीरो-क्लिक है। सही रुख: जो गिन सकते हैं गिनें, जो नहीं गिन सकते उसके लिए प्रॉक्सी देखें, और प्रवृत्ति पर निर्णय लें। प्रवृत्ति भरोसेमंद है, तब भी जब निरपेक्ष नंबर नहीं। ## अक्सर पूछे जाने वाले प्रश्न ### मैं GA4 में ChatGPT या Perplexity से ट्रैफ़िक कैसे देखूँ? एक चैनल/सेगमेंट बनाएँ जो AI इंजन डोमेन — chatgpt.com, chat.openai.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com — को सेशन स्रोत के रूप में मिलाए। यह क्लिक-थ्रू रेफ़रल पकड़ता है, हालाँकि कुछ "डायरेक्ट" में हट जाते हैं, इसलिए गिनती को एक न्यूनतम सीमा मानें। ### मेरा AI-सर्च रेफ़रल ट्रैफ़िक इतना कम क्यों है? क्योंकि AI सर्च ज़्यादातर ज़ीरो-क्लिक है — इंजन पेज पर ही जवाब दे देता है और केवल अल्पसंख्यक क्लिक करता है। कम रेफ़रल गिनतियाँ अक्सर कहीं बड़े साइटेशन इंप्रेशन के साथ मेल खाती हैं। उस हिस्से को देखने के लिए जो रेफ़रल चूकते हैं, साइटेशन और ब्रांडेड-सर्च उछाल मापें। ### AI सर्च के लिए सबसे अच्छा अग्रणी संकेतक क्या है? साइटेशन कवरेज: आपकी ट्रैक की गई व्यवसाय-महत्वपूर्ण क्वेरीज़ का प्रतिशत जहाँ आप ChatGPT, Perplexity और Claude में साइट किए जाते हैं। यह ट्रैफ़िक और ब्रांड उछाल से पहले हिलता है, इसलिए यह आपको जल्दी बता देता है कि आपका GEO कार्य असर कर रहा है या नहीं। ### क्या मैं AI सर्च से सटीक राजस्व श्रेय पा सकता हूँ? नहीं, 2026 में भरोसेमंद ढंग से नहीं। रेफ़रर डायरेक्ट में रिस जाते हैं और अधिकांश असर डिज़ाइन से ज़ीरो-क्लिक है। AI-सर्च मापन को त्रिकोणीयन मानें — क्लिक गिनें, ब्रांडेड-सर्च और डायरेक्ट-ट्रैफ़िक प्रॉक्सी देखें, और एक झूठी-सटीक डॉलर राशि के बजाय प्रवृत्ति पर निर्णय लें। --- ## मल्टी-एजेंट ऑर्केस्ट्रेशन पैटर्न: क्यू, स्टेट और हैंडऑफ़ Source: https://alejandrorioja.com/hi/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: भरोसेमंद मल्टी-एजेंट सिस्टम चतुर प्रॉम्प्ट से नहीं बनते — वे डिस्ट्रिब्यूटेड सिस्टम के उबाऊ अनुशासन से बनते हैं: एजेंटों के बीच टिकाऊ क्यू, मॉडल के बाहर रखा गया स्टेट, और ऐसे आइडम्पोटेंट हैंडऑफ़ जो रीट्राई झेल जाते हैं। मॉडल वर्कर है; क्यू रीढ़ की हड्डी है। ## विषय-सूची _जून 2026 में अपडेट किया गया।_ **संक्षेप में:** भरोसेमंद मल्टी-एजेंट सिस्टम चतुर प्रॉम्प्ट से नहीं जीते जाते — वे डिस्ट्रिब्यूटेड सिस्टम के उबाऊ अनुशासन से जीते जाते हैं। एजेंटों के बीच एक टिकाऊ **क्यू** रखें, **स्टेट को मॉडल के बाहर** रखें, और हर **हैंडऑफ़ को आइडम्पोटेंट** बनाएँ ताकि कोई रीट्राई दोबारा कार्रवाई न कर सके। मॉडल वर्कर है; क्यू रीढ़ की हड्डी है। इन तीनों को सही कर लें और ऑर्केस्ट्रेशन डरावना नहीं रह जाता। **ऑपरेटर का नज़रिया:** मेरे 100 से ज़्यादा एजेंटों में अधिकतर सिंगल-स्टेप हैं। जो नहीं हैं — वे पाइपलाइन जो पहले क्लासिफ़ाई करती हैं, फिर एनरिच करती हैं, फिर कार्रवाई करती हैं — वे तभी भरोसेमंद बनीं जब मैंने "प्रॉम्प्ट चेन" सोचना बंद किया और "LLM वर्कर वाली जॉब क्यू" सोचना शुरू किया। यह आर्किटेक्चर है, प्रॉम्प्ट इंजीनियरिंग नहीं। "मल्टी-एजेंट" सुनने में ऐसा लगता है जैसे एजेंट आपस में बात करते हों। व्यवहार में, भरोसेमंद संस्करण इसका उलटा है: एजेंट सीधे संवाद करते ही नहीं। वे एक क्यू पर संदेश छोड़ते हैं और एक क्यू से काम उठाते हैं, और ऑर्केस्ट्रेशन उनके बीच की पाइपलाइन (प्लंबिंग) में बसता है। ये वे पैटर्न हैं जो प्रोडक्शन में टिके रहते हैं। ## पैटर्न 1: हर एजेंट के बीच एक टिकाऊ क्यू रखें पहली प्रवृत्ति होती है एजेंट A के भीतर से सीधे एजेंट B को कॉल करना। ऐसा न करें। सीधी कॉल दोनों को जोड़ देती हैं: अगर B धीमा है, A रुक जाता है; अगर B विफल होता है, A का काम खो जाता है; अगर आपको B को स्केल करना है, तो A को छुए बिना नहीं कर सकते। इसके बजाय, A अपना काम पूरा करता है और B के लिए एक **संदेश क्यू में डालता है**। B एक अलग वर्कर है जो क्यू को अपनी गति से खाली करता है। ```typescript // एजेंट A समाप्त करता है और क्यू के ज़रिए हैंडऑफ़ करता है — B को कोई सीधी कॉल नहीं await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // A का काम पूरा हुआ। B इसे स्वतंत्र रूप से उठाएगा। ``` Cloudflare पर मैं ठीक इसी के लिए Workers Queues इस्तेमाल करता हूँ — वही प्रिमिटिव जो [जिस एजेंट स्टैक का मैं इस्तेमाल करता हूँ](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) के पीछे हैं। क्यू आपको मुफ़्त में चार चीज़ें देती है: **बफ़रिंग** (B बंद हो सकता है फिर भी काम नहीं खोता), **रीट्राई** (विफल संदेश दोबारा भेजे जाते हैं), **बैकप्रेशर** (बढ़ोतरी क्रैश की बजाय क्यू में जमा होती है), और **डिकपलिंग** (A को छुए बिना B को स्केल या रीडिप्लॉय करें)। इनमें से हर एक वह चीज़ है जिसे वरना आपको हाथ से बनाना पड़ता और गलती करनी पड़ती। ## पैटर्न 2: स्टेट को हमेशा मॉडल के बाहर रखें सबसे आम मल्टी-एजेंट बग यह मान लेना है कि मॉडल को चरणों के बीच कुछ याद रहता है। नहीं रहता। हर मॉडल कॉल स्टेटलेस है; एकमात्र स्मृति वही है जो आप प्रॉम्प्ट में डालते हैं। इसलिए "यह जॉब पाइपलाइन में कहाँ है" के लिए सत्य का स्रोत एक डेटाबेस में बसना चाहिए, बातचीत में नहीं। मैं एक ही जॉब रिकॉर्ड रखता हूँ जिसे हर एजेंट पढ़ता और अपडेट करता है: ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` हर एजेंट वही लूप चलाता है: जॉब स्टेट **पढ़ो**, अपना काम करो, नया स्टेट **लिखो**, अगला चरण क्यू में डालो। मॉडल कभी स्टेट नहीं रखता — वह संबंधित हिस्सा इनपुट के रूप में पाता है और एक परिणाम लौटाता है। यही सिस्टम को रीस्टार्ट-योग्य बनाता है: अगर कोई वर्कर जॉब के बीच मर जाए, तो स्टेट रिकॉर्ड अब भी ठीक-ठीक बताता है कि चीज़ें कहाँ थीं, और दोबारा भेजा गया क्यू संदेश वहीं से आगे बढ़ाता है। यह डिबगिंग को भी संभालने लायक बनाता है, क्योंकि स्टेट टेबल हर जॉब की यात्रा का एक क्वेरी-योग्य रिकॉर्ड है — वही इंस्ट्रूमेंटेशन मानसिकता जो [मैं कैसे मापता हूँ कि कोई एजेंट सचमुच काम कर रहा है या नहीं](/how-i-measure-whether-an-ai-agent-is-actually-working/) में है। ## पैटर्न 3: हर हैंडऑफ़ को आइडम्पोटेंट बनाएँ क्यू *कम-से-कम-एक-बार* डिलीवरी की गारंटी देती हैं, ठीक एक बार की नहीं। इसका मतलब है कि एक संदेश दो बार पहुँच सकता है — नेटवर्क झटके, रीट्राई, रीडिप्लॉय। अगर आपके एजेंट की कार्रवाई आइडम्पोटेंट नहीं है, तो दोहरी डिलीवरी दोहरी कार्रवाई करती है: दो पुष्टि-ईमेल, दो बुकिंग, दो चार्ज। यह ऑर्केस्ट्रेशन बग की सबसे बुरी श्रेणी है, और यही वह है जिसे टीमें प्रोडक्शन में खोजती हैं। हल यह है कि कार्रवाइयों को एक की (key) से आइडम्पोटेंट बनाया जाए: ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // इस चरण से आगे पहले ही प्रोसेस हो चुका — यह डुप्लिकेट डिलीवरी है। छोड़ दें। return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` चरण-जाँच ऑपरेशन को दो बार चलाने के लिए सुरक्षित बना देती है: दूसरी डिलीवरी देखती है कि जॉब पहले ही आगे बढ़ चुका है और कुछ नहीं करती। बाहरी साइड-इफ़ेक्ट (ईमेल भेजना, कार्ड चार्ज करना) के लिए, डाउनस्ट्रीम API को एक आइडम्पोटेंसी की पास करें ताकि *वह* भी डीडुप्लिकेट करे। मान लें कि हर संदेश दो बार पहुँचेगा और इस तरह डिज़ाइन करें कि वह हानिरहित हो — क्योंकि आख़िरकार ऐसा होगा। ## पैटर्न 4: ऑर्केस्ट्रेटर बनाम कोरियोग्राफ़ी — सोच-समझकर चुनें फ़्लो को जोड़ने के दो तरीके हैं, और सही चुनाव जटिलता पर निर्भर करता है। **कोरियोग्राफ़ी** (जो मैं डिफ़ॉल्ट रूप से अपनाता हूँ): हर एजेंट केवल अगला चरण जानता है और उसे क्यू में डालता है। फ़्लो श्रृंखला से उभरता है। सरल, विकेंद्रित, बढ़ाने में आसान — एक क्यू डालकर एक चरण जोड़ें। नुकसान यह है कि कोई एक जगह पूरे फ़्लो का वर्णन नहीं करती, इसलिए एक जटिल पाइपलाइन के बारे में सोचना कठिन हो सकता है। **ऑर्केस्ट्रेशन** (एक केंद्रीय समन्वयक): एक ऑर्केस्ट्रेटर फ़्लो का स्वामी होता है, हर एजेंट को बारी-बारी से कॉल करता है, और परिणामों के आधार पर तय करता है कि आगे क्या। पूरा फ़्लो एक पठनीय जगह में बसता है और ब्रांचिंग लॉजिक स्पष्ट होता है। कीमत है एक केंद्रीय घटक जिसे स्वयं टिकाऊ होना चाहिए — अगर ऑर्केस्ट्रेटर का अपना स्टेट बाहर नहीं रखा गया (पैटर्न 2), तो वह एकल विफलता-बिंदु बन जाता है। मेरा नियम: **जब तक ब्रांचिंग जटिल न हो जाए तब तक कोरियोग्राफ़ी, फिर एक टिकाऊ ऑर्केस्ट्रेटर।** एक रैखिक तीन-चरण पाइपलाइन कोरियोग्राफ़ी है। शर्तीय रूटिंग, समानांतर फ़ैन-आउट, और जॉइन वाले फ़्लो को एक ऐसा ऑर्केस्ट्रेटर चाहिए जिसका स्टेट डेटाबेस में बसता हो ताकि वह क्रैश के बाद फिर से शुरू हो सके। ## पैटर्न 5: टुकड़े खोए बिना फ़ैन-आउट, फ़ैन-इन जब एक जॉब N समानांतर उप-कार्य जन्म देता है (50 रिकॉर्ड एनरिच करना, 20 दस्तावेज़ सारांशित करना) और जारी रखने से पहले आपको उन सबका इंतज़ार करना होता है, तो आपको एक **जॉइन** चाहिए। तरकीब है जॉब स्टेट में एक काउंटर: 1. पैरेंट N चाइल्ड संदेश क्यू में डालता है और जॉब रिकॉर्ड में `expected: N, completed: 0` लिखता है। 2. हर चाइल्ड अपना काम करता है और `completed` को **परमाणविक रूप से बढ़ाता** है। 3. जो चाइल्ड `completed` को `expected` के बराबर तक पहुँचाता है, वह अगला चरण क्यू में डालता है। परमाणविक वृद्धि भार-वहन करने वाली है — इसके बिना, एक साथ ख़त्म होने वाले दो चाइल्ड दोनों सोच सकते हैं कि वे आख़िरी नहीं हैं, और जॉइन कभी ट्रिगर नहीं होता। ऐसा काउंटर इस्तेमाल करें जिसे डेटास्टोर परमाणविक रूप से बढ़ा सके, या एक ट्रांज़ैक्शन। यह पैटर्न आपको पाइपलाइन के महँगे बीच के हिस्से को समानांतर करने देता है (अक्सर Haiku-सस्ता काम — देखें [Haiku बनाम Sonnet की लागत-गणित](/ai-agent-cost-math-when-haiku-beats-sonnet)) जबकि अंत में एक साफ़ जॉइन बनाए रखता है। ## जो मैं छोड़ दूँगा इनमें से कुछ भी करने के लिए आपको एक भारी-भरकम एजेंट फ़्रेमवर्क की ज़रूरत नहीं है। क्यू, एक स्टेट टेबल, और आइडम्पोटेंसी कीज़ ऐसी प्रिमिटिव हैं जो हर प्लेटफ़ॉर्म के पास पहले से हैं। मैंने टीमों को विस्तृत मल्टी-एजेंट फ़्रेमवर्क की ओर हाथ बढ़ाते देखा है ताकि वे वे सुविधाएँ पा सकें जो एक क्यू मुफ़्त देती है, और एक ऐसा ब्लैक बॉक्स विरासत में पा लेते हैं जिसे डिबग करना उस पाइपलाइन से कठिन है जिसे उसने बदला। उबाऊ प्रिमिटिव से शुरू करें। किसी फ़्रेमवर्क की ओर तभी हाथ बढ़ाएँ जब आपने कोई ठोस दर्द महसूस किया हो जिसे वह हल करता है। सारांश: एजेंट स्टेटलेस वर्कर हैं, क्यू टिकाऊ रीढ़ की हड्डी हैं, स्टेट एक डेटाबेस में बसता है, और हर हैंडऑफ़ दो बार चलाने के लिए सुरक्षित है। बस यही पूरा खेल है। ## अक्सर पूछे जाने वाले प्रश्न ### क्या एजेंटों को एक-दूसरे को सीधे कॉल करना चाहिए या क्यू से गुज़रना चाहिए? क्यू से। सीधी कॉल एजेंटों को जोड़ देती हैं — एक की विफलता या सुस्ती दूसरे तक फैलती है, और आप स्वतंत्र रूप से स्केल या रीडिप्लॉय नहीं कर सकते। एक टिकाऊ क्यू आपको बफ़रिंग, रीट्राई, बैकप्रेशर, और डिकपलिंग मुफ़्त में देती है। ### मल्टी-एजेंट स्टेट कहाँ बसना चाहिए? मॉडल के बाहर, एक डेटाबेस में, एक जॉब रिकॉर्ड के रूप में जिसे हर एजेंट पढ़ता और अपडेट करता है। मॉडल कॉल स्टेटलेस होती हैं, इसलिए पाइपलाइन प्रगति के लिए सत्य का स्रोत बाहरी होना चाहिए — यही सिस्टम को क्रैश के बाद रीस्टार्ट-योग्य बनाता है। ### मैं किसी एजेंट को एक ही जॉब पर दो बार कार्रवाई करने से कैसे रोकूँ? हैंडऑफ़ को आइडम्पोटेंट बनाएँ। कार्रवाई से पहले जॉब का चरण जाँचें और अगर वह पहले ही आगे बढ़ चुका हो तो कुछ न करें, और बाहरी API को आइडम्पोटेंसी कीज़ पास करें। क्यू कम-से-कम-एक-बार डिलीवर करती हैं, इसलिए मान लें कि हर संदेश दो बार आ सकता है और इस तरह डिज़ाइन करें कि डुप्लिकेट हानिरहित हों। ### क्या मुझे एक मल्टी-एजेंट फ़्रेमवर्क चाहिए? आमतौर पर नहीं। टिकाऊ क्यू, एक स्टेट टेबल, और आइडम्पोटेंसी कीज़ अधिकांश प्रोडक्शन ज़रूरतों को उन प्रिमिटिव से पूरा कर देती हैं जो आपका प्लेटफ़ॉर्म पहले से देता है। फ़्रेमवर्क तभी अपनाएँ जब आप किसी ठोस समस्या से टकराएँ जिसे वह अनोखे ढंग से हल करता है, डिफ़ॉल्ट रूप से नहीं। --- ## वह इवैल हार्नेस जिससे मैं बिना डर के AI एजेंट शिप करता हूँ Source: https://alejandrorioja.com/hi/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: बिना डर के एजेंट शिप करना एक ही चीज़ से आता है: एक इवैल हार्नेस। ग्रेडेड टेस्ट केस का एक तय सेट, अपने आप स्कोर किया गया (असर्शन्स के साथ एक LLM जज), हर प्रॉम्प्ट या मॉडल बदलाव से पहले चलाया गया। अगर स्कोर टिका रहे, तो शिप करो। टेस्ट सेट असली प्रोडक्शन विफलताओं से बनाया जाता है। ## विषय-सूची _जून 2026 में अपडेट किया गया।_ **संक्षेप:** किसी लाइव एजेंट पर मैं प्रॉम्प्ट बदल सकता हूँ या मॉडल अदल-बदल सकता हूँ और साँस रोके बिना — इसकी वजह एक ही है: एक **इवैल हार्नेस**। ग्रेडेड टेस्ट केस का एक तय सेट, अपने आप स्कोर किया गया — जहाँ मैं लिख सकता हूँ वहाँ कठोर असर्शन्स, और जहाँ नहीं वहाँ एक LLM जज — हर बदलाव से पहले चलाया गया। स्कोर टिका रहे, मैं शिप करता हूँ। स्कोर गिरे, तो नहीं। टेस्ट सेट सिंथेटिक नहीं है; यह असली प्रोडक्शन विफलताओं से बनाया जाता है, इसलिए हर बग एक स्थायी रिग्रेशन टेस्ट बन जाता है। **ऑपरेटर का नज़रिया:** 100 से ज़्यादा एजेंटों में, जिन्हें मैं भरोसे के साथ छूता हूँ और जिनसे मैं डरता हूँ — उनके बीच फ़र्क यही है कि उनमें इवैल हैं या नहीं। इवैल हार्नेस न होने का मतलब है हर प्रॉम्प्ट छेड़छाड़ एक जुआ है। एक इवैल हार्नेस "मुझे लगता है यह बेहतर है" को "यह नापने लायक 4 अंक बेहतर है और इसने कुछ नहीं तोड़ा" में बदल देता है। पूरा ताला यही खुलता है। आप बिना टेस्ट के कोड शिप नहीं करेंगे। लोग बिना इवैल के लगातार एजेंट शिप करते हैं, और फिर हैरान होते हैं कि एक "नन्हीं प्रॉम्प्ट छेड़छाड़" ने प्रोडक्शन क्यों तोड़ दिया। इवैल हार्नेस ग़ैर-नियतात्मक सॉफ़्टवेयर के लिए टेस्ट सूट है। यह रही वह जिसे मैं सचमुच चलाता हूँ। ## असली विफलताओं से बने टेस्ट सेट से शुरू करें हार्नेस अपने टेस्ट केस जितना ही अच्छा होता है, और सबसे अच्छे टेस्ट केस प्रोडक्शन से आते हैं, आपकी कल्पना से नहीं। हर बार जब कोई एजेंट असल दुनिया में विफल होता है, मैं ठीक वही इनपुट पकड़ लेता हूँ (मैं हर रन को एक ट्रेस ID के साथ लॉग करता हूँ — देखें [प्रोडक्शन में एजेंट को डीबग कैसे करें](/how-to-debug-an-ai-agent-in-production)) और उसे एक इवैल केस में बदल देता हूँ: ```typescript interface EvalCase { id: string; input: AgentInput; // ठीक वही प्रोडक्शन इनपुट expected?: string; // ग्राउंड ट्रुथ, जब कोई हो assertions: Assertion[]; // कठोर जाँचें जो पास होनी ही चाहिए rubric?: string; // LLM जज के लिए, जब आउटपुट खुला-छोर हो } ``` यहाँ दो अभ्यास मायने रखते हैं। **प्रोडक्शन से खींचें**, ताकि आपके इवैल वही टेस्ट करें जो सचमुच टूटता है, न कि वह जो आपने अनुमान लगाया था। और **पूरे दायरे को ढकें** — सुखद रास्ता, किनारे के मामले, प्रतिकूल इनपुट, और वे खाली/विकृत इनपुट जो चुपचाप विफलताएँ पैदा करते हैं। अच्छी तरह चुने गए 30 से 50 केस का टेस्ट सेट 500 आलसी केसों से कहीं ज़्यादा पकड़ता है। मैं 40 ऐसे केस रखना पसंद करूँगा जो हर एक किसी असली विफलता-तरीके को दर्शाते हों, बजाय हज़ार ऐसे जो सब एक ही आसान रास्ता टेस्ट करते हों। ## पहले असर्शन्स से स्कोर करें, फिर एक LLM जज से हर आउटपुट को स्कोर करने के लिए मॉडल की ज़रूरत नहीं होती। मैं सबसे सस्ते स्कोरर की ओर बढ़ता हूँ जो काम कर जाए। हर संरचित चीज़ के लिए **कठोर असर्शन्स**। क्या आउटपुट वैध JSON के रूप में पार्स होता है? क्या उसमें ज़रूरी फ़ील्ड है? क्या निकाली गई तारीख दायरे में है? क्या उसने सही आर्ग्युमेंट्स के साथ सही टूल बुलाया? ये नियतात्मक, मुफ़्त, और दो-टूक हैं — जितने लिख सकें, उतने लिखें। ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` खुले-छोर बाक़ी हिस्से के लिए **एक LLM जज** — लहजा, उपयोगिता, "क्या इसने सचमुच सवाल का जवाब दिया"। यहाँ आप किसी मॉडल को इनपुट, आउटपुट और एक रुब्रिक देते हैं, और स्कोर करने को कहते हैं। दो नियम जज को ईमानदार रखते हैं: रुब्रिक को **विशिष्ट** बनाएँ (वर्णित एंकरों वाला 1–5 पैमाना "गुणवत्ता आँको" से बेहतर है), और जज के रूप में एक **मज़बूत मॉडल** इस्तेमाल करें — आँकना एक तर्क-कार्य है, इसलिए यह वह जगह है जहाँ मैं ख़ुशी से Sonnet का दाम चुकाता हूँ, भले ही एजेंट ख़ुद [लागत के गणित](/ai-agent-cost-math-when-haiku-beats-sonnet) के अनुसार Haiku पर चल रहा हो। धुँधली रुब्रिक या कमज़ोर जज आपको ऐसा शोर देता है जो संकेत जैसा दिखता है। ## हर बदलाव से पहले हार्नेस चलाएँ हार्नेस एक सवाल का जवाब देने के लिए मौजूद है: *क्या इस बदलाव ने एजेंट को बेहतर बनाया या बदतर?* इसलिए मैं इसे हर प्रॉम्प्ट संपादन, मॉडल अदला-बदली, या टूल बदलाव से पहले चलाता हूँ। ```bash # main पर बेसलाइन npm run eval -- --suite=booking-agent > baseline.json # बदलाव करें, फिर दोबारा चलाएँ npm run eval -- --suite=booking-agent > candidate.json # तुलना करें npm run eval:diff baseline.json candidate.json ``` डिफ़ कुल स्कोर, हर केस का पास/फेल, और — सबसे अहम — **कौन-से ख़ास केस रिग्रेस हुए** यह दिखाता है। एक कुल स्कोर जो तब ऊपर चढ़ता है जब तीन केस चुपचाप टूट रहे हों, सुधार नहीं है; यह एक सौदा है जिसे मैं देखना और मंज़ूर करना चाहता हूँ, ऐसा नहीं जो चुपके से निकल जाए। हर केस के डिफ़ पर नज़र रखना ही वह तरीका है जिससे आप "एक चीज़ ठीक की, दो और तोड़ दीं" से बचते हैं — वही विफलता-तरीका जो लोगों को अपने ही प्रॉम्प्ट से डरा देता है। ## एक रिग्रेशन गेट लगाएँ और उसे रोकने दें जब आप हार्नेस पर भरोसा कर लें, तो उसे एक गेट के रूप में प्रोडक्शन तक के रास्ते में जोड़ दें। मेरा नियम दो-टूक है: **जो बदलाव स्कोर को बेसलाइन सीमा से नीचे गिरा दे, वह शिप नहीं होता।** "बाद में देख लूँगा" नहीं — वह रोक दिया जाता है, ठीक एक विफल CI टेस्ट की तरह। ```typescript const PASS_THRESHOLD = 0.90; // 90% केस पास होने चाहिए if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` यही वह चीज़ है जो इवैल को एक "अच्छा-हो-तो-सही" से उस चीज़ में बदल देती है जो आपको तेज़ चलने देती है। गेट ही "बिना डर के शिप करना" को शब्दशः सच बनाता है: किसी बुरे बदलाव का सबसे बुरा हाल एक लाल इवैल रन है, प्रोडक्शन घटना नहीं। और क्योंकि हर बार कुछ टूटने पर टेस्ट सेट बढ़ता है, गेट समय के साथ अपने-आप सख़्त और ज़्यादा सुरक्षात्मक होता जाता है। ## स्कोरिंग में ग़ैर-नियतात्मकता का हिसाब रखें एक बारीकी जो लोगों को गिरा देती है: एक ही इनपुट अलग-अलग रन में अलग स्कोर पा सकता है क्योंकि मॉडल अलग तरह से सैंपल करता है। अगर आप हर केस को एक बार चलाते हैं, तो आपको भूतिया रिग्रेशन दिखेंगे — एक केस जो "टूटा" वह असल में महज़ सैंपलिंग शोर है। दो उपाय। विचलन घटाने के लिए इवैल को **`temperature: 0`** पर चलाएँ (यह उसे पूरी तरह ख़त्म नहीं करेगा)। और जिन केसों को आपने टिमटिमाते देखा हो, उन्हें **N बार चलाएँ और पास दर लें**, एक अकेला पास/फेल नहीं। जो केस 10 में से 9 बार पास होता है वह उससे बेहतर हालत में है जो 10 में से 5 बार पास होता है, भले ही दोनों एक अकेला हरा रन दिखा सकें। यह वही "किस्से से ज़्यादा मात्रा" वाला सिद्धांत है जो मैं [रुक-रुक कर होने वाली विफलताओं को डीबग करते](/how-to-debug-an-ai-agent-in-production) समय इस्तेमाल करता हूँ — एक रन एक राय है, पचास रन डेटा हैं। ## प्रोडक्शन मॉनिटरिंग से लूप बंद करें इवैल हार्नेस ज्ञात केसों के विरुद्ध टेस्ट करता है। प्रोडक्शन नए केस फेंकता है। तो लूप यह है: लाइव व्यवहार पर नज़र रखें, एक नया विफलता-तरीका पकड़ें, उसे एक इवैल केस में बदलें, ठीक करें, और अब वह स्थायी रूप से सुरक्षित है। मॉनिटरिंग का पहलू — लाइव ट्रैफ़िक पर सफलता दर, आउटपुट वैधता, और प्रति रन लागत ट्रैक करना — वह है जिसे मैं [मैं कैसे नापता हूँ कि कोई AI एजेंट सचमुच काम कर रहा है या नहीं](/how-i-measure-whether-an-ai-agent-is-actually-working/) में बताता हूँ। इवैल और मॉनिटरिंग एक ही तंत्र के दो हिस्से हैं: मॉनिटरिंग बग ढूँढती है, इवैल यह पक्का करती हैं कि वे मरे रहें। वह फ़ीडबैक लूप ही असली उत्पाद है। कोई भी अकेला इवैल सेट बासी पड़ जाता है; पर एक *प्रक्रिया* जो हर प्रोडक्शन विफलता को एक स्थायी टेस्ट में बदल देती है, हर हफ़्ते मज़बूत होती जाती है। इसी तरह एक एजेंट "छूने में डरावना" से उस चीज़ में बदल जाता है जिसे मैं किसी शुक्रवार की दोपहर बिना झिझके रीफ़ैक्टर कर दूँ। ## अक्सर पूछे जाने वाले सवाल ### एक AI एजेंट इवैल सेट में क्या जाता है? असली प्रोडक्शन इनपुट को ग्रेडेड केसों में बदला गया — सुखद रास्ता, किनारे के मामले, प्रतिकूल और विकृत इनपुट — हर एक के साथ कठोर असर्शन्स और, खुले-छोर आउटपुट के लिए, एक LLM-जज रुब्रिक। असल विफलताओं से लिए गए 30 से 50 केस सैकड़ों सिंथेटिक केसों को मात देते हैं जो सब आसान रास्ता टेस्ट करते हैं। ### क्या मुझे एजेंट आउटपुट आँकने के लिए LLM इस्तेमाल करना चाहिए? जहाँ भी आउटपुट संरचित हो (वैध JSON, सही फ़ील्ड, सही टूल कॉल) वहाँ कठोर असर्शन्स इस्तेमाल करें — वे मुफ़्त और नियतात्मक हैं। लहजे और उपयोगिता जैसी खुले-छोर ख़ूबियों के लिए एक LLM जज बचाकर रखें, एक विशिष्ट रुब्रिक और एक मज़बूत जज मॉडल के साथ, ताकि आपको संकेत मिले, शोर नहीं। ### मैं किसी प्रॉम्प्ट बदलाव को प्रोडक्शन चुपचाप तोड़ने से कैसे रोकूँ? हर बदलाव से पहले इवैल हार्नेस चलाएँ और एक बेसलाइन के विरुद्ध डिफ़ करें, सिर्फ़ कुल स्कोर नहीं, बल्कि हर केस के रिग्रेशन पर नज़र रखें। फिर परिणाम पर डिप्लॉय को गेट करें ताकि कोई भी बदलाव जो बेसलाइन सीमा से नीचे गिरे, एक विफल टेस्ट की तरह रोक दिया जाए। ### इवैल में ग़ैर-नियतात्मकता को मैं कैसे संभालूँ? विचलन घटाने के लिए तापमान 0 पर चलाएँ, और जो केस टिमटिमाते हैं उन्हें कई बार चलाएँ और एक अकेले रन के बजाय पास दर से स्कोर करें। जो केस 10 में से 9 बार पास होता है वह उससे ज़्यादा स्वस्थ है जो 10 में से 5 बार पास होता है, भले ही एक अकेला रन दोनों को हरा दिखाए। --- ## AI एजेंट से अपना न्यूज़लेटर कैसे ऑटोमेट करें Source: https://alejandrorioja.com/hi/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-26 Tags: AI Agents, Growth TL;DR: Claude एजेंट मेरी कंटेंट क्यू पढ़ता है, सप्ताह का सबसे मज़बूत एंगल चुनता है, मेरी आवाज़ में न्यूज़लेटर का ड्राफ्ट बनाता है, एंगेजमेंट टियर के अनुसार लिस्ट सेगमेंट करता है, और Kit API के ज़रिए भेजने का शेड्यूल बनाता है — बिना मेरे एडिटर खोले। मैं एक रेंडर किया हुआ प्रीव्यू देखता हूँ और अप्रूव दबाता हूँ। कठिन क्रिएटिव काम मेरा है; मैकेनिकल एग्जीक्यूशन एजेंट का। ## विषय सूची _जून 2026 में अपडेट किया गया।_ **TL;DR:** Claude एजेंट मेरी कंटेंट क्यू पढ़ता है, सप्ताह का सबसे मज़बूत एंगल चुनता है, मेरी आवाज़ में न्यूज़लेटर का ड्राफ्ट बनाता है, एंगेजमेंट टियर के अनुसार लिस्ट सेगमेंट करता है, और Kit API के ज़रिए भेजने का शेड्यूल बनाता है — बिना मेरे एडिटर खोले। मैं एक रेंडर किया हुआ प्रीव्यू देखता हूँ और अप्रूव दबाता हूँ। कठिन क्रिएटिव काम मेरा है; मैकेनिकल एग्जीक्यूशन एजेंट का। **[ऑपरेटर नोट]** जो न्यूज़लेटर लगातार भेजी जाती है, वह उससे बेहतर है जो "बेहतर" है लेकिन इंस्पिरेशन आने पर ही भेजी जाती है। बाधा एग्जीक्यूशन का ओवरहेड था, विचार नहीं। मेरे पास विचार थे; हर हफ्ते उन्हें फॉर्मेट, शेड्यूल और सेगमेंट करने की बैंडविड्थ नहीं थी। एजेंट ने वह गैप खत्म कर दिया। ## अधिकतर न्यूज़लेटर वर्कफ्लो में असली बॉटलनेक न्यूज़लेटर ऑटोमेशन की अधिकतर सलाह गलत चीज़ पर फोकस करती है: वेलकम सीक्वेंस, ऑटोमेशन, टैगिंग लॉजिक। यह ठीक है, लेकिन हफ्ते-दर-हफ्ते कंटेंट बनाने की समस्या नहीं सुलझाती। असली रुकावट यह है: आप जानते हैं क्या कहना है, लेकिन बैठकर उसे फॉर्मेट करना, सब्जेक्ट लाइन के वेरिएंट लिखना, सही सेगमेंट चुनना, और सही समय पर शेड्यूल करना हर हफ्ते 2-3 घंटे का कॉन्टेक्स्ट-स्विचिंग खर्च करता है। 52 हफ्तों से गुणा करें तो आपने पूरा एक कार्य-सप्ताह सिर्फ न्यूज़लेटर *भेजने* में बिताया। एजेंट "मुझे पता है इस हफ्ते का एंगल क्या है" के बाद हर कदम संभालता है। ## मैं जो स्टैक यूज़ कर रहा हूँ - **[Kit](/recommends/convertkit)** (पहले ConvertKit) — ईमेल प्लेटफ़ॉर्म। उत्कृष्ट API, मज़बूत सब्सक्राइबर टैगिंग, साफ एनालिटिक्स। एजेंट-फ्रेंडली API ने मुझे कन्विंस किया। - **Claude (Anthropic SDK)** — जनरेशन लेयर - **Cloudflare Workers** — शेड्यूल्ड ट्रिगर (हर मंगलवार सुबह 8 बजे CT चलता है) - **Airtable** — कंटेंट क्यू और अप्रूवल इनबॉक्स अगर आप Kit पर नहीं हैं, तो वही पैटर्न किसी भी प्लेटफ़ॉर्म के साथ काम करता है जिसके पास ब्रॉडकास्ट बनाने और शेड्यूल करने के लिए REST API हो। ## स्टेप 1: कंटेंट क्यू एजेंट को "हम किस बारे में लिख रहे हैं" के लिए एक सच्चे स्रोत की ज़रूरत है। मेरी [Airtable](/recommends/airtable) टेबल है जिसमें कॉलम हैं: - `Topic` — एंगल या सवाल - `Status` — Queue / Approved / Sent - `Tier` — सभी सब्सक्राइबर के लिए या केवल एंगेज्ड सब्सक्राइबर के लिए - `Notes` — कोई भी बाधाएं (यह टोन अवॉइड करें, यह लिंक शामिल करें, आदि) हर हफ्ते, मैं क्यू में 2-3 टॉपिक जोड़ने में 10 मिनट बिताता हूँ। यही मेरा क्रिएटिव इनपुट है। बाकी एजेंट का काम है। ## स्टेप 2: ड्राफ्ट एजेंट ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## स्टेप 3: अप्रूवल स्टेप एजेंट Kit के ड्राफ्ट स्टेट में ब्रॉडकास्ट बनाता है और Airtable रिकॉर्ड को "Approved" मार्क करता है। Kit मुझे प्रीव्यू लिंक के साथ नोटिफिकेशन भेजता है। मैं उस पर क्लिक करता हूँ, पढ़ता हूँ, और अगर सही लगे तो भेजने की पुष्टि करता हूँ। अगर बदलाव चाहूँ, तो Kit में सीधे एडिट करता हूँ। यही वह गेट है जो एजेंट को आउटबाउंड ईमेल में पूरी तरह ऑटोनॉमस होने से रोकता है। मैं ड्राफ्ट पर लगभग 90% समय भरोसा करता हूँ। रिव्यू में जो 10% पकड़ता हूँ — थोड़ा गलत टोन, एक स्टैट जिसे वेरिफाई करना हो, एक लिंक जोड़ना हो — वह 3 मिनट की रिव्यू की कीमत पर है। ## एजेंट जो संभालता है जो मैं दोबारा नहीं करना चाहता - सब्जेक्ट लाइन वेरिएंट लिखना और सबसे अच्छा चुनना - प्रीहेडर टेक्स्ट फॉर्मेट करना - सही भेजने का समय कैलकुलेट करना (मेरा ऑडियंस गुरुवार सुबह खोलता है; एजेंट यह जानता है) - टॉपिक के टियर के आधार पर सही से सेगमेंट करना - रिकॉर्ड रखने के लिए सब कुछ Airtable में लॉग करना ## मेरे पास जो अभी भी है *आइडिया*। क्यू में टॉपिक मेरा है। एंगल मेरा है। एजेंट एक स्पष्ट ब्रीफ का शानदार एग्जीक्यूटर है; यह स्ट्रैटेजी लेयर नहीं है। अगर मैंने क्यू में बुरा टॉपिक डाला, तो मुझे बुरे टॉपिक के बारे में अच्छी तरह लिखी न्यूज़लेटर मिलेगी। इसके अलावा: पहले रिव्यू का गेट। हर भेजने से पहले मेरी नज़र उस पर जाती है। यह नहीं बदलेगा। ## ऑपरेटर की बॉटम लाइन अगर आप न्यूज़लेटर मैकेनिक्स पर हफ्ते में एक घंटे से ज़्यादा खर्च कर रहे हैं — फॉर्मेटिंग, शेड्यूलिंग, सेगमेंटिंग — तो आपको इसे ऑटोमेट करना चाहिए। Kit API क्लीन है, Worker cron ट्रिगर रॉक-सॉलिड है, और Claude ड्राफ्ट क्वालिटी इतनी ऊँची है कि मैं ~90% पहले ड्राफ्ट बिना बदलाव के अप्रूव कर देता हूँ। Airtable में क्यू बनाएं, Worker कनेक्ट करें, और भेजने की जगह आइडिया बनाने पर वापस आएं। --- ## एक भी नया ब्लॉग पोस्ट लिखे बिना AI सर्च में रैंक कैसे करें Source: https://alejandrorioja.com/hi/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-25 Tags: GEO, SEO TL;DR: AI इंजन उस कंटेंट को उद्धृत करते हैं जो सीधे सवालों का जवाब देता है, स्पष्ट लेखकत्व का दावा करता है और ज्ञान को इस तरह संरचित करता है जिससे पुनः प्राप्ति आसान हो। अधिकांश मौजूदा ब्लॉग पोस्ट को पुनर्लेखन नहीं बल्कि संपादन के साथ तीनों मानदंडों को पूरा करने के लिए संशोधित किया जा सकता है। प्लेबुक: एक सीधा TL;DR जोड़ें, एंटिटी सिग्नल को मजबूत करें, FAQ स्कीमा जोड़ें और llms.txt में सबमिट करें। नया कंटेंट वैकल्पिक है; पुनर्संरचना नहीं है। ## विषय सूची _जून 2026 में अपडेट किया गया।_ **TL;DR:** AI इंजन उस कंटेंट को उद्धृत करते हैं जो सीधे सवालों का जवाब देता है, स्पष्ट लेखकत्व का दावा करता है और ज्ञान को इस तरह संरचित करता है जिससे पुनः प्राप्ति आसान हो। अधिकांश मौजूदा ब्लॉग पोस्ट को पुनर्लेखन नहीं बल्कि संपादन के साथ तीनों मानदंडों को पूरा करने के लिए संशोधित किया जा सकता है। प्लेबुक: एक सीधा TL;DR जोड़ें, एंटिटी सिग्नल को मजबूत करें, FAQ स्कीमा जोड़ें और llms.txt में सबमिट करें। नया कंटेंट वैकल्पिक है; पुनर्संरचना नहीं है। **[ऑपरेटर की नज़र]** एक भी नया GEO-लक्षित लेख लिखने से पहले मैंने यह प्रक्रिया 341 मौजूदा पोस्ट पर लागू की। ChatGPT और Perplexity में उद्धरण बढ़े। नए कंटेंट ने लाभ को तेज़ किया — लेकिन मौजूदा कंटेंट ऑडिट वह जगह थी जहां मैंने शुरू किया, और उम्मीद से ज़्यादा तेज़ी से फल मिला। ## AI इंजन आपके मौजूदा कंटेंट को क्यों नहीं उद्धृत करते कुछ नया लिखने से पहले पूछें: जो मेरे पास पहले से है वह क्यों उद्धृत नहीं हो रहा? जवाब लगभग कभी नहीं होता "कंटेंट मौजूद नहीं है।" यह आमतौर पर इनमें से एक होता है: 1. **शीर्ष पर कोई सीधा जवाब नहीं** — पोस्ट जवाब को पैराग्राफ 6 में दफन कर देती है 2. **लेखकत्व सिग्नल कमज़ोर** — कोई स्पष्ट लेखक एंटिटी नहीं, कंटेंट में कोई क्रेडेंशियल नहीं 3. **संरचनात्मक शोर** — लंबे परिचय, अप्रासंगिक खंड, कोई स्पष्ट शीर्षक पदानुक्रम नहीं 4. **कोई मशीन-पठनीय Q&A नहीं** — AI इंजन संरचित प्रश्न-उत्तर जोड़े पसंद करते हैं; अधिकांश ब्लॉग पोस्ट में ये नहीं होते 5. **किसी AI-पठनीय इंडेक्स में नहीं** — कोई llms.txt नहीं, कोई साइटमैप नहीं जो क्रॉलर ढूंढें पांचों मौजूदा कंटेंट पर ठीक करने योग्य हैं। किसी के लिए भी नई पोस्ट की ज़रूरत नहीं। ## चार-चरण रेट्रोफिट प्रक्रिया ### चरण 1: पहले 100 शब्दों में सीधा TL;DR जोड़ें AI इंजन वह करते हैं जो आप स्कैन करते समय करते हैं — गहरे जाने से पहले सीधा जवाब ढूंढते हैं। अगर आपकी पोस्ट किसी कहानी, सवाल या संदर्भ-निर्माण से शुरू होती है, तो मॉडल शायद कभी इतना आगे न पढ़े कि आपका असली जवाब मिले। समाधान: पहले 100 शब्दों में एक **TL;DR** ब्लॉक जोड़ें। प्रारूप: निष्कर्ष → क्यों → बाधा या चेतावनी। दो से चार वाक्य। कोई भराई नहीं। पहले का उदाहरण: > *क्या आपने कभी सोचा है कि कुछ व्यवसाय Google के खोज परिणामों पर हावी क्यों लगते हैं? इस पोस्ट में, हम उन रणनीतियों की खोज करेंगे जो शीर्ष-रैंकिंग साइटें उपयोग करती हैं...* बाद का उदाहरण: > **TL;DR:** 2026 में लोकल SEO के लिए तीन चीज़ें काम करती हैं: Google Business Profile की पूर्णता, डायरेक्टरी में उद्धरण की निरंतरता और NAP डेटा के लिए संरचित स्कीमा। "हर दिन पोस्ट करें" और "100 रिव्यू जल्दी पाएं" जैसी रणनीतियां इन तीन के सामने गौण हैं। सीमा आपके GBP की सटीकता है — पहले उसे ठीक करें। पुनर्लेखन लंबा नहीं है। बस आगे रख दिया गया है। ### चरण 2: एंटिटी सिग्नल को मजबूत करें AI इंजन ज्ञान ग्राफ बनाते हैं। वे जानना चाहते हैं: यह किसने लिखा, यह किस बारे में है और इस विषय पर लेखक विश्वसनीय है? लेखक एंटिटी के लिए: सुनिश्चित करें कि About पेज हर पोस्ट से लिंक है, आपके लेखक स्कीमा में LinkedIn और Twitter के `sameAs` लिंक हैं, और हर पोस्ट की लेखक बायो में विशिष्ट क्रेडेंशियल का उल्लेख है (न कि "मार्केटिंग प्रोफेशनल" — "तीन SaaS कंपनियों के लिए SEO 0 से 100K मासिक आगंतुकों तक चलाया")। विषय एंटिटी के लिए: वे सटीक शब्द उपयोग करें जो आपके दर्शक खोजते हैं। अगर आप "GEO" (जनरेटिव इंजन ऑप्टिमाइजेशन) को कवर कर रहे हैं, तो सिर्फ संक्षिप्त रूप नहीं बल्कि कहीं "जनरेटिव इंजन ऑप्टिमाइजेशन" कहें। मॉडल कंटेंट वर्गीकृत करने के लिए शब्द सह-उपस्थिति का उपयोग करते हैं। ### चरण 3: सवालों का जवाब देने वाली हर पोस्ट में FAQ स्कीमा जोड़ें FAQPage स्कीमा GEO उद्धरण के लिए सबसे अधिक प्रभाव वाला स्कीमा प्रकार है क्योंकि यह उस फ़ॉर्मेट में सवाल को जवाब से स्पष्ट रूप से मैप करता है जिसे मॉडल सीधे पार्स कर सकते हैं। उन 3-5 सवालों को लें जिनका आपकी पोस्ट अंतर्निहित रूप से जवाब देती है और उन्हें स्पष्ट बनाएं: ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` इसे अपनी पोस्ट के `` में या CMS के स्कीमा फ़ील्ड के ज़रिए जोड़ें। हर प्रमुख AI इंजन इसे क्रॉल और पार्स करता है। ### चरण 4: llms.txt और अपने प्लेटफ़ॉर्म के AI इंडेक्स में सबमिट करें `llms.txt` एक उभरता मानक है — `yoursite.com/llms.txt` पर एक प्लेन-टेक्स्ट फ़ाइल जो AI क्रॉलर को बताती है कि कौन सा कंटेंट उच्च-गुणवत्ता वाला है और इसे कैसे प्राथमिकता दें। यह LLMs के लिए `robots.txt` के समान है। बुनियादी llms.txt: ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` इसे `lastmod` टाइमस्टैंप वाले साफ साइटमैप के साथ जोड़ें। AI क्रॉलर पुराने दिखने वाले कंटेंट को कम प्राथमिकता देते हैं। ## किन पोस्ट को रेट्रोफिट करना है, इसे कैसे प्राथमिकता दें हर पोस्ट रेट्रोफिट करने लायक नहीं है। अपने पहले दौर को यहां केंद्रित करें: 1. **पोस्ट जो पहले से प्रश्न-प्रारूप कीवर्ड के लिए पेज 1 पर रैंक करती हैं** — ये उद्धृत होने के सबसे करीब हैं; उन्हें सिर्फ संरचना सुधार चाहिए 2. **उन विषयों पर पोस्ट जिन पर आप सत्यापित रूप से विश्वसनीय हैं** — AI इंजन लेखकत्व को भारी वज़न देते हैं; वह पोस्ट जहां आपके क्रेडेंशियल प्रासंगिक हैं, एंटिटी सिग्नल से उद्धरण बढ़त पाती है 3. **सीधे सवाल का जवाब देने वाली पोस्ट बनाम जानकारी देने वाली पोस्ट** — "X कैसे करें" और "X क्या है" सूची पोस्ट या राय टुकड़ों से बेहतर रेट्रोफिट होती हैं अपने Search Console डेटा का उपयोग करें: प्रश्न वाले क्वेरी के लिए फ़िल्टर करें (how, what, why, best way to)। उन क्वेरी के लिए 5-15 पर रैंक करने वाली पोस्ट आपके सर्वोत्तम रेट्रोफिट उम्मीदवार हैं — वे प्रासंगिक हैं लेकिन उद्धृत होने के लिए शीर्ष के पर्याप्त करीब नहीं हैं। ## वह गलती जो अधिकांश लोग करते हैं वे मौजूदा आर्काइव को रेट्रोफिट करने से पहले AI सर्च के लिए अनुकूलित नई पोस्ट लिखते हैं। नया कंटेंट मदद करता है, लेकिन मौजूदा पोस्ट के पास उम्र, बैकलिंक और क्रॉल इतिहास की ताकत है। एक अच्छी तरह से संरचित तीन साल पुरानी पोस्ट महीनों तक उसी विषय पर नई पोस्ट से बेहतर प्रदर्शन करेगी। पहले रेट्रोफिट करें। जहां वास्तविक अंतराल हों — जो सवाल आपकी मौजूदा पोस्ट बिल्कुल नहीं करती — वहां नया कंटेंट लिखें। तभी नया पुराने से बेहतर होता है। ## ऑपरेटर का निष्कर्ष अगर आपके पास 20 से अधिक मौजूदा ब्लॉग पोस्ट हैं, तो आपका GEO काम कंटेंट कैलेंडर नहीं बल्कि ऑडिट और रेट्रोफिट से शुरू होता है। कुछ भी नया लिखने से पहले अपनी शीर्ष 20 पोस्ट पर TL;DR जोड़ें, एंटिटी सिग्नल मजबूत करें, FAQ स्कीमा जोड़ें और llms.txt में सबमिट करें। आप महीनों में नहीं, हफ्तों में उद्धरण सुधार देखेंगे — और आपके पास यह मापने के लिए एक साफ बेसलाइन होगी कि नया कंटेंट वास्तव में सुई को हिलाता है या नहीं। --- ## मैंने एक Claude स्किल बनाई जो मेरे Facebook विज्ञापन चलाती है — यहाँ है कोड Source: https://alejandrorioja.com/hi/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-21 Tags: AI Agents TL;DR: मैंने एक Claude स्किल बनाई जो Graph API के माध्यम से मेरे Meta Ads अकाउंट को पढ़ती है, कम प्रदर्शन वाले विज्ञापनों की पहचान करती है, मेरी ब्रांड वॉयस में विज्ञापन कॉपी फिर से लिखती है, और बिना Ads Manager को छुए नए विज्ञापन सेट बनाती है। पूरी चीज़ 300 लाइनों से कम TypeScript में है। ROI तुरंत आया: मैंने साप्ताहिक विज्ञापन प्रबंधन का समय ~3 घंटे से घटाकर लगभग 20 मिनट कर दिया। ## विषय-सूची _जून 2026 में अपडेट।_ **TL;DR:** मैंने एक Claude स्किल बनाई जो Graph API के माध्यम से मेरे Meta Ads अकाउंट को पढ़ती है, कम प्रदर्शन वाले विज्ञापनों की पहचान करती है, मेरी ब्रांड वॉयस में विज्ञापन कॉपी फिर से लिखती है, और बिना Ads Manager को छुए नए विज्ञापन सेट बनाती है। पूरी चीज़ 300 लाइनों से कम TypeScript में है। ROI तुरंत आया: मैंने साप्ताहिक विज्ञापन प्रबंधन का समय ~3 घंटे से घटाकर लगभग 20 मिनट कर दिया। **[ऑपरेटर की नज़र]** मैं Pickleland और अपने कंसल्टिंग ब्रांड के लिए विज्ञापन चलाता हूँ। दो अकाउंट, अलग-अलग ऑडियंस, लगातार क्रिएटिव थकान। मैं रविवार की दोपहरें Ads Manager में ऐसी चीजें करते हुए बिता रहा था जो एक मॉडल को करनी चाहिए। तो मैंने इसे ऑटोमेट कर दिया। ## मैंने Facebook विज्ञापन मैन्युअली प्रबंधित करना क्यों बंद किया Facebook विज्ञापन चलाने का असली काम तीन हिस्सों में बंटता है: 1. **मॉनिटरिंग** — यह जाँचना कि कौन से विज्ञापन सेट पैसे जला रहे हैं बनाम कमा रहे हैं 2. **डायग्नोसिस** — यह पता लगाना कि *क्यों* कुछ कम प्रदर्शन कर रहा है (क्रिएटिव थकान? खराब टार्गेटिंग? लैंडिंग पेज?) 3. **इटरेशन** — नई कॉपी लिखना, नए विज्ञापन सेट बनाना, बजट एडजस्ट करना काम 1 यांत्रिक है। काम 3 ज्यादातर यांत्रिक है (वॉयस की सीमा के साथ)। काम 2 को निर्णय की जरूरत है — और यह एकमात्र ऐसा है जिसमें लूप में इंसान का होना फायदेमंद है। एक Claude स्किल 1 और 3 कर सकती है। मैं काम 2 के आउटपुट की समीक्षा करता हूँ इससे पहले कि कुछ भी पब्लिश हो। यही वह आर्किटेक्चर है जिस पर मैं टिका। ## Meta Graph API सेटअप (यह परेशान करने वाला हिस्सा है) किसी भी कोड से पहले: आपको Meta Business अकाउंट, एक सिस्टम यूज़र और एक स्थायी एक्सेस टोकन चाहिए। Facebook का डेव पोर्टल असुविधाजनक है लेकिन रास्ता यह है: 1. developers.facebook.com पर **Meta App** बनाएँ (प्रकार: Business) 2. **Marketing API** प्रोडक्ट जोड़ें 3. अपने Business Portfolio → Settings → Users → System Users में, एक सिस्टम यूज़र बनाएँ और उसे अपने विज्ञापन अकाउंट पर `ADVERTISER` रोल दें 4. इन परमिशन के साथ टोकन जनरेट करें: `ads_read`, `ads_management`, `business_management` टोकन को `META_ACCESS_TOKEN` के रूप में और अपने विज्ञापन अकाउंट ID (फॉर्मेट: `act_XXXXXXXX`) को `META_AD_ACCOUNT_ID` के रूप में अपनी `.env` में सेव करें। ## स्किल फ़ाइल संरचना ``` .claude/skills/fb-ads/ SKILL.md ← निर्देश जो Claude पढ़ता है index.ts ← असली टूल इम्प्लीमेंटेशन types.ts ← साझा टाइप्स ``` `SKILL.md` वह है जो Claude को बताता है कि स्किल का उपयोग कब और कैसे करना है। मेरी कहती है: ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` "कभी भी स्वचालित रूप से सक्रिय न करें" की बाधा गैर-परक्राम्य है। यह स्किल चीज़ें PAUSED स्थिति में बनाती है। मैं समीक्षा करता हूँ और मैन्युअली सक्रिय करता हूँ। लाइव विज्ञापन खर्च को छूने वाली किसी भी चीज़ को इंसानी चेकपॉइंट की जरूरत है। ## मुख्य TypeScript कोड (कोड ब्लॉक अंग्रेजी में रहते हैं — केवल आसपास का टेक्स्ट अनुवादित है।) ## मैं इसे रोज़ाना कैसे उपयोग करता हूँ स्किल Claude Code से इनवोक होती है (मेरा डेली टूल)। एक विशिष्ट सोमवार सुबह का सेशन: ``` > check my ads from the last 7 days ``` Claude `runAdsReport(7)` चलाता है, परिणामों को टेबल के रूप में फॉर्मेट करता है, कम प्रदर्शन वालों को फ्लैग करता है, और पूछता है कि क्या मैं रीराइट चाहता हूँ। मैं हाँ कहता हूँ। यह नई कॉपी जनरेट करता है, मुझे दोनों वर्शन साइड-बाय-साइड दिखाता है, और नए क्रिएटिव के साथ PAUSED विज्ञापन सेट बनाता है। मैं उन्हें Ads Manager में समीक्षा करता हूँ, जो मुझे पसंद हैं उन्हें एक्टिवेट करता हूँ, और हारे हुओं को आर्काइव करता हूँ। कुल समय: 20 मिनट। Ads Manager में रविवार की दोपहरें: शून्य। ## यह किसे रिप्लेस नहीं करती स्किल मुझे यह नहीं बता सकती कि प्रोडक्ट-मार्केट फिट की समस्या कॉपी की समस्या के रूप में छुपी है या नहीं। अगर ROAS हर जगह खराब है, तो यह फनल या ऑफर की समस्या है, हेडलाइन की नहीं। Claude टूटे हुए फनल पर ईमानदारी से कॉपी रीराइट करेगा — और रीराइट्स इसे नहीं बचाएँगी। डायग्नोसिस का चरण अभी भी मेरा है। मैं रिपोर्ट पढ़ता हूँ, फनल डेटा देखता हूँ, और तय करता हूँ कि क्या हम क्रिएटिव को इटरेट कर रहे हैं या ऊपरी स्तर पर कुछ हल कर रहे हैं। एजेंट उस निर्णय *के अलावा* सब कुछ में तेज़ है। ## ऑपरेटर का निष्कर्ष अगर आप मैन्युअली विज्ञापन प्रबंधित कर रहे हैं और हफ्ते में दो बार से ज़्यादा Ads Manager को छू रहे हैं, तो आप वे ऑपरेशन कर रहे हैं जो एक स्क्रिप्ट को करने चाहिए। Graph API अच्छी तरह से डॉक्युमेंटेड है और Meta परमिशन फ्लो, हालाँकि परेशान करने वाला है, एक बार का सेटअप है। एक दोपहर में स्किल बनाएँ। पुनः प्राप्त समय का फायदा पहले हफ्ते में दिखता है। --- ## 5 AI टूल्स जो मैं वास्तव में अपना बिजनेस चलाने के लिए उपयोग करता हूं (2026) Source: https://alejandrorioja.com/hi/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-19 Tags: AI Agents, Growth TL;DR: पांच टूल्स: Claude (ऑपरेटर लेयर + कोडिंग), Cursor (TypeScript डेवलपमेंट), Airtable (सभी एजेंट्स के लिए डेटा बैकबोन), Kit (न्यूज़लेटर + ईमेल ऑटोमेशन), और Cloudflare Workers (एजेंट होस्टिंग)। मैंने जो कुछ और आज़माया वो इनमें से किसी एक से बदल दिया गया या पूरी तरह काट दिया गया। यही वह स्टैक है जिसे मैं दोबारा बनाऊंगा अगर मुझे आज से शुरू करना हो। ## विषय सूची _जून 2026 में अपडेट किया गया।_ **TL;DR:** पांच टूल्स: Claude (ऑपरेटर लेयर + कोडिंग), Cursor (TypeScript डेवलपमेंट), [Airtable](/recommends/airtable) (सभी एजेंट्स के लिए डेटा बैकबोन), [Kit](/recommends/convertkit) (न्यूज़लेटर + ईमेल ऑटोमेशन), और Cloudflare Workers (एजेंट होस्टिंग)। मैंने जो कुछ और आज़माया वो इनमें से किसी एक से बदल दिया गया या पूरी तरह काट दिया गया। यही वह स्टैक है जिसे मैं दोबारा बनाऊंगा अगर मुझे आज से शुरू करना हो। **[ऑपरेटर की नज़र]** मैं दो बिजनेस चलाता हूं: एक पर्सनल AI कंसल्टिंग ब्रांड (alejandrorioja.com) और Pickleland — Texas के Pflugerville में एक पिकलबॉल सुविधा। अलग-अलग संदर्भ, अलग-अलग दर्शक, अलग-अलग ऑपरेशन। ये पांच टूल्स दोनों को चलाते हैं। मैं इन्हें इसलिए नहीं लिस्ट कर रहा क्योंकि ये ट्रेंडी हैं; बल्कि इसलिए कि मैंने इनके रिप्लेसमेंट को डिलीट कर दिया। ## 1. Claude — ऑपरेटर लेयर Claude (Claude Code और Anthropic SDK के ज़रिए) हर चीज़ का दिमाग है जो चलती है। मैं इसे तीन मोड में उपयोग करता हूं: **Claude Code** मेरा रोज़मर्रा का डेवलपमेंट टूल है। मैं TypeScript लिखता हूं, एजेंट बनाता हूं, इन्फ्रास्ट्रक्चर समस्याओं को डीबग करता हूं, और कंटेंट मैनेज करता हूं — सब Claude Code इंटरफेस से। यह सिर्फ ऑटोकम्पलीट नहीं है; यह एक सहयोगी है जो 500 लाइन की फ़ाइल पढ़ सकता है, इरादे को समझ सकता है, और एक रिफैक्टर सुझा सकता है जो मैंने सोचा नहीं था। **Anthropic SDK** मेरे द्वारा बनाए गए हर एजेंट को पावर देता है। मेरा न्यूज़लेटर एजेंट, मेरी Facebook ads स्किल, मेरा कंटेंट पाइपलाइन, मेरा OG कार्ड जेनरेटर — सब Claude बैकएंड पर। मॉडल की क्वालिटी इतनी अच्छी है कि मैं लगभग 85% समय पहले ड्राफ्ट पर भरोसा करता हूं। **Claude का वॉयस और ब्रांड** जज्मेंट अंडररेटेड है। जब मैं कुछ ऐसा लिखता हूं जो मेरी तरह लगना चाहिए, तो मैंने पाया कि Claude + एक विस्तृत सिस्टम प्रॉम्प्ट मेरे द्वारा टेस्ट किए गए हर दूसरे मॉडल से बेहतर प्रदर्शन करता है। ट्रिक एक विशिष्ट, राय वाला सिस्टम प्रॉम्प्ट है — "एक कैजुअल टोन में लिखो" नहीं बल्कि "Alejandro की तरह लिखो: सीधा, प्रैक्टिशनर, कोई हाइप नहीं, नंबर्ड, फर्स्ट-पर्सन, ईमानदार चेतावनियों के साथ।" मैं Claude Max के लिए भुगतान करता हूं। यह मेरा सबसे ज़्यादा उपयोग किया जाने वाला सब्सक्रिप्शन है, और ROI की कोई तुलना नहीं है। ## 2. Cursor — जहां TypeScript लिखा जाता है Cursor IDE है। मैंने लगभग एक साल पहले VS Code से स्विच किया और पीछे मुड़कर नहीं देखा। Tab कम्पलीशन इतनी तेज़ है कि यह वास्तव में बदल देती है कि मैं कोड कैसे लिखता हूं — मैं एक उच्च स्तर पर सोचता हूं और Cursor को सिंटैक्टिक बॉयलरप्लेट संभालने देता हूं। AI सुझावों के लिए diff व्यू साफ है। मल्टी-फाइल कॉन्टेक्स्ट विंडो का मतलब है कि मैं इसे एक फंक्शन अपडेट करने के लिए कह सकता हूं और यह कॉलर्स को भी अपडेट करता है। मैं आर्किटेक्चर डिसीज़न के लिए Cursor का उपयोग नहीं करता। मैं अभी भी उन्हें कागज़ पर या Claude में स्केच करता हूं। लेकिन एक बार डिज़ाइन स्पष्ट हो जाए, Cursor डिज़ाइन से चलने वाले TypeScript तक सबसे तेज़ रास्ता है। सबसे बड़ा अनलॉक: Cursor + Claude Code पैरेलल में। मैं हाई-लेवल प्लानिंग और एजेंट ऑर्केस्ट्रेशन के लिए Claude Code का उपयोग करता हूं; इम्प्लीमेंटेशन डिटेल वर्क के लिए Cursor। वे कॉन्फ्लिक्ट नहीं करते — वे अलग-अलग ऊंचाइयों को कवर करते हैं। ## 3. Airtable — डेटा बैकबोन मेरा हर AI एजेंट पढ़ने और लिखने के लिए एक जगह चाहता है। वह जगह [Airtable](/recommends/airtable) है। यहाँ बताया गया है कि मैं दोनों बिजनेस में इसका उपयोग किस लिए करता हूं: - **कंटेंट क्यू** — प्रगति में पोस्ट और न्यूज़लेटर टॉपिक्स, स्टेटस ट्रैकिंग के साथ - **बुकिंग रिकॉर्ड** — बुकिंग सिस्टम से सिंक किए गए Pickleland कोर्ट रिज़र्वेशन - **एफिलिएट लिंक कैटलॉग** — 105+ स्लग्स जेनरेशन के समय कंटेंट एजेंट मेटाडेटा पढ़ता है - **एजेंट ऑडिट लॉग** — क्या चला, कब, क्या प्रोड्यूस किया, कोई एरर API साफ और तेज़ है। Airtable हाई-थ्रूपुट वर्कलोड के लिए डेटाबेस नहीं है — लेकिन एजेंट साइड-टेबल्स, रिव्यू क्यू, और ह्यूमन-इन-द-लूप अप्रूवल वर्कफ्लो के लिए, यह बिल्कुल सही टूल है। विजुअल इंटरफेस का मतलब है कि मैं बिना क्वेरी लिखे किसी भी टेबल को इंस्पेक्ट कर सकता हूं। मैंने जो विकल्प आज़माया: Notion डेटाबेस। Notion API धीमा है और डेटा मॉडल एजेंट रीड के लिए अधिक बोझिल है। एजेंट-एडजेसेंट डेटा के लिए Airtable जीतता है। ## 4. Kit — न्यूज़लेटर और ईमेल ऑटोमेशन मैंने [Kit](/recommends/convertkit) (पहले ConvertKit) पर एक कारण से स्विच किया: API वास्तव में अच्छा है। अधिकांश ईमेल प्लेटफॉर्म अपने API को एक बाद का विचार मानते हैं। Kit इसे फर्स्ट-क्लास प्रोडक्ट के रूप में मानता है। मैं ब्रॉडकास्ट बना सकता हूं, शेड्यूल सेंड कर सकता हूं, टैग के आधार पर सेगमेंट कर सकता हूं, और एनालिटिक्स पढ़ सकता हूं — सब प्रोग्रामेटिकली। मेरा न्यूज़लेटर एजेंट बिना मेरे कंपोज़र को छुए यह सब करता है। Kit-विशिष्ट चीज़ें जो मैं उपयोग करता हूं: - **Broadcasts API** — मेरा एजेंट हर हफ्ते प्रोग्रामेटिकली शेड्यूल्ड ब्रॉडकास्ट बनाता है - **सब्सक्राइबर टैगिंग** — मैं व्यवहार से सब्सक्राइबर को टैग करता हूं (आखिरी 5 सेंड खोले = "एंगेज्ड"; 60 दिनों में नहीं खोला = "एट-रिस्क") और मेरा एजेंट सेगमेंट को उसी के अनुसार टारगेट करता है - **फॉर्म्स + लैंडिंग पेजेज़** — साफ, तेज़ लोडिंग, नो-कोड। मैं इन्हें प्रोग्रामेटिकली हैंडल नहीं करता; ये बस काम करते हैं। अगर आप Mailchimp या किसी लीगेसी प्लेटफॉर्म पर हैं: माइग्रेशन इसके लायक है। Mailchimp के API को वह करने के लिए तीन अतिरिक्त कॉल चाहिए जो Kit एक में करता है। ## 5. Cloudflare Workers — जहां एजेंट रहते हैं हर शेड्यूल्ड एजेंट Cloudflare Workers पर चलता है। पिच: ग्लोबल एज डिप्लॉयमेंट, फ्री टियर पर ज़ीरो कोल्ड स्टार्ट, और एक cron ट्रिगर सिस्टम जो वास्तव में काम करता है। मेरे एजेंट को सर्वर की ज़रूरत नहीं। उन्हें एक शेड्यूल्ड फंक्शन चाहिए जो विश्वसनीय रूप से चले, एक्सटर्नल API कॉल कर सके, और मेरे स्केल पर लगभग कुछ भी न लगे। Workers जवाब है। Workers पर जो मेरे पास चल रहा है: - **कंटेंट पाइपलाइन** — EN पोस्ट जेनरेट करता है, 12 ट्रांसलेशन में फैलाता है, OG कार्ड जेनरेट करता है - **न्यूज़लेटर एजेंट** — साप्ताहिक सेंड को ड्राफ्ट और शेड्यूल करता है - **Facebook Ads मॉनिटर** — परफॉर्मेंस पढ़ता है, अंडरपरफॉर्मर को फ्लैग करता है, मुझे नोटिफाई करता है - **Pickleland ऑक्युपेंसी रिपोर्टर** — बुकिंग डेटा पढ़ता है, मुझे दैनिक सारांश भेजता है इन सब की कुल मासिक लागत: ~$5। यह पेड Workers प्लान है। एजेंट cron शेड्यूल पर विश्वसनीय रूप से चलते हैं; मेरे पास छह महीनों में एक फेल हुआ (Meta की तरफ से DNS समस्या, मेरी नहीं)। ## मैंने क्या काटा और क्यों **Zapier** — Workers + संबंधित प्लेटफॉर्म APIs सीधे से बदल दिया। Zapier लेटेंसी जोड़ता है, स्केल पर ज़्यादा लागत करता है, और Workers जैसी कोई सीलिंग नहीं है। **ChatGPT** — Claude का कॉन्टेक्स्ट विंडो, टूल यूज़, और सिस्टम प्रॉम्प्ट क्वालिटी ऑपरेटर यूज़ केस के लिए बेहतर है। मैं त्वरित वेब सर्च के लिए ChatGPT टैब रखता हूं लेकिन इस पर बिल्ड नहीं करता। **Webflow** — अपनी साइट को Astro + Cloudflare Pages पर मूव किया। ज़्यादा कंट्रोल, बेहतर परफॉर्मेंस, बिल्ड प्रोसेस जिसे मैं स्क्रिप्ट कर सकता हूं। **Grammarly** — Claude वो सब करता है जो Grammarly करता है और मेरी आवाज़ को बेहतर रखता है। ## ऑपरेटर का निष्कर्ष ऊपर दिए गए पांच टूल्स न सबसे नए हैं और न सबसे ज़्यादा चर्चित। ये वो हैं जो दो अलग-अलग बिजनेस में दैनिक प्रोडक्शन उपयोग के तहत टिके रहे। अपने स्टैक में कोई नया टूल जोड़ने से पहले पूछें: इन पांच में से कौन यह काम कर सकता है? आप हैरान होंगे कितनी बार जवाब आता है "उनमें से एक पहले से कर सकता है।" --- ## आपका AI एजेंट प्रोडक्शन में बार-बार क्यों विफल होता है (और इसे कैसे ठीक करें) Source: https://alejandrorioja.com/hi/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-28 Tags: AI Agents TL;DR: अधिकांश प्रोडक्शन एजेंट विफलताएं पांच कारणों से होती हैं: एज केस को हैंडल न करने वाले भंगुर प्रॉम्प्ट, क्षणिक API एरर के लिए रिट्राई लॉजिक की कमी, क्या टूट रहा है यह देखने के लिए ऑब्जर्वेबिलिटी नहीं, कोई एग्जिट कंडीशन न होने वाले रनअवे लूप, और पर्याप्त अस्पष्ट टूल डेफिनेशन जिससे मॉडल गलत को चुनता है। सभी पांच मॉडल या फ्रेमवर्क बदले बिना ठीक करने योग्य हैं। ## विषय सूची _जून 2026 में अपडेट किया गया।_ **TL;DR:** अधिकांश प्रोडक्शन एजेंट विफलताएं पांच कारणों से होती हैं: एज केस को हैंडल न करने वाले भंगुर प्रॉम्प्ट, क्षणिक API एरर के लिए रिट्राई लॉजिक की कमी, क्या टूट रहा है यह देखने के लिए ऑब्जर्वेबिलिटी नहीं, कोई एग्जिट कंडीशन न होने वाले रनअवे लूप, और पर्याप्त अस्पष्ट टूल डेफिनेशन जिससे मॉडल गलत को चुनता है। सभी पांच मॉडल या फ्रेमवर्क बदले बिना ठीक करने योग्य हैं। **[ऑपरेटर की नज़र]** मेरे पास प्रोडक्शन में 30+ एजेंट हैं। मुझे ये सभी विफलताएं हुई हैं। जिन्होंने सबसे ज़्यादा समय जलाया वे विदेशी नहीं थे — वे उबाऊ इन्फ्रास्ट्रक्चर विफलताएं थीं जो मुझे लगती थीं कि मैंने संभाल ली हैं। ## विफलता 1: एज केस इनपुट पर टूटने वाले भंगुर प्रॉम्प्ट आपके टेस्ट केस पर काम करने वाला प्रॉम्प्ट उन इनपुट पर विफल होगा जिनकी आपने उम्मीद नहीं की थी। यह मॉडल लिमिटेशन नहीं है — यह इंस्ट्रक्शन लेखन समस्या है। **लक्षण:** एजेंट बकवास आउटपुट उत्पन्न करता है, गलत टूल कॉल करता है, या जब इनपुट थोड़ा अलग होता है तो मलफॉर्म्ड JSON आउटपुट करता है। **मूल कारण:** आपका सिस्टम प्रॉम्प्ट केवल हैप्पी पाथ का वर्णन करता है। यह मॉडल को नहीं बताता कि डेटा गायब, मलफॉर्म्ड, या अस्पष्ट होने पर क्या करना है। **सुधार:** अपने सिस्टम प्रॉम्प्ट में स्पष्ट एज केस हैंडलिंग जोड़ें: ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` मॉडल एज केस के लिए स्पष्ट निर्देशों का विश्वसनीय रूप से पालन करता है। गलती यह मानना है कि यह गंदे केस को संभालने के लिए हैप्पी-पाथ निर्देशों को सामान्यीकृत करेगा। ## विफलता 2: क्षणिक API एरर के लिए कोई रिट्राई लॉजिक नहीं आपका एजेंट जो भी बाहरी API कॉल करता है वह किसी न किसी समय विफल होगा। Claude API, Meta Graph API, आपका डेटाबेस — सभी 5xx एरर लौटाते हैं, टाइमआउट होते हैं, या रेट-लिमिट होते हैं। अगर आपके एजेंट में रिट्राई लॉजिक नहीं है, तो एक क्षणिक एरर पूरे रन को मार देता है। **लक्षण:** एजेंट रन अलग-अलग चरणों में बेतरतीब ढंग से विफल होते हैं। लॉग 503 या 429 दिखाते हैं, कोई फॉलो-अप प्रयास नहीं। **सुधार:** प्रत्येक बाहरी कॉल को एक्सपोनेंशियल-बैकऑफ रिट्राई में लपेटें: ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` एक्सपोनेंशियल बैकऑफ के साथ तीन रिट्राई ~99% क्षणिक विफलताओं को हैंडल करता है। इसे हर बाहरी कॉल में जोड़ें और आपकी आधी यादृच्छिक विफलताएं गायब हो जाएंगी। ## विफलता 3: कोई ऑब्जर्वेबिलिटी नहीं — आप नहीं देख सकते कि क्या टूट रहा है यह प्रोडक्शन में सबसे आम विफलता मोड है और सबसे अधिक समय डिबग करने में लगाने वाला: एजेंट चुपचाप विफल होता है या गलत आउटपुट देता है, और आपको पता नहीं होता कि चेन में कहाँ गलत हुआ। **लक्षण:** आप जानते हैं कि कुछ गड़बड़ है लेकिन चरण की पहचान नहीं कर सकते। आप `console.log` स्टेटमेंट जोड़ते हैं और पुनः उत्पन्न करने की कोशिश में मैन्युअल रूप से फिर से चलाते हैं। **सुधार:** प्रत्येक चरण पर संरचित लॉगिंग, एक रन ID के साथ जो पूरे एग्जीक्यूशन को ट्रेस करता है: ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` अगर आप Cloudflare Workers पर हैं, तो ये लॉग Logpush या Workers Tail में जाते हैं। अगर स्थानीय रूप से या VPS पर चल रहे हैं, तो एक लॉग एग्रीगेटर में पाइप करें। संरचित JSON का मतलब है कि आप `runId` द्वारा फ़िल्टर करके देख सकते हैं कि एकल रन में बिल्कुल क्या हुआ। ## विफलता 4: बिना एग्जिट कंडीशन के रनअवे लूप एजेंटिक लूप — जहां मॉडल टूल कॉल करता है और कंडीशन पूरी होने तक इटरेट करता है — हमेशा चल सकते हैं अगर वह कंडीशन कभी पूरी नहीं होती या मॉडल इसे गलत पहचानता है। **लक्षण:** टाइमआउट से पहले एजेंट API लागत में सैकड़ों डॉलर खर्च करता है। या यह बिना कोई प्रगति किए बार-बार एक ही टूल कॉल चलाता है। **सुधार:** हमेशा एक हार्ड इटरेशन कैप और प्रगति जांच रखें: ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` यह "बहुत लंबे समय तक चला" और "एक ही जगह घूमता रहा" दोनों विफलता मोड को पकड़ता है। कैप हैप्पी पाथ के लिए पर्याप्त उदार होनी चाहिए लेकिन ब्लास्ट रेडियस सीमित करने के लिए पर्याप्त तंग। ## विफलता 5: अस्पष्ट टूल डेफिनेशन जिसे मॉडल गलत हल करता है अगर आप मॉडल को ओवरलैपिंग डिस्क्रिप्शन वाले दो टूल देते हैं, तो यह कभी-कभी गलत को कॉल करेगा। यह विशेष रूप से `search_database` बनाम `get_record` या `send_email` बनाम `create_draft` जैसे टूल के साथ सामान्य है। **लक्षण:** मॉडल टूल की सही श्रेणी को कॉल करता है लेकिन गलत विशिष्ट को चुनता है। या यह गलत संदर्भ में टूल कॉल करता है (जब केवल पढ़ना उचित था तब राइट टूल का उपयोग करना)। **सुधार:** टूल डिस्क्रिप्शन को परस्पर अनन्य बनाएं और स्पष्ट रूप से "कब इसका उपयोग न करें" जोड़ें: ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` "X होने पर उपयोग न करें" क्लॉज वह हिस्सा है जिसे अधिकांश लोग छोड़ देते हैं। यह सबसे महत्वपूर्ण हिस्सा है। मॉडल सकारात्मक डिस्क्रिप्शन से अनुमान लगाने की तुलना में स्पष्ट नकारात्मक बाधाओं का पालन करने में बेहतर है। ## एक और बात: खराब इनपुट पर अपने एजेंट का परीक्षण करें अधिकांश एजेंट केवल साफ, हैप्पी-पाथ इनपुट पर परीक्षण किए जाते हैं। प्रोडक्शन में गंदे इनपुट होते हैं: खाली स्ट्रिंग, null फ़ील्ड, Unicode एज केस, API रिस्पॉन्स जो 200 लौटाते हैं लेकिन अप्रत्याशित स्कीमा के साथ। एक टेस्ट सूट जोड़ें जो स्पष्ट रूप से परीक्षण करे: - खाली या null इनपुट - अधिकतम अपेक्षित लंबाई पर इनपुट - विशेष अक्षर या गैर-ASCII टेक्स्ट वाले इनपुट - बाहरी API अप्रत्याशित रिस्पॉन्स शेप लौटाते हैं अगर आपका एजेंट इनमें से किसी पर टूटता है, तो इसे लाइव होने से पहले ठीक करें। प्रोडक्शन वातावरण आपके द्वारा की गई हर धारणा को खोजेगा। ## ऑपरेटर का निष्कर्ष प्रोडक्शन में अधिकांश एजेंट विफलताएं इन्फ्रास्ट्रक्चर समस्याएं हैं जो मॉडल समस्याओं के रूप में छुपी हैं। मॉडल स्विच करने से पहले, अपने प्रॉम्प्ट में रिट्राई, संरचित लॉगिंग, लूप कैप और स्पष्ट एज केस हैंडलिंग जोड़ें। अस्पष्ट टूल डेफिनेशन ठीक करें। फिर खराब इनपुट पर टेस्ट करें। मॉडल को दोष देने से पहले यह सब करें — मेरे अनुभव में, मॉडल आमतौर पर बदलने की ज़रूरत वाली आखिरी चीज़ है। --- ## 15 मिनट में अपना पहला AI एजेंट कैसे बनाएं Source: https://alejandrorioja.com/hi/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-18 Tags: AI Agents TL;DR: आपको किसी फ्रेमवर्क, कोर्स या पीएचडी की ज़रूरत नहीं है। आपको चाहिए Node.js, Anthropic SDK, और 25 लाइनें TypeScript की। यह ट्यूटोरियल एक असली, काम करने वाला एजेंट बनाता है — एक संरचित कंटेंट सारांशकर्ता जिसे आप उसी सेशन में Cloudflare पर डिप्लॉय कर सकते हैं। एकमात्र पूर्वापेक्षा है एक मुफ़्त API की। ## विषय-सूची _जून 2026 में अपडेटेड।_ **TL;DR:** आपको किसी फ्रेमवर्क, कोर्स या पीएचडी की ज़रूरत नहीं है। आपको चाहिए Node.js, Anthropic SDK, और 25 लाइनें TypeScript की। यह ट्यूटोरियल एक असली, काम करने वाला एजेंट बनाता है — एक संरचित कंटेंट सारांशकर्ता जिसे आप उसी सेशन में Cloudflare पर डिप्लॉय कर सकते हैं। एकमात्र पूर्वापेक्षा है एक मुफ़्त API की। **[ऑपरेटर का नज़रिया]** AI से ऑटोमेट करना चाहने वाले संस्थापकों से मैं सबसे आम जो बात सुनता हूँ वह है "मुझे पहले और सीखना होगा"। नहीं, ऐसा नहीं है। एजेंट पैटर्न सरल है, और इसे समझने का सबसे तेज़ तरीका है एक बनाना। अगर मैं आज शून्य से शुरू करता तो जो सटीक रास्ता अपनाता, वह यहाँ है। ## क्यों ज़्यादातर "AI एजेंट बनाएं" ट्यूटोरियल आपको निराश करते हैं वे या तो Python का इस्तेमाल करते हैं (ML इंजीनियरों के लिए ठीक, बाकी सबके लिए रुकावट), या असली कोड को LangChain जैसे फ्रेमवर्क के पीछे छिपा देते हैं, या कुछ इतना अमूर्त बना देते हैं कि उसे आपके असली काम से जोड़ा ही न जा सके। यह ट्यूटोरियल तीन चीज़ें अलग तरह से करता है: 1. **केवल TypeScript** — अगर आपने कभी JavaScript लिखा है, तो आप इसे फ़ॉलो कर सकते हैं 2. **कोई फ्रेमवर्क नहीं** — आप कोड की हर वह लाइन देखेंगे जो मॉडल को छूती है 3. **एक उपयोगी आउटपुट** — आप एक संरचित सारांशकर्ता बनाएंगे जिसे आप वाकई ग्राहक ईमेल, समीक्षाओं या मीटिंग नोट्स पर इस्तेमाल कर सकते हैं ## आप क्या बना रहे हैं एक **कंटेंट सारांशकर्ता एजेंट**: कोई भी टेक्स्ट ब्लॉक पेस्ट करें, और एक सुसंगत प्रारूप में संरचित सारांश वापस पाएं। एक HTTP अनुरोध अंदर, एक साफ़ सारांश बाहर। इसे पहले प्रोजेक्ट के रूप में क्यों: यह पैटर्न — सिस्टम प्रॉम्प्ट + उपयोगकर्ता इनपुट → संरचित आउटपुट — हर उस एजेंट की नींव है जिसे मैं चलाता हूँ। सिस्टम प्रॉम्प्ट बदलिए और आपके पास एक प्रश्न-उत्तरकर्ता, एक टोन पुनर्लेखक, एक वर्गीकरणकर्ता, या एक मसौदा जनरेटर होगा। इसे एक बार सीख लीजिए और आपने वह 80% सीख लिया जो प्रोडक्शन एजेंट असल में करते हैं। ## पूर्वापेक्षाएँ (2 मिनट) - **Node.js 18+** — `node --version` से जाँचें। ज़रूरत हो तो nodejs.org से इंस्टॉल करें। - **एक Anthropic API की** — [Claude](/recommends/claude) पर साइन अप करें, कंसोल से एक की लें। फ्री टियर काम करता है। - एक टर्मिनल और एक टेक्स्ट एडिटर। कोई Docker नहीं। कोई वर्चुअल एनवायरनमेंट नहीं। कुछ भी `pip install` नहीं। ## चरण 1: प्रोजेक्ट बनाएं (2 मिनट) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` एजेंट को आसानी से चलाने के लिए `package.json` में एक स्क्रिप्ट जोड़ें: ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## चरण 2: एजेंट लिखें (5 मिनट) `agent.ts` बनाएं और यह पेस्ट करें: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## चरण 3: इसे चलाएं (1 मिनट) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` अपेक्षित आउटपुट: ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` यह एक काम करने वाला AI एजेंट है। असली इनपुट, कस्टम सिस्टम प्रॉम्प्ट, संरचित आउटपुट। पूरी चीज़ 30 लाइनों का कोड है। ## चरण 4: इसे अपने उपयोग के लिए अनुकूलित करें सिस्टम प्रॉम्प्ट ही एकमात्र चीज़ है जो इस एजेंट को आपका बनाती है। यहाँ तीन तुरंत बदलकर इस्तेमाल किए जा सकने वाले विकल्प हैं: **ग्राहक समीक्षा वर्गीकरणकर्ता:** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: