AI-native startup कैसे बनाएं

 (x.com/cyberfund)
13 पॉइंट द्वारा GN⁺ 6 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • यह एक नया ऑपरेटिंग मॉडल है जिसमें फाउंडर प्रोडक्ट सुधार पर फोकस करता है जबकि AI रात में दोहराए जाने वाले काम संभालता है; असली बदलाव समय के उपयोग में नहीं बल्कि कंपनी कितनी तेज़ी से सीखती, iterate करती और evolve करती है इसमें है
  • AI-native कंपनी में ऑपरेटिंग मॉडल ही बदल जाता है: कम लोग, कम coordination, agents दोहराए जाने वाले काम चलाते हैं, और इंसान दिशा, taste, संबंध, सत्यापन और ज़िम्मेदारी पर ध्यान देते हैं
  • बदलाव की प्रक्रिया इन चरणों में आगे बढ़ती है: काम की mapping, context system बनाना, सबसे सरल automation चुनना, दोहराए जाने वाले काम को skill में बदलना, quality जाँचने के लिए eval लिखना, और साप्ताहिक improvement loop चलाना
  • मॉडल हर महीने बदलते और बेहतर होते रहते हैं और एक-दूसरे जैसे लगने लगते हैं, इसलिए कंपनी की असली संपत्ति context और eval जैसी ऑपरेटिंग systems होती हैं
  • ऐसे माहौल में जहाँ सभी एक ही मॉडल इस्तेमाल करते हैं, असली moat है discipline — यानी हर हफ्ते काम की mapping करना, context जोड़ना, eval लिखना और loop को लगातार चलाना

दो startups का अंतर

  • एक ही बाज़ार में, एक ही महीने शुरू हुई दो कंपनियों की सुबह 9 बजे तुलना
    • पहली कंपनी में operations lead backlog में पड़े support tickets संभाल रहा है, analyst पिछले हफ्ते का dashboard फिर से बना रहा है, और founder standup के बीच उस customer call issue में फँसा है जिसे कोई हल नहीं कर पाया — सब लोग कल की समस्याएँ सँभालने में लगे हैं, इसलिए product ठहरा हुआ है
    • दूसरी कंपनी में यह सब काम agents ने रात भर में कर दिया — ticket classification, dashboard refresh, और calls से churn risk surface करना पूरा; founder पहले ही समस्या ठीक कर चुका है और टीम व product को बेहतर बना रहा है
  • असली फर्क है सीखने की रफ़्तार; दूसरी कंपनी हर दिन तेज़ सीखती है, और यह leverage हफ्तों, महीनों और सालों में compounding होकर बढ़ता जाता है

चरण 1 - काम की mapping (Map The Work)

  • पिछले 2 हफ्तों में बार-बार हुए सभी काम सूचीबद्ध करें — customer call notes, lead research, outbound drafts, support classification, product QA, onboarding, release notes, investor updates, weekly metrics, bug reproduction, hiring screening, invoice review, competitor monitoring आदि
    • अगर कोई काम दोहराया जाता है, तो वह encoding का candidate है; ज़्यादातर founder calendars में ऐसे 20–40 items होते हैं
    • अगर शुरुआती टीम ईमानदारी से सूची बनाए, तो उसे पहले से routine बन चुके 10–15 काम मिल जाएंगे

  • autonomy level के हिसाब से वर्गीकरण

    • L1 केवल इंसानों के लिए — strategic decisions, final hiring, बड़े refunds, legal signatures, board communication
    • L2 AI तैयार करे, इंसान approve करे — investor update drafts, contract redlines, pricing page rewrite, support macros
    • L3 AI execute करे, इंसान supervise करे — inbound classification, meeting notes routing, lead enrichment, test generation
    • L4 स्पष्ट सीमाओं के भीतर autonomous — competitor monitoring, overnight report generation, known vendor invoice extraction, simple anomaly detection

  • उबाऊ workflows अक्सर जीतते हैं

    • weekly strategy memo जैसे दिखावटी कामों की तुलना में, रोज़ होने वाला support tagging 10 गुना ज़्यादा चलता है, ज़्यादा समय बचाता है और साफ़ answer data देता है — frequency, prestige को हरा देती है
    • पहला target वही काम होना चाहिए जो frequent, measurable, reversible हो और किसी असली bottleneck से जुड़ा हो

  • कौन-से काम automate नहीं करने चाहिए

    • जो काम rare, अस्पष्ट, high-trust वाले या unstable हों, उन्हें बाहर रखें
    • C.H. Robinson टीम ने प्रतिदिन 10,000 emails की classification को L4 तक धकेला, लेकिन supervision असंभव होने पर उसे वापस L2 पर लाना पड़ा — volume ने misclassification की cost छिपा दी थी
    • अगर आप यह नहीं समझा सकते कि अच्छा output कैसा दिखता है, तो वह encoding के लिए तैयार नहीं है; और अगर एक गलत output customer relationship को नुकसान पहुँचा सकता है, तो धीरे चलें

  • शुरुआत की संरचना

    • 1 page और 3 workflows से शुरू करें — personal (inbox classification, daily brief, investor update draft), customer-facing (call summary, ticket classification, lead enrichment), internal (test generation, invoice extraction, weekly metrics narrative)
    • एक साथ बहुत ज़्यादा experiments करने से ध्यान बँट जाता है और 20 अधूरे pilots बन जाना सबसे आम failure mode है

चरण 2 - context system बनाना (Build The Context System)

  • context, AI-native startup की operating memory है, यानी कंपनी अपने बारे में जो कुछ जानती है, उसे ऐसी जगह रखना जहाँ agents उसे पढ़ सकें
    • मॉडल बदले जा सकते हैं, लेकिन context ही कंपनी की असली संपत्ति है — यही तय करता है कि agent co-founder की तरह काम करेगा या किसी उलझे हुए temp worker की तरह
    • अगर outputs को फिर से लिखने में review से ज़्यादा समय लगता है, तो समस्या prompt या model में नहीं, बल्कि इस बात में है कि agent कंपनी को पर्याप्त नहीं जानता

  • साप्ताहिक diagnostic तरीका

    • एक representative task किसी नए agent को दें जिसके पास सिर्फ workspace context हो, और उससे अगले 3 actions माँगें
    • अगर 2 या उससे ज़्यादा सुझाव मज़बूत हों, तो context काम कर रहा है; अगर 3 generic जवाब मिलें, तो context कमज़ोर है और prompt से उसे बचाया नहीं जा सकता

  • Git repository को आधार बनाएं

    • एक shared Git repository से शुरू करें जिसे टीम के सभी लोग और agents पढ़ सकें — version control, diff, इंसानों और agents दोनों के लिए readable, और किसी एक vendor runtime पर निर्भर नहीं
    • day-7 workspace एक single root के रूप में बनाया जा सकता है जिसमें CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md, और active tasks के लिए GTD.md हो
    • इसे हाथ से लिखी 40–60 lines तक रखें — क्या avoid करना है इसकी generated 400-line बकवास सूची से यह बेहतर है

  • permission boundaries के हिसाब से विभाजन

    • जैसे-जैसे आप बढ़ें, shared company repository + function-wise private repositories (sales, product, engineering, finance, support), या project/customer-wise private repositories + company-wide shared root अपनाएँ
    • enterprise scale पर self-hosted Gitea, GitHub Enterprise, GitLab जैसे private Git servers में directory/repository level permissions दें
    • Block का internal harness Goose role-based scopes के साथ एक ही artifact stream पढ़ता है; scope गड़बड़ होते ही यह public statements और private deal context को मिलाने लगता है — boundaries बहुत महत्वपूर्ण हैं

  • system में जाने वाले 3 तरह के data

    • connectors — SaaS, API, MCP servers, email, calendar, CRM, support, analytics, GitHub, Linear, Stripe, warehouse, documents से external data collect करना
      • हर connector में identifier, scoped permission, audit log और managed credentials होने चाहिए; वरना वही सबसे बड़ा security hole बन जाता है — Zitadel जैसी IAM layer identity discipline संभालती है
      • Anthropic के MCP code execution tasks में, server-folder filesystem pattern के जरिए सभी tool definitions पहले से load करने की तुलना में context usage लगभग 150,000 tokens से घटकर लगभग 2,000 tokens रह गया — 98.7% reduction
    • कंपनी द्वारा बनाया गया data — specs, customer summaries, decisions, lessons, project notes, operating rules; default रूप में Markdown
      • सबसे महत्वपूर्ण नियम है raw और distilled को अलग रखना — call transcript raw है; उस call से निकले decisions, customer objections, follow-up owner, और renewal risk distilled हैं, और agents वास्तव में इन्हीं को query करते हैं
      • decision log को append-only रखें, एक line में एक item, ताकि reasoning निष्कर्षों के साथ ट्रेस की जा सके
    • databases और streams — जैसे Postgres product data, warehouse marketing data, analytics events, जहाँ source पहले से मौजूद है
      • इन्हें अंधाधुंध Markdown में copy न करें; DB को source of truth रहने दें, agents को restricted read user दें, schema को agent-facing file (data-models/postgres.md) में document करें, और allowed queries व writes साफ़ लिखें
      • default रूप से agents को production data delete करने से रोकें — 2025 के मध्य की Replit incident (जिसमें एक coding agent ने session के दौरान production DB delete कर दिया) याद दिलाती है कि prompt instructions कोई security boundary नहीं हैं

  • advanced version और source tracking

    • structured context graph — agent query करने से पहले raw sources को entities और relationships में बदलें, जैसे लोग, कंपनियाँ, objections, commitments, feature requests, renewal risk, follow-ups, dates, decisions, source links
      • transcript store करने के बजाय उसकी सामग्री निकालें और उसी व्यक्ति/परियोजना की calls को chain करें, ताकि "Vandelay Industries का renewal risk क्या है?" जैसे सवाल का जवाब सटीक statement lines के citation के साथ दिया जा सके
    • हर summary को उसके source (transcript, ticket, commit, invoice, DB row) तक trace किया जा सके — source न हो तो unverifiable लेकिन plausible summaries जमा होती जाती हैं, और पहली गलत जवाब पर पूरे agent system से भरोसा टूट जाता है
      • source होने पर agent auditable बन जाता है, और टीम का सदस्य एक click में source खोलकर कुछ ही seconds में disagreement सुलझा सकता है

चरण 3 - सबसे सरल automation चुनना (Choose The Simplest Automation)

  • हर workflow को agent मत बनाइए - सबसे अच्छे systems script, AI-सहायता प्राप्त इंसान, deterministic workflow, और agent का मिश्रण होते हैं
    • संस्थापक की भूमिका यह चुनना है कि quality bar पार करते हुए सुरक्षित रूप से चलने वाला सबसे हल्का tool कौन-सा है

  • टूल के अनुसार उपयोग

    • Script - deterministic steps (report export करना, CSV convert करना, test run करना, link check करना, JSON validate करना, weekly metrics pack format करना)
    • AI-सहायता प्राप्त इंसान - ऐसे outputs जहाँ कंपनी से बाहर जाने से पहले निर्णय की ज़रूरत हो (investor updates, founder emails, pricing copy, contract notes)
    • Workflow - जब steps पहले से ज्ञात हों (call collection→summary→objection extraction→CRM note writing→follow-up generation), जहाँ engine के रूप में LangGraph, Temporal, Inngest, Prefect sequence, retry, और observability संभालते हैं
    • Agent - जब path पहले से तय नहीं किया जा सकता हो (production bug investigation, market research, abnormal support cases, उलझे हुए customer accounts)
      • Browserbase का bb agent Slack-facing general-purpose agent है, जो हर task के लिए अलग skill files और scoped permissions load करता है - हर task के लिए अलग bot बनाने से बेहतर, क्योंकि bots समय के साथ एक-दूसरे से अलग दिशा में drift करने लगते हैं

  • Harness - 6-step safety layer

    • Preflight - agent token खर्च करने से पहले context और permissions की जाँच
    • Plan - task decomposition और proposed steps को सामने लाना
    • Approve - इंसान या judge model gate खराब plan को execute होने से पहले रोकता है
    • Execute - task चलाना
    • Verify - tests, schema, rubric, और examples से output validate करना
    • Log - जो हुआ उसे run file में record करना ताकि अगला iteration सही उत्तर रखे

  • Guardrails code और config में हों (prompt में नहीं)

    • "production data delete मत करो" जैसा prompt कोई security boundary नहीं है
    • Non-negotiables - execution और daily cost caps, retry caps, maximum tool-call depth, per-agent scoped credentials, बिना approval production write पर रोक, code auto-merge पर रोक, fleet-wide kill switch
    • 2025 भर हुई recursive generation incidents (जहाँ agent लगातार child agents को call करते रहे) ने harness के पकड़ने से पहले ही वास्तविक cost पैदा की - caps runtime पर होने चाहिए, model को instruction ignore करने का मौका मिलने से पहले

चरण 4 - skills और evals को encode करना (Encode Skills And Evals)

  • अब तक की सारी चीज़ें तैयारी हैं; दोहराए जाने वाले काम को skills में encode करना और evals से score करना ही वह engine है जो कंपनी को हर हफ्ते थोड़ा-थोड़ा compounding growth देता है
    • Skill मतलब दोहराए जाने वाले task के लिए reusable instructions + examples - किसी चीज़ को दो बार हाथ से करने के बाद उसके दोहराए जाने वाले हिस्से को encode करें
    • हर skill का रूप साफ़ होना चाहिए - scope, inputs, load किया जाने वाला context, procedure, output format, examples, escalation rules, owner, execution logs
    • अगर उसमें यह नहीं लिखा कि क्या लेता है, क्या लौटाता है, कब मदद माँगनी है, और उसे कौन maintain करता है, तो वह skill नहीं बल्कि लंबा prompt है

  • skill template उदाहरण (customer-call-synthesis)

    • Scope: transcript मिलने के बाद sales calls / Inputs: transcript, account history, product context, open opportunities
    • Load: ICP, pricing, product roadmap, objection taxonomy / Steps: fact extraction→objection clustering→risk identification→follow-up writing
    • Output: CRM notes·customer brief·feature requests·next actions / Examples: expected notes के साथ पिछली 3 calls
    • Escalate: legal·security issues, churn risk, enterprise pricing / Owner: revenue lead / Eval: expected extracted fields वाली पिछली 30 calls

  • founder-friendly skills से शुरुआत करें

    • Customer call synthesis - raw transcript से objections, feature requests, risks, commitments, next actions निकालना
    • Inbox triage - investor·customer·hiring·operations messages को sort करना और पहले 3 प्रकार के reply drafts बनाना
    • Investor updates - metrics और decisions से narrative लिखना, फिर दोनों तरफ के citations जोड़ना
    • Pricing page analysis - live page की तुलना latest customer objection log से करना
    • Weekly metrics narrative - क्या बदला, क्या टूटा, और क्या जाँचना है, यह समझाना
    • Test generation - spec को tests और draft PR में बदलना

  • eval की 3 layers (क्रम में जोड़ें)

    • पहली, हाथ से label किया गया ground truth - इंसान वास्तविक examples में चिह्नित करे कि अच्छा output क्या है
    • दूसरी, deterministic checks - zero cost पर clear verdict देते हैं (schema validity, source से मेल खाते numbers, resolve होने वाले links, मौजूद citations, pass होने वाले tests)
    • तीसरी, LLM judging - सिर्फ उन हिस्सों के लिए जहाँ deterministic checks नहीं पहुँचते (writing quality, tone, brief से मेल), इसके लिए छोटा और तेज़ model काफी है, लेकिन भरोसा करने से पहले इंसानों द्वारा marked examples से calibration ज़रूरी है

  • case study: customer call synthesis

    • revenue lead ने पिछली 30 calls mark कीं - महत्वपूर्ण facts, objections, risks, follow-ups
    • deterministic checks - names, contractual amount, follow-up date के week की accuracy; और brief call जैसा लगता है या नहीं, यह LLM judge देखता है
    • लगभग 50 runs के बाद आम तौर पर वही दो चीज़ें टूटती हैं - 3 या उससे अधिक लोगों वाली call में speaker tracking fail होना, या दो अलग objections को एक में merge कर देना - इन्हें cluster स्तर पर ठीक करके consistent behavior तक फिर से लिखें

  • case study: outbound lead qualification

    • संस्थापक ने पिछली 300 leads पर ICP fit के लिए yes/no mark किया
    • mechanical checks - कंपनी वास्तविक है या नहीं, website load होती है या नहीं, employee count भरा गया या नहीं / बाकी के लिए ICP description के विरुद्ध LLM judgment
    • eval तैयार होने के बाद open source prompt-evolution loops (GEPA, DSPy) label के मुकाबले classification prompt को रात भर rewrite करते हैं - संस्थापक अंतिम prompt नहीं पढ़ता; सिर्फ eval judgment मायने रखता है

  • eval maturity के 5 चरण

      1. एक example की manual review → 2) लिखे गए rubric से कुछ cases score करना → 3) उसी rubric को पिछली 20~300 items पर लागू करना → 4) ऐसे holdout set पर test करना जिसे agent ने पहले नहीं देखा → 5) उस business metric को track करना जिसे skill बदलने की कोशिश कर रही थी

  • launch के बाद अच्छा state बनाए रखें - हर हफ्ते 6 numbers

    • acceptance rate, override rate, cost per run, cycle time, review time, incident count
    • acceptance rate सबसे महत्वपूर्ण है - अगर यह लगभग 70% से कम है (छोटे edits को acceptance माना जाए), तो autonomy level बढ़ाने की तैयारी नहीं हुई है
    • acceptance rate कम होने पर prompt rewrite करना लगभग कभी सही जवाब नहीं होता; आम तौर पर समस्या इन चार में से एक होती है - runtime में context जोड़ना, skill scope को संकरा करना, file में working examples जोड़ना, या उन cases के लिए clear escalation rules लिखना जिन्हें इसे लेना ही नहीं चाहिए था

चरण 5 - टीम को AI-native बनाना (Make The Team AI-Native)

  • संस्थापक पहले शुरू करे - टीम को नए operating mode में लाने का सबसे तेज़ तरीका है कंपनी के context के भीतर live दिखाना
    • calendar·inbox·Slack से रात भर खींचकर लाया गया morning brief, कल की calls का customer synthesis, spec से agent द्वारा निकाला गया test PR, और आखिरी metrics pack से बना investor update draft दिखाएँ
    • लक्ष्य है calibration - अपनी आँखों से देखना कि agent layer क्या कर सकती है और क्या नहीं
    • Jack Dorsey ने 2025 भर हर सुबह कई घंटे इन tools को खुद इस्तेमाल किया और फिर Block का पुनर्गठन किया - इससे बड़े efficiency-driven layoffs हुए, और निर्णय ऐसे leadership से आए जिसने agents को सीधे इस्तेमाल किया था

  • पहले दिन से install, onboarding का अंत output के साथ

    • हर team member पहली session से उसी दिन ship किए जा सकने वाले output के साथ निकले (साफ़ customer brief, support macro, test PR, pricing page critique) - ऐसी training जो वास्तविक काम produce नहीं करती, अगले हफ्ते तक भूल जाती है
    • Ramp के Glass tool में नियम था कि हर onboarding session का अंत नए व्यक्ति की 1 skill·artifact को shared library में जोड़कर हो; इसी वजह से 3 महीनों में daily users 20 से बढ़कर लगभग 700 हो गए

  • इंसानों की भूमिका बढ़ती है

    • इंसान system design करते हैं, relationships own करते हैं, outputs का judgment करते हैं, और accountability लेते हैं / agents execution संभालते हैं
    • जो team member सिर्फ संकरे tasks चलाते हैं, वे इस model में उजागर हो जाते हैं; जो judgment को instructions, examples, और evals में बदल सकते हैं, वे पहले से अधिक मूल्यवान हो जाते हैं

  • hiring भी बदलती है

    • role खोलने की threshold ऊँची हो जाती है - जो कुछ पहले hiring से होता था उसका हिस्सा अब skill है, इसलिए नया role सिर्फ वहीं दें जहाँ सच में इंसान चाहिए
    • hiring में trivia की जगह, तय समय में हाथ से पूरा न हो सकने वाला बड़ा project दें और देखें कि उम्मीदवार agents को कैसे direct करता है - judgment, taste, और agent के भटकने पर recovery की क्षमता देखें
    • वास्तविक उदाहरण - analyst को 3 घंटे में source collection·evidence extraction·polished brief तक एक वास्तविक report, engineer को एक दिन में वास्तविक product surface की copy या spec-based internal tool (tests सहित), growth hire को 50~100 कंपनियों पर market map·campaign plan (scraping·clustering·writing·prioritization) - मुख्य बात यह है कि इन्हें समय सीमा के भीतर हाथ से पूरा करना संभव न हो

चरण 6 - startup को feedback loop की तरह चलाएं (Run As A Feedback Loop)

  • AI-native startup हर हफ्ते अपनी operating system में सुधार करते हैं - शुरुआत पर लौटें और फिर से शुरू करें
    • review में क्या शामिल होगा - agent ने क्या किया, इंसानों ने कहाँ override किया, कौन-से eval fail हुए, कौन-सा context छूटा, किन skills को संकुचित करना है, किन workflows को खत्म करना है, और किन workflows की autonomy level बढ़ानी है

  • एक साथ दो loop चलाएं

    • inner loop - मौजूदा काम में सुधार (प्रति execution लागत↓, cycle time↓, incidents↓, artifact per review time↓)
    • outer loop - आगे की चीज़ों की खोज (नए customer segment, product ideas, pricing changes, partnerships, competitor moves, regulatory changes, churn risk), background agent 24 घंटे candidates उपलब्ध कराते हैं और इंसान तय करते हैं कि किसका पीछा करना है

  • Software factory (inner loop का सबसे बड़ा हिस्सा)

    • इंसान spec और tests लिखते हैं और agent उनके अनुसार implementation करता है, deterministic checks खुद चलती हैं और merge से पहले इंसान review करते हैं
    • वहाँ से शुरू करें जहाँ acceptance criteria साफ हों और impact scope छोटा हो - test generation, dependency upgrades, migration, internal tools, integration scaffold, QA scripts, security auto-fixes
    • दो hard rules - कुछ भी auto-merge नहीं होता, कोई भी agent production पर नहीं लिखता
      • Cursor भी बड़े पैमाने पर autonomous cloud agents चलाते हुए 2026 की शुरुआत तक merge पर human review gate बनाए रखता है - यही gate बाकी सबको सुरक्षित रूप से scale करने देता है

  • Market learning system (outer loop)

    • call logs, objections extraction, feature request clustering, competitor tracking, usage changes पर नज़र, support patterns को पढ़ना, lost deals का अध्ययन
    • findings को hypothesis में बदलें, फिर सबसे मजबूत को test करें - customer conversations, landing page tests, product experiments, data पर नई queries
    • agent सुझाव देते हैं और इंसान चुनते हैं - अगर strategy के सुझाव और decisions दोनों agent पर छोड़ दिए जाएँ, तो वे या तो साधारण consensus पर टिक जाते हैं या सबसे आसानी से बढ़ने वाले metric को hill-climbing की तरह optimize करते हैं

  • कंपनी-स्तर के self-improvement का मूल = eval लिखने की क्षमता

    • सैकड़ों उदाहरणों को हाथ से अच्छा/बुरा label करें, eval बनाएं और उसे prompt evolution loop से जोड़ें - GEPA, DSPy जैसे frameworks छोटे reflection models से prompt mutations सुझाते हैं और eval labeled set पर ranking करके winner deploy करता है, फिर दोहराया जाता है
    • founders eval लिखते हैं और failure clusters पढ़ते हैं, लेकिन evolved prompts को न लिखते हैं, न पढ़ते हैं
    • रुकावट agent capability नहीं, बल्कि यह है कि क्या आप “अच्छा” के मानदंड encode कर सकते हैं - coding मदद करती है पर bottleneck नहीं है, और ऐसा domain expert जो outputs को भरोसेमंद तरीके से अच्छा/बुरा mark कर सके, पूरे loop को चला सकता है
    • eval वह core artifact है जो पूरा भार संभालता है, और जिस क्षण eval लिखना रुकता है, उसी क्षण कंपनी की compounding growth भी रुक जाती है

निष्कर्ष

  • ज़रूरत प्रतिभा या बड़ी team की नहीं, बल्कि काम को map करने, context जमा करने, eval लिखने और हर हफ्ते loop चलाने की discipline की है - जब सभी एक ही model इस्तेमाल कर रहे हों, तो operating system ही गुप्त हथियार होता है

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

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

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