येलो ब्रिक रोड पर मौत से बचना

@joeschmidtiv
अंग्रेज़ी2 माह पहले · 27 मई 2026
1.2M
1.6K
195
85
4.7K

TL;DR

जहाँ AI लैब्स हॉरिजॉन्टल टूल्स पर हावी हैं, वहीं स्टार्टअप्स जटिल, मल्टी-स्टेप इंडस्ट्री कार्यों और प्रोप्रायटरी डेटा फ्लाईव्हील्स को संभालने वाले वर्टिकल 'सिस्टम्स ऑफ़ वर्क' बनाकर सफल हो सकते हैं।

क्यों एप्लिकेशन लेयर खत्म नहीं हुई है

यह सवाल मुझे फाउंडर्स और संभावित कर्मचारियों से लगातार मिल रहा है: क्या AI एप्लिकेशन लेयर बनाने के लिए कुछ बचा भी है, या OpenAI और Anthropic सब कुछ खत्म कर देंगे?

इस सवाल के पीछे AI से जुड़ा एक खास तरह का पागलपन है। कुछ लोगों ने निष्कर्ष निकाला है कि स्थायी रूप से टिकने के लिए एकमात्र जगहें या तो किसी बड़ी लैब के अंदर हैं या फिर रोबोटिक्स, हार्डटेक या इसी तरह के क्षेत्रों में फ्रंटियर पर काम करना है – सैद्धांतिक रूप से वो सब जो "लैब्स छू नहीं सकतीं।" अगर सॉफ्टवेयर का हर टुकड़ा खत्म होने वाला है, चाहे Codex या Claude सीधे काम सोख ले, या भविष्य का कोई मॉडल जो आपकी बनाई चीज़ को बेकार कर दे, तो भागो!

सुनो, मैं लगभग किसी से भी ज्यादा AI मैक्सिमलिस्ट हूं, और मुझे लगता है कि वे आधे सही हैं। लैब्स वास्तव में एप्लिकेशन सरफेस के एक बड़े हिस्से पर कब्जा करने आ रही हैं। लेकिन "एप्लिकेशन लेयर" सिर्फ एक समान अवसर नहीं है। सही ढांचा यह है कि आप येलो ब्रिक रोड पर हैं या ओज़ में कहीं और।

येलो ब्रिक रोड उस रास्ते का हमारा संक्षिप्त नाम है जिस पर लैब्स चल रही हैं, जहां वे असाधारण संसाधन लगा रही हैं। लैब्स कोड जनरेशन, लेखन, या इमेज-क्रिएशन जैसी समस्याओं के लिए सबसे उपयुक्त होने का कारण यह है कि ये समस्याएं रॉ मॉडल क्षमता से बेहतर होती हैं: प्री-ट्रेनिंग और पोस्ट-ट्रेनिंग पर खर्च किया गया हर डॉलर उत्पाद की गुणवत्ता में सुधार करता है। इस बीच, ओज़ का बाकी हिस्सा अधिक जटिल, अक्सर वर्टिकल, समस्याओं से भरा है, जो किसी बिजनेस यूजर को मानक टूल्स और कंप्यूटर उपयोग तक पहुंच वाला एक क्षैतिज उपकरण देने जितना सरल नहीं है। मूल्य अंतर्निहित मॉडल की रॉ क्षमता (हालांकि यह अभी भी महत्वपूर्ण है!) की तुलना में उसके चारों ओर बने स्कैफोल्डिंग से अधिक आता है जो आउटपुट को एक विशिष्ट उद्योग के अंदर भरोसेमंद, अनुपालन योग्य और संचालन योग्य बनाता है।

हम इसे रियल टाइम में होते देख रहे हैं क्योंकि OpenAI और Anthropic प्रभावी रूप से बाजार को बता रहे हैं कि वे एक सामान्य AI सहकर्मी के साथ हर समस्या का समाधान नहीं कर सकते। उन्होंने एंटरप्राइज़ के लिए अपने मॉडल्स को कॉन्फ़िगर और कस्टमाइज़ करने के लिए पूरी कंपनियां बनाने हेतु बड़े पैमाने पर फॉरवर्ड-डिप्लॉइड जॉइंट वेंचर्स की घोषणा की है। आप उन कार्यक्रमों में अरबों नहीं डालते अगर आपको लगता है कि अगला मॉडल रिलीज़ इसका ध्यान रखेगा।

