For the last two years, AI engineering followed a simple script. Give an agent a prompt, some tools, and a memory layer.

കഴിഞ്ഞ രണ്ട് വർഷമായി, AI എഞ്ചിനീയറിംഗ് ലളിതമായ ഒരു രീതിയാണ് പിന്തുടർന്നിരുന്നത്. ഒരു ഏജന്റിന് ഒരു പ്രോംപ്റ്റും (prompt), ചില ടൂളുകളും, ഒരു മെമ്മറി ലെയറും നൽകുക. അത് ഒരു മീറ്റിംഗ് ഷെഡ്യൂൾ ചെയ്യുന്നതോ, ഒരു കരാർ സംഗ്രഹിക്കുന്നതോ, അല്ലെങ്കിൽ ഒരു സ്ക്രിപ്റ്റ് ഡിബഗ് ചെയ്യുന്നതോ കാണുക. ഒരു ഏജന്റിനെ സ്വയം ഉപയോഗപ്രദമാക്കുക എന്നതായിരുന്നു ഇതിന്റെ പ്രധാന ലക്ഷ്യം.

ആ ലക്ഷ്യം ഇപ്പോൾ മാറിപ്പോയിരിക്കുന്നു.

ഇൻഡസ്ട്രി ഇപ്പോൾ ഒറ്റപ്പെട്ട ഏജന്റുകളിൽ നിന്ന് ഏജന്റ് ടീമുകളിലേക്ക് മാറുന്നത് നമ്മൾ കാണുന്നു. ഒരു കസ്റ്റമർ സർവീസ് ട്രയാജ് ബോട്ട് (triage bot) ഒരു റീഫണ്ട് അഭ്യർത്ഥന തിരിച്ചറിയുകയും ആ കേസ് ഒരു പേയ്‌മെന്റ് ഏജന്റിന് കൈമാറുകയും ചെയ്യുന്നു. വെബ് ഡാറ്റ സ്ക്രാപ്പ് ചെയ്യുന്ന ഒരു റിസർച്ച് ഏജന്റ് ഒരു പ്രത്യേക മേഖലയിലെ വിവരങ്ങൾക്കായി ഒരു പ്രൊപ്രൈറ്ററി ഡാറ്റാബേസിലുള്ള സ്പെഷ്യലിസ്റ്റ് ഏജന്റിന് ജോലി ഏൽപ്പിക്കുന്നു. ഒരു ഷിപ്പ്‌മെന്റ് പ്ലാൻ ചെയ്യുന്ന ലോജിസ്റ്റിക് ഏജന്റിന് തത്സമയ ഫ്രൈറ്റ് കൊട്ടേഷൻ (freight quote) ആവശ്യമായി വരുമ്പോൾ, അത് ഒരു പ്രൈസിംഗ് ഏജന്റിനോട് വില ചോദിക്കുന്നു.

ഇത് കേൾക്കുമ്പോൾ ലളിതമായി തോന്നാം. എന്നാൽ പ്രായോഗികമായി ഇത് വളരെ ദുർബലമാണ്.

പുതിയ വെല്ലുവിളി ഇന്റർഓപ്പറബിലിറ്റി (interoperability) ആണ്. ടീമുകൾ വ്യത്യസ്ത ഫ്രെയിംവർക്കുകളിൽ ഏജന്റുകളെ നിർമ്മിക്കുന്നു. വ്യത്യസ്ത വെണ്ടർമാർ വ്യത്യസ്ത ഇന്റർഫേസുകളുള്ള ഏജന്റുകളെ വിപണിയിലെത്തിക്കുന്നു. ഒരു കമ്പനിക്ക് മറ്റൊരു കമ്പനിയുമായി സഹകരിക്കേണ്ടി വരുമ്പോൾ, ഈ വിടവ് വർദ്ധിക്കുന്നു. പരസ്പരം ആശയവിനിമയം നടത്താൻ ഒരു പൊതുഭാഷ ഇല്ലാത്ത കഴിവുള്ള തൊഴിലാളികളാൽ നിറഞ്ഞ ഒരു സാഹചര്യമാണ് ഇപ്പോൾ നമുക്കുള്ളത്. ഒരു ഏജന്റിന് ഒരു ഡയറക്ടറിയിൽ മറ്റൊരു ഏജന്റിനെ തിരയാൻ കഴിയില്ല. തന്റെ സഹപ്രവർത്തകൻ എന്താണ് ചെയ്യുന്നതെന്ന് വിവരിക്കുന്ന വിവരങ്ങൾ വായിക്കാൻ അതിന് കഴിയില്ല. കൂടാതെ, ഡാറ്റാ ചോർച്ചയോ (data leakage), കോൺടെക്സ്റ്റ് നഷ്ടപ്പെടലോ, അല്ലെങ്കിൽ ഒരേ ജോലി തന്നെ ആവർത്തിക്കപ്പെടലോ (duplicate execution) സംഭവിക്കാനുള്ള സാധ്യതയില്ലാതെ ഒരു സെൻസിറ്റീവ് ജോലി കൈമാറാനും അതിന് കഴിയില്ല.

