നിങ്ങളുടെ ആദ്യത്തെ ഏജന്റ് വർക്ക്ഫ്ലോ (agent workflow) തുടങ്ങുന്നത് ഒരു പ്രോംപ്റ്റും (prompt) ഏതാനും ടൂളുകളും (tools) ഉപയോഗിച്ചാണ്. അത് ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. ഒരു ഓർഡറിന്റെ സ്റ്റാറ്റസ് പരിശോധിക്കുന്നു. അത് കൃത്യമായി പ്രവർത്തിക്കുന്നു, അതിനാൽ നിങ്ങൾ അത് പുറത്തിറക്കുന്നു.

പിന്നീട് ഉൽപ്പന്നം വളരുന്നു. മീറ്റിംഗ് നോട്ടുകൾ സിങ്ക് ചെയ്യുന്ന ഒരു CRM അപ്ഡേറ്റർ സെയിൽസ് വിഭാഗം ആവശ്യപ്പെടുന്നു. മൂന്ന് ആഭ്യന്തര സിസ്റ്റങ്ങളെ ബന്ധിപ്പിക്കുന്ന ഒരു റീഫണ്ട് വർക്ക്ഫ്ലോ സപ്പോർട്ട് വിഭാഗത്തിന് ആവശ്യമാണ്. വെണ്ടർ ഫോമുകൾ പൂരിപ്പിക്കുന്നതിനായി എൻജിനീയറിംഗ് വിഭാഗം ബ്രൗസർ ആക്ഷനുകൾ ചേർക്കുന്നു. ഓരോ അഭ്യർത്ഥനയും ചെറുതായി തോന്നാം. ഓരോന്നിനും സ്വന്തമായി ഒരു പ്രോംപ്റ്റ് ഫയലും, സ്വന്തമായി ഒരു സ്ലാക്ക് (Slack) ത്രെഡും, സ്വന്തമായി ഒരു "ക്വിക്ക് ഫിക്സും" (quick fix) ഉണ്ടാകുന്നു. ആറ് മാസത്തിന് ശേഷം, നിങ്ങളുടെ ഏജന്റ് ഒരൊറ്റ സിസ്റ്റമല്ല. അത് കോപ്പി ചെയ്ത പ്രോംപ്റ്റുകളുടെയും, മറഞ്ഞിരിക്കുന്ന ബിസിനസ്സ് നിയമങ്ങളുടെയും, ആർക്കും കണ്ടെത്താൻ കഴിയാത്ത പഴയ ചാറ്റ് ത്രെഡുകളിൽ എടുത്ത തീരുമാനങ്ങളുടെയും ഒരു ചിതറിക്കിടക്കുന്ന കൂട്ടമായി മാറുന്നു. ഇതിനെയാണ് 'പ്രോംപ്റ്റ് സ്പ്രാൾ' (prompt sprawl) എന്ന് വിളിക്കുന്നത്. ഇത് നിങ്ങളുടെ AI ഉൽപ്പന്നം ടെസ്റ്റ് ചെയ്യാനും റിവ്യൂ ചെയ്യാനും ആത്മവിശ്വാസത്തോടെ പഴയ പതിപ്പിലേക്ക് തിരിച്ചുപോകാനും (roll back) പ്രയാസകരമാക്കുന്നു.

ഇതിനുള്ള പരിഹാരം ഒരു AI ഏജന്റ് സ്കിൽ രജിസ്ട്രി (AI agent skill registry) ആണ്.

ഒരു സ്കിൽ (Skill) യഥാർത്ഥത്തിൽ എന്താണ്

