ഓരോ API-യും ഏജന്റുകൾക്കായി പുനർനിർമ്മിക്കപ്പെടും

MCP കണക്ഷൻ പ്രശ്നം പരിഹരിക്കുന്നു. എന്നാൽ അത് 'verb gap' പരിഹരിക്കുന്നില്ല.

ഒരു മികച്ച REST API ഒരു ഉച്ചനേരത്തിനുള്ളിൽ MCP-യിൽ ഉൾപ്പെടുത്താൻ (wrap) നിങ്ങൾക്ക് സാധിക്കും. എന്നിരുന്നാലും, ഒരു കോഡിംഗ് ഏജന്റ് ഇതിൽ ബുദ്ധിമുട്ട നേരിടും. അത് തെറ്റായ എൻഡ്പോയിന്റ് (endpoint) തിരഞ്ഞെടുക്കും. ഒരു ടൂൾ മാത്രം മതിയാകുമ്പോൾ അത് മൂന്ന് ടൂളുകൾ വിളിച്ചേക്കാം. ചോദിക്കാതെ തന്നെ ഡാറ്റ നശിപ്പിക്കുന്ന തരത്തിലുള്ള മാറ്റങ്ങൾ (destructive write) അത് വരുത്തിയേക്കാം.

API തകരാറിലായതല്ല. അത് തെറ്റായ ഉപഭോക്താവിനെ (consumer) മുൻനിർത്തി നിർമ്മിച്ചതാണ്.

ഇരുപത് വർഷങ്ങളായി, APIs നിർമ്മിക്കപ്പെട്ടത് മനുഷ്യർക്ക് വേണ്ടിയാണ്. മനുഷ്യർക്ക് വ്യക്തമായ ഉദ്ദേശ്യവും (intent) ഒരു മാനസിക മാതൃകയും (mental model) ഉണ്ട്. എന്നാൽ ഏജന്റുകൾക്ക് ഇവ രണ്ടും ഇല്ല. നിങ്ങളുടെ ഇന്റർഫേസിൽ നിന്ന് അവ രണ്ടും അവർ സ്വയം പുനർനിർമ്മിക്കേണ്ടി വരും.

പ്രധാന ഉപഭോക്താവ് ഇത്രയധികം മാറുന്ന സാഹചര്യത്തിൽ, ഇന്റർഫേസും മാറേണ്ടതുണ്ട്.

ഗൗരവകരമായ ഉൽപ്പന്നങ്ങൾ നിലവിലുള്ള API-കളെ വെറുതെ ഉൾപ്പെടുത്തുക മാത്രമല്ല ചെയ്യുകയെന്ന് ഞാൻ വിശ്വസിക്കുന്നു. പകരം അവ ഏജന്റ്-നേറ്റീവ് (agent-native) പ്രവർത്തനങ്ങളെ അടിസ്ഥാനമാക്കി പുനർനിർമ്മിക്കും.

ഇതിനർത്ഥം റിസോഴ്സ്-അധിഷ്ഠിത (resource-shaped) API-കളിൽ നിന്ന് ഉദ്ദേശ്യ-അധിഷ്ഠിത (intent-shaped) കരാറുകളിലേക്ക് മാറണം എന്നാണ്. ലക്ഷ്യങ്ങൾ (goals), അവസ്ഥ (state), പാർശ്വഫലങ്ങൾ (side-effects), അനുമതി (approval), വീണ്ടെടുക്കൽ (recovery) എന്നിവയെ അടിസ്ഥാനമാക്കി നമ്മൾ പുനർരൂപകൽപ്പന ചെയ്യണം.

കണക്ഷനും ട്രാൻസ്പോർട്ടിനും MCP മികച്ചൊരു മാനദണ്ഡമാണ്. എന്നാൽ അതിന്റെ സ്പെസിഫിക്കേഷനിൽ (spec), ഒരു ടൂൾ എന്നത് പേരും സ്കീമയും (schema) മാത്രമുള്ള ഒരു ഫങ്ക്ഷൻ മാത്രമാണ്. പ്രവർത്തനങ്ങളുടെ ക്രമമോ അല്ലെങ്കിൽ ഏതാണ് അപകടകരമായത് എന്നോ അത് തീരുമാനിക്കുന്നില്ല.