तो अगर आप AI ऐप्स बनाकर अमीर बनना चाहते हैं – येलो ब्रिक रोड से बचें और ओज़ में कहीं और बनाएं। यहां हमने वो सीखा है जो काम करता है, और हमारे कुछ पोर्टफोलियो फाउंडर्स ने भी वही सीखा है।

येलो ब्रिक रोड

अगर आप कोई कंपनी शुरू कर रहे हैं, तो येलो ब्रिक रोड जाने का सबसे स्पष्ट रास्ता है, लेकिन यह सबसे खतरनाक भी है। एक उच्च प्रदर्शन वाला मॉडल लें, इसमें कुछ ऑफ-द-शेल्फ कनेक्टर (जैसे G Drive, Slack, Salesforce, Notion, GitHub) लगाएं, और उसके ऊपर किसी तरह का एजेंटिक ऑर्केस्ट्रेशन लेयर शिप करें। जादू!

इसमें समस्या यह है कि लैब्स Cowork और Codex के साथ यही कर रही हैं। जाहिर है, उनके पास मॉडल है, जो उन्हें बेहतर मार्जिन, नियंत्रण, और अपने डाउनस्ट्रीम किसी भी व्यक्ति पर मूल्य निर्धारण शक्ति लगाने की क्षमता देता है। लेकिन शायद सबसे महत्वपूर्ण बात यह है कि उनके पास वास्तुशिल्प विकल्प भी हैं जो परिभाषित करते हैं कि उनके उत्पाद किस चीज़ को अच्छी तरह से हल करने के लिए बने हैं। वे अब तक मॉडल प्लस टूल कॉल्स पैटर्न के बारे में जानबूझकर रहे हैं, और यह ठीक वही है जो सड़क पर क्षैतिज कम-चरण वाले काम के लिए आवश्यक है। भले ही कोई स्टार्टअप किसी तरह Codex या Claude Code से बेहतर प्रदर्शन कर सके, लैब्स के पास विशाल वितरण शाखाएं और AI में सबसे बड़ा ब्रांड हेलो है।

यदि आप एक AI ऐप कंपनी हैं जो उसी कनेक्टर्स, उसके नीचे कोई सब-एजेंट या कॉन्फ़िगरेशन, और कोई वितरण नहीं, के साथ वही प्लेबुक चला रहे हैं, तो आप संभवतः कहीं न जाने वाली सड़क पर चल रहे हैं।

ओज़ का बाकी हिस्सा

स्टार्टअप्स के लिए सब कुछ अंधकारमय और निराशाजनक नहीं है। येलो ब्रिक रोड के बाहर एक बहुत बड़ा अवसर है, जहां स्टार्टअप्स के पास अपने ग्राहक का मालिक बनने और जटिल समस्याओं को हल करने का स्पष्ट रास्ता है।

ये व्यवसाय एजेंटिक अनुभव बना रहे हैं जहां मॉडल टूल्स, ऑटोमेशन और इंटीग्रेशन (पढ़ें: सॉफ्टवेयर) के एक जटिल जाल के माध्यम से बुना जाता है, जिसके परिणामस्वरूप इनमें से अधिकांश स्टार्टअप डिफ़ॉल्ट रूप से वर्टिकल होते हैं। वे मल्टी-स्टेप और मल्टी-प्लेयर काम पर ध्यान केंद्रित कर सकते हैं, भूमिका- और वर्टिकल-विशिष्ट कार्यों के लिए सब-एजेंट के साथ, जहां Anthropic और OpenAI क्षैतिज प्लेटफॉर्म के साथ नहीं पहुंच सकते: सिस्टम से संदर्भ इकट्ठा करना, फिर कई मनुष्यों के माध्यम से रूट करना जिन्हें विभिन्न चरणों में अनुमोदन करना होता है। इसमें अक्सर एक या अधिक लीगेसी सिस्टम शामिल होते हैं, यह नियतात्मक परिणामों की ओर जाता है जहां अस्पष्टता स्वीकार्य नहीं है, और कभी-कभी यह किसी मूल्यवान व्यावसायिक परिणाम से जुड़ा होता है। लैब्स समझती हैं कि ये समस्याएं कितनी मूल्यवान हैं: यही कारण है कि वे अपने स्वयं के आउटसोर्स कॉन्फ़िगरेशन शॉप बना रही हैं, और यही कारण है कि रीइन्फोर्समेंट लर्निंग व्यवसायों का एक पूरा अपमार्केट वर्ग मौजूद है।

ओज़ का बाकी हिस्सा विज़ार्ड के कब्जे में क्यों नहीं होगा