ഒരു സ്കിൽ എന്നത് ഒരു ഫോൾഡറിൽ സേവ് ചെയ്തിരിക്കുന്ന ഒരു പ്രോംപ്റ്റ് മാത്രമല്ല. ഏജന്റ് എന്താണ് ചെയ്യേണ്ടത്, ഏതെല്ലാം ടൂളുകൾ ഉപയോഗിക്കണം, എന്തൊക്കെ ചെയ്യരുത് എന്ന് നിർവചിക്കുന്ന, വേർഷൻ ഉള്ളതും (versioned) ടെസ്റ്റ് ചെയ്യാൻ കഴിയുന്നതുമായ ഒരു പാക്കേജാണ് അത്. നിങ്ങളുടെ ടീമും മെഷീനും തമ്മിലുള്ള ഒരു കരാറായി ഇതിനെ കരുതുക. ഒരു ഏജന്റ് ഒരു സ്കിൽ ലോഡ് ചെയ്യുമ്പോൾ, അതിന്റെ പരിധികൾ എവിടെയാണെന്നും വിജയം എന്നാൽ എന്താണെന്നും കൃത്യമായി അറിയാൻ അതിന് കഴിയണം.

ഈ ഘടനയില്ലാതെ, ഓരോ പ്രോംപ്റ്റും ഒരു ചെറിയ, പ്രഖ്യാപിക്കപ്പെടാത്ത പ്രൊഡക്ഷൻ സിസ്റ്റമായി മാറുന്നു. ആരും ശ്രദ്ധിക്കാത്ത മറഞ്ഞിരിക്കുന്ന പെർമിഷനുകളും (permissions), ഉൾച്ചേർക്കപ്പെട്ട ബിസിനസ്സ് നിയമങ്ങളും, ചിലവ് വർദ്ധിപ്പിക്കുന്ന ഘടകങ്ങളും ഇതിൽ ഉണ്ടാകാം. പ്രോഡക്റ്റ് റോഡ്മാപ്പ് മുന്നോട്ട് പോകുമ്പോൾ പ്രോംപ്റ്റുകൾ പഴയപടി തുടരുന്നത് കാരണം അവ യഥാർത്ഥ ഉൽപ്പന്നത്തിൽ നിന്ന് അകന്നുപോകുന്നു. ഏറ്റവും മോശമായ കാര്യം, അവ കോപ്പി ചെയ്യപ്പെടുന്നു എന്നതാണ്. ആരെങ്കിലും ഒരു ഡെമോയ്ക്കായി അത് ഫോർക്ക് (fork) ചെയ്തേക്കാം, അല്ലെങ്കിൽ ഒരു പുതിയ മൈക്രോസർവീസിലേക്ക് പേസ്റ്റ് ചെയ്തേക്കാം; ഇപ്പോൾ നിങ്ങൾക്ക് അറിയാതെ തന്നെ രണ്ട് വ്യത്യസ്തമായ വിവരങ്ങൾ നൽകുന്ന സ്രോതസ്സുകൾ ഉണ്ടാകുന്നു.

പ്രോംപ്റ്റുകൾ മാത്രം ഉപയോഗിക്കുന്നത് എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

പ്രോംപ്റ്റുകൾ വെറും ടെക്സ്റ്റ് പോലെ തോന്നിക്കുന്നതുകൊണ്ട് ടീമുകൾ അവയെ കോൺഫിഗറേഷൻ (configuration) പോലെയാണ് കൈകാര്യം ചെയ്യുന്നത്. എന്നാൽ യഥാർത്ഥത്തിൽ, അവ പലരും സമ്മതിക്കുന്നതിനേക്കാൾ കോഡിനോട് (code) അടുത്താണ്. ഒരു പ്രൊഡക്ഷൻ പ്രോംപ്റ്റ് സാധാരണയായി സീക്വൻസിംഗ് (sequencing), ഫോർമാറ്റിംഗ് (formatting), എറർ ഹാൻഡ്‌ലിംഗ് (error handling), ആക്സസ് കൺട്രോൾ (access control) എന്നിവയെക്കുറിച്ചുള്ള ലോജിക് ഉൾക്കൊള്ളുന്നു. ഈ ലോജിക് സ്വാഭാവിക ഭാഷയിൽ (natural language) മാത്രമായിരിക്കുമ്പോൾ അവ്യക്തത ഉണ്ടാകുന്നു. CRM അപ്ഡേറ്റ് ചെയ്യാൻ ഏജന്റിന് അനുമതിയുണ്ടോ, അതോ പ്രോംപ്റ്റ് അത് വെറുതെ നിർദ്ദേശിക്കുകയാണോ ചെയ്തത്? ബില്ലിംഗ് API പ്രവർത്തനരഹിതമായാൽ, സുരക്ഷിതമായി എങ്ങനെ പരാജയപ്പെടണമെന്ന് പ്രോംപ്റ്റിന് അറിയാമോ, അതോ അത് ഒരു വിജയ സന്ദേശം ഉണ്ടാക്കി കാണിക്കുകയോ (hallucinate) ചെയ്യുമോ?