ഇത് 'verb gap' ഉണ്ടാക്കുന്നു. APIs ഏജന്റുകൾക്ക് നാമങ്ങളും (nouns) CRUD പ്രവർത്തനങ്ങളും നൽകുന്നു. എന്നാൽ ഏജന്റുകൾക്ക് ഉദ്ദേശ്യം ഉൾക്കൊള്ളുന്ന ക്രിയകൾ (verbs) ആവശ്യമാണ്.

GitHub നോക്കൂ. ഏജന്റുകളുടെ യുക്തിചിന്ത (reasoning) മെച്ചപ്പെടുത്തുന്നതിനായി അവർ അവരുടെ ടൂൾസെറ്റ് പരിമിതപ്പെടുത്തുകയാണ്. ഒരു പ്രൊഡക്റ്റ് API-യെ ഏജന്റ് ടൂളുകളുമായി നേരിട്ട് (1:1 mapping) ബന്ധിപ്പിക്കുന്നത് ഫലപ്രദമല്ലെന്ന് അവർ മനസ്സിലാക്കുന്നു.

ഒരു API ഘടനാപരമായി ശരിയായിരിക്കാമെങ്കിലും (structurally valid), ഒരു ഏജന്റിനെ സംബന്ധിച്ചിടത്തോളം അർത്ഥശൂന്യമായിരിക്കാം (semantically useless) എന്ന് ഗവേഷണങ്ങൾ കാണിക്കുന്നു. ഒരു ഏജന്റ്-നേറ്റീവ് API "ഞാൻ എന്താണ് തിരികെ നൽകേണ്ടത്" എന്ന് മാത്രമല്ല ഉത്തരം നൽകുന്നത്, മറിച്ച് താഴെ പറയുന്നവയ്ക്കും ഉത്തരം നൽകുന്നു:

  • ലക്ഷ്യം എന്താണ്?
  • ഞാൻ ഏത് അവസ്ഥയിലാണ്?
  • പാർശ്വഫലങ്ങൾ എന്തൊക്കെയാണ്?
  • എനിക്ക് അനുമതി ആവശ്യമുണ്ടോ?
  • എനിക്ക് എങ്ങനെ വീണ്ടെടുക്കാം?

നേരിട്ടുള്ള ഒരു റൈറ്റിന് (raw write) പകരം, നിങ്ങൾക്ക് താഴെ പറയുന്ന രീതിയിൽ വിഭജിക്കേണ്ടതുണ്ട്:

  • പ്രവർത്തനം മുൻകൂട്ടി കാണുക (Preview).
  • വ്യക്തമായ അനുമതി വാങ്ങുക.
  • മാറ്റം സ്ഥിരീകരിക്കുക (Commit).
  • പരാജയപ്പെട്ടാൽ പഴയ അവസ്ഥയിലേക്ക് മടങ്ങുക (Rollback).

ഇതൊരു "ഏജന്റ് എഡിഷൻ" മാത്രമല്ല. ഇതൊരു മികച്ച API ആണ്. ഡെവലപ്പർമാർക്കും പ്രിവ്യൂകൾ, വ്യക്തമായ പെർമിഷൻ എററുകൾ, റോൾബാക്കുകൾ എന്നിവ ആവശ്യമാണ്. കാലക്രമേണ, ഏജന്റ്-നേറ്റീവ് ഡിസൈൻ മനുഷ്യകേന്ദ്രീകൃതമായ ഡിസൈനിനെ മാറ്റിസ്ഥാപിക്കും.

ഈ മാറ്റം വളരെ വലുതാണ്. ഇത് APIs, CLIs, ലോഗുകൾ എന്നിവയെ ബാധിക്കുന്നു. മനുഷ്യർക്ക് വായിക്കാവുന്ന വിവരണങ്ങളിൽ നിന്ന് മെഷീനുകൾക്ക് വിശകലനം ചെയ്യാവുന്ന അവസ്ഥകളിലേക്ക് (machine-parseable state) നമ്മൾ മാറണം.

സുരക്ഷ എന്നത് പിന്നീട് ചേർക്കാവുന്ന ഒരു പാക്കേജ് (wrapper) അല്ല. സുരക്ഷ എന്നത് പ്രവർത്തനത്തിന്റെ തന്നെ ഭാഗമായി രൂപകൽപ്പന ചെയ്യേണ്ട ഒരു ഗുണമാണ്.

Source: https://dev.to/gyu07/every-api-will-be-rebuilt-for-agents-2hj4

Optional learning community: https://t.me/GyaanSetuAi