എന്റെ AI ഏജന്റുകൾ ഞങ്ങളുടെ ടീം ചാറ്റിൽ ഫലങ്ങൾ പോസ്റ്റ് ചെയ്തു. ഒരു മനുഷ്യൻ മറുപടി നൽകിയപ്പോൾ, ആദ്യത്തെ സന്ദേശം കാണാതെ തന്നെ രണ്ടാമതൊരു ഏജന്റ് അതിൽ ഇടപെട്ടു. ഇതിന്റെ ഫലമായി സന്ദർഭങ്ങൾ വിട്ടുപോവുകയും, ഒരേ ജോലി തന്നെ ആവർത്തിക്കപ്പെടുകയും, തെറ്റുകൾ സംഭവിക്കുകയും ചെയ്തു. നിലവിലുള്ള മെമ്മറി സെർവറിലേക്കും (memory server) മോണിറ്ററിംഗ് സ്റ്റാക്കിലേക്കും (monitoring stack) ഒരു ലഘുവായ Inter-Agent Communication Protocol (IACP) ഘടിപ്പിച്ചതോടെ, ഈ ആശയക്കുഴപ്പങ്ങൾ അവസാനിക്കുകയും പ്രവർത്തനരീതി കൂടുതൽ കൃത്യമാവുകയും ചെയ്തു.

എന്തുകൊണ്ടാണ് ഈ പ്രശ്നം പ്രധാനപ്പെട്ടത്

പ്രൊഡക്ഷനിൽ, AI ഏജന്റുകൾ വെറും പരീക്ഷണങ്ങൾ മാത്രമല്ല; ഡാറ്റ ശേഖരിക്കാനും കോഡ് നിർമ്മിക്കാനും അല്ലെങ്കിൽ ഡിപ്ലോയ്‌മെന്റുകൾ (deployments) തുടങ്ങാനും സഹായിക്കുന്ന മൈക്രോ-സർവീസുകളായി (micro-services) അവ പ്രവർത്തിക്കുന്നു. ഓരോ ഏജന്റും മനുഷ്യരോട് മാത്രം സംസാരിക്കുമ്പോൾ, ഉത്തരവാദിത്തങ്ങൾ തമ്മിലുള്ള ഓവർലാപ്പിംഗ് ഒരു മറഞ്ഞിരിക്കുന്ന 'റേസ് കണ്ടീഷൻ' (race condition) ആയി മാറുന്നു. ഒരു സ്ലാക്ക് (Slack) സന്ദേശം നിസ്സാരമായി തോന്നാമെങ്കിലും, പരസ്പരവിരുദ്ധമായ ഔട്ട്‌പുട്ടുകൾ പരിശോധിക്കാൻ ഡെവലപ്പർമാർക്ക് സമയം നഷ്ടപ്പെടുന്നു, രണ്ട് ബോട്ടുകൾ ഒരേ റിപ്പോസിറ്ററി (repository) എഡിറ്റ് ചെയ്യുമ്പോൾ പൈപ്പ്‌ലൈനുകൾ (pipelines) തടസ്സപ്പെടുന്നു, കൂടാതെ ഓട്ടോമേഷനിലുള്ള വിശ്വാസവും കുറയുന്നു.

വിട്ടുപോയ കണ്ണികൾ: റിയൽ-ടൈം ഷെയർഡ് സ്റ്റേറ്റ് (real-time shared state)

മിക്ക ടീമുകളും ഏജന്റുകളെ ഒരു പ്രോംപ്റ്റ് (prompt) സ്വീകരിക്കുകയും ഒരു ഫലം നൽകുകയും ചെയ്യുന്ന "ബ്ലാക്ക് ബോക്സുകളായി" ആണ് കാണുന്നത്; പ്രോംപ്റ്റിൽ ആവശ്യമായ എല്ലാ വിവരങ്ങളും അടങ്ങിയിട്ടുണ്ടെന്ന് അവർ കരുതുന്നു. എന്നാൽ യഥാർത്ഥത്തിൽ, ഏജന്റുകൾ നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്ന ഒരു വർക്ക്സ്പേസ് പങ്കിടുന്നു: ഒരു റിപ്പോസിറ്ററി ലോക്ക് ചെയ്യപ്പെട്ടേക്കാം, ഒരു സർവീസ് പ്രവർത്തനരഹിതമാകാം, അല്ലെങ്കിൽ ഒരു മുൻപത്തെ വിശകലനം (analysis) ഇപ്പോൾ മാത്രം പൂർത്തിയായതാകാം. ഒരു ബ്രോഡ്കാസ്റ്റ് സംവിധാനമില്ലാതെ, ഓരോ ബോട്ടും പഴയ വിവരങ്ങൾ (stale snapshot) ഉപയോഗിച്ചാണ് പ്രവർത്തിക്കുന്നത്.