ചെലവ് (Cost) എന്നത് മറ്റൊരു നിശബ്ദ കൊലയാളിയാണ്. ഏജന്റിനോട് "ഘട്ടം ഘട്ടമായി ചിന്തിക്കാനും വിപുലമായി തിരയാനും" (think step by step and search extensively) ആവശ്യപ്പെടുന്ന ഒരു പ്രോംപ്റ്റ്, ഓരോ തവണ പ്രവർത്തിക്കുമ്പോഴും ധാരാളം ടോക്കണുകൾ (tokens) ഉപയോഗിച്ചേക്കാം. ആ പ്രോംപ്റ്റ് ഉയർന്ന ട്രാഫിക് ഉള്ള ഒരു സപ്പോർട്ട് ഫ്ലോയിലേക്ക് കോപ്പി ചെയ്യപ്പെടുമ്പോൾ, നിങ്ങളുടെ പ്രതിമാസ ഇൻഫറൻസ് ബില്ല് (inference bill) ഇരട്ടിയാകുന്നു, എന്നാൽ അതിന്റെ കാരണം ആർക്കും അറിയില്ല.

ബിസിനസ്സ് മാറുകയും എന്നാൽ ടെക്സ്റ്റ് മാറാതെ ഇരിക്കുകയും ചെയ്യുമ്പോഴാണ് 'ഡ്രിഫ്റ്റ്' (Drift) സംഭവിക്കുന്നത്. ഉദാഹരണത്തിന്, നിങ്ങളുടെ റീഫണ്ട് പോളിസിക്ക് ഇനി മുതൽ ഒരു നിശ്ചിത തുകയ്ക്ക് മുകളിൽ മാനേജരുടെ അനുമതി ആവശ്യമാണ് എന്ന് കരുതുക. ആ നിയമം ഒരു പോളിസി ലെയറിന് (policy layer) പകരം ഒരു പ്രോംപ്റ്റിനുള്ളിലാണ് ഇരിക്കുന്നതെങ്കിൽ, അപ്‌ഡേറ്റ് ചെയ്യേണ്ട പ്രോംപ്റ്റുകൾ കണ്ടെത്താൻ ഓരോ ഡിപ്ലോയ്മെന്റിലൂടെയും നിങ്ങൾ തിരയേണ്ടി വരും. ഒരെണ്ണം പോലും വിട്ടുപോയാൽ, ഏജന്റുകൾ നൽകാൻ പാടില്ലാത്ത പണം നൽകിക്കൊണ്ടിരിക്കും.

ഒരു പ്രൊഡക്ഷൻ സ്കില്ലിന്റെ ഘടന (Anatomy)