उपरोक्त की प्रतिक्रिया यह होगी कि अब तक, मॉडल्स/लैब्स में सुधार के खिलाफ दांव लगाना काफी बुरा व्यापार रहा है। वे संभवतः बेहतर होते रहेंगे और अंततः इन एप्लिकेशन लेयर व्यवसायों द्वारा सेवा किए गए बाजार को खा जाएंगे।

लैब्स निश्चित रूप से सुधरेंगी, लेकिन मैं तर्क दूंगा कि ओज़ का बाकी हिस्सा समय के साथ अपनी रक्षा करने के कुछ तरीके हैं:

डेटा और लर्निंग फ्लाईव्हील:

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

भले ही ग्राहक डेटा का उपयोग ग्राहकों के बीच नहीं किया जा सकता, एप्लिकेशन कंपनियां ग्राहक समस्या प्रकारों में पैटर्न पहचान का लाभ उठाने में सक्षम होंगी, और भविष्य की समस्याओं के लिए सही आर्किटेक्चर को सूचित करने के लिए इसका उपयोग करेंगी। एक कंपनी जिसने अपने एजेंटों को सौ कानूनी रेडलाइन, एक हजार बीमा अंडरराइटिंग साइकिल, या दस हजार SDR अभियानों के माध्यम से चलाया है, उसने समस्या के आकार को इस तरह से आंतरिक कर लिया है जिसे अगला प्रवेशकर्ता पहली बार एक नया एजेंट शुरू करके दोहरा नहीं सकता।

एक क्षैतिज एजेंट सिद्धांत रूप में वही सीखने का बुनियादी ढांचा बना सकता है। इसके न करने का कारण, शुद्ध फोकस के अलावा, UX है: इस तरह के ज्ञान को कैप्चर करना पूरी तरह से उन वर्कफ़्लो सतहों पर निर्भर करता है जो आप उपयोगकर्ता को देते हैं, और वर्टिकल खिलाड़ी उन सतहों को ठीक उसी के आसपास आकार दे सकते हैं जो उनके वर्कफ़्लो को सतह पर लाने की आवश्यकता है। क्षैतिज उपकरण ऐसा नहीं कर सकते। eval सेट, लेबल किए गए आउटपुट, और एज-केस टैक्सोनॉमी एक वर्टिकल-विशिष्ट डेटा फ्लाईव्हील में संयोजित हो सकते हैं जो फाइन-ट्यूनिंग को ईंधन दे सकते हैं जिसे अगला प्रवेशकर्ता तुलनीय उत्पादन एक्सपोजर के बिना उत्पन्न नहीं कर सकता। यह संभव है या नहीं यह डेटा अधिकारों, संचित उत्पादन एक्सपोजर की मात्रा, और ग्राहक अनुबंधों की संरचना पर निर्भर करता है, लेकिन पैटर्न पहचान बहरहाल अर्जित होती है।

मॉडल परिवर्तनशीलता और जटिलता का प्रबंधन: लैब्स पहले से ही आंतरिक रूप से रूटिंग कर रही हैं — विभिन्न अनुरोधों के लिए विभिन्न मॉडल क्लास, हुड के नीचे ensembles। वे जो नहीं कर सकते हैं वह विक्रेताओं के बीच रूट करना है, या किसी विशिष्ट उप-कार्य के लिए प्रतियोगी के मॉडल का मूल्यांकन करना है, या संकीर्ण टुकड़े के लिए ओपन-सोर्स फाइन-ट्यून का उपयोग करना है जहां यह वास्तव में सबसे अच्छा है। ओज़ की बाकी कंपनी पूरे मॉडल बाजार में प्रत्येक उप-कार्य के लिए सही मॉडल चुनती है, न कि केवल वही जो इसकी पैरेंट लैब शिप करती है। यह वह काम भी करती है जो कोई नहीं करना चाहता — अपग्रेड पर evals को फिर से चलाना, ग्राहक के एज केस के लिए प्रॉम्प्ट को रीकैलिब्रेट करना, उत्पादन को तोड़े बिना रोल आउट करना — हर बार जब कोई नया मॉडल आता है। लैब्स ग्राहक की ओर से ऐसा नहीं कर रही हैं; वे आपको अपना अगला मॉडल बेचती हैं और आपको माइग्रेट करने के लिए कहती हैं। ओज़ की बाकी कंपनी माइग्रेशन को अवशोषित करती है। ग्राहक को पूरे बाजार में उपलब्ध सर्वश्रेष्ठ बुद्धिमत्ता, साथ ही हर अपग्रेड के माध्यम से निरंतरता मिलती है।

