Yellow Brick Road पर मौत से कैसे बचें — app layer अभी मरी नहीं है

 (a16z.news)
3 पॉइंट द्वारा GN⁺ 2 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • AI app layer को OpenAI·Anthropic जैसी बड़ी labs द्वारा निगल लिए जाने की चिंता founders के बीच फैल रही है, लेकिन app layer एक अकेला अवसर नहीं है बल्कि "Yellow Brick Road" और "Rest of Oz" में बंटी हुई संरचना है
  • Yellow Brick Road वह horizontal क्षेत्र है, जैसे code generation, writing, image generation, जहाँ model की अपनी performance में सुधार भर से quality बेहतर होती है, और यही वह रास्ता है जिस पर labs भारी संसाधन लगा रही हैं
  • Rest of Oz वह क्षेत्र है जहाँ vertical·multi-step·multi-approval workflows जैसे मामलों में model के ऊपर की scaffolding reliability और compliance तय करती है, और यहीं startups के लिए ग्राहक को अपने पास रखने का मौका है
  • OpenAI·Anthropic द्वारा enterprise customization के लिए large-scale forward-deployed joint ventures घोषित करना ही यह संकेत देता है कि generalized AI coworker अकेले हर समस्या हल नहीं कर सकता
  • अगली पीढ़ी का enterprise software "off the road" बनाया जाएगा, और मुख्य रक्षा-पंक्ति यह है कि model बदला जा सकता है, लेकिन system of work नहीं

मुख्य प्रश्न और आधार

  • founders और संभावित hires से बार-बार पूछा जाने वाला सवाल है: "क्या OpenAI और Anthropic सब कुछ खत्म कर देंगे, और क्या AI app layer में बनाने के लिए कुछ बचा है?"
  • कुछ लोग इस निष्कर्ष पर पहुँचते हैं कि स्थायी निचले वर्ग से बचने की जगह सिर्फ बड़ी labs के भीतर या robotics·hardtech जैसे frontier क्षेत्रों में है
  • लेखक, AI maximalist नज़रिए से, मानते हैं कि वे "आधे सही" हैं; labs सचमुच app surface के बड़े हिस्से को absorb करेंगी
  • लेकिन असली बात यह है कि app layer एक अकेला अवसर नहीं है — सही framing यह है कि आप Yellow Brick Road पर हैं, या Oz के किसी और हिस्से में

The Yellow Brick Road — labs का रास्ता

  • high-performance models में G Drive, Slack, Salesforce, Notion, GitHub जैसे off-the-shelf connectors लगाकर उनके ऊपर agent orchestration layer रखना
  • यह pattern इसलिए खतरनाक है क्योंकि labs Cowork और Codex के साथ पहले से यही काम कर रही हैं
    • model का ownership → बेहतर margins, control, और downstream पर pricing power
    • product को सफल बनाने के लिए परिभाषित architecture choices उनके हाथ में हैं — अब तक उन्होंने जानबूझकर "model + tool calls" pattern अपनाया है, जो इस रास्ते पर मौजूद horizontal low-level tasks के लिए बिल्कुल फिट है
  • अगर कोई startup performance में Codex या Claude Code से आगे भी निकल जाए, तब भी labs के पास विशाल distribution और AI क्षेत्र की सबसे बड़ी brand halo है
  • वही connector mix, sub-agents या configuration के बिना, और distribution के बिना इस playbook को दोहराने वाली AI app company एक "कहीं नहीं जाने वाला रास्ता" पकड़ रही है

The Rest of Oz — startups का अवसर

  • वह क्षेत्र जहाँ models को tools·automation·integrations के जटिल जाल के ज़रिये जोड़कर agent experience बनाया जाता है, और जो स्वाभाविक रूप से अधिकतर vertical बन जाता है
  • यहाँ उन multi-step·multi-participant tasks पर ध्यान दिया जा सकता है जिन तक horizontal platform नहीं पहुँच पाते
    • पूरे system से context इकट्ठा करने के बाद, step-by-step approvals चाहिए वाले कई लोगों तक route करना
    • एक या अधिक legacy systems से जुड़ना, deterministic outcomes चाहिए होना, और ambiguity की गुंजाइश न होना
    • अक्सर यह मूल्यवान business outcomes से जुड़ा होता है
  • labs भी इस समस्या के मूल्य को समझती हैं, इसलिए वे सीधे outsourced configuration shops चलाती हैं, और इसी वजह से reinforcement learning business का upmarket class भी मौजूद है

Rest of Oz को जादूगर क्यों नहीं निगल पाएगा

  • Data and learning flywheels

    • training set में न मिलने वाले implicit industry norms, undocumented standards, और practitioners के दिमाग में मौजूद tribal knowledge खुले web पर नहीं मिलते
    • यहाँ दो flywheels एक साथ चलते हैं
      • across-customer: कई ग्राहकों में एक ही समस्या के अलग रूप देखकर जमा होने वाले patterns
      • within-customer: किसी खास decision के पीछे की वजह, implicit exceptions, और उस कंपनी के अपने rules of thumb
    • 100 legal redlines, 1,000 insurance underwriting cases, या 10,000 SDR campaigns चला चुकी company अपने भीतर समस्या का ऐसा shape समेट लेती है जिसे नया entrant अभी-अभी लॉन्च किए agent से replicate नहीं कर सकता
    • horizontal agent वही learning infrastructure क्यों नहीं बना सकता, इसका मुख्य कारण UX है — workflow surface को ठीक से सिर्फ vertical player ही design कर सकता है
    • eval sets, labeled outputs, और edge-case taxonomies मिलकर vertical-specific data flywheel बनाते हैं, जो fine-tuning का fuel बनता है

  • Managing model variability and complexity

    • labs अंदरूनी तौर पर request-level model routing और ensembles पहले से करती हैं, लेकिन vendors के बीच routing, competitor models का evaluation, और open source fine-tuned models को संकरे domain में लगाना उनके लिए संभव नहीं
    • Rest of Oz companies parent lab ने जो जारी किया है सिर्फ उसी तक सीमित नहीं रहतीं, बल्कि पूरे model market से subtask के हिसाब से सबसे उपयुक्त model चुनती हैं
    • हर upgrade पर evals दोबारा चलाना, customer edge cases के अनुसार prompts को recalibrate करना, और production तोड़े बिना rollout करना जैसे "कोई नहीं करना चाहता" वाले काम ये अपने ऊपर लेती हैं
    • lab अगला model बेचकर बस "migrate करो" कह देती है, लेकिन Rest of Oz company migration को absorb करके ग्राहक को पूरे market की सबसे अच्छी intelligence और upgrade continuity देती है

  • Cost optimization

    • हर query को Opus 4.7 पर चलाना negative gross margin तक पहुँचने का सबसे तेज़ रास्ता है
    • सबसे अच्छी Rest of Oz companies models को tier-based routing से चलाती हैं
      • सबसे कठिन tasks के लिए frontier models
      • ज़्यादातर tasks के लिए mid-tier
      • योग्य हिस्सों के लिए छोटे custom·fine-tuned models
    • कुछ कंपनियाँ इसके ऊपर अपना post-training भी करती हैं, ताकि ग्राहक जिस संकरे slice की परवाह करते हैं, उसके लिए frontier API की लागत के एक हिस्से में serving हो सके
    • अगर lab "X डॉलर में minimum intelligence" जैसा floor price तय करती है, तो Rest of Oz company उसका उल्टा बेचती है: workflow को वास्तव में जितनी intelligence चाहिए, उसके लिए सबसे कम dollar cost

  • Governance

    • किसी vertical में ग्राहक AI को कैसे चलाता है, उसके control plane बन जाने में बहुत मूल्य है — permissions, audit, agent क्या कर सकता है, और उसने वास्तव में क्या किया, सब यहीं converge होते हैं
    • यह control plane industry और role के हिसाब से पूरी तरह अलग use-case-specific guardrails से बना होता है
    • tools, workflows, और data को end-to-end own करने से ऐसे deterministic outcomes देना संभव होता है जो horizontal tools के लिए कठिन हैं
    • यह अंतिम buyer की जगह regulatory complexity absorb करने वाला पक्ष बन जाता है
      • legal: FRCP और वकीलों की ethical rules
      • healthcare: HIPAA
      • finance: SEC और FINRA
      • insurance: state-level insurance regulation आदि
    • CIO ऐसा partner चाहता है जो उसके लिए दिए गए agents की compliance की contractual responsibility ले

  • साझा निष्कर्ष: focus

    • चाहे vertical हो जैसे insurance·legal·accounting, या deeply performed function जैसे sales·customer support·finance, एक ऐसी team चाहिए जो एक ही customer set के workflows, edge cases, और regulations के लिए समर्पित हो
    • labs यह काम नहीं कर सकतीं क्योंकि उनकी संरचना उन्हें सभी के लिए हर जगह मौजूद रहने को मजबूर करती है — या तो "हर जगह" रहो, या "एक चीज़ बहुत अच्छी" करो

Sales case — 11x CEO Prabhav Jain की व्यावहारिक सलाह

  • Focus on outcomes

    • lab-resilient company बनाने का tactical path यह है कि शुरुआत ग्राहक की सच में महत्वपूर्ण specific outcome से की जाए — 11x के मामले में pipeline generation
    • हर activity को tasks में तोड़ना → कौन-सा हिस्सा agentic है और कौन नहीं, कहाँ sophisticated domain insight चाहिए और कहाँ नहीं
    • multi-step workflows, messy inputs, hard-to-interpret states, और real-world constraints वाले मामलों में सिर्फ बेहतर model काफ़ी नहीं; traditional software engineering चाहिए, और इस surface पर labs को कोई खास बढ़त नहीं
    • 11x जिन tasks को संभालता है, उनके उदाहरण
      • custom signals आधारित lead prospecting, lead enrichment, deep account research
      • CRM context fetcher, channel-specific message writer, lead qualification agent, email deliverability system
    • सामान्य training data में न मिलने वाले domain knowledge को workflow के सही समय पर model में inject करना app company का काम है, और यह समय के साथ जमा होता है
    • skills business evolution के साथ लगातार पुराने पड़ते हैं, इसलिए workflow और context को evolve करने की क्षमता ही competitive advantage है
      • उदाहरण: AI-written emails आने के बाद users की संवेदनशीलता हर कुछ महीनों में बदलने लगी, इसलिए agents को market dynamics के मुताबिक लगातार adapt होना पड़ता है
      • पिछले कुछ महीनों में positive reply rate 4 गुना बढ़ी, और ग्राहकों के लिए सैकड़ों मिलियन डॉलर की pipeline बनाई गई

  • Work on problems where complexity is high

    • असली business value जटिल समस्याओं में unlock होती है, नहीं तो आप सिर्फ thin wrapper बनकर रह जाते हैं
    • GTM उदाहरण: "जो कंपनियाँ पहले से ग्राहक हैं, उनके contacts को outreach नहीं करना" जैसा सरल नियम भी व्यवहार में बहुत जटिल होता है
      • CRM में domain mapping हो सकती है, दर्जनों subsidiaries वाली company हो सकती है, सिर्फ parent company domain दर्ज हो सकता है, और Salesforce के stale matching fields की वजह से मौजूदा ग्राहक के CRO को cold pitch चला जा सकता है
    • real-world data messy होता है, और न इंसान न model इसे जादू से हल कर सकते हैं — समस्या के वास्तविक shape के अनुसार engineered purpose-built agents चाहिए
    • 11x के data के अनुसार, उसके अपने data की quality और freshness ग्राहक के data से बेहतर है, इसलिए अपने data पर anchor करना डिफ़ॉल्ट है

  • Guardrails — बुरी चीज़ें रोकने का साधन नहीं, ग्राहक जिसके लिए भुगतान करते हैं वही सार

    • guardrails को बहुत कम आंका जाता है; एक ही product के भीतर भी हर use case के लिए अलग guardrails चाहिए
    • regulated financial services prospects और mid-market SaaS customers की assurance requirements अलग होती हैं, और यह फर्क agent कैसे लिखेगा, किससे संपर्क करेगा, किस data तक पहुँचेगा, call में क्या कहेगा, और decisions को कैसे log करेगा — सब पर असर डालता है
    • one-size-fits-all system टूट जाता है; use-case-specific design, customer-specific configuration, और ongoing audit चाहिए
    • इसके लिए ग्राहक की ज़रूरतों के हिसाब से tuning करने वाले FDE (Forward Deployed Engineer) और technical deployment strategists चलाए जाते हैं
    • F1000 institution case
      • बड़े पैमाने पर SMB ग्राहकों के लिए consent-based outbound voice चलाया गया
      • शुरुआती iterations में pickup rate कम थी → calls के पहले 10 seconds में SMB business owners को engage करने का तरीका जल्दी सीखा गया
      • SMB business owners बड़े B2B buyers या consumers से अलग व्यवहार करते हैं, और अब इस segment में ग्राहक की sales team के एक महीने की तुलना में एक दिन में अधिक sales opportunities बनाई जा रही हैं

Insurance case — FurtherAI CEO Aman Gour

  • वास्तविक insurance operations में AI deploy करते हुए बार-बार जो मान्यता सामने आई — "model ही intelligence है और workflow सिर्फ scaffolding" — carriers के साथ काम करते-करते उस पर ठीक उल्टा यकीन हो गया
  • insurance में intelligence का बड़ा हिस्सा workflow के भीतर ही मौजूद होता है
    • भले ही दो carriers एक जैसा path लें (submission → review → quote → bind), असली फर्क उसके भीतर की हर चीज़ में होता है
      • कौन-सा risk escalation होगा
      • कौन-से loss signals महत्वपूर्ण हैं
      • appetite rules टकराएँ तो कौन-सा rule जीतेगा
      • human approval कब चाहिए, external data कब बुलाना है, और final decision को कैसे document करना है
    • यह logic किसी एक साफ rule engine में नहीं होता; यह SOPs, manager reviews, underwriting philosophy, carrier-specific appetite, और वर्षों के operating experience में बिखरा होता है, और इसका बड़ा हिस्सा model के पढ़ने लायक documented form में भी नहीं होता
  • निष्कर्ष हर बार एक ही रहा: न तो हर चीज़ शुरुआत से infer करने वाला pure agent, और न ही वास्तविकता के messy होते ही टूट जाने वाला rigid workflow, बल्कि agentic workflows
    • workflow → repeatability, auditability, cost control
    • agent → variability handle करना, happy path टूटने पर recovery
    • human-in-the-loop → वे judgment calls जहाँ accountability महत्वपूर्ण है
  • Day 1 पर manual work को automate किया जाता है; समय के साथ हर escalation एक signal बनती है, हर exception feedback बनती है, और हर human correction इस बात का संकेत बनती है कि runbook में कहाँ कमी है — इसी तरह workflow carrier की operating memory में evolve होता है
  • labs बेहतर models और बेहतर general agents जारी करती रहेंगी, लेकिन कौन-सा account escalate हुआ, कौन-सा risk reject हुआ, और underwriter ने appetite guide को override करके क्यों सही फैसला लिया — यह तब तक सीखा नहीं जा सकता जब तक आप carrier के production में काफ़ी समय न बिताएँ
  • "Day 1 पर ship किया गया workflow moat नहीं है; production usage जो समय के साथ loop बनाता है, वही moat है"

यह पहचानने के 3 tests कि आप Rest of Oz में हैं या नहीं

  • The tools-and-steps test

    • task में कितने steps लगते हैं और supporting tools कितने जटिल हैं
    • तुलना
      • horizontal AI search (Google Drive के पार): 1 step, 1 tool, forgiving result — गलत हुआ तो फिर से पूछ लो
      • legal redline (3 साल के firm precedents से मिलान): दर्जनों steps, कई tools, output को partner review पास करना चाहिए और अदालत में चुनौती भी मिल सकती है
    • दोनों ही "agent काम कर रहा है" जैसे दिखते हैं, लेकिन इनमें से सिर्फ एक को focused team द्वारा वर्षों तक बनाया गया deep software चाहिए

  • The system test

    • क्या आप वह system बना रहे हैं जिससे ग्राहक अपना काम गुज़ारता है, या आप पहले से मौजूद system के ऊपर एक tool हैं?
    • system data capture, governance, और execution record को end-to-end own करता है, और वही वह जगह बनता है जिसे ग्राहक "जहाँ असली काम होता है" कहकर दिखाता है
    • tool सिर्फ ग्राहक के मौजूदा workflow में intelligence जोड़ता है; revenue तो आता है, लेकिन यह वही क्षेत्र है जिसे labs ले सकती हैं
    • High ACV अक्सर system होने का संकेत है, पर गारंटी नहीं — असली कसौटी यह है कि अगर lab सीधा competing product ले आए, तब भी क्या ग्राहक को आपका tool चाहिए रहेगा

  • The hedge fund / P&L test

    • lab की performance benchmark से मापी जाती है, जबकि Rest of Oz की performance ग्राहक के P&L से
    • ग्राहक को SWE-Bench·MMLU scores की परवाह नहीं — वह देखता है कि agent ने deal close की या नहीं, contract सही तरह redline किया या नहीं, सही policy bind की या नहीं
    • जो ग्राहक workflow-specific outcomes पर अटका है → Rest of Oz; जो general capability के लिए भुगतान करता है → Claude या Codex seat ही काफी है
    • सबसे अच्छे agent businesses को hedge fund की तरह ग्राहक के P&L से मापे जाने वाले alpha पर खेलना चाहिए

दोनों पक्ष जीत सकते हैं

  • Yellow Brick Road पर भी बहुत बड़े विजेता निकलेंगे — labs models को own करती हैं और अपने design किए horizontal tools की distribution भी
  • Rest of Oz की जीत की शर्त है system of work का ownership — वह surface जहाँ company का असली काम execute होता है और data capture होता है
    • data capture, workflow का action system, और governance का ownership
    • जैसे-जैसे vertical में complex workflows mature होते हैं, वे सिमटकर ग्राहक के लिए एक core experience बन जाते हैं जिस पर वह निर्भर करता है
    • जब नई और पुरानी model generations जारी होती हैं, तब enterprise इन्हें integrate और deliver करने वाली layer बन जाता है
    • models उसके नीचे fungible होते हैं, लेकिन system of work नहीं
  • अगली पीढ़ी का enterprise software "off the road" बनाया जाएगा

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.