ഈ കുഴപ്പങ്ങളിൽ നിന്ന് രക്ഷപ്പെടണമെങ്കിൽ, ഓരോ സ്കില്ലിനെയും ഒരു സോഫ്റ്റ്‌വെയർ ആർട്ടീഫാക്റ്റ് (software artifact) പോലെ പരിഗണിക്കുക. ഒരു ഉപയോഗപ്രദമായ പ്രൊഡക്ഷൻ സ്കില്ലിൽ വെറും ടെക്സ്റ്റ് മാത്രമല്ല വേണ്ടത്. അതിന് ഇവ ആവശ്യമാണ്:

  • പേരും ലക്ഷ്യവും. "prompt_v3_final" എന്നതിന് പകരം ബിസിനസ്സ് ലക്ഷ്യത്തെക്കുറിച്ച് വ്യക്തമായ വിവരണത്തോടു കൂടിയ "process_standard_refund" എന്ന് നൽകുക.
  • ഇൻപുട്ട് സ്കീമയും (Input schema) ആവശ്യമായ കോൺടെക്സ്റ്റും (context). സ്കിൽ പ്രതീക്ഷിക്കുന്ന കൃത്യമായ ഫീൽഡുകൾ നിർവചിക്കുക. അതിന് ഒരു യൂസർ ഐഡി (user ID), സംഭാഷണ ചരിത്രം (conversation history), അല്ലെങ്കിൽ ടെനന്റ് ഐഡന്റിഫയർ (tenant identifier) എന്നിവ ആവശ്യമുണ്ടോ? ഇവിടെ കൃത്യമായ ടൈപ്പിംഗ് (strong typing) ഉപയോഗിക്കുന്നത് ഏജന്റ് തെറ്റായ അനുമാനങ്ങളിൽ എത്തുന്നതിനെ തടയുന്നു.
  • ടൂൾ പെർമിഷനുകളും സുരക്ഷാ പരിധികളും (Safety limits). ഏതെല്ലാം ടൂളുകൾ സ്കില്ലിന് ഉപയോഗിക്കാമെന്ന് വ്യക്തമായി പട്ടികപ്പെടുത്തുക. റീട്രൈകൾ (retries), ചിലവ് പരിധികൾ (spending limits), റേറ്റ് ക്യാപ്പുകൾ (rate caps) എന്നിവയിൽ ഗാർഡ്‌റെയിലുകൾ (guardrails) ഏർപ്പെടുത്തുക. സ്കിൽ യൂസർ ഡിലീഷൻ API ഉപയോഗിക്കരുത് എന്നുണ്ടെങ്കിൽ, അത് വെറും വിവരണത്തിൽ മാത്രമല്ല, കോഡിലും വ്യക്തമാക്കുക.
  • വിജയ മാനദണ്ഡങ്ങളും ടെസ്റ്റ് കേസുകളും (Success criteria and test cases). ഒരു സ്കിൽ പ്രവർത്തിക്കുന്നു എന്നത് കൊണ്ട് മാത്രം അത് "ജയിച്ചു" എന്ന് പറയാനാവില്ല. ഔട്ട്‌പുട്ടിൽ എന്തൊക്കെ ഉണ്ടായിരിക്കണം എന്ന് നിർവചിക്കുക. ഒരു റീഫണ്ട് സ്കില്ലിനെ സംബന്ധിച്ചിടത്തോളം, ഒരു സാധൂകരിക്കപ്പെട്ട ട്രാൻസാക്ഷൻ റെക്കോർഡ്, അയച്ച ഇമെയിൽ കൺഫർമേഷൻ, ഒരു ഓഡിറ്റ് ലോഗ് എൻട്രി എന്നിവ ഉണ്ടാകുന്നത് വിജയമായി കണക്കാക്കാം.
  • വേർഷൻ ഹിസ്റ്ററിയും ഉടമസ്ഥാവകാശവും (Version history and owner status). ഇതിന് ഒരു ഉത്തരവാദിത്തപ്പെട്ട വ്യക്തി ഉണ്ടായിരിക്കണം. v2.3 എന്തിനാണ് നിലവിലുള്ളതെന്നും v2.2-ൽ എന്താണ് തകരാറിലായതെന്നും ഒരു ചേഞ്ച്‌ലോഗ് (changelog) വിശദീകരിക്കണം.

നിങ്ങളുടെ ലെയറുകൾ വേർതിരിക്കുക

ടീമുകൾ വരുത്തുന്ന ഏറ്റവും വലിയ തെറ്റ് എല്ലാം കൂടി ഒരു പ്രോംപ്റ്റിൽ കുത്തിനിറയ്ക്കുക എന്നതാണ്. അവർ സൗഹൃദപരമായ നിർദ്ദേശങ്ങൾ, ടൂൾ ഡോക്യുമെന്റേഷൻ, സെക്യൂരിറ്റി പോളിസി, എറർ ഹാൻഡ്‌ലിംഗ് എന്നിവയെല്ലാം ഒരു വലിയ ടെക്സ്റ്റ് കട്ടയായി മാറ്റുന്നു. ഇത് പരിപാലിക്കാൻ (maintain) പ്രയാസമാണ്.

അവയെ വേർതിരിക്കുക:

  • നിർദ്ദേശങ്ങൾ (Instructions) ഏജന്റിനുള്ള മാർഗ്ഗനിർദ്ദേശങ്ങളാണ്. അവ ടോൺ (tone), ഫോർമാറ്റ് (format), പൊതുവായ സമീപനം എന്നിവ വിശദീകരിക്കുന്നു.
  • ടൂൾ റൂൾസ് (Tool Rules) ഏജന്റിന് ഏതൊക്കെ ടൂളുകൾ ലഭ്യമാണെന്നും അവ എന്ത് ചെയ്യുന്നു എന്നും പറഞ്ഞുതരുന്നു. ഇത് കണ്ടെത്തലിനുള്ളതാണ് (discovery), അനുമതി നൽകാനല്ല.
  • പോളിസി (Policy) കോഡ് വഴിയാണ് നടപ്പിലാക്കുന്നത്, പ്രതീക്ഷിച്ചതുകൊണ്ട് മാത്രമല്ല. $500-ന് മുകളിലുള്ള ഒരു റീഫണ്ട് പരിശോധിക്കാൻ രണ്ടാമതൊരാളുടെ സഹായം വേണമെങ്കിൽ, ആ പരിശോധന ടൂൾ വിളിക്കുന്നതിന് മുമ്പ് പ്രവർത്തിക്കുന്ന ഒരു വാലിഡേഷൻ ഫംഗ്ഷനിൽ (validation function) ഉണ്ടായിരിക്കണം.
  • ഇവാലുകൾ (Evals) എന്നത് ഏതൊരു മാറ്റത്തിന് ശേഷവും സ്കിൽ ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടെന്ന് തെളിയിക്കുന്ന ടെസ്റ്റുകളാണ്.

ഉദാഹരണത്തിന്, "ദയവായി ഉപഭോക്താവിന്റെ മുഴുവൻ ക്രെഡിറ്റ് കാർഡ് നമ്പറും വെളിപ്പെടുത്തരുത്" എന്ന് എഴുതരുത്. പകരം, ഏജന്റ് കാണുന്നതിന് മുമ്പ് തന്നെ PAN നമ്പറുകൾ മറച്ചുവെക്കുന്ന (redact) ഒരു ഡാറ്റാ ഫോർമാറ്റർ നിർമ്മിക്കുക. ബുദ്ധിപരമായ ഉപഭോക്തൃ ഇൻപുട്ടുകൾ കൊണ്ട് കോഡിന്റെ ജോലി മാറ്റാൻ കഴിയില്ല എന്നതുകൊണ്ടാണ് പോളിസി കോഡിൽ ഉൾപ്പെടുത്തേണ്ടത്.

പ്രൊഡക്ഷനെ എപ്പോഴും "Latest" എന്നതിലേക്ക് പോയിന്റ് ചെയ്യുന്നത് നിർത്തുക

ഒരു സൈലന്റ് പ്രോംപ്റ്റ് അപ്‌ഡേറ്റിനേക്കാൾ ഒരു വെള്ളിയാഴ്ച വൈകുന്നേരം നശിപ്പിക്കുന്നത് മറ്റൊന്നുമില്ല. നിങ്ങളുടെ പ്രൊഡക്ഷൻ ഏജന്റ് എപ്പോഴും ഒരു സ്കില്ലിന്റെ "latest" പതിപ്പാണ് എടുക്കുന്നതെങ്കിൽ, 'main'-ലേക്ക് നടത്തുന്ന ഓരോ മെർജും (merge) ഒരു വലിയ പ്രശ്നത്തിന് കാരണമായേക്കാം. dev, staging, prod എന്നിങ്ങനെയുള്ള ഏലിയാസുകൾ (aliases) നിങ്ങൾക്ക് ആവശ്യമാണ്. പരിശോധ