लागत अनुकूलन: हर क्वेरी को Opus 4.7 के माध्यम से चलाना नकारात्मक सकल मार्जिन का सबसे तेज़ रास्ता है। सर्वश्रेष्ठ ओज़ की बाकी कंपनियां मॉडल के स्तरों पर रूट करती हैं — सबसे कठिन कार्यों के लिए फ्रंटियर मॉडल, थोक के लिए मिड-टियर, छोटे कस्टम या फाइन-ट्यून किए गए मॉडल जहां उन्होंने उनका उपयोग करने का अधिकार अर्जित किया है। कुछ अब अपने स्वयं के मॉडल को उसके ऊपर पोस्ट-ट्रेन कर रहे हैं, उन्हें काम के संकीर्ण टुकड़े के लिए अनुकूलित कर रहे हैं जिसकी उनका ग्राहक परवाह करता है और उन्हें फ्रंटियर API कॉल की लागत के एक अंश पर सेवा प्रदान कर रहे हैं। लैब्स फर्श की कीमत तय करती हैं: $X पर उपलब्ध सबसे कम बुद्धिमत्ता। ओज़ की बाकी कंपनी इसके विपरीत बेचती है — बुद्धिमत्ता के उस विशिष्ट स्तर के लिए सबसे कम डॉलर लागत जो वर्कफ़्लो को वास्तव में आवश्यक है। यह तभी संभव है जब आप ठीक से जानते हों कि प्रत्येक उप-कार्य को किस स्तर की आवश्यकता है, जिसे लैब्स संरचनात्मक रूप से हर वर्टिकल में नहीं जान सकती हैं। यह सीधे परिणामों के लिए कम, नियंत्रित कीमतों में तब्दील हो जाता है।

शासन: अपने ग्राहकों के लिए उस वर्टिकल में AI चलाने के तरीके का नियंत्रण तल बनने में काफी मूल्य है — वह स्थान जहां अनुमतियां, ऑडिटिंग, एजेंट को क्या करने की अनुमति है, और एजेंट ने वास्तव में क्या किया, सभी एकाग्र होते हैं। वह नियंत्रण तल उपयोग केस विशिष्ट गार्डरेल से बना है जो उद्योगों और नौकरी के प्रकारों में पूरी तरह से अलग दिखते हैं। क्योंकि वे टूल्स, वर्कफ़्लो, और एजेंट द्वारा छूए गए डेटा को एंड-टू-एंड रखते हैं, वे उन तरीकों से नियतात्मक परिणाम प्रदान कर सकते हैं जिनसे क्षैतिज उपकरण संघर्ष करेंगे। वे वह संस्था भी हैं जो अंतिम खरीदार के लिए नियामक जटिलता को अवशोषित करते हैं — कानून में FRCP और बार नियम, स्वास्थ्य सेवा में HIPAA, वित्त में SEC और FINRA, राज्य बीमा नियम, इत्यादि। एक क्षैतिज खिलाड़ी एक साथ सौ विभिन्न वर्टिकल बने बिना विश्वसनीय रूप से ऐसा नहीं कर सकता। CIO एक ऐसे पार्टनर को चाहते हैं जो संविदात्मक रूप से बताए कि वे अपने द्वारा प्रदान किए जा रहे एजेंटों के लिए अनुपालन संभाल रहे हैं।

ये सब एक ही चीज़ पर वापस आते हैं: फोकस। यह एक वर्टिकल (बीमा, कानूनी, लेखा) या गहराई से किया गया एक कार्य (बिक्री, ग्राहक सहायता, वित्त) हो सकता है। किसी भी तरह, काम को एक टीम की आवश्यकता होती है जो एक ग्राहक सेट पर केंद्रित हो — उसके वर्कफ़्लो, उसके एज केस, उसके नियम। लैब्स उसके लिए नहीं बनी हैं। उन्हें हर जगह, सभी के लिए होना है, जिस तरह उन्होंने पहले स्थान पर येलो ब्रिक रोड बनाया है। वही व्यापार-बंद उन्हें ओज़ के बाकी हिस्से से बाहर रखता है — आप एक साथ हर जगह हो सकते हैं, या आप एक चीज़ में महान हो सकते हैं। दोनों नहीं।

बिक्री एक उदाहरण के रूप में – 11x के तकनीकी CEO से व्यावहारिक सुझाव

आपको व्यवहार में इसके बारे में कैसे सोचना चाहिए? यहां Prabhav Jain, 11x के CEO से कुछ व्यावहारिक सुझाव दिए गए हैं।

परिणामों पर ध्यान दें

एक ऐसी कंपनी बनाने का एक सामरिक रास्ता जो लैब्स के प्रति लचीला है, बस एक विशिष्ट परिणाम से शुरू करना है जिसकी आपके ग्राहक वास्तव में परवाह करते हैं। हमारे लिए वह कंपनियों को अधिक पाइपलाइन उत्पन्न करने में मदद करना था। वहां से प्रश्न सामरिक हो जाते हैं। हम किन गतिविधियों को एंड-टू-एंड रखना चाहते हैं जो वास्तव में पाइपलाइन चलाती हैं? प्रत्येक गतिविधि को कार्यों में विघटित करें। कौन से कार्य एजेंटिक हैं और कौन से नहीं। किन्हें जटिल डोमेन अंतर्दृष्टि की आवश्यकता है और किन्हें नहीं। लैब्स भी वर्कफ़्लो शिप करेंगी, लेकिन जब वर्कफ़्लो में कई चरण, गन्दे इनपुट, व्याख्या करने में कठिन स्थिति, या वास्तविक दुनिया की बाधाएं हों, तो एक बेहतर मॉडल अकेला आपको वहां नहीं ले जाएगा। काम अच्छे पुराने सॉफ्टवेयर इंजीनियरिंग पर आता है, और लैब्स के पास उस सतह पर एक केंद्रित एप्लिकेशन कंपनी पर कोई बढ़त नहीं है। उदाहरण के लिए, यहां कुछ कार्य हैं जिन्हें हम संभालते हैं, कुछ एजेंटिक, और कुछ नहीं: कस्टम सिग्नल पर आधारित लीड प्रॉस्पेक्टिंग, लीड एनरिचमेंट, गहरा खाता अनुसंधान, CRM से संदर्भ लाने वाला, चैनल-विशिष्ट संदेश लेखक, लीड क्वालिफिकेशन एजेंट, और ईमेल डिलीवरेबिलिटी सिस्टम। ये ऐसे कार्य नहीं हैं जिन्हें आप एक बार में कर सकते हैं और इन्हें गहन इंजीनियरिंग की आवश्यकता होती है।

Oz सादृश्य में महत्वपूर्ण अंतर्दृष्टि यह है कि किसी भी वास्तविक वर्कफ़्लो का लगभग आधा हिस्सा जो गैर-एजेंटिक है, उसमें लैब का कोई लाभ नहीं है। मॉडल लेयर के नीचे नियतात्मक सॉफ्टवेयर लिखने में वे आपसे बेहतर नहीं हैं। और जो आधा एजेंटिक है, उसके लिए अभी भी आपको उस परिणाम के खिलाफ मॉडल को ट्यून, ट्रेन और प्रतिबंधित करने की आवश्यकता है जो आप वास्तव में चाहते हैं। डोमेन ज्ञान अक्सर सामान्य प्रशिक्षण डेटा में नहीं बैठता है। वे कौशल वर्टिकल या फंक्शन के लिए जमीन से बनाए जाते हैं, और वर्कफ़्लो में सही समय पर मॉडल में फीड किए जाते हैं। जब हमारे एजेंट फोन पर एक इनबाउंड लीड को क्वालिफाई कर रहे होते हैं, तो मुझे उस विशिष्ट उद्योग और उस व्यक्तित्व के लिए एक अच्छी बिक्री बातचीत क्या है, इस पर प्रशिक्षित होना होगा। वह एप्लिकेशन कंपनी का काम है, और यह संयोजित होता है।

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

उन समस्याओं पर काम करें जहां जटिलता अधिक है

जटिल समस्याएं वह जगह हैं जहां वास्तविक व्यावसायिक मूल्य अनलॉक होता है। अन्यथा आप खुद को एक पतला आवरण बनाते हुए पाएंगे।

किसी भी पर्याप्त जटिल व्यावसायिक समस्या को विघटित करें और गंदगी जल्दी दिखाई देती है। यहां GTM दुनिया का एक उदाहरण है जो तुच्छ लगता है: आपको किसी कंपनी के किसी संपर्क से संपर्क नहीं करना चाहिए यदि वह कंपनी पहले से ही ग्राहक है। यह कुछ भी नहीं बल्कि तुच्छ है। हो सकता है कि आपके CRM में कंपनी से जुड़ा डोमेन हो। दर्जनों सहायक कंपनियों वाली कंपनियों के बारे में क्या? यदि CRM रिकॉर्ड में मूल कंपनी का डोमेन है तो क्या होगा? क्या होगा यदि Salesforce में एक बासी मिलान फ़ील्ड वर्तमान ग्राहक के CRO को एक कोल्ड पिच भेजता है? वास्तविक दुनिया का डेटा गन्दा है। मनुष्य इससे जूझते हैं। मॉडल जादुई रूप से उस बार को साफ नहीं करते हैं। उस गंदगी से आदेश निकालने के लिए समस्या के विशिष्ट आकार के लिए इंजीनियर किए गए उद्देश्य-निर्मित एजेंटों की आवश्यकता होती है, न कि CRM पर इंगित एक सामान्य-उद्देश्य वाले सह-पायलट की। वास्तव में, हमारे पास मौजूद डेटा के आधार पर, हमने महसूस किया है कि हमारे डेटा की गुणवत्ता और ताजगी हमारे ग्राहकों की तुलना में बहुत अधिक है, इसलिए डिफ़ॉल्ट रूप से, हम अपने स्वयं के एंकर करते हैं।

गार्डरेल सिर्फ बुरी चीजों को होने से रोकने के लिए नहीं हैं। इसके लिए आपके ग्राहक आपको भुगतान कर रहे हैं।

गार्डरेल को बहुत कम आंका जाता है। एक ही उत्पाद के अंदर भी, प्रत्येक उपयोग केस को अपनी आवश्यकता होती है। हमारे लिए, एक विनियमित वित्तीय सेवा संभावना एक मिड-मार्केट SaaS ग्राहक से अलग गारंटी की मांग करती है, और वे गारंटी इस बात पर आधारित होती हैं कि एजेंट को कैसे लिखने की अनुमति है, वह किससे संपर्क कर सकता है, वह किस डेटा को छू सकता है, वह कॉल पर क्या कह सकता है और हर निर्णय कैसे लॉग किया जाता है।

एक-आकार-सभी-के-लिए-फिट प्रणाली उस भिन्नता के तहत ढह जाती है। गार्डरेल को प्रति उपयोग केस बनाया जाना है, प्रति ग्राहक कॉन्फ़िगर किया जाना है, और लगातार ऑडिट किया जाना है, और वह काम सीधे एप्लिकेशन कंपनी के साथ है। यही कारण है कि हमारे पास FDE और तकनीकी तैनाती रणनीतिकार हैं जिन्हें प्रत्येक ग्राहक की आवश्यकता के लिए ट्यून करने की आवश्यकता है। एक उदाहरण के रूप में, हमने एक F1000 संस्थान के साथ उनके बड़े SMB ग्राहक आधार के लिए सहमति प्राप्त आउटबाउंड वॉयस करने के लिए काम किया। शुरुआती कुछ पुनरावृत्तियों में कम उठाव दर थी - हमें जल्दी से पुनरावृति करनी थी और सीखना था कि इस विशिष्ट प्रकार के दर्शकों को कॉल के पहले 10 सेकंड में कैसे संलग्न किया जाए। SMB व्यवसाय के मालिक बड़े B2B खरीदारों या उपभोक्ताओं से बहुत अलग व्यवहार करते हैं। अब हम उनके लिए एक दिन में उनके उस सेगमेंट की पूरी बिक्री टीम की तुलना में अधिक बिक्री के अवसर उत्पन्न करते हैं।

बीमा एक उदाहरण के रूप में – FurtherAI के CEO से व्यावहारिक सुझाव

बिक्री एक उदाहरण है। बीमा दूसरा है, और यह एक अलग कोण से एक ही बिंदु बनाता है। यहां बताया गया है कि Aman Gour, FurtherAI के CEO, सड़क से हटकर निर्माण के बारे में कैसे सोचते हैं:

जब हमने वास्तविक बीमा संचालन के अंदर AI तैनात करना शुरू किया, तो हमने एक विशेष धारणा सुनते रहे: मॉडल बुद्धिमत्ता है, और वर्कफ़्लो उसके चारों ओर सिर्फ एक मचान है।

जितना अधिक हमने वाहकों के साथ काम किया, उतना ही हमें विश्वास हो गया कि यह उल्टा है।

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

वह तर्क एक साफ नियम इंजन में नहीं रहता है। यह SOP, प्रबंधक समीक्षा, अंडरराइटिंग दर्शन, वाहक-विशिष्ट भूख, और वर्षों के परिचालन अनुभव में फैला हुआ है। इसका बहुत कुछ ऐसे रूप में नहीं लिखा गया है जिसे एक मॉडल आसानी से पढ़ सके।

यही कारण है कि हम एक शुद्ध एजेंट में विश्वास नहीं करते हैं जो हर बार खरोंच से तर्क करता है, और हम एक कठोर वर्कफ़्लो में विश्वास नहीं करते हैं जो वास्तविकता के गन्दा होते ही टूट जाता है। और इसके बजाय एजेंटिक वर्कफ़्लो का निर्माण कर रहे हैं। वर्कफ़्लो आपको पुनरावृत्ति, ऑडिटेबिलिटी और लागत नियंत्रण देता है। एजेंट परिवर्तनशीलता को संभालता है और जब खुशी का रास्ता टूटता है तो ठीक हो जाता है। मानव उन निर्णयों के लिए लूप में रहता है जहां जवाबदेही मायने रखती है।

पहले दिन, यह मैनुअल काम को स्वचालित करता है। लेकिन समय के साथ, हर वृद्धि एक संकेत बन जाती है, हर अपवाद एक प्रतिक्रिया है और हर मानव सुधार दिखाता है कि रनबुक कहाँ अधूरा था। समय के साथ, वर्कफ़्लो एक स्क्रिप्ट नहीं रह जाता है और वाहक की संचालन स्मृति बनने लगता है। यह वह हिस्सा है जिसे लैब्स तक पहुंचना मुश्किल पाएंगी। वे बेहतर मॉडल और बेहतर सामान्य एजेंट शिप करती रहेंगी, और उन्हें ऐसा करना चाहिए। लेकिन वे किसी वाहक के उत्पादन वर्कफ़्लो के अंदर इतने लंबे समय तक नहीं बैठती हैं कि यह सीख सकें कि एक खाता क्यों बढ़ाया गया, एक जोखिम क्यों अस्वीकार किया गया, या एक अंडरराइटर ने भूख गाइड को ओवरराइड क्यों किया और ऐसा करना सही था।

वह समझ केवल वर्कफ़्लो को, उत्पादन में, हजारों बार चलाने से आती है। पहले दिन आप जो वर्कफ़्लो शिप करते हैं, वह खाई नहीं है। वह लूप जो समय के साथ उत्पादन उपयोग बनाता है, वह खाई है।

हमारे लिए, इसका मतलब है कि सड़क से हटकर निर्माण करना।

आप कैसे तय करते हैं कि आप ओज़ के बाकी हिस्से में हैं या नहीं?

टूल्स-एंड-स्टेप्स टेस्ट: काम में कितने चरण हैं, और इसे समर्थन देने के लिए आपको जो टूल्स बनाने हैं, वे कितने जटिल हैं? Google Drive में एक क्षैतिज AI खोज की तुलना करें — एक क्षमाशील परिणाम के साथ एक टूल के खिलाफ एक कदम, उपयोगकर्ता सारांश पढ़ता है और गलत होने पर फिर से पूछता है — तीन साल के फर्म के पूर्व निर्णय के खिलाफ एक मल्टी-स्टेप कानूनी रेडलाइन से: कई टूल्स पर दर्जनों कदम, आउटपुट जिसे पार्टनर समीक्षा पास करनी होती है और अदालत में बहस करने की आवश्यकता हो सकती है। दोनों "एक एजेंट काम कर रहा है" जैसे दिखते हैं, लेकिन उनमें से केवल एक को उस तरह के गहरे सॉफ्टवेयर की आवश्यकता होती है जिसे बनाने में एक केंद्रित टीम को वर्षों लगते हैं।

सिस्टम टेस्ट: क्या आप एक ऐसी प्रणाली बना रहे हैं जिसके माध्यम से ग्राहक अपना काम चलाता है, या एक उपकरण जो उनके पास पहले से मौजूद सिस्टम के ऊपर बैठता है? सिस्टम वर्कफ़्लो को एंड-टू-एंड रखते हैं — डेटा कैप्चर, शासन, किए गए काम के रिकॉर्ड — और वे वही हैं जो ग्राहक यह बताते समय इंगित करता है कि वास्तविक काम कैसे होता है। दूसरी ओर, उपकरण केवल एक वर्कफ़्लो में बुद्धिमत्ता जोड़ते हैं जिसे ग्राहक पहले से चलाता है। उपकरण का मामला वास्तविक राजस्व उत्पन्न करता है और लैब्स इसे ले सकती हैं क्योंकि ग्राहक ऑर्केस्ट्रेशन लेयर के रूप में आप पर निर्भर नहीं है। उच्च ACV आमतौर पर एक सिस्टम का संकेत है, क्योंकि सिस्टम वास्तविक हेडकाउंट को बदलते हैं और तदनुसार भुगतान प्राप्त करते हैं, लेकिन यह गारंटी नहीं है। अपने आप से पूछें कि क्या ग्राहक को अभी भी आपके टूल की आवश्यकता होगी यदि कोई लैब ऐसा कुछ शिप करती है जो कथित तौर पर आपके साथ सीधे प्रतिस्पर्धा करता है। यदि हाँ, तो आप एक सिस्टम बना रहे हैं। यदि नहीं, तो आप एक उपकरण हैं — भले ही आपका ACV अधिक हो।

हेज फंड / P&L टेस्ट: जहां लैब के प्रदर्शन को बेंचमार्क के खिलाफ आंका जाता है, वहीं ओज़ के बाकी हिस्से के प्रदर्शन को आपके ग्राहक के P&L के खिलाफ आंका जाता है। आपके ग्राहक को इस बात से कोई फर्क नहीं पड़ता कि आपके मॉडल ने SWE-Bench या MMLU पर अच्छा स्कोर किया — उन्हें इस बात से फर्क पड़ता है कि आपके एजेंट ने डील बंद की, अनुबंध को सही ढंग से रेडलाइन किया, या सही पॉलिसी बाइंड की। यदि वे अपने वर्कफ़्लो-विशिष्ट परिणाम पर केंद्रित हैं, न कि एक सामान्य क्षमता स्कोर पर, तो आप ओज़ के बाकी हिस्से में हैं। यदि वे सामान्य क्षमता के लिए भुगतान कर रहे हैं, तो आप उन्हें कुछ ऐसा बेच रहे हैं जो वे Claude या Codex सीट से प्राप्त कर सकते हैं। सर्वश्रेष्ठ एजेंट व्यवसायों को हेज फंड की तरह निष्पादित करने की आवश्यकता होगी — बेंचमार्क स्कोर में नहीं, बल्कि ग्राहक P&L में मापे गए अल्फा पर जीतना।

दोनों जीत सकते हैं (और जीतेंगे)

हम येलो ब्रिक रोड पर और उससे दूर, बड़े पैमाने पर विजेताओं को देखने जा रहे हैं। मॉडल जीतते रहेंगे क्योंकि उनके पास मॉडल है और उनके पास उन क्षैतिज उपकरणों के लिए वितरण है जिन्हें उन्होंने डिज़ाइन किया है।

ओज़ का बाकी हिस्सा जीत सकता है यदि वे कार्य प्रणाली के मालिक हैं — वह सतह जहां कंपनी का काम वास्तव में निष्पादित होता है और उससे बहने वाला डेटा कैप्चर किया जाता है। ये कंपनियां डेटा कैप्चर, कार्रवाई की वर्कफ़्लो प्रणाली और शासन की मालिक हैं। जैसे-जैसे एक वर्टिकल में अधिक जटिल वर्कफ़्लो परिपक्व होते हैं, वे एक मुख्य अनुभव में संयोजित होते हैं जिस पर ग्राहक निर्भर हो जाता है। जैसे-जैसे मौजूदा और नए प्रवेशकों से नई मॉडल पीढ़ियां शिप होती हैं, कंपनी वह लेयर बन जाती है जो उन्हें एकीकृत करती है और ग्राहक तक पहुंचाती है। मॉडल नीचे विनिमेय है; कार्य प्रणाली नहीं है।

एंटरप्राइज़ सॉफ्टवेयर की अगली पीढ़ी सड़क से हटकर बनाई जाएगी।

यदि आप इसे बना रहे हैं, तो संपर्क करें: jschmidt@a16z.com.

एक क्लिक में सहेजें

YouMind में वायरल लेखों की AI गहन पढ़ाई

स्रोत सहेजें, केंद्रित सवाल पूछें, तर्क का सारांश बनाएँ और एक वायरल लेख को एक ही AI वर्कस्पेस में दोबारा इस्तेमाल करने लायक नोट्स में बदलें।

YouMind देखें
क्रिएटर्स के लिए

अपने Markdown को एक साफ़-सुथरे 𝕏 आर्टिकल में बदलें

जब आप अपना लंबा कंटेंट पब्लिश करते हैं, तो इमेज, टेबल और कोड ब्लॉक को 𝕏 के लिए फ़ॉर्मेट करना मुश्किल होता है। YouMind पूरे Markdown ड्राफ़्ट को एक साफ़-सुथरे, पोस्ट के लिए तैयार 𝕏 आर्टिकल में बदल देता है।

Markdown से 𝕏 आज़माएँ

समझने के लिए और पैटर्न

हाल के वायरल लेख

और वायरल लेख देखें