എല്ലാ ഏജന്റ് സിസ്റ്റങ്ങളും ഒരേപോലെ അസ്വസ്ഥതയുണ്ടാക്കുന്ന ഒരു വിട്ടുവീഴ്ച നേരിടുന്നുണ്ട്. കോഡ് റിവ്യൂകൾക്കും ഗിറ്റ് ഹിസ്റ്ററിക്കും അനുയോജ്യമായ രീതിയിൽ ആഴത്തിലുള്ളതും കൃത്യമായി ക്രമീകരിച്ചതുമായ ഒരു നോളജ് ബേസ് നിങ്ങൾക്ക് വേണം. എന്നാൽ റൺടൈം വേഗത്തിൽ പ്രവർത്തിക്കുകയും ശ്രദ്ധ കേന്ദ്രീകരിക്കുകയും ചെയ്യേണ്ടതുമുണ്ട്. ഈ രണ്ട് ആവശ്യങ്ങളും പരസ്പരം വിരുദ്ധമാണ്. കൂടുതൽ നിർദ്ദേശങ്ങൾ നിങ്ങൾ സൂക്ഷിച്ചുവെക്കുന്തോറും, അവയെല്ലാം പ്രോംപ്റ്റിലേക്ക് നേരിട്ട് നൽകി നല്ലത് സംഭവിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നത് പ്രലോഭനമായി മാറും. ആ പ്രതീക്ഷയ്ക്ക് വലിയ വില നൽകേണ്ടി വരും.
Agent Project Context ഇക്കോസിസ്റ്റത്തിൽ, ഈ സംഘർഷം രണ്ട് പാളികളിലായി കൃത്യമായി വിഭജിക്കപ്പെട്ടിരിക്കുന്നു. APC ഡ്യൂറബിലിറ്റി (durability) കൈകാര്യം ചെയ്യുന്നു. APX വേഗത കൈകാര്യം ചെയ്യുന്നു. അവ എങ്ങനെ പരസ്പരം പ്രവർത്തിക്കുന്നുവെന്നും, എന്തുകൊണ്ടാണ് APX എല്ലാ സ്കിൽ ഡെഫനിഷനുകളും പ്രീലോഡ് ചെയ്യാൻ വിസമ്മതിക്കുന്നതെന്നും മനസ്സിലാക്കുന്നത്, മിക്ക ഒപ്റ്റിമൈസേഷൻ ഗൈഡുകളെക്കാളും കൂടുതൽ കാര്യങ്ങൾ പ്രോംപ്റ്റ് എഞ്ചിനീയറിംഗിനെക്കുറിച്ച് നിങ്ങൾക്ക് പറഞ്ഞുതരും.
ആർക്കൈവും എൻജിനും
APC-യുടെ ജോലി സ്ഥിരത ഉറപ്പാക്കുക എന്നതാണ്. ഇത് പുനരുപയോഗിക്കാവുന്ന സ്കിൽ ഫയലുകൾ .apc/skills/ എന്ന ഫോൾഡറിൽ പ്ലെയിൻ മാർക്ക്ഡൗൺ ഡോക്യുമെന്റുകളായി സൂക്ഷിക്കുന്നു. ഈ ഫയലുകൾ നിങ്ങളുടെ റെപ്പോസിറ്ററിനുള്ളിൽ ഉള്ളതുകൊണ്ട്, അവ വെർഷൻ കൺട്രോളിനൊപ്പം (version control) നിലനിൽക്കുന്നു. ഒരു ഡിപ്ലോയ്മെന്റ് നടപടിക്രമം മാറ്റുന്നതിനായി നിങ്ങൾക്ക് ഒരു പുൾ റിക്വസ്റ്റ് (pull request) തുറക്കാം. ആറ് ആഴ്ച മുമ്പുള്ള ഒരു സെക്യൂരിറ്റി പോളിസി റോളബാക്ക് (rollback) നിങ്ങൾക്ക് താരതമ്യം (diff) ചെയ്യാം. ഏജന്റ് എപ്പോൾ എന്താണ് അറിഞ്ഞിരിക്കേണ്ടിയിരുന്നത് എന്ന് നിങ്ങൾക്ക് കൃത്യമായി ഓഡിറ്റ് ചെയ്യാം. ഒരു തെറ്റായ ഡിപ്ലോയ്മെന്റ് നടപ്പിലാകുമ്പോഴോ അല്ലെങ്കിൽ ഒരു കംപ്ലയൻസ് ഓഡിറ്റർ ചോദ്യങ്ങൾ ചോദിച്ചു തുടങ്ങുമ്പോഴോ ഈ പരിശോധനാക്ഷമത (reviewability) വളരെ പ്രധാനമാണ്.
മറുവശത്ത്, APX നിലവിലെ സാഹചര്യത്തിലാണ് പ്രവർത്തിക്കുന്നത്. നിങ്ങൾക്കും മോഡലിനും ഇടയിലുള്ള യഥാർത്ഥ സംഭാഷണമാണ് ഇത് കൈകാര്യം ചെയ്യുന്നത്. അറിവ് ആർക്കൈവ് ചെയ്യുക എന്നതല്ല, മറിച്ച് അത് കൃത്യമായി ഉപയോഗിക്കുക എന്നതാണ് ഇതിന്റെ ലക്ഷ്യം. APX സ്കില്ലുകളെ സ്ഥിരമായ ഭാരമായി (permanent baggage) കാണുമ്പോൾ, മുഴുവൻ സിസ്റ്റവും സാവധാനത്തിലാകുന്നു. കോൺടെക്സ്റ്റ് വിൻഡോ (context window) നിറയുന്നു. ടോക്കൺ ചിലവ് വർദ്ധിക്കുന്നു. അതിലും മോശമായ കാര്യം, നിലവിലെ അഭ്യർത്ഥനയുമായി യാതൊരു ബന്ധവുമില്ലാത്ത നിർദ്ദേശങ്ങളിലേക്ക് മോഡലിന്റെ ശ്രദ്ധ ചിതറിപ്പോകുന്നു എന്നതാണ്.
അതുകൊണ്ടാണ് സ്കിൽ ബോഡികൾ ആവശ്യാനുസരണം (on demand) ലോഡ് ചെയ്യുന്നത്.
അമിതമായി നിറഞ്ഞ പ്രോംപ്റ്റുകളുടെ യഥാർത്ഥ വില
ടോക്കണുകൾക്ക് പണം ചിലവാകുമെന്ന് മിക്ക ടീമുകളും മനസ്സിലാക്കുന്നുണ്ട്. എന്നാൽ അപ്രസക്തമായ ടോക്കണുകൾ കൃത്യതയെ (accuracy) ബാധിക്കുമെന്ന് കുറച്ചുപേർ മാത്രമേ തിരിച്ചറിയുന്നുള്ളൂ.
APX ലഭ്യമായ എല്ലാ സ്കില്ലുകളും ഓരോ ഘട്ടത്തിലും (turn) ഉൾപ്പെടുത്തുമ്പോൾ, പ്രോംപ്റ്റ് അനാവശ്യ വിവരങ്ങളാൽ നിറയുന്നു (noisy). ഡിപ്ലോയ്മെന്റ് റൺബുക്ക്, സെക്യൂരിറ്റി ഗൈഡ്, API സ്റ്റൈൽ റഫറൻസ്, ടെസ്റ്റിംഗ് ചെക്ക്ലിസ്റ്റ്, ഓൺബോർഡിംഗ് FAQ എന്നിവയെല്ലാം മോഡലിന് ഒരേസമയം ലഭിക്കുന്നു. വലിയ കോൺടെക്സ്റ്റ് വിൻഡോ ഉണ്ടെങ്കിൽ പോലും, കൃത്യമായ വിവരങ്ങൾ കണ്ടെത്തുന്നതിനായി മോഡൽ ആദ്യം അനാവശ്യ വിവരങ്ങൾക്കിടയിൽ നിന്ന് തിരയേണ്ടി വരുമ്പോൾ അതിന്റെ യുക്തിപരമായ ചിന്താശേഷി (reasoning quality) കുറയുന്നു. ലോക്കൽ ടെസ്റ്റ് സെറ്റപ്പിനെക്കുറിച്ചുള്ള ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുമ്പോൾ, പ്രൊഡക്ഷൻ ഡിപ്ലോയ്മെന്റുകൾക്കായി ഉദ്ദേശിച്ച ഒരു സെക്യൂരിറ്റി ആവശ്യകതയിലേക്ക് മോഡൽ ശ്രദ്ധ മാറ്റിയേക്കാം. ഒരു ലളിതമായ ബഗ് ഫിക്സിംഗിൽ റിലീസ് ചെക്ക്ലിസ്റ്റിലെ ഘട്ടങ്ങൾ മോഡൽ തെറ്റായി ഉൾപ്പെടുത്തിയേക്കാം (hallucinate). ബന്ധമില്ലാത്ത ഓരോ അധിക ഖണ്ഡികയും ശ്രദ്ധ തിരിക്കുന്ന ഘടകങ്ങളാണ്.
ഇതിലെ കണക്ക് ലളിതമാണ്. മിക്ക ഘട്ടങ്ങളിലും മിക്ക സ്കില്ലുകളും ആവശ്യമില്ല. ഒരു എറർ ലോഗിന് (error log) പെട്ടെന്നുള്ള പരിഹാരം നിങ്ങൾ തേടുകയാണെങ്കിൽ, ഡിപ്ലോയ്മെന്റ് റൺബുക്കിന്റെയോ സെക്യൂരിറ്റി ഹാർഡനിംഗ് ഗൈഡിന്റെയോ പൂർണ്ണരൂപം നിങ്ങൾക്ക് ആവശ്യമില്ല. എറർ കാണാനും, നിങ്ങളുടെ പ്രോജക്റ്റ് രീതികൾ മനസ്സിലാക്കാനും, ശരിയായ ഫയൽ എഡിറ്റ് ചെയ്യാനും മോഡലിനെ സഹായിക്കുകയാണ് വേണ്ടത്. അപ്രസക്തമായ സ്കിൽ ബോഡികൾ ലോഡ് ചെയ്യുന്നത് ഇതിന് സഹായിക്കില്ല. പകരം, യഥാർത്ഥ പ്രശ്നത്തിൽ പ്രവർത്തിച്ചു തുടങ്ങുന്നതിന് മുമ്പ് തന്നെ ഉപയോഗശൂന്യമായ വിവരങ്ങൾ ഒഴിവാക്കാൻ ഇത് മോഡലിനെ നിർബന്ധിക്കുന്നു.
ഓൺ-ഡിമാൻഡ് ലോഡിംഗ് എങ്ങനെ പ്രവർത്തിക്കുന്നു
ഈ സംവിധാനം ലളിതമാണെങ്കിലും വളരെ കൃത്യതയോടെ രൂപകൽപ്പന ചെയ്തതാണ്. APC യഥാർത്ഥ വിവരങ്ങൾ (ground truth) സൂക്ഷിച്ചുവെക്കുന്നു. നിങ്ങളുടെ സ്കിൽ ഡെഫനിഷനുകൾ അവയുടെ സ്ഥാനത്ത് തന്നെ നിലനിൽക്കുന്നു: .apc/skills/<name>.md.
APX ആ ഫയലുകളെ ആക്റ്റീവ് മെമ്മറിയിലേക്ക് പകർത്തി വെക്കുന്നില്ല. പകരം, സ്കിൽ പേരുകളുടെ ഒരു ചെറിയ രജിസ്ട്രി (registry) ഇത് തയ്യാറാക്കുന്നു. മോഡൽ ഈ ലിസ്റ്റ് കാണുകയും ഒരു കാറ്റലോഗ് ഉണ്ടെന്ന് മനസ്സിലാക്കുകയും ചെയ്യുന്നു. ലഭ്യമായ കഴിവുകൾ പരിശോധിക്കാനോ സ്ഥിരീകരിക്കാനോ ആവശ്യമുണ്ടെങ്കിൽ, അതിന് ഒരു list_skills കോൾ ഉപയോഗിക്കാം. ഇത് വലിയ അളവിലുള്ള വിവരങ്ങൾ നൽകാതെ തന്നെ കാര്യങ്ങൾ മനസ്സിലാക്കാൻ സഹായിക്കുന്നു.
ഒരു സ്കിൽ ഫയലിൽ രേഖപ്പെടുത്തിയിരിക്കുന്ന കൃത്യമായ സിന്റാക്സ് (syntax), വിശദമായ ഘട്ടങ്ങൾ, അല്ലെങ്കിൽ പ്രത്യേക നിയന്ത്രണങ്ങൾ (constraints) ഒരു ടാസ്കിന് ആവശ്യമായി വരുമ്പോൾ, മോഡൽ load_skill വിളിക്കുന്നു. ആ സമയത്ത് മാത്രം, APX ആ ഫയലിലെ പൂർണ്ണമായ മാർക്ക്ഡൗൺ ബോഡി APC-യിൽ നിന്ന് എടുത്ത് കോൺടെക്സ്റ്റിലേക്ക് ഉൾപ്പെടുത്തുന്നു. നിർദ്ദേശം കൃത്യസമയത്ത് ലഭിക്കുകയും അതിന്റെ ആവശ്യത്തിനായി ഒരിക്കൽ മാത്രം ഉപയോഗിക്കുകയും ചെയ്യുന്നു, അതിനാൽ അനാവശ്യ ഭാരമായി അത് സിസ്റ്റത്തിൽ തുടരുന്നില്ല.
ഒരു ലൈബ്രറി ഇംപോർട്ട് ചെയ്യുന്നതും (importing a library), എല്ലാ ഫങ്ക്ഷൻ ഡെഫനിഷനുകളും നിങ്ങളുടെ മെയിൻ ഫയലിലേക്ക് കോപ്പി പേസ്റ്റ് ചെയ്യുന്നതും തമ്മിലുള്ള വ്യത്യാസം ചിന്തിച്ചുനോക്കൂ. ഒരു രീതി നിങ്ങളുടെ കോഡ് ബേസിനെ (codebase) എളുപ്പത്തിൽ കൈകാര്യം ചെയ്യാവുന്നതാക്കി മാറ്റുന്നു. മറ്റേ രീതി അബദ്ധവശാൽ മാത്രം പ്രവർത്തിക്കുന്ന ഒരു കുഴപ്പമായി മാറുന്നു.
സ്കില്ലുകൾ തമ്മിൽ കൂട്ടിമുട്ടുമ്പോൾ ആര് ജയിക്കും
സ്കില്ലുകൾ ലോഡ് ചെയ്യുമ്പോൾ APX വ്യക്തമായ മുൻഗണനാ ക്രമം (priority order) പാലിക്കുന്നുണ്ട്. എല്ലാ സാഹചര്യങ്ങളും ഒരുപോലെയല്ല, അതിനാൽ പൊതുവായ നിർദ്ദേശങ്ങൾ ഒരിക്കലും പ്രാദേശികമായ അറിവിനെ (local knowledge) മറികടക്കാൻ പാടില്ല.
പ്രോജക്റ്റ് സ്കില്ലുകൾക്കാണ് (Project skills) ഏറ്റവും ഉയർന്ന മുൻഗണന. ഈ ഫയലുകൾ നിങ്ങളുടെ നിലവിലെ റെപ്പോസിറ്ററിയിലെ .apc/skills/ എന്ന ഫോൾഡറിലാണ് സ്ഥിതി ചെയ്യുന്നത്. അവ നിങ്ങളുടെ ടീമിന്റെ പ്രത്യേക രീതികൾ (conventions), നിങ്ങളുടെ കസ്റ്റം റാപ്പറുകൾ (custom wrappers), പഴയ നാമകരണ മാനദണ്ഡങ്ങൾ (legacy naming standards), നിങ്ങളുടെ പ്രത്യേക ടൂൾചെയിൻ (toolchain) എന്നിവ ഉൾക്കൊള്ളുന്നു. നിങ്ങളുടെ പ്രോജക്റ്റ് ഡാറ്റാബേസ് മൈഗ്രേഷനുകൾ കൈകാര്യം ചെയ്യുന്നതിന് സ്വന്തമായ ഒരു രീതി നിർവചിച്ചിട്ടുണ്ടെങ്കിൽ, ആ നിർവചനത്തിനാണ് മുൻഗണന ലഭിക്കുക.
അടുത്തത് ഗ്ലോബൽ സ്കില്ലുകളാണ് (Global skills). പ്രോജക്റ്റിൽ പ്രത്യേക നിർദ്ദേശങ്ങൾ ഇല്ലാത്തപ്പോൾ പ്രയോഗിക്കാൻ കഴിയുന്ന, സ്ഥാപനവ്യാപകമായ രീതികളെ ഇവ ഉൾക്കൊള്ളുന്നു. ഇവ ഒരു സ്റ്റാൻഡേർഡ് ലൈബ്രറി പോലെ പ്രവർത്തിക്കുന്നു.
ബിൽറ്റ്-ഇൻ റൺടൈം സ്കില്ലുകൾ (Built-in runtime skills) ഏറ്റവും താഴെയായി ഒരു ഫാള்பാക്ക് (fallback) ആയി നിലകൊള്ളുന്നു. എല്ലാ ഏജന്റുകളും മനസ്സിലാക്കേണ്ട പൊതുവായ കഴിവുകളെ (generic capabilities) ഇവ കൈകാര്യം ചെയ്യുന്നു, എന്നാൽ ഒരു പ്രത്യേക പ്രോജക്റ്റും ഇവയെ വീണ്ടും നിർവചിക്കാൻ ശ്രമിച്ചിട്ടില്ലാത്ത കാര്യങ്ങളാണിവ.
ഈ പാളികളായുള്ള സമീപനം (layered approach) നിങ്ങളുടെ റെപ്പോസിറ്ററിക്ക് അതിന്റെ സ്വഭാവത്തിന്മേൽ നിയന്ത്രണം നിലനിർത്താൻ സഹായിക്കുന്നു. നിങ്ങളുടെ ടീം ബോധപൂർവ്വം കസ്റ്റമൈസ് ചെയ്ത ഒരു വർക്ക്ഫ്ലോയെ (workflow) ഒരു ഗ്ലോബൽ അല്ലെങ്കിൽ ബിൽറ്റ്-ഇൻ സ്കില്ലിന് അബദ്ധവശാൽ തടസ്സപ്പെടുത്താനോ (hijack) മാറ്റം വരുത്താനോ കഴിയില്ല.
ഇത് പ്രായോഗികമായി എങ്ങനെയിരിക്കും
ഒരു സാധാരണ മെയിന്റനൻസ് ടാസ്ക് (maintenance task) സങ്കൽപ്പിക്കുക. ഒരു സഹപ്രവർത്തകൻ ചാറ്റിൽ ഒരു എറർ ലോഗ് (error log) പേസ്റ്റ് ചെയ്യുന്നു. ട്രേസ്ബാക്ക് (traceback) ഒരു യൂട്ടിലിറ്റി മോഡ്യൂളിലെ (utility module) ഒരു സിംഗിൾ നൾ റെഫറൻസിലേക്ക് (null reference) വിരൽ ചൂണ്ടുന്നു. ഇതിനുള്ള പരിഹാരം ഒരുപക്ഷേ രണ്ട് വരികളുള്ള ഡിഫൻസീവ് കോഡിംഗ് (defensive coding) മാത്രമായിരിക്കാം.
ഓൺ-ഡിമാൻഡ് ലോഡിംഗ് (on-demand loading) ഇല്ലാത്ത ഒരു സിസ്റ്റത്തിൽ, APX തനിക്കറിയാവുന്ന എല്ലാ സ്കില്ലുകളും കോൺടെക്സ്റ്റിൽ (context) നിറയ്ക്കും. ആ രണ്ട് വരികൾ പരിശോധിക്കുന്നതിന് മുമ്പ് മോഡൽ നാൽപ്പത് പേജുകളോളം വരുന്ന ടെക്സ്റ്റ് വിശകലനം ചെയ്യേണ്ടി വരും. അത് റിലീസ് ചെക്ക്ലിസ്റ്റ് (release checklist) കണ്ട് വേർഷൻ മാറ്റണോ എന്ന് ചിന്തിക്കുന്നു. സെക്യൂരിറ്റി ഗൈഡ് (security guide) കണ്ട്, വെറുമൊരു നൾ ചെക്ക് (null check) മാത്രം ആവശ്യമുള്ള ഒരു ഫങ്ക്ഷനിൽ ഇൻപുട്ട് വാലിഡേഷൻ (input validation) വേണോ എന്ന് ആലോചിക്കുന്നു. ഡിപ്ലോയ്മെന്റ് റൺബുക്ക് (deployment runbook) കണ്ട് സ്റ്റേജിംഗ് എൻവയോൺമെന്റുകളെ (staging environments) കുറിച്ച് ചിന്തിക്കാൻ തുടങ്ങുന്നു. മോഡൽ അതിന്റെ ലക്ഷ്യത്തിൽ നിന്ന് വ്യതിചലിക്കുന്നു (drifts). മറുപടി നൽകാൻ കൂടുതൽ സമയം എടുക്കുന്നു. ടോക്കൺ മീറ്റർ (token meter) വേഗത്തിൽ വർദ്ധിക്കുന്നു.
APX-ന്റെ ഓൺ-ഡിമാൻഡ് ഡിസൈൻ ഉപയോഗിക്കുമ്പോൾ, മോഡൽ പേരുകൾ മാത്രമേ കാണുന്നുള്ളൂ. [release-checklist], [security-guide], [deployment-runbook], കൂടാതെ [error-handling] എന്നിവ നിലവിലുണ്ടെന്ന് അതിന് അറിയാം. അത് ആദ്യത്തെ മൂന്നും അവഗണിക്കുന്നു. നിങ്ങളുടെ പ്രോജക്റ്റിലെ നൾ സേഫ്റ്റി (null safety) സംബന്ധിച്ച രീതികൾ പ്രത്യേകമാണെങ്കിൽ അത് [error-handling] ലോഡ് ചെയ്തേക്കാം. അത് ബഗ് പരിഹരിക്കുന്നു. ബന്ധമില്ലാത്ത സ്കില്ലുകൾ ഒരിക്കലും കോൺടെക്സ്റ്റ് വിൻഡോയിലേക്ക് (context window) പ്രവേശിച്ചില്ല. പ്രോംപ്റ്റ് (prompt) വ്യക്തമായിരുന്നതുകൊണ്ട് മോഡൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചു.
ടാസ്ക് സങ്കീർണ്ണമാകുമ്പോഴും ഇതേ ലോജിക് തന്നെയാണ് പ്രവർത്തിക്കുന്നത്. പിന്നീട് ഒരു പ്രൊഡക്ഷൻ ഡിപ്ലോയ്മെന്റ് (production deployment) തയ്യാറാക്കാൻ നിങ്ങൾ ഏജന്റിനോട് ആവശ്യപ്പെട്ടാൽ, ആ ഘട്ടങ്ങൾ പ്രസക്തമാകുമ്പോൾ അതിന് ഡിപ്ലോയ്മെന്റ് റൺബുക്ക് ലോഡ് ചെയ്യാനും, സെക്യൂരിറ്റി ഗൈഡ് പരിശോധിക്കാനും, റിലീസ് ചെക്ക്ലിസ്റ്റ് കൃത്യമായി പാലിക്കാനും കഴിയും. അറിവ് എപ്പോഴും അവിടെ ഉണ്ടായിരുന്നു, അത് ശരിയായ നിമിഷത്തിനായി കാത്തിരിക്കുകയായിരുന്നു എന്ന് മാത്രം.
പ്രോംപ്റ്റ് ഡിസിപ്ലിൻ ഒരു ആർക്കിടെക്ചർ ആയി
APC-യും APX-ഉം തമ്മിലുള്ള വേർതിരിവ് വെറുമൊരു ഇംപ്ലിമെന്റേഷൻ ഡീറ്റെയിൽ (implementation detail) മാത്രമല്ല. അത് പ്രോംപ്റ്റ് ഡിസിപ്ലിന്റെ (prompt discipline) ഒരു തത്വശാസ്ത്രമാണ്. APC അറിവിനെ എന്നെന്നേക്കുമായി സംരക്ഷിക്കുന്നു, ഇത് അവയെ റിവ്യൂ ചെയ്യാനും (reviewable), വേർഷൻ ചെയ്യാനും (versioned), സുരക്ഷിതമായി വെക്കാനും സഹായിക്കുന്നു. ആ അറിവിൽ എത്രത്തോളം ഇപ്പോൾ ആക്റ്റീവ് കോൺടെക്സ്റ്റിൽ (active context) ഉൾപ്പെടുത്തണമെന്ന് APX തീരുമാനിക്കുന്നു.
സമൃദ്ധമായ ഒരു സ്കിൽ കാറ്റലോഗ് (skill catalog) ഒരു ആസ്തിയാണ് (asset). എന്നാൽ അമിതമായി വിവരങ്ങൾ നിറഞ്ഞ പ്രോംപ്റ്റ് (bloated prompt) ഒരു ബാധ്യതയാണ് (liability). കോൺടെക്സ്റ്റ് എപ്പോഴും ആക്റ്റീവ് ആക്കാതെ തന്നെ അത് പോർട്ടബിൾ (portable) ആയി നിലനിർത്തുക എന്നതാണ് ലക്ഷ്യം. നിങ്ങളുടെ ടീം എഴുതിയ എല്ലാ നിർദ്ദേശങ്ങളും നിങ്ങളുടെ റെപ്പോസിറ്ററിയിൽ ഉണ്ടായിരിക്കണം, എന്നാൽ നിലവിലെ ടാസ്കിൽ സഹായിക്കുന്നവ മാത്രം ഏജന്റ് വായിച്ചാൽ മതി.
ഓരോ തവണയും എല്ലാ സ്കില്ലുകളും മോഡൽ ഉപയോഗിക്കാൻ നിർബന്ധിക്കുന്നുണ്ടെങ്കിൽ, നിങ്ങൾ ഒരു ഇന്റലിജന്റ് അസിസ്റ്റന്റിനെയല്ല (intelligent assistant) നിർമ്മിക്കുന്നത്. മറിച്ച്, ഓരോ ചോദ്യത്തിനും മുഴുവൻ ആർക്കൈവും (archive) വലിച്ചെത്തിക്കുന്ന ഒരു ലൈബ്രേറിയനെയാണ് നിങ്ങൾ നിർമ്മിക്കുന്നത്. എല്ലാം സംഭരിക്കുക (Store everything). ആവശ്യമുള്ളവ മാത്രം ലോഡ് ചെയ്യുക (Load what matters). ഇങ്ങനെ ചെയ്യുന്നതിലൂടെ ഏജന്റുകളെ വേഗതയുള്ളതാക്കാനും, കോൺടെക്സ്റ്റ് വൃത്തിയായി സൂക്ഷിക്കാനും, യുക്തിസഹമായ ചിന്താശേഷി (reasoning) നിലനിർത്താനും സാധിക്കും.