మీ మొదటి ఏజెంట్ వర్క్ఫ్లో ఒక ప్రాంప్ట్ మరియు కొన్ని టూల్స్తో మొదలవుతుంది. ఇది ప్రశ్నలకు సమాధానం ఇస్తుంది. ఆర్డర్ స్టేటస్ను వెతుకుతుంది. అది పనిచేస్తుంది, కాబట్టి మీరు దానిని విడుదల చేస్తారు.
ఆ తర్వాత ఉత్పత్తి పెరుగుతుంది. సేల్స్ టీమ్ మీటింగ్ నోట్స్ను సింక్ చేసే CRM అప్డేటర్ను కోరుతుంది. సపోర్ట్ టీమ్కు మూడు అంతర్గత సిస్టమ్లను ప్రభావితం చేసే రీఫండ్ వర్క్ఫ్లో అవసరం అవుతుంది. ఇంజనీరింగ్ టీమ్ వెండర్ ఫారమ్లను నింపడానికి బ్రౌజర్ యాక్షన్లను జోడిస్తుంది. ప్రతి అభ్యర్థన చిన్నదిగా అనిపిస్తుంది. ప్రతి దానికి ఒక ప్రత్యేకమైన ప్రాంప్ట్ ఫైల్, ఒక ప్రత్యేకమైన Slack థ్రెడ్ మరియు ఒక ప్రత్యేకమైన "క్విక్ ఫిక్స్" ఉంటుంది. ఆరు నెలల తర్వాత, మీ ఏజెంట్ ఇకపై ఒకే సిస్టమ్గా ఉండదు. అది కాపీ చేయబడిన ప్రాంప్ట్లు, దాగి ఉన్న బిజినెస్ రూల్స్ మరియు ఎవరికీ దొరకని పాత చాట్ థ్రెడ్లలో తీసుకున్న నిర్ణయాల యొక్క చెల్లాచెదురైన కుప్పగా మారుతుంది. దీనినే 'prompt sprawl' అంటారు. ఇది మీ AI ఉత్పత్తిని టెస్ట్ చేయడం కష్టతరం చేస్తుంది, రివ్యూ చేయడం కష్టతరం చేస్తుంది మరియు నమ్మకంతో వెనక్కి (roll back) తీసుకోవడం అసాధ్యం చేస్తుంది.
దీనికి పరిష్కారం ఒక AI agent skill registry.
అసలు ఒక Skill అంటే ఏమిటి
ఒక skill అంటే కేవలం ఒక ఫోల్డర్లో సేవ్ చేసిన ప్రాంప్ట్ కాదు. ఇది ఏజెంట్ ఏమి చేస్తుంది, ఏ టూల్స్ను పిలవగలదు మరియు ఏమి చేయకూడదు అని నిర్వచించే ఒక versioned, testable ప్యాకేజీ. దీనిని మీ టీమ్ మరియు మెషిన్ మధ్య ఒక ఒప్పందం (contract) లాగా భావించండి. ఒక ఏజెంట్ ఒక skillని లోడ్ చేసినప్పుడు, దాని పరిధులు ఎక్కడ ఉన్నాయో మరియు విజయం అంటే ఏమిటో దానికి ఖచ్చితంగా తెలియాలి.
ఈ నిర్మాణం లేకపోతే, ప్రతి ప్రాంప్ట్ ఒక చిన్న, ప్రకటించబడని ప్రొడక్షన్ సిస్టమ్గా మారుతుంది. ఇది ఎవరూ ట్రాక్ చేయని దాగి ఉన్న పర్మిషన్లు, ఎంబెడెడ్ బిజినెస్ రూల్స్ మరియు ఖర్చు ప్రభావాలను కలిగి ఉంటుంది. ప్రొడక్ట్ రోడ్మ్యాప్ ముందుకు సాగుతున్నప్పుడు ప్రాంప్ట్ వెనుకబడిపోవడం వల్ల అది అసలు ఉత్పత్తి నుండి విడిపోతుంది. అన్నిటికంటే దారుణం ఏమిటంటే, అది కాపీ చేయబడుతుంది. ఎవరైనా డెమో కోసం దానిని ఫోర్క్ చేస్తారు లేదా కొత్త మైక్రోసర్వీస్లోకి పేస్ట్ చేస్తారు, ఇప్పుడు మీకు చీకటిలో విడిపోతున్న రెండు 'sources of truth' ఉంటాయి.
ప్రాంప్ట్లు మాత్రమే ఎందుకు విఫలమవుతాయి
ప్రాంప్ట్లు టెక్స్ట్ లాగా కనిపిస్తాయి, కాబట్టి టీమ్లు వాటిని కాన్ఫిగరేషన్లాగా పరిగణిస్తాయి. వాస్తవానికి, అవి ఎవరూ ఒప్పుకోవడానికి ఇష్టపడనంత వరకు కోడ్కు చాలా దగ్గరగా ఉంటాయి. ఒక ప్రొడక్షన్ ప్రాంప్ట్ సాధారణంగా సీక్వెన్సింగ్, ఫార్మాటింగ్, ఎర్రర్ హ్యాండ్లింగ్ మరియు యాక్సెస్ కంట్రోల్ గురించి లాజిక్ను ఎన్కోడ్ చేస్తుంది. ఆ లాజిక్ కేవలం నేచురల్ లాంగ్వేజ్లో మాత్రమే ఉన్నప్పుడు, అస్పష్టత ఏర్పడుతుంది. CRMని అప్డేట్ చేయడానికి ఏజెంట్కు అనుమతి ఉందా, లేదా ప్రాంప్ట్ కేవలం సూచించిందా? ఒకవేళ బిల్లింగ్ API డౌన్ అయితే, ప్రాంప్ట్కు సురక్షితంగా ఎలా ఫెయిల్ అవ్వాలో తెలుసా, లేదా అది ఒక సక్సెస్ మెసేజ్ను హాలూసినేట్ (hallucinate) చేస్తుందా?
ఖర్చు మరొక నిశ్శబ్ద హంతకుడు. ఏజెంట్ను "స్టెప్ బై స్టెప్ ఆలోచించి, విస్తృతంగా వెతకమని" కోరే ప్రాంప్ట్ ప్రతి రన్పై టోకెన్లను ఖర్చు చేయవచ్చు. ఆ ప్రాంప్ట్ను హై-ట్రాఫిక్ సపోర్ట్ ఫ్లోలోకి కాపీ చేసినప్పుడు, మీ నెలవారీ ఇన్ఫరెన్స్ బిల్లు రెట్టింపు అవుతుంది మరియు ఎవరికీ ఎందుకు అనేది తెలియదు.
బిజినెస్ మారినప్పుడు టెక్స్ట్ మారకపోతే 'drift' జరుగుతుంది. మీ రీఫండ్ పాలసీ ఇప్పుడు ఒక నిర్దిష్ట పరిమితి పైన మేనేజర్ ఆమోదం కావాలని కోరుతోంది. ఆ రూల్ ఒక పాలసీ లేయర్కు బదులుగా ప్రాంప్ట్ లోపల ఉంటే, అప్డేట్ చేయాల్సిన కాపీలను కనుగొనడానికి మీరు ప్రతి డిప్లాయ్మెంట్ను వెతకాల్సి ఉంటుంది. ఒకదాన్ని మిస్ అయితే, ఏజెంట్లు ఇవ్వకూడని డబ్బును ఇస్తుంటారు.
ప్రొడక్షన్ Skill యొక్క నిర్మాణం (Anatomy)
మీరు ఈ గందరగోళం నుండి తప్పించుకోవాలనుకుంటే, ప్రతి skillని ఒక సాఫ్ట్వేర్ ఆర్టిఫాక్ట్లా పరిగణించండి. ఒక ఉపయోగకరమైన ప్రొడక్షన్ skill కేవలం టెక్స్ట్తోనే సరిపోదు. దానికి ఇవి అవసరం:
- పేరు మరియు ఉద్దేశ్యం. "prompt_v3_final" అని కాకుండా, బిజినెస్ గోల్ యొక్క స్పష్టమైన వివరణతో "process_standard_refund" అని ఉండాలి.
- Input schema మరియు అవసరమైన context. skill ఆశించే ఖచ్చితమైన ఫీల్డ్లను నిర్వచించండి. దానికి user ID, conversation history, లేదా tenant identifier అవసరమా? ఇక్కడ స్ట్రాంగ్ టైపింగ్ (Strong typing) ఉండటం వల్ల ఏజెంట్ సొంతంగా ఊహలు (assumptions) చేయకుండా నిరోధించవచ్చు.
- Tool permissions మరియు సేఫ్టీ లిమిట్స్. ఏ టూల్స్ను skill ఉపయోగించగలదో స్పష్టంగా జాబితా చేయండి. Retries, spending limits మరియు rate caps పై గార్డ్రైల్స్ (guardrails) ఏర్పాటు చేయండి. ఒకవేళ skill యూజర్ డిలీషన్ APIని తాకకూడదు అనుకుంటే, దానిని కేవలం వచనంలో (prose) మాత్రమే కాకుండా కోడ్లో కూడా చెప్పండి.
- Success criteria మరియు టెస్ట్ కేసులు. ఒక skill రన్ అవుతున్నంత మాత్రాన అది "పనిచేస్తుంది" అని కాదు. అవుట్పుట్లో ఏముండాలి అనేది నిర్వచించండి. రీఫండ్ skill కోసం, విజయం అంటే ఒక వాలిడేటెడ్ ట్రాన్సాక్షన్ రికార్డ్, పంపబడిన ఈమెయిల్ కన్ఫర్మేషన్ మరియు క్రియేట్ చేయబడిన ఆడిట్ లాగ్ ఎంట్రీ అని అర్థం కావచ్చు.
- Version history మరియు ఓనర్ స్టేటస్. దీనికి ఒక యజమాని ఉండాలి. v2.3 ఎందుకు ఉందో మరియు v2.2లో ఏమి విఫలమైందో ఒక changelog వివరించాలి.
మీ లేయర్లను వేరు చేయండి
టీమ్లు చేసే అతిపెద్ద తప్పు ఏమిటంటే అన్నింటినీ ఒకే ప్రాంప్ట్లో నింపేయడం. వారు ఫ్రెండ్లీ గైడెన్స్, టూల్ డాక్యుమెంటేషన్, సెక్యూరిటీ పాలసీ మరియు ఎర్రర్ హ్యాండ్లింగ్ను ఒకే పెద్ద టెక్స్ట్ బ్లాక్గా కలిపేస్తారు. అది మెయింటైన్ చేయడం అసాధ్యం.
వాటిని విడదీయండి:
- Instructions అనేవి ఏజెంట్కు మార్గదర్శకాలు. ఇవి టోన్, ఫార్మాట్ మరియు సాధారణ విధానాన్ని వివరిస్తాయి.
- Tool Rules అనేవి ఏ ఏ టూల్స్ ఉన్నాయో మరియు అవి ఏమి చేస్తాయో ఏజెంట్కు తెలియజేస్తాయి. ఇది కేవలం వాటిని కనుగొనడం మాత్రమే, అనుమతి పొందడం కాదు.
- Policy అనేది కోడ్ ద్వారా అమలు చేయబడుతుంది, కేవలం ఆశించడం ద్వారా కాదు. ఒకవేళ $500 కంటే ఎక్కువ రీఫండ్ కావాలంటే దానికి రెండో వ్యక్తి పరిశీలన అవసరమైతే, ఆ తనిఖీ టూల్ను పిలవకముందే నడిచే ఒక వాలిడేషన్ ఫంక్షన్లో ఉంటుంది.
- Evals అనేవి ఏదైనా మార్పు చేసిన తర్వాత కూడా నైపుణ్యం (skill) పని చేస్తుందని నిరూపించే పరీక్షలు.
ఉదాహరణకు, "దయచేసి కస్టమర్ యొక్క పూర్తి క్రెడిట్ కార్డ్ నంబర్ను ఎప్పుడూ బయట పెట్టకండి" అని వ్రాయకండి. బదులుగా, ఏజెంట్ చూడకముందే PANలను మాస్క్ చేసే ఒక డేటా ఫార్మాటర్ను రూపొందించండి. తెలివైన యూజర్ ఇన్పుట్ ద్వారా కోడ్ను మార్చలేము కాబట్టి, పాలసీని కోడ్లోనే ఉంచాలి.
ప్రొడక్షన్ను "Latest" వైపు పాయింట్ చేయడం ఆపండి
నిశ్శబ్దంగా జరిగే ప్రాంప్ట్ అప్డేట్ వల్ల శుక్రవారం సాయంత్రం అంతా పాడైపోవచ్చు. మీ ప్రొడక్షన్ ఏజెంట్ ఎప్పుడూ ఒక స్కిల్ యొక్క "latest" వెర్షన్ను తీసుకుంటుంటే, ప్రతి మెర్జ్ (merge) ఒక సంభావ్య లైవ్ ఇన్సిడెంట్గా మారుతుంది. మీకు dev, staging, మరియు prod వంటి ఏలియాస్లు (aliases) అవసరం. పరీక్షించబడిన వెర్షన్ను ఈ దశల ద్వారా ముందుకు పంపండి. prod అనేది v2.1.4 కి పాయింట్ చేసినప్పుడు, మీరు దాని పనితీరును గమనించి, కొలవవచ్చు మరియు ప్రశాంతంగా నిద్రపోవచ్చు. ఏదైనా తప్పు జరిగితే, మీరు ఏలియాస్ను వెనక్కి మారుస్తారు. ఒత్తిడిలో ఉన్నప్పుడు అర్ధరాత్రి వేళ నేచురల్ లాంగ్వేజ్ను డీబగ్ చేయడం చేయకూడదు.
ఈ క్రమశిక్షణ మీ బృందాన్ని బ్యాక్వర్డ్స్ కాంపాటబిలిటీ (backwards compatibility) గురించి ఆలోచించేలా చేస్తుంది. v2.2 వెర్షన్, v2.1 లాగే అదే ఇన్పుట్ షేప్ను హ్యాండిల్ చేయగలదా? లేకపోతే, ఆ ప్రమోషన్ స్టేజింగ్లోనే విఫలమవుతుంది, తద్వారా కస్టమర్కు తెలియకముందే మీరు దానిని గుర్తించవచ్చు.
భద్రత ప్యాకేజీ లోపలే మొదలవుతుంది
తనిఖీ చేయని ప్రాంప్ట్లతో నిండిన రిజిస్ట్రీ అనేది ప్రమాదానికి దారితీసే ఒక లోపం. మీరు కోడ్ను ఎలా స్కాన్ చేస్తారో, మీ స్కిల్స్ను కూడా అదే రిస్క్ల కోసం స్కాన్ చేయాలి.
ప్రాంప్ట్ టెంప్లేట్లలో దాగి ఉన్న హార్డ్కోడ్డ్ సీక్రెట్స్ లేదా API కీలను వెతకండి. డేటాను బయటకు పంపే ఎక్స్టర్నల్ వెబ్హుక్స్ (webhooks) లేదా షెల్ కమాండ్ల కోసం తనిఖీ చేయండి. సిస్టమ్ పాలసీని అధిగమించడానికి చేసే ప్రయత్నాలను గమనించండి, ఉదాహరణకు "ignore previous instructions" అని ఉండే ప్రాంప్ట్లు లేదా ఏజెంట్ను దాని స్వంత కాన్ఫిగరేషన్ను వెల్లడించమని అడిగే ప్రాంప్ట్లు. ఇవి కేవలం సిద్ధాంతపరమైనవి మాత్రమే కాదు. ఇవి ప్రాంప్ట్-ఇంజెక్షన్ దాడులలో సాధారణంగా కనిపించే పద్ధతులు, మరియు ఎవరూ రివ్యూ చేయని కాపీ చేసిన టెక్స్ట్తో ఇవి వచ్చే అవకాశం ఉన్నందున ఇవి ప్రమాదకరమైనవి.
మీ స్కిల్ ప్యాకేజీలను స్టాటిక్ అనాలిసిస్ (static analysis) ద్వారా రన్ చేయండి. ఒకవేళ స్కిల్ ఫైల్లో అనుమతించబడిన జాబితా (allowlist)లో లేని URL ఉంటే, బిల్డ్ను ఫెయిల్ చేయండి. అది ఆమోదించబడిన మేనిఫెస్ట్లో లేని టూల్ను రిఫరెన్స్ చేస్తే, దానిని తిరస్కరించండి.
మీరు దాన్ని పరీక్షించలేకపోతే, మీరు దానిని నమ్మలేరు
ఎవల్యూయేషన్స్ (evaluations) లేని రిజిస్ట్రీ అనేది కేవలం ప్రాంప్ట్ల ఫోల్డర్ మాత్రమే. ప్రతి స్కిల్కు హ్యాపీ పాత్ (happy path), ఎడ్జ్ కేసెస్ (edge cases), మరియు ఫెయిల్యూర్ మోడ్స్ను పరీక్షించే ఒక టెస్ట్ సెట్ అవసరం. అధిక రిస్క్ ఉన్న స్కిల్స్ కోసం, కేవలం ఫంక్షనల్ టెస్ట్లు మాత్రమే సరిపోవు. ఏజెంట్ మరొక యూజర్ యొక్క డేటాను చూడలేదని నిర్ధారించుకోవడానికి మీరు పర్మిషన్ బౌండరీలను పరీక్షించాల్సి ఉంటుంది. పాలసీ ఒక చర్యను నిరోధించినప్పుడు అది "వద్దు" అని చెబుతుందో లేదో నిర్ధారించుకోవడానికి రిఫ్యూజల్ బిహేవియర్ (refusal behavior) చెక్లు అవసరం. మీ కోడ్-లెవల్ ప్రొటెక్షన్లను అడ్వర్సరియల్ ఇన్పుట్లు దాటవేయలేవని నిర్ధారించుకోవడానికి ప్రాంప్ట్-ఇంజెక్షన్ రెసిస్టెన్స్ టెస్ట్లు అవసరం.
మీ పరీక్షలకు స్పష్టమైన పేర్లు పెట్టండి. "refund_skill_rejects_negative_amount" అని పిలవబడే ఒక టెస్ట్, తదుపరి ఇంజనీర్కు ఏ ప్రవర్తన రక్షించబడుతుందో ఖచ్చితంగా చెబుతుంది. వెర్షన్ ప్రమోషన్ సమయంలో ఒక టెస్ట్ విఫలమైతే, ఆ బిల్డ్ సురక్షితం కాదని మీకు బలమైన ఆధారాలు లభిస్తాయి.
నిజమైన లక్ష్యం నియంత్రణ (Control)
రీయూజ్ (Reuse) బాగుంటుంది, కానీ నియంత్రణ (control) మాత్రమే మిమ్మల్ని ఉద్యోగంలో నిలబెడుతుంది. ఒక స్కిల్ రిజిస్ట్రీ మీ బృందానికి ఈ క్రింది వాటిని ఖచ్చితంగా చెప్పేలా చేస్తుంది: ఇది ఆమోదించబడిన వర్క్ఫ్లో. ఇది ప్రొడక్షన్లో నడుస్తున్న వెర్షన్. ఇవి అది ఉపయోగించగల టూల్స్. మనం దీనిని ఎలా రోల్బ్యాక్ (roll back) చేయాలి అనేది కూడా స్పష్టంగా తెలుస్తుంది.
ఆ స్పష్టత మిమ్మల్ని కేవలం తెలివైన డెమోలను పంపడం నుండి నమ్మదగిన సాఫ్ట్వేర్ను నడపడం వైపు మారుస్తుంది. డెమోలు స్టేక్హోల్డర్లను పది నిమిషాల పాటు ఆకట్టుకుంటాయి. కానీ నమ్మదగిన సాఫ్ట్వేర్ తెల్లవారుజామున మూడు గంటల సమయంలో కూడా నడుస్తుంది, ఎక్సెప్షన్లను చక్కగా హ్యాండిల్ చేస్తుంది మరియు మంగళవారం మధ్యాహ్నం ఎవరో ఒక పుల్ రిక్వెస్ట్ (pull request) మెర్జ్ చేసినంత మాత్రాన తన ప్రవర్తనను మార్చుకోదు.
మీ రిజిస్ట్రీని నిర్మించండి. మీ స్కిల్స్కు వెర్షన్లు ఇవ్వండి. మీ పాలసీలను కోడ్లో అమలు చేయండి. మీ నిద్ర సమయం దానిపై ఆధారపడి ఉన్నట్లుగా పరీక్షించండి. మీ భవిష్యత్తు స్వయం మీకు కృతజ్ఞతలు చెబుతుంది.