നിലവിലുള്ള ടൂളുകൾ ഉപയോഗിച്ച് IACP നിർമ്മിക്കുന്നു

ഒരു പുതിയ പ്ലാറ്റ്‌ഫോം നിർമ്മിക്കുന്നതിന് പകരം, സംഭാഷണ ചരിത്രം സൂക്ഷിക്കുന്ന മെമ്മറി സെർവറും (memory server) ഏജന്റുകളുടെ പ്രവർത്തനം നിരീക്ഷിക്കുന്ന മോണിറ്ററിംഗ് സ്യൂട്ടും (monitoring suite) ഞാൻ വിപുലീകരിച്ചു. ഈ പ്രോട്ടോക്കോൾ അഞ്ച് പ്രധാന കഴിവുകൾ നൽകുന്നു:

  • Structured Identity – claude@greenmac:8f3a2c പോലുള്ള ഒരു തനതായ ഐഡന്റിഫയർ ഓരോ ഔട്ട്‌ബൗണ്ട് സന്ദേശത്തോടും ചേർക്കുന്നു. ഇത് സന്ദേശം അയച്ചത് ആരാണെന്നും ഏത് ഇൻസ്റ്റൻസിൽ നിന്നാണെന്നും പെട്ടെന്ന് മനസ്സിലാക്കാൻ സഹായിക്കുന്നു, അതുവഴി "ബോട്ട് X എന്ന് പറഞ്ഞു" എന്ന തരത്തിലുള്ള അവ്യക്തതകൾ ഒഴിവാക്കാം.

  • History Injection – ഒരു മറുപടി നൽകുന്നതിന് മുമ്പ്, ഒരു ബോട്ട് ഏറ്റവും പുതിയ ചാറ്റ് ഭാഗങ്ങൾ (മറ്റ് ഏജന്റുകളുടെ സന്ദേശങ്ങൾ ഉൾപ്പെടെ) എടുത്ത് പ്രോംപ്റ്റിന്റെ തുടക്കത്തിൽ ചേർക്കുന്നു. ഇത് സന്ദർഭങ്ങൾ (context) നഷ്ടപ്പെടാതിരിക്കാൻ സഹായിക്കുന്നു, കൂടാതെ സഹപ്രവർത്തകർ ഇതിനകം എന്താണ് സംഭാവന ചെയ്തതെന്ന് മനസ്സിലാക്കി പ്രവർത്തിക്കാൻ മോഡലിനെ പ്രാപ്തമാക്കുന്നു.

  • State Transitions – ഏജന്റുകൾ നിരന്തരം ഹാർട്ട്ബീറ്റുകൾ (heartbeats) അയക്കുന്നതിന് പകരം, അവരുടെ ആന്തരിക അവസ്ഥ മാറുമ്പോൾ (ഉദാഹരണത്തിന്: working, blocked, അല്ലെങ്കിൽ idle) ഒരു സ്റ്റാറ്റസ് മാറ്റം അറിയിക്കുന്നു. ഇത് ഉപയോഗിച്ച് മറ്റ് പ്രക്രിയകൾക്ക് ഉടനടി പ്രതികരിക്കാം; ഉദാഹരണത്തിന്, ഒരു ഏജന്റ് idle എന്ന് റിപ്പോർട്ട് ചെയ്യുമ്പോൾ മാത്രം അടുത്ത ജോലി ക്യൂ ചെയ്യാം.

  • Advisory Leases – ഒരു ഏജന്റിന് ഒരു റിസോഴ്സിന് (repo, API endpoint, compute node) പ്രത്യേക അനുമതി ആവശ്യമായി വരുമ്പോൾ, അത് ഒരു TTL (time-to-live) ഉള്ള ഒരു ലീസ് (lease) ക്ലെയിം ചെയ്യുന്നു. ഏജന്റ് പ്രവർത്തനരഹിതനായാൽ, ആ ലീസ് തനിയെ അവസാനിക്കുകയും റിസോഴ്സ് മറ്റുള്ളവർക്കായി ലഭ്യമാവുകയും ചെയ്യുന്നു, ഇത് രണ്ട് ബോട്ടുകൾ ഒരേസമയം ഒരേ റിസോഴ്സിൽ ഇടപെടുന്നത് തടയുന്നു.

  • Inbox Mechanism – ഇൻബോക്സിൽ വായിക്കാത്ത സന്ദേശങ്ങൾ ഉണ്ടെങ്കിൽ ഒരു "സ്റ്റോപ്പ് ഹുക്ക്" (stop hook) ഏജന്റിന്റെ പ്രവർത്തനം താൽക്കാലികമായി നിർത്തിവെക്കുന്നു. നിലവിലെ ജോലി പൂർത്തിയാക്കുന്നതിന് മുമ്പ് ഏജന്റ് ആ സന്ദേശങ്ങൾ പരിശോധിക്കേണ്ടതുണ്ട്, ഇത് പ്രധാനപ്പെട്ട ഏകോപന സന്ദേശങ്ങൾ അവഗണിക്കപ്പെടാതിരിക്കാൻ ഉറപ്പാക്കുന്നു.

ഈ ഘടകങ്ങൾ എല്ലാം ചേർന്ന് എല്ലാവരെയും ഒരേ വിവരങ്ങൾ നൽകുന്ന ലളിതവും നിരീക്ഷിക്കാവുന്നതുമായ ഒരു കമ്മ്യൂണിക്കേഷൻ ലെയർ രൂപപ്പെടുത്തുന്നു.

ഇത് അവഗണിക്കുന്ന ടീമുകൾ നേരിടുന്ന വെല്ലുവിളികൾ

ഒരു ടീം അഡ്‌ഹോക്ക് പ്രോംപ്റ്റുകളെയും (ad-hoc prompts) മാനുവൽ മോണിറ്ററിംഗിനെയും മാത്രം ആശ്രയിച്ചാൽ, മറഞ്ഞിരിക്കുന്ന ചിലവുകൾ വർദ്ധിച്ചുകൊണ്ടേയിരിക്കും:

  • Duplicated effort – രണ്ട് ഏജന്റുകൾ ഒരേ റിപ്പോർട്ടുകൾ നിർമ്മിച്ചേക്കാം, ഇത് കമ്പ്യൂട്ട് സൈക്കിളുകളും ക്ലൗഡ് ചിലവുകളും വർദ്ധിപ്പിക്കുന്നു.
  • Resource contention – ഒരു കോഡ്ബേസിലേക്ക് (codebase) ഒരേസമയം എഴുതാൻ ശ്രമിക്കുന്നത് മെർജ് കോൺഫ്ലിക്റ്റുകൾക്ക് (merge conflicts) കാരണമാകുന്നു, ഇത് പരിഹരിക്കാൻ മനുഷ്യന്റെ ഇടപെടൽ ആവശ്യമാണ്.
  • Operational risk – പഴയ വിവരങ്ങൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന ഒരു ഏജന്റ്, മറ്റൊരു ഏജന്റ് റോളബാക്ക് (rollback) ചെയ്യുന്ന സമയത്ത് ഡിപ്ലോയ്‌മെന്റ് നടത്താൻ ശ്രമിച്ചേക്കാം, ഇത് സർവീസിനെ അസ്ഥിരപ്പെടുത്തും.

ഏജന്റുകൾ അവരുടെ ഐഡന്റിറ്റി, സ്റ്റേറ്റ്, റിസോഴ്സ് ക്ലെയിമുകൾ എന്നിവ അറിയിക്കുന്ന രീതി ഔദ്യോഗികമാക്കുന്നതിലൂടെ, വലിയൊരു ഓർക്കസ്ട്രേഷൻ എഞ്ചിൻ (orchestration engine) ഇല്ലാതെ തന്നെ IACP ഈ റിസ്കുകൾ കുറയ്ക്കുന്നു.

എതിർവാദം: അധികമായ ജോലിഭാരം (added overhead)

ഹിസ്റ്ററി ചേർക്കുന്നതും ലീസ് മാനേജ് ചെയ്യുന്നതും ലേറ്റൻസിനും (latency) അധിക കോഡ് പാത്തുകൾക്കും കാരണമാകുമെന്ന് വിമർശകർ വാദിക്കുന്നു. ഒരു ഏജന്റ് മാത്രം ചെറിയ ജോലികൾ ചെയ്യുന്ന സാഹചര്യത്തിൽ ഇതിന്റെ ഗുണം കുറവായിരിക്കാം. എങ്കിലും, നിലവിലുള്ള മെമ്മറി, മോണിറ്ററിംഗ് സർവീസുകൾ തന്നെ ഉപയോഗിക്കുന്നതിനാൽ അധികമായ ജോലിഭാരം കുറവാണ്. ഏജന്റുകൾ തമ്മിലുള്ള ആശയക്കുഴപ്പം നേരിടുന്ന ടീമുകൾക്ക് ഈ മാറ്റം തീർച്ചയായും ഗുണകരമാണ്.

അടുത്തതായി ശ്രദ്ധിക്കേണ്ടവ

ഈ പ്രോട്ടോക്കോൾ നിലവിൽ ഒരു പ്രോട്ടോടൈപ്പ് (prototype) മാത്രമാണ്, എങ്കിലും ഇതിന്റെ മോഡുലാർ സ്വഭാവം ഏത് ലാംഗ്വേജ്-അഗ്നോസ്റ്റിക് (language-agnostic) ഏജന്റ് ഫ്രെയിംവർക്കുമായും സംയോജിപ്പിക്കാൻ സഹായിക്കുന്നു. അടുത്ത ഘട്ടങ്ങളിൽ ഇവ ഉൾപ്പെടാം:

  • കോർ ലോജിക്കിൽ മാറ്റം വരുത്താതെ തന്നെ ഡെവലപ്പർമാർക്ക് അഞ്ച് ഹുക്കുകൾ ചേർക്കാൻ സാധിക്കുന്ന തരത്തിൽ ഒരു ലൈറ്റ്വെയ്റ്റ് SDK പുറത്തിറക്കുക.
  • സ്റ്റേറ്റ് ട്രാൻസിഷനുകളും ലീസ് ചേണും (lease churn) വിഷ്വലൈസ് ചെയ്യുന്ന തരത്തിൽ മോണിറ്ററിംഗ് സ്യൂട്ടിലേക്ക് മെട്രിക്സ് ചേർക്കുന്നത് വഴി ടീമുകൾക്ക് തടസ്സങ്ങൾ (bottlenecks) തിരിച്ചറിയാൻ സഹായിക്കുന്നു.
  • ഉയർന്ന ട്രാഫിക് സാഹചര്യങ്ങളിൽ ചില ഏജന്റുമാരുടെ ലീസുകൾക്ക് മറ്റുള്ളവയേക്കാൾ മുൻഗണന നൽകുന്ന രീതിയിലുള്ള പോളിസി ലെയറുകളിൽ പരീക്ഷണം നടത്തുക.

ഈ എക്സ്റ്റൻഷനുകൾ പ്രചാരം നേടുകയാണെങ്കിൽ, വെബ് സർവീസുകൾക്കായി HTTP ചെയ്തതുപോലെ, മൾട്ടി-ഏജന്റ് പ്രൊഡക്ഷൻ പൈപ്പ്‌ലൈനുകൾക്കായി IACP ഒരു ഡീ-ഫാക്റ്റോ സ്റ്റാൻഡേർഡായി (de-facto standard) മാറിയേക്കാം.

സംഗ്രഹം: ആരാണ് സംസാരിക്കുന്നത്, സമീപകാല സംഭാഷണം എങ്ങനെയുള്ളതാണ്, ഒരു ഏജന്റിന്റെ സ്റ്റാറ്റസ് എപ്പോൾ മാറുന്നു, ആരുടെ പക്കലാണ് ഒരു റിസോഴ്സ് ഉള്ളത്, പെൻഡിംഗ് മെസ്സേജുകൾ ഉണ്ടോ എന്നിങ്ങനെയുള്ള ലളിതമായ ചില നിയമങ്ങൾ (conventions) പാലിക്കുന്നത് വഴി, AI ഏജന്റുകൾ പരസ്പരം ആശയക്കുഴപ്പമുണ്ടാക്കുന്ന രീതിയിൽ സംസാരിക്കുന്നത് ഒഴിവാക്കാനും ഒരു ബഹളമയമായ ചാറ്റ്‌റൂമിനെ വിശ്വസനീയമായ ഒരു ഏകോപന ചാനലായി മാറ്റാനും സാധിക്കും.