A2A നിർമ്മിച്ചിരിക്കുന്നത് കൃത്യമായി ഈ പ്രശ്നം പരിഹരിക്കാനാണ്. ഇത് ഏജന്റുകൾക്ക് പരസ്പരം കണ്ടെത്താനും (discovery), ചുമതലകൾ ഏൽപ്പിക്കാനും (delegation), സുരക്ഷിതമായി സഹകരിക്കാനും (secure collaboration) ഒരു പൊതു പ്രോട്ടോക്കോൾ നൽകുന്നു.

ഒറ്റപ്പെട്ട ഏജന്റുകളിൽ നിന്ന് ഏജന്റ് സിലോകളിലേക്ക് (Agent Silos)

ഏജന്റ് ഫ്രെയിംവർക്കുകളുടെ ആദ്യഘട്ടത്തിൽ, സിസ്റ്റത്തിന്റെ അതിർത്തിയെ ഏജന്റിന്റെ അതിർത്തിയായിട്ടാണ് കണക്കാക്കിയിരുന്നത്. നിങ്ങൾ ഒരു റീസണിംഗ് ലൂപ്പ് (reasoning loop) നിർമ്മിക്കുകയും അതിന് ചില ടൂളുകൾ നൽകുകയും ചെയ്തു, അത് ഒരു വർക്ക്ഫ്ലോയിലൂടെ ചിന്തിച്ച് മുന്നോട്ട് പോകുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിച്ചു. ഏജന്റ് ഒരു കോഡ്ബേസിനുള്ളിലോ, ഒരു ക്ലൗഡ് അക്കൗണ്ടിനുള്ളിലോ, അല്ലെങ്കിൽ ഒരു വെണ്ടർ പ്ലാറ്റ്‌ഫോമിനുള്ളിലോ ഒതുങ്ങിനിൽക്കുമ്പോൾ ഇത് നന്നായി പ്രവർത്തിച്ചു.

യഥാർത്ഥ ബിസിനസ്സുകൾ ഒരു ഏകീകൃത സംവിധാനത്തിനുള്ളിൽ (monoliths) മാത്രം പ്രവർത്തിക്കുന്നില്ല. ഒരു റീഫണ്ട് അഭ്യർത്ഥന ഒരു CRM-ൽ തുടങ്ങി, പൈത്തണിൽ (Python) എഴുതപ്പെട്ട ഒരു ഇന്റേണൽ പേയ്‌മെന്റ് സർവീസിലേക്ക് മാറുകയും, ഒടുവിൽ ഒരു തേർഡ് പാർട്ടി ഹോസ്റ്റ് ചെയ്യുന്ന ഫ്രോഡ് ചെക്കിൽ അവസാനിക്കുകയും ചെയ്തേക്കാം. ഈ സേവനങ്ങളെ ഓരോന്നും ഒരു ഏജന്റായി മാറുമ്പോൾ, വ്യത്യസ്ത സ്റ്റാക്കുകളിൽ (stacks) നിർമ്മിച്ച ഏജന്റുകൾക്ക് പരസ്പരം സ്വാഭാവികമായി മനസ്സിലാക്കാൻ കഴിയില്ലെന്ന് നിങ്ങൾ പെട്ടെന്ന് തിരിച്ചറിയും. പ്രൊപ്രൈറ്ററി ഫ്രെയിംവർക്കുകളിൽ നിർമ്മിച്ച എന്റർപ്രൈസ് ഏജന്റുകൾ അവരുടെ കഴിവുകളെ പുറംലോകത്തേക്ക് അറിയിക്കാറില്ല.

ഒരു സ്റ്റാൻഡേർഡ് ഇല്ലാതെ, ഓരോ ഇന്റഗ്രേഷനും ഒരു കസ്റ്റം പ്രോജക്റ്റായി മാറുന്നു. എഞ്ചിനീയർമാർ ഓരോ തവണയും പ്രത്യേകമായി 'ഗ്ലൂ കോഡ്' (glue code) എഴുതേണ്ടി വരുന്നു. വിവരങ്ങൾ കൈമാറുന്നതിനിടെ കോൺടെക്സ്റ്റ് നഷ്ടപ്പെടുന്നു. ഓരോ കൈമാറ്റവും വ്യത്യസ്തമായ രീതിയിൽ ക്രമീകരിക്കുന്നതിനാൽ (bespoke), സുരക്ഷാ നയങ്ങൾ പൊരുത്തക്കേടുകൾ നിറഞ്ഞതാകുന്നു.

ഏജന്റ് കാർഡുകൾ: ഒരു പബ്ലിക് റെസ്യൂമെ (Public Resume)

ഏജന്റുകൾക്ക് തങ്ങൾ ആരാണെന്നും എന്താണ് ചെയ്യാൻ കഴിയുന്നതെന്നും അറിയിക്കാനുള്ള ഒരു മാർഗമായി A2A 'ഏജന്റ് കാർഡുകൾ' (Agent Cards) അവതരിപ്പിക്കുന്നു.

ഒരു ഏജന്റ് കാർഡിനെ മെഷീൻ-റീഡബിൾ ആയ ഒരു റെസ്യൂമെയായി കരുതുക. ഒരു ഏജന്റ് അതിന്റെ ഡൊമെയ്ൻ (domain), ആവശ്യമായ ഇൻപുട്ടുകൾ, പ്രതീക്ഷിക്കുന്ന ഔട്ട്പുട്ടുകൾ, അത് സ്വീകരിക്കുന്ന ജോലികളിലെ നിയന്ത്രണങ്ങൾ എന്നിവ വിവരിക്കുന്ന ഒരു കാർഡ് പ്രസിദ്ധീകരിക്കുന്നു. ഒരു പേയ്‌മെന്റ് ഏജന്റ് ഒരു ഓർഡർ ഐഡിയും (order ID) റീസൺ കോഡും (reason code) നൽകിയാൽ നിശ്ചിത തുകയ്ക്ക് താഴെയുള്ള റീഫണ്ട് അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുമെന്നും, ഒരു കൺഫർമേഷൻ നമ്പറോ അല്ലെങ്കിൽ ഒരു എററോ (error) തിരികെ നൽകുമെന്നും പ്രഖ്യാപിച്ചേക്കാം. ഒരു ഡാറ്റ സ്പെഷ്യലിസ്റ്റ് നിശ്ചിത വലുപ്പത്തിലുള്ള സ്ട്രക്ചേർഡ് ഫയലുകൾ സ്വീകരിക്കുമെന്നും കൃത്യമായ സമയത്തിനുള്ളിൽ ക്ലീൻ ചെയ്ത ടൈം-സീരീസ് ഡാറ്റ (time-series data) നൽകുമെന്നും പ്രസ്താവിച്ചേക്കാം.

ജോലി ഏൽപ്പിക്കുന്നതിന് മുമ്പ്, അഭ്യർത്ഥിക്കുന്ന ഏജന്റ് കാർഡ് വായിക്കുന്നു. ലക്ഷ്യമിടുന്ന ഏജന്റിന് ആ ജോലി ചെയ്യാൻ കഴിയുമോ എന്ന് അത് മനസ്സിലാക്കുന്നു. പേലോഡിന് (payload) ഏത് ഫോർമാറ്റ് വേണമെന്ന് അത് പഠിക്കുന്നു. ഒരു സിൻക്രണസ് റെസ്പോൺസ് (synchronous response) ആണോ അതോ പിന്നീട് പൂർത്തിയാകുന്ന ഒരു അസിൻക്രണസ് ടാസ്ക് (asynchronous task) ആണോ പ്രതീക്ഷിക്കേണ്ടതെന്ന് അത് അറിയുന്നു.

ഇത് ഊഹങ്ങൾ ഒഴിവാക്കുന്നു. ഓരോ പങ്കാളിക്കും വേണ്ടി പ്രത്യേകം ഇന്റഗ്രേഷനുകൾ ഹാർഡ്കോഡ് ചെയ്യുന്നതിന് പകരം, ലഭ്യമായ കഴിവുകൾ പരിശോധിക്കാനും അനുയോജ്യമായ ടീംമേറ്റിനെ ഡൈനാമിക് ആയി തിരഞ്ഞെടുക്കാനും ഒരു ഏജന്റിന് സാധിക്കുന്നു.

ടാസ്ക്കുകൾ: വെറും API കോളുകൾ മാത്രമല്ല, ഘടനാപരമായ ജോലികൾ

ഏജന്റുകൾ മനുഷ്യരെപ്പോലെ ചാറ്റ് ചെയ്യേണ്ടതില്ല. അവർക്ക് ജോലികൾ വൃത്തിയായി കൈമാറേണ്ടതുണ്ട്. A2A ഈ കൈമാറ്റത്തെ ഒരു 'ടാസ്ക്' (Task) ആയി മാതൃകയാക്കുന്നു.

ഒരു ടാസ്ക് എന്നത് വെറുമൊരു