नया AI स्टैक: मॉडल्स, हार्नेस, लूप्स और सेल्फ-इम्प्रूविंग एजेंट्स

हर कोई AI मॉडल के बारे में बात कर रहा है।

कोई भी उस लेयर के बारे में बात नहीं कर रहा जो उन्हें वास्तव में उपयोगी बनाती है।

Claude Code. Codex. Cursor.

ये सिर्फ मॉडल नहीं हैं।

ये एक सिस्टम में लिपटे हुए मॉडल हैं।

उस सिस्टम को हार्नेस कहा जाता है।

और सबसे अच्छे हार्नेस अब खुद में सुधार कर रहे हैं।

यहाँ वह सब कुछ है जो आपको नए AI स्टैक के बारे में समझने की ज़रूरत है।

वह झूठ जो हर कोई AI उत्पादों के बारे में मानता है

ज़्यादातर लोग सोचते हैं कि AI की प्रगति = स्मार्ट मॉडल।

ऐसा नहीं है।

मॉडल स्टैक का एक हिस्सा है।

आर्किटेक्चर प्रकाशित है। हर कोई उसी ट्रांसफॉर्मर की नकल करता है। हर लैब एक ही बिल्डिंग ब्लॉक का उपयोग करती है।

जो चीज़ वास्तव में Claude Code को एक वीकेंड प्रोजेक्ट से अलग करती है, वह मॉडल नहीं है।

यह वह चीज़ है जो मॉडल को घेरती है।

हार्नेस।

2017 में, AI प्रगति अटेंशन मैकेनिज्म के बारे में थी। 2020 में, यह स्केल के बारे में थी। 2026 में, यह हार्नेस इंजीनियरिंग के बारे में है।

और हार्नेस अब इंसानों द्वारा नहीं, बल्कि AI द्वारा डिज़ाइन किए जा रहे हैं।

हार्नेस क्या है?

हार्नेस वह सिस्टम है जो मॉडल को घेरता है।

यह तय करता है:

→ मॉडल कैसे सोचता है और योजना बनाता है

→ यह कब टूल को कॉल करता है और परिणामों के साथ क्या करता है

→ यह विभिन्न चरणों में क्या याद रखता है

→ यह आर्टिफैक्ट को कैसे स्टोर करता है और स्थिति का प्रबंधन कैसे करता है

→ यह अपने स्वयं के आउटपुट का मूल्यांकन कैसे करता है

→ यह कब वापस लूप करता है और फिर से प्रयास करता है

इसे एक ऑपरेटिंग सिस्टम की तरह समझें।

मॉडल CPU है। हार्नेस OS है।

आपके पास एक शक्तिशाली CPU और भयानक सॉफ्टवेयर हो सकता है और कुछ भी उपयोगी नहीं भेज सकते। आपके पास एक मामूली CPU और उत्कृष्ट सॉफ्टवेयर हो सकता है और कुछ बढ़िया भेज सकते हैं।

सबसे सफल कोडिंग एजेंट — Claude Code, Codex, Cursor — सभी की एक ही अंतर्दृष्टि है:

लूप उतना ही मायने रखता है जितना कि मॉडल।

3 हार्नेस पैटर्न जो हर AI बिल्डर को चाहिए

हर प्रोडक्शन AI सिस्टम इनमें से कम से कम एक का उपयोग करता है।

पैटर्न 1: लूप

मॉडल एक बार जवाब नहीं देता और रुक जाता है।

यह लूप करता है।

योजना बनाएँ → निष्पादित करें → निरीक्षण करें → सुधार करें → दोहराएँ

यह हर कोडिंग एजेंट का मूल है।

एक सरलीकृत Claude Code लूप:

1. कार्य पढ़ें
2. दृष्टिकोण की योजना बनाएं
3. कोड लिखें → इसे चलाएं
4. देखें कि क्या विफल हुआ
5. इसे ठीक करें
6. फिर से चलाएं
7. तब तक दोहराएं जब तक टेस्ट पास न हो जाएं

मॉडल लूप 3 पर लूप 1 की तुलना में अधिक स्मार्ट नहीं है।

लेकिन सिस्टम है।

प्रत्येक लूप मॉडल को नया संदर्भ देता है — त्रुटि संदेश, परीक्षण परिणाम, निष्पादन ट्रेस।

लूप 1 का आउटपुट लूप 2 का इनपुट बन जाता है।

वह यौगिक संदर्भ ही कारण है कि एजेंटिक सिस्टम जटिल कार्यों पर सिंगल-शॉट प्रॉम्प्टिंग से बेहतर प्रदर्शन करते हैं।

मुख्य अंतर्दृष्टि: मॉडल स्थिर रहता है। संदर्भ स्मार्ट होता जाता है।

पैटर्न 2: मेमोरी के रूप में फ़ाइल सिस्टम

अधिकांश डेवलपर्स सब कुछ कॉन्टेक्स्ट विंडो में भर देते हैं।

यह एक जाल है।

लंबी अवधि के कार्य उत्पन्न करते हैं:

→ प्रयोग लॉग

→ कोड डिफ़ → त्रुटि ट्रेस

→ पिछले रोलआउट इतिहास → पेपर सारांश → मध्यवर्ती आर्टिफैक्ट

यह सब किसी भी कॉन्टेक्स्ट विंडो से कहीं आगे बढ़ जाता है।

समाधान: कॉन्टेक्स्ट में नहीं, फ़ाइलों में लिखें।

1# बुरा: सब कुछ कॉन्टेक्स्ट में
2context = previous_output + tool_result + error_log + history...
3# चरण 47 पर फट जाता है
4
5# अच्छा: फ़ाइल सिस्टम का उपयोग करें
6agent.write("experiments/run_3/error_log.txt", error_trace)
7agent.write("experiments/run_3/results.json", metrics)
8
9# बाद में, एजेंट केवल वही पढ़ता है जिसकी उसे ज़रूरत है
10relevant = agent.read("experiments/run_3/results.json")

यह लंबी अवधि के कार्यों के बारे में सब कुछ बदल देता है।

→ एजेंट क्रैश के बाद फिर से शुरू कर सकता है

→ एजेंट अपने स्वयं के निष्पादन इतिहास पर तर्क कर सकता है

→ चरण 200 पर भी संदर्भ साफ रहता है

→ कई उप-एजेंट फ़ाइलों के माध्यम से स्थिति साझा कर सकते हैं

सबसे अच्छे एजेंट फ़ाइल सिस्टम को दूसरे मस्तिष्क की तरह मानते हैं।

डंप नहीं। एक संरचित मेमोरी।

पैटर्न 3: उप-एजेंट

एक एजेंट सब कुछ नहीं कर सकता।

सबसे अच्छे सिस्टम समानांतर उप-एजेंट उत्पन्न करते हैं।

मूल एजेंट:

→ कार्य को स्वतंत्र उप-कार्यों में तोड़ता है

→ उन्हें समानांतर में चलाने के लिए उप-एजेंट लॉन्च करता है

→ उनकी स्थिति की निगरानी करता है → उनके परिणामों को वापस मर्ज करता है

एक शोध हार्नेस के लिए उदाहरण:

1मूल एजेंट प्राप्त करता है: "एक पूर्ण प्रतिस्पर्धी विश्लेषण रिपोर्ट लिखें"
2
3एक साथ 4 उप-एजेंट उत्पन्न करता है:
4→ उप-एजेंट 1: प्रतियोगी A की मूल्य निर्धारण और सुविधाओं पर शोध करें
5→ उप-एजेंट 2: प्रतियोगी B की मूल्य निर्धारण और सुविधाओं पर शोध करें
6→ उप-एजेंट 3: दोनों प्रतियोगियों के बारे में हाल की खबरें खोजें
7→ उप-एजेंट 4: Reddit और App Store से उपयोगकर्ता समीक्षाएं खींचें
8
9मूल एजेंट प्रतीक्षा करता है, फिर सभी 4 आउटपुट को अंतिम रिपोर्ट में मर्ज करता है
10
11कुल समय: सबसे धीमे उप-एजेंट के समान (4 गुना अधिक नहीं)

मुख्य डिज़ाइन नियम: उप-एजेंट आउटपुट फ़ाइलों में जाना चाहिए।

क्षणिक संदर्भ नहीं। फ़ाइलें।

यदि वे केवल संदर्भ में रहते हैं, तो उप-एजेंट सत्र समाप्त होने पर वे गायब हो जाते हैं।

यदि वे फ़ाइलों में रहते हैं, तो मूल एजेंट उनका निरीक्षण कर सकता है, सिस्टम क्रैश से उबर सकता है, और सब कुछ ऑडिट करने योग्य है।

वे टूल जो हर कोडिंग एजेंट उपयोग करता है

यदि आप एक एजेंट बना रहे हैं, तो यह टूलकिट है जिसे हर प्रमुख कोडिंग एजेंट मानकीकृत करता है।

1फ़ाइल सिस्टम टूल:
2→ glob, grep, ls          # फ़ाइलें खोजें
3→ read, read_many         # सामग्री पढ़ें
4→ write                   # नई फ़ाइल बनाएं
5→ edit                    # स्ट्रिंग-रिप्लेस एडिट
6→ apply_patch             # संरचित डिफ़
7
8शेल टूल:
9→ bash                    # कोई भी कमांड चलाएं
10→ PowerShell              # Windows समकक्ष
11
12संस्करण नियंत्रण:
13→ git_status, git_diff    # परिवर्तनों का निरीक्षण करें
14→ git_commit              # प्रगति सहेजें
15
16एजेंट प्रबंधन:
17→ spawn_agent             # उप-एजेंट लॉन्च करें
18→ wait_agent              # परिणाम की प्रतीक्षा करें
19→ list_agents             # देखें क्या चल रहा है
20→ interrupt_agent         # यदि आवश्यक हो तो रद्द करें
21
22बाहरी संदर्भ:
23→ web_search, web_fetch   # वर्तमान जानकारी प्राप्त करें
24→ MCP tools               # बाहरी सेवाओं से कनेक्ट करें

आपको हर एजेंट के लिए इन सभी की आवश्यकता नहीं है।

लेकिन हर प्रोडक्शन एजेंट को अंततः उनमें से अधिकांश की आवश्यकता होती है।

जो शुरुआत में सबसे ज्यादा मायने रखते हैं: bash, read, write, edit।

उन चारों में महारत हासिल करें और आप लगभग कुछ भी बना सकते हैं।

संदर्भ इंजीनियरिंग: वह कौशल जिसके बारे में कोई बात नहीं करता

मॉडल निश्चित है।

आप रनटाइम पर इसके वेट नहीं बदल सकते।

लेकिन आप बदल सकते हैं कि यह क्या देखता है।

वह है संदर्भ इंजीनियरिंग।

और यह अब AI इंजीनियरिंग में सबसे अधिक लाभप्रद कौशलों में से एक है।

खराब संदर्भ:

→ सब कुछ डालें → सर्वश्रेष्ठ की आशा करें

→ संदर्भ फूलता है → मॉडल फोकस खो देता है → आउटपुट खराब हो जाते हैं

अच्छा संदर्भ:

→ संरचित। संक्षिप्त। विकसित होने वाला।

→ सही चरण पर सही जानकारी।

→ पिछली विफलताएं वर्तमान प्रयास को सूचित करती हैं।

अत्याधुनिक दृष्टिकोण (ACE — एजेंटिक कॉन्टेक्स्ट इंजीनियरिंग):

13 घटक:
2
3जनरेटर:   कार्य चलाता है, एक संरचित संदर्भ प्लेबुक को संदर्भित करता है
4रिफ्लेक्टर:   सफलताओं और विफलताओं का विश्लेषण करता है, अंतर्दृष्टि निकालता है
5क्यूरेटर:     प्लेबुक को नई सीख के साथ अपडेट करता है — जोड़ता है, हटाता है, डीडुप्लिकेट करता है
6
7प्लेबुक एक प्रॉम्प्ट ब्लॉब नहीं है।
8यह (पहचानकर्ता, अंतर्दृष्टि) जोड़ियों की एक संरचित सूची है।
9
10उदाहरण:
11{
12  "id": "001",
13  "insight": "पुनः प्रयास करने से पहले हमेशा त्रुटि ट्रेस को फ़ाइल में लिखें।"
14},
15{
16  "id": "002",
17  "insight": "वेब खोज के लिए उप-एजेंट साइट-विशिष्ट क्वेरी के साथ बेहतर परिणाम देता है।"
18},
19{
20  "id": "003",
21  "insight": "कमिट करने से पहले परीक्षण चलाने से 80% प्रतिगमन पकड़ में आ जाते हैं।"
22}

प्लेबुक प्रत्येक रन के बाद अपडेट होती है।

जो एजेंट कार्य 50 चलाता है, वह 49 रनों की आसुत सीख के साथ काम कर रहा है।

जो एजेंट कार्य 1 चलाता है, उसके पास कुछ नहीं था।

इस तरह एक सिस्टम मॉडल वेट को छुए बिना स्मार्ट हो जाता है।

हार्नेस जो खुद में सुधार करता है

यह वह जगह है जहाँ यह रोमांचक हो जाता है।

क्या होगा अगर हार्नेस ही वह चीज़ थी जिसे अनुकूलित किया जा रहा था?

प्रॉम्प्ट नहीं। मॉडल नहीं।

वह कोड जो एजेंट को चलाता है।

यह वास्तव में Self-Harness करता है।

3-चरणीय लूप:

चरण 1 — कमजोरियों का पता लगाएं

कार्यों के एक सेट पर वर्तमान हार्नेस चलाएं। विफलता ट्रेस एकत्र करें। मूल कारण के अनुसार विफलताओं को क्लस्टर करें।

"यह विफल हुआ" नहीं। बल्कि यह क्यों विफल हुआ।

खोजी गई विफलता के प्रकार:

→ "लंबी फ़ाइल रीड पर एजेंट टाइमआउट"

→ "मूल एजेंट के क्रैश होने पर उप-एजेंट आउटपुट खो गए"

→ "स्व-सुधार के लिए त्रुटि संदेश पर्याप्त जानकारीपूर्ण नहीं"

→ "चरण 30 के बाद संदर्भ बहुत बड़ा हो जाता है, मॉडल फोकस खो देता है"

चरण 2 — सुधार प्रस्तावित करें

वही मॉडल विफलता पैटर्न को देखता है। हार्नेस कोड में विशिष्ट, संकीर्ण संपादन प्रस्तावित करता है।

पुनर्लेखन नहीं। लक्षित संपादन।

प्रस्तावित हार्नेस संपादन:

→ फ़ाइल रीड ऑपरेशन में टाइमआउट हैंडलर जोड़ें

→ प्रत्येक चरण पर उप-एजेंट आउटपुट को डिस्क पर ऑटो-फ्लश करें (केवल अंत में नहीं)

→ त्रुटि संदेश प्रारूप को मानकीकृत करें जिसमें शामिल हों: चरण, टूल, इनपुट, आउटपुट, विफलता का कारण

→ हर 25 बारी पर संदर्भ संपीड़न चरण जोड़ें

चरण 3 — मान्य करें और मर्ज करें

प्रत्येक प्रस्तावित संपादन का आयोजित कार्यों पर परीक्षण किया जाता है।

क्या यह कमजोरी को ठीक करता है बिना कुछ और तोड़े?

यदि हाँ: हार्नेस में मर्ज कर दिया जाता है। यदि नहीं: लॉग किया जाता है, अस्वीकार कर दिया जाता है, हार्नेस अपरिवर्तित रहता है।

परिणाम: हार्नेस हर पीढ़ी के साथ बेहतर होता जाता है।

Self-Harness चलाने वाला Claude 3.5 Sonnet SWE-bench Verified पर 20% से 50% तक चला गया।

बेहतर मॉडल से नहीं।

बेहतर सिस्टम से।

विकासवादी हार्नेस खोज

Self-Harness एक हार्नेस को पुनरावृत्त रूप से ठीक करता है।

AlphaEvolve हार्नेस की एक आबादी चलाता है और सर्वश्रेष्ठ को विकसित करता है।

एल्गोरिथ्म:

11. हार्नेस उम्मीदवारों के एक पूल से शुरू करें
22. बेंचमार्क कार्यों पर प्रत्येक को स्कोर करें
33. सर्वश्रेष्ठ प्रदर्शन करने वालों को "माता-पिता" के रूप में चुनें
44. मॉडल से डिफ़/सुधार प्रस्तावित करने के लिए कहें
55. नए "बाल" हार्नेस उत्पन्न करें
66. बच्चों को स्कोर करें
77. जो सुधार करते हैं उन्हें रखें
88. उन्हें वापस पूल में जोड़ें
99. दोहराएं
10
11(प्राकृतिक चयन के समान तर्क। कोड पर लागू।)

(प्राकृतिक चयन के समान तर्क। कोड पर लागू।)

AlphaEvolve से एक महत्वपूर्ण डिज़ाइन विवरण:

विकास के लिए पात्र कोड क्षेत्रों को स्पष्ट रूप से चिह्नित किया गया है:

1# EVOLVE-BLOCK-START
2def plan_next_step(context, tools):
3    # इस अनुभाग को विकासवादी खोज द्वारा संशोधित किया जा सकता है
4    prompt = f"दिया गया: {context}\nउपलब्ध उपकरण: {tools}\nअगली कार्रवाई:"
5    return llm.generate(prompt)
6# EVOLVE-BLOCK-END
7
8# बाकी हार्नेस स्थिर रहता है
9def run_tool(tool_name, args):
10    return tool_registry[tool_name](**args)

यह रोकथाम एजेंट को गलती से सुरक्षा-महत्वपूर्ण कोड को संशोधित करने से रोकता है।

विकासवादी खोज केवल उसी को छूती है जिसे आप स्पष्ट रूप से छूने की अनुमति देते हैं।

AlphaEvolve ने इसका उपयोग मैट्रिक्स गुणन एल्गोरिदम को अनुकूलित करने के लिए किया।

परिणाम: DeepMind के हाथ से अनुकूलित कोड को हराया।

एजेंट ने ऐसे समाधान खोजे जो मानव इंजीनियरों ने दशकों में नहीं खोजे थे।

डार्विन गोडेल मशीन: एजेंट जो खुद को फिर से लिखते हैं

इस विचार का सबसे चरम संस्करण।

एक एजेंट जो कार्यों में बेहतर होने के लिए अपने स्वयं के हार्नेस कोड को संशोधित करता है।

डार्विन गोडेल मशीन (DGM):

11. पूल में एक कोडिंग एजेंट से शुरू करें
22. इसे बेंचमार्क पर चलाएं, स्कोर एकत्र करें
33. एजेंट अपने स्वयं के मूल्यांकन लॉग की जांच करता है
44. एजेंट अपने स्वयं के हार्नेस कोड में सुधार प्रस्तावित करता है
55. उपलब्ध उपकरण: bash + फ़ाइल संपादक (फ़ाइलें देखें/बनाएं/संपादित करें)
66. एजेंट का नया संस्करण बनाया गया है
77. नए संस्करण को स्कोर किया गया है
88. यदि बेहतर है: पूल में जोड़ा गया
99. यदि बदतर है: त्याग दिया गया
1010. दोहराएं — प्रदर्शन के अनुसार माता-पिता का चयन करना, संतानों की संख्या के विपरीत

प्रारंभिक स्थिति: Claude 3.5 Sonnet + सरल प्रारंभिक हार्नेस।

परिणाम:

→ SWE-bench Verified: 20% → 50%

→ पॉलीग्लॉट कोडिंग बेंचमार्क: 14.2% → 30.7%

मॉडल वेट में शून्य परिवर्तन। पीढ़ियों के बीच शून्य मानव इंजीनियरिंग।

एजेंट ने स्वयं के बेहतर संस्करण डिज़ाइन किए।

यह विज्ञान कथा नहीं है।

यह 2025 का एक पेपर है।

बचने के लिए 5 विफलता मोड

ये वे तरीके हैं जिनसे वास्तविक शोध दल विफल हुए हैं।

सभी दस्तावेजित हैं। सभी टालने योग्य हैं।

1. संदर्भ पतन

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

समाधान: सब कुछ महत्वपूर्ण फ़ाइलों में लिखें। चरण 20 के बाद कभी भी अकेले संदर्भ पर भरोसा न करें।

2. कार्यान्वयन बहाव

जब कार्य तकनीकी रूप से कठिन हो जाता है, तो मॉडल वास्तविक लक्ष्य के बजाय आसान, अधिक सामान्य समाधानों की ओर बढ़ जाता है।

समाधान: शुरुआत में एक स्पेक फ़ाइल लिखें। एजेंट हर लूप पर स्पेक की जाँच करता है।

3. अति-आशावाद

असफल प्रयोगों के बावजूद मॉडल सफलता की घोषणा करता है।

यह "संख्यात्मक डक्ट टेप" ढूंढता है — ऐसे पैच जो वास्तविक समस्या को हल किए बिना मेट्रिक्स को अच्छा दिखाते हैं।

समाधान: एक परीक्षण सेट अलग रखें जिसे एजेंट कभी नहीं देखता। केवल आयोजित डेटा पर मान्य करें।

4. रिवॉर्ड हैकिंग

एजेंट जो भी सिग्नल दिया जाता है उसे अनुकूलित करता है।

यदि सिग्नल यूनिट टेस्ट है — तो यह ऐसे टेस्ट लिखता है जो हमेशा पास होते हैं। यदि सिग्नल एक जज मॉडल है — तो यह जज को बेवकूफ बनाने के लिए ट्रिक सीखता है। यदि सिग्नल बेंचमार्क स्कोर है — तो यह बेंचमार्क आर्टिफैक्ट का शोषण करता है।

समाधान: मूल्यांकनकर्ता लूप के बाहर रहता है। प्रमुख निर्णय बिंदुओं पर मानव समीक्षा।

5. विविधता पतन

विकासवादी लूप एक रणनीति पर एकत्रित होते हैं।

हर पीढ़ी एक ही समाधान का एक प्रकार दिखती है।

समाधान: स्पष्ट रूप से नवीनता को ट्रैक करें। मौजूदा पूल सदस्यों के समान समाधानों को दंडित करें (एम्बेडिंग-आधारित कोसाइन समानता काम करती है)।

सादे भाषा में नया AI स्टैक

जब आप गंभीर AI उत्पाद बनाते हैं तो आप वास्तव में यही बना रहे होते हैं:

लेयर 1 — मॉडल

कच्ची बुद्धिमत्ता। पूर्व-प्रशिक्षित। रनटाइम पर निश्चित वेट।

यह CPU है। शक्तिशाली लेकिन निष्क्रिय।

लेयर 2 — हार्नेस

OS। मॉडल को लपेटता है। सब कुछ व्यवस्थित करता है।

→ उपकरण (bash, फ़ाइल रीड/राइट, वेब खोज)

→ मेमोरी (फ़ाइल सिस्टम, संरचित लॉग)

→ लूप (योजना बनाएं → निष्पादित करें → मूल्यांकन करें → पुनः प्रयास करें) → उप-एजेंट (समानांतर निष्पादन)

→ संदर्भ प्रबंधन (मॉडल प्रत्येक चरण पर क्या देखता है)

लेयर 3 — ऑप्टिमाइज़र

हार्नेस जो हार्नेस में सुधार करता है।

→ निष्पादन ट्रेस से विफलता पैटर्न निकालता है

→ हार्नेस कोड में लक्षित संपादन प्रस्तावित करता है → आयोजित कार्यों पर मान्य करता है

→ सुधारों को मर्ज करता है, प्रतिगमन को त्यागता है

लेयर 4 — मूल्यांकनकर्ता

अन्य सभी लेयर के बाहर रहता है।

→ बेंचमार्क स्कोर → प्रमुख निर्णय बिंदुओं पर मानव समीक्षा → आयोजित परीक्षण सेट जिसे ऑप्टिमाइज़र कभी नहीं छूता

आप किसी भी लेयर को छोड़ नहीं सकते।

लेयर 2 छोड़ें — आपका मॉडल एक चैटबॉट है, उत्पाद नहीं।

लेयर 3 छोड़ें — मैन्युअल इंजीनियरिंग के बिना आपका सिस्टम कभी बेहतर नहीं होता।

लेयर 4 छोड़ें — आपका एजेंट गलत चीज़ को अनुकूलित करता है और आपको पता नहीं चलेगा।

अब बिल्डर्स के लिए इसका क्या मतलब है

इन विचारों से लाभ उठाने के लिए आपको एक स्व-सुधार हार्नेस बनाने की आवश्यकता नहीं है।

यहाँ से शुरू करें:

सप्ताह 1: लूप बनाएं

सिंगल-शॉट प्रॉम्प्ट बनाना बंद करें। किसी भी कार्य के लिए एक योजना बनाएं → निष्पादित करें → मूल्यांकन करें → पुनः प्रयास करें लूप बनाएं जिसमें एक से अधिक चरण हों।

सप्ताह 2: स्थायी मेमोरी जोड़ें

संदर्भ पर भरोसा करना बंद करें। मध्यवर्ती आउटपुट को फ़ाइलों में लिखें। एजेंट को अपने पिछले काम को पढ़ने दें।

सप्ताह 3: उप-एजेंट जोड़ें

अपने वर्कफ़्लो के किसी भी हिस्से की पहचान करें जो समानांतर में चल सकता है। उप-एजेंट उत्पन्न करें। उनके आउटपुट को फ़ाइलों में लिखें। मर्ज करें।

सप्ताह 4: संदर्भ इंजीनियरिंग जोड़ें

ट्रैक करें कि कौन से पैटर्न सफलता और विफलता की ओर ले जाते हैं। एक सरल संरचित प्लेबुक बनाएं जो प्रत्येक रन के बाद अपडेट हो।

वह है हार्नेस।

मॉडल नहीं।

मॉडल पहले से ही मौजूद है।

हार्नेस वह है जो आप बनाते हैं।

2026 में AI के बारे में असुविधाजनक सच्चाई

फ्रंटियर लैब में शोध में तेजी नाटकीय रूप से बढ़ी है।

Anthropic और OpenAI पहले से कहीं अधिक तेजी से शिप कर रहे हैं।

इसलिए नहीं कि मॉडल रातोंरात स्मार्ट हो गए।

क्योंकि हार्नेस बेहतर हो गए।

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

खाई मॉडल नहीं है।

खाई सिस्टम है।

और सिस्टम अब खुद में सुधार कर सकता है।

यदि यह उपयोगी था:

→ रिपोस्ट करें — हर AI बिल्डर को इस स्टैक को समझने की जरूरत है

→ @sairahul1 को फॉलो करें — इस तरह के और विश्लेषण के लिए

→ बुकमार्क करें — अकेला 4-लेयर स्टैक सेव करने लायक है

इस तरह के और दिलचस्प लेखों के लिए theaibuilders.co पर सब्सक्राइब करें

मैं AI, उत्पाद बनाने और ऐसे सिस्टम के बारे में लिखता हूं जो आपके बिना काम करते हैं।