एक एजेंट जो अपने आप बेहतर होता है: Orkas के स्व-विकास के भीतर

अधिकांश AI सहायक "इस्तेमाल करो और भूल जाओ" जैसे हैं। आज कोई आदत सुधारें तो कल वे वही गलती दोहराते हैं; पिछले हफ़्ते उन्हें अपनी टीम का खास कार्यप्रवाह सिखाएँ तो इस हफ़्ते वे ऐसे पेश आते हैं जैसे कभी सुना ही न हो। हर बातचीत शून्य से शुरू होती है — और मॉडल कितना भी समझदार हो, वह फिर भी भूलने की बीमारी वाला एक समझदार व्यक्ति है।

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

यह लेख बताता है कि यह तंत्र कैसे बनाया गया है। यह "मॉडल को बातचीत याद रखने दो" जितना सरल नहीं है — इसके पीछे एक पूरा चक्र है: खुद का अवलोकन करना → तय करना कि आत्मचिंतन करना है या नहीं → वास्तव में आत्मचिंतन करना → निष्कर्षों को दोबारा इस्तेमाल योग्य रूप में लिखना → अगली बार फिर इस्तेमाल करना। हम इसे एक-एक हिस्से में समझेंगे।

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

पूरा चक्र, शुरुआत से अंत तक

बार-बार वास्तविक उपयोग
      │  स्थानीय रिकॉर्ड: कौन-से टूल कॉल हुए, त्रुटियाँ हुईं या नहीं, सुधार हुआ या नहीं
      ▼
   संकेत इकट्ठे होते हैं
      │  बातचीत से वहीं संकेत निकाले जाते हैं, सब डिवाइस पर रहते हैं
      ▼
  तय करें कि आत्मचिंतन करना है या नहीं
      │  संकेतों का भारित स्कोर, सीमा पार होने पर ही सक्रिय; नेटवर्क की गड़बड़ियाँ नहीं गिनी जातीं
      ▼
   पृष्ठभूमि में आत्मचिंतन
      │  हर बारी नहीं — समय-समय पर, योग्य एजेंटों को चुनकर
      ▼
  दो चीज़ों में सार निकाला जाता है
      │  ① दोबारा इस्तेमाल योग्य "स्किल"   ② अपने बारे में "समझ"
      ▼
  अगली बारी में अपने आप शामिल
      └──────────► फिर शुरुआत पर, चक्र चलता रहे

इस चक्र के हर चरण में बारीकियाँ हैं। जिन जगहों पर गलती करना सबसे आसान है, वे वही दो चरण हैं जो पहली नज़र में सबसे सरल लगते हैं: आत्मचिंतन कब करना है, और करने के बाद क्या दर्ज करना है। शुरुआत से शुरू करते हैं।

चरण 1: लगभग बिना लागत के खुद का अवलोकन

अनुभव से सीखने के लिए पहले देखने लायक "अनुभव" चाहिए। हर एजेंट रन के अंत में प्रोग्राम स्थानीय तौर पर, उसी समय, कुछ हल्के तथ्य गिनता है: इस बारी में लगभग कितने टूल कॉल हुए, कोई त्रुटि हुई या नहीं, वह अस्थायी त्रुटि थी (जैसे नेटवर्क की समस्या) या वास्तविक, और उपयोगकर्ता ने उसी समय उसे सुधारा या नहीं। बस कुछ गिनतियाँ और संकेतक, जिनकी गणना पूरी तरह मशीन पर होती है, बिना किसी मॉडल को कॉल किए और बिना कहीं भेजे।

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

"सुधारा गया या नहीं" वाला हिस्सा थोड़ा दिलचस्प है। यह पूरी तरह अनुमान-आधारित स्थानीय निर्णय है, जो आपके डिवाइस पर संदेश के कुछ वाक्यांशों का मिलान करके लगाया जाता है — चीनी में "不对" / "应该是" / "重新", अंग्रेज़ी में जैसे wrong, actually, instead। इसका उद्देश्य सटीक होना नहीं है — यह केवल एक संकेत है, फैसला नहीं, और कभी-कभार गलत सकारात्मक संकेत स्वीकार्य है, क्योंकि बाद में इसे दूसरे संकेतों के साथ भार दिया जाता है; अकेले इसके आधार पर कुछ तय नहीं होता।

चरण 2: आत्मचिंतन करना वास्तव में कब उपयोगी है

मेरे विचार से पूरे तंत्र का यही हिस्सा सबसे अधिक कौशल दिखाता है।

सरल तरीका है "N घटनाएँ इकट्ठी हो जाएँ तो आत्मचिंतन करो।" लेकिन यह मोटा तरीका है: लगातार तीन नेटवर्क टाइमआउट और उपयोगकर्ता के लगातार तीन सुधार स्पष्ट रूप से एक ही बात नहीं हैं और उन्हें एक जैसा नहीं मानना चाहिए। Orkas इस्तेमाल करता है कई संकेतों की भारित स्कोरिंग: हर उल्लेखनीय घटना एक भार वाला संकेत है; इस बारी सक्रिय हुए संकेतों के भार जोड़ें, और कुल स्कोर सीमा (डिफ़ॉल्ट रूप से 0.7) पार करे तभी आत्मचिंतन करें।

मुख्य संकेत मोटे तौर पर ऐसे हैं:

उदाहरण के लिए: किसी बारी में उपयोगकर्ता का सुधार (0.9) और कुछ जटिलता (0.5), दोनों हों तो कुल 1.4 बनता है, जो 0.7 से काफ़ी अधिक है, इसलिए आत्मचिंतन होता है; केवल थोड़ी जटिलता (0.5) वाली बारी सीमा तक नहीं पहुँचती और छोड़ दी जाती है। भार देना भी एक विवेकपूर्ण चुनाव दर्शाता है — उपयोगकर्ता के सीधे सुधार को सबसे अधिक भार, 0.9, मिलता है, क्योंकि यह सबसे अधिक संकेत-से-शोर अनुपात वाला फ़ीडबैक है: उपयोगकर्ता ने साफ़ कहा है कि आप गलत हैं, इसलिए इसे दर्ज करना बहुत संभव है कि उपयोगी हो।

वह एक बेहद ज़रूरी अपवाद

पूरे स्कोरिंग तर्क में एक नियम है जिसे मैं इस बात की कसौटी मानता हूँ कि यह तंत्र "सही चीज़ें सीखता है" या नहीं: अस्थायी त्रुटियाँ कभी नहीं गिनी जातीं।

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

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

चरण 3: आत्मचिंतन पृष्ठभूमि में होता है, आपके सामने नहीं

एक आसान जाल: जैसे ही पता चले कि "आत्मचिंतन का समय है", वहीं रुककर आत्मचिंतन करने लगें। इससे एजेंट बीच-बीच में अटकता हुआ लगता है, मानो "जीवन पर विचार" करने निकल गया हो — यह खराब अनुभव है।

Orkas आत्मचिंतन को एक तय अंतराल पर पृष्ठभूमि में चलाता है। समय-निर्धारण के नियम मोटे तौर पर ये हैं:

• कुछ-कुछ समय बाद आत्मचिंतन चक्र शुरू करें (मान लें, एक दर्जन से अधिक घंटों के अंतराल पर)।
• एक ही एजेंट के दो आत्मचिंतनों के बीच न्यूनतम विराम (कुछ घंटे) रखें, ताकि यह बहुत बार न चले।
• लेकिन अगर बहुत समय से आत्मचिंतन न हुआ हो (मान लें, एक हफ़्ते से अधिक), तो एक बार अनिवार्य करें, ताकि यह अनिश्चित समय तक टलता न रहे।
• हर चक्र में चुने जाने वाले एजेंटों की संख्या सीमित रखें, ताकि एक साथ बहुत अधिक काम न फैल जाए।

एक छोटा-सा डिज़ाइन मुझे पसंद है, जिसे कहते हैं बदलाव-जाँच द्वार: चक्र शुरू होने पर पहले जाँचें कि इस एजेंट के पास पिछले आत्मचिंतन के बाद कुछ नया है या नहीं — कोई नए संकेत, कोई अपडेट हुए बातचीत रिकॉर्ड। अगर कोई बदलाव ही नहीं है, तो इस बार इसे छोड़ दें और मॉडल की लागत वाला आत्मचिंतन व्यर्थ न करें। सरल है, लेकिन व्यवहार में बहुत बचत करता है।

चरण 4: आत्मचिंतन वास्तव में कैसे होता है

जब सचमुच आत्मचिंतन का समय आता है, तो प्रक्रिया यह है: पहले हाल की गतिविधि को एक "पैकेट" में व्यवस्थित करें, फिर उसे सावधानी से लिखे प्रॉम्प्ट के साथ मॉडल को पढ़ने और सार निकालने के लिए दें।

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

असली सावधानी प्रॉम्प्ट में चाहिए। वह मॉडल से "विवरण" नहीं, बल्कि यह देने को कहता है: अमल करने योग्य निर्देश। अंतर छोटा दिखता है, लेकिन बहुत मायने रखता है। तुलना करें:

✗ "एजेंट का आउटपुट कभी-कभी बहुत लंबा होता है; ध्यान रखें।"

✓ "फ़ैमिली ऑफ़िस से जुड़े सवालों का जवाब देते समय कभी भी 5 बुलेट बिंदुओं से अधिक न दें।"

✗ "लगता है उपयोगकर्ता संक्षिप्त आउटपुट पसंद करता है।"

✓ "फ़ैमिली ऑफ़िस के संदर्भ में जवाब देते समय हमेशा पहले मुख्य निष्कर्ष दें, फिर उसका तर्क।"

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

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

दो चीज़ों में निकला सार

आत्मचिंतन का आउटपुट दो जगह जाता है।

एक है स्किल। हर स्किल मेटाडेटा वाला एक Markdown दस्तावेज़ है — फ्रंटमैटर ब्लॉक में नाम, विवरण, बनाए और अपडेट किए जाने का समय, कितनी बार पैच किया गया, और आखिरी बार कब इस्तेमाल हुआ, दर्ज होते हैं — जिसके बाद वास्तविक चरण या मुख्य बातें आती हैं:

---
name: "Weekly Report Export"
description: "Compile this week's data into the standard weekly-report format"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---

## Steps
1. ...
2. ...

स्किल को फ़ाइलों के रूप में रखना एक व्यावहारिक चुनाव है: कोई व्यक्ति उन्हें सीधे पढ़ और संपादित कर सकता है — वे किसी अपारदर्शी डेटाबेस में बंद नहीं रहतीं।

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

स्किल सिर्फ़ लिखकर छोड़ देने के लिए नहीं हैं

सिर्फ़ स्किल बनाते जाएँ तो समय के साथ कबाड़ जमा हो जाता है। इसलिए स्किल का पूरा जीवनचक्र होता है।

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

संख्या की भी सीमा है। स्किल की कुल संख्या सीमित होती है (मान लें, 200); भर जाने पर नई स्किल जोड़ने के लिए पुरानी स्किल हटाई जाती है LRU (सबसे लंबे समय से इस्तेमाल न हुई) के ज़रिए, ताकि जगह बने। हटाने में एक प्राथमिकता है: पहले उन्हें निकालें जो बनने के बाद कभी इस्तेमाल नहीं हुईं — जो स्किल कभी पढ़ी ही नहीं गई, उसका सार शायद शुरुआत में ठीक से निकाला ही नहीं गया था, और उसका जगह छोड़ना बेहतर है।

जब भी एजेंट कोई स्किल पढ़ता है, उसका "अंतिम इस्तेमाल का समय" अपडेट होता है। यह टाइमस्टैम्प LRU के हटाने के निर्णय में काम आता है और स्थानीय तंत्र को यह भी बताता है कि कौन-सी स्किल वास्तव में इस्तेमाल हो रही हैं और कौन-सी सिर्फ़ जगह घेर रही हैं।

कैसे पता चले कि कोई स्किल वास्तव में उपयोगी है

यही वह चरण है जिसे कई "अपने आप सीखने वाली" प्रणालियाँ लापरवाही से छोड़ देती हैं: कुछ सीख तो लिया — लेकिन क्या वह अच्छा है? Orkas इसे स्थानीय तौर पर कुछ मापों में बदलता है। इनकी गणना मशीन पर चलने वाले विकास तंत्र के अपने उपयोग के लिए होती है — यह तय करने के लिए कि किस स्किल को बदलना या हटाना है — और ये भी कभी इस मशीन से बाहर नहीं जाते।

तंत्र यह है: हर बारी की शुरुआत में उपलब्ध स्किल सिस्टम प्रॉम्प्ट की सूची में दिखाई देती हैं — यह एक "प्रदर्शन" है; अगर एजेंट उस बारी वास्तव में किसी स्किल को पढ़ता है, तो वह एक "उपयोग" है। दोनों की तुलना से पहला माप मिलता है —

• उपयोग दर = उपयोग / प्रदर्शन। जो स्किल दिन-ब-दिन वहाँ पड़ी रहे और कोई उसे न चुने, उसकी उपयोग दर कम होगी, जिसका मतलब है कि वह या तो बेकार है या उसका विवरण ऐसा है कि किसी को समझ नहीं आता कि उसे कब इस्तेमाल करना है।
• उपयोग के बाद संपादन दर = उन मौकों का अनुपात जब स्किल इस्तेमाल हुई, लेकिन उपयोगकर्ता ने बाद में परिणाम हाथ से संपादित किया। अधिक दर का मतलब है कि स्किल का बनाया परिणाम उपयोगकर्ता की पसंद से पूरी तरह मेल नहीं खाता।
• निष्प्रभाविता दर = उन मौकों का अनुपात जब स्किल इस्तेमाल हुई, लेकिन बारी किसी गैर-अस्थायी त्रुटि पर समाप्त हुई। अधिक दर संकेत देती है कि स्किल में ही कुछ गलत हो सकता है।

यहाँ उस अपवाद की झलक फिर दिखती है: निष्प्रभाविता दर निकालते समय अस्थायी त्रुटियाँ नहीं गिनी जातीं, और न ही वे बारियाँ जिन्हें उपयोगकर्ता ने बीच में खुद रोक दिया — नेटवर्क की एक गड़बड़ी के कारण पूरी तरह अच्छी स्किल पर दाग नहीं लगाया जा सकता।

इन कुछ संख्याओं के साथ स्किल "बंद डिब्बे में जमा होने वाली चीज़" से "ऐसी चीज़ जिसका मूल्यांकन और सुधार हो सकता है" बन जाती हैं। किस स्किल को बदलना या हटाना है, यह अब सिर्फ़ अंदाज़े का निर्णय नहीं रहता।

चक्र को पूरा करना

ऊपर की बातों को जोड़ें तो एक पूरा चक्र ऐसे चलता है:

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

चक्र दौर-दर-दौर चलता रहता है। हर दौर कोई बड़ी छलाँग नहीं लाता, लेकिन दिशा एक ही है: आपको बेहतर समझना और वही गलतियाँ कम दोहराना।

कुछ समझौते जिनका ज़िक्र ज़रूरी है

पीछे मुड़कर देखें तो इस तंत्र के कुछ निर्णय अहम हैं।

आत्मनिरीक्षण सस्ता होना चाहिए। खुद का अवलोकन ऐसे मापों से होता है जिनकी मॉडल लागत शून्य है; वास्तव में महँगा आत्मचिंतन पृष्ठभूमि में ले जाया जाता है, कम बार चलता है, और उससे पहले बदलाव की जाँच होती है। "महँगे" हिस्से पर कड़ा नियंत्रण हो, तो पूरा तंत्र सचमुच चल सकता है।

गलत सीखने से बेहतर है न सीखना। अस्थायी त्रुटियों का अपवाद, आत्मचिंतन को "कुछ भी न सहेजने" देना, अस्पष्ट विवरणों के बजाय अमल योग्य निर्देश लिखना — सब एक ही सोच की ओर इशारा करते हैं: खुद को सुधारने वाली प्रणाली के लिए गलत दिशा में सीखना, धीरे सीखने से कहीं अधिक खतरनाक है।

जो सीखा जाए, वह दिखाई देना चाहिए, संपादन योग्य होना चाहिए और आपके नियंत्रण में होना चाहिए। स्किल साधारण टेक्स्ट फ़ाइलें हैं, स्व-समझ साधारण टेक्स्ट का ज्ञापन है, स्किल की प्रभावशीलता मापों से जाँची जा सकती है — और ये सभी फ़ाइलें आपकी अपनी मशीन पर हैं, क्लाउड में नहीं। कहीं कोई बंद डिब्बा नहीं; इंसान कभी भी खोलकर बदलाव कर सकता है।

सीखने पर लगाम रखें। संख्या की सीमा, LRU से हटाना, लंबाई की सीमा — इनके बिना "लगातार सीखना" देर-सबेर "लगातार फूलना" बन जाता है। भूलना, छोड़ना और छाँटना उतना ही महत्त्वपूर्ण है जितना याद रखना।

समापन

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

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

यह धीमा चक्र जिन विशेषज्ञ एजेंटों पर आधारित है, उन्हें देखने के लिए देखें Orkas एजेंट टीम.