ప్రతి కొన్ని నెలలకు ఒకసారి, పరిశ్రమ స్వయంగా ఆలోచించగల సాఫ్ట్వేర్ కోసం ఒక కొత్త పదాన్ని సృష్టిస్తుంది. ప్రస్తుతం ఆ పదం "Agentic AI." విక్రేతలు తమ ల్యాండింగ్ పేజీలు మరియు పిచ్ డెక్స్లలో దీనిని వేగంగా ప్రచారం చేస్తున్నారు. కానీ ఒక సిస్టమ్ మీ వాతావరణం, మీ డేటా మరియు మీ వైఫల్య రూపాలతో (failure modes) పోరాడి నిలబడే వరకు, ఆ లేబుల్ కేవలం మార్కెటింగ్ కాపీ మాత్రమే. ఆ పదం భద్రత, విశ్వసనీయత లేదా అనుకూలత గురించి మీకు ఏమీ చెప్పదు.
ఫీచర్ జాబితాలను చదవడం ఆపి, సామర్థ్యాలను (capabilities) కొలవడం ప్రారంభించాల్సిన సమయం ఆసన్నమైంది.
ది లేబుల్ ప్రాబ్లం (The Label Problem)
సేల్స్ ఇంజనీర్లు "ఏజెంటిక్" ఆర్కిటెక్చర్కు నిరూపణగా డాష్బోర్డ్లు, మల్టీ-మోడల్ డ్రాప్డౌన్ మెనూలు మరియు మొబైల్ యాక్సెస్ను చూపిస్తారు. అవి ఇంటర్ఫేస్ ఎంపికలు మాత్రమే, ప్రవర్తనా గ్యారెంటీలు కావు. ఒక ఉత్పత్తి అత్యాధునికంగా కనిపించవచ్చు, కానీ API టైమ్ అవుట్ అయిన తర్వాత తన ప్రణాళికను సవరించాల్సి వచ్చినప్పుడు అది కుప్పకూలిపోవచ్చు.
అసలైన విషయం ఏమిటంటే, ఆ సిస్టమ్ నిజంగా ఒక స్వయంప్రతిపత్తి గల ఏజెంట్లా ప్రవర్తిస్తుందా లేదా అనేది. అది పనిని దశలుగా విభజిస్తుందా? అది కఠినమైన పరిమితుల లోపల నిజమైన సిస్టమ్లను తాకుతుందా? ఏదైనా విఫలమైనప్పుడు, అది సర్దుబాటు చేసుకుంటుందా లేదా కేవలం విఫలమై వేచి చూస్తుందా? మీ స్టాక్ (stack) కు సంబంధించిన ఆధారాలతో మీరు ఈ ప్రశ్నలకు సమాధానం ఇచ్చే వరకు, మీరు ఒక ఉత్పత్తిని కాకుండా, కేవలం ఒక భావనను (concept) కొనుగోలు చేస్తున్నారు.
ఐదు సామర్థ్య పరీక్షలు (Five Capability Tests That Actually Matter)
నేను ప్రతి ఏజెంటిక్ క్లెయిమ్ను ఐదు నిర్దిష్ట సామర్థ్యాల ఆధారంగా అంచనా వేస్తాను. ప్రతి దాని కోసం, నేను ఒక సాధారణ ప్రశ్న అడుగుతాను: ఆ ప్రవర్తన డాక్యుమెంట్ చేయబడిందా, పైలట్లో ధృవీకరించబడిందా లేదా ఇంకా తెలియదా? "తెలియదు" అనేది డిఫాల్ట్ స్థితి. దానికి విరుద్ధంగా నిరూపించాల్సిన బాధ్యత ఉత్పత్తిపైనే ఉంది.
ప్రణాళిక (Planning). సిస్టమ్ అస్పష్టమైన లక్ష్యాన్ని క్రమబద్ధమైన, ధృవీకరించదగిన దశలుగా విభజిస్తుందా? ఎవరైనా ఒక టు-డూ లిస్ట్ (to-do list) తయారు చేయగలరు. "ఈ త్రైమాసికంలో మన క్లౌడ్ ఖర్చును పదిహేను శాతం తగ్గించండి" వంటి గందరగోళమైన లక్ష్యాన్ని నిర్వహించడమే అసలైన పరీక్ష. నిజమైన ఏజెంట్ ప్రస్తుత వినియోగం యొక్క ఆడిట్ను రూపొందిస్తుంది, ఖాళీగా ఉన్న వనరులను గుర్తిస్తుంది, రైట్సైజింగ్ (rightsizing) సిఫార్సులను సిద్ధం చేస్తుంది మరియు సరైన క్రమంలో మార్పు అభ్యర్థనలను షెడ్యూల్ చేస్తుంది. అది మీకు కేవలం ఐదు పాయింట్ల వ్యాసాన్ని ఇచ్చి పని పూర్తయిందని చెబితే, అది ప్రణాళిక కాదు. అది కేవలం సారాంశం (summarizing).
టూల్స్ (Tools). అది నిర్ణీత పరిధిలో నిజమైన సిస్టమ్లపై పనిచేస్తుందా? మెరిసే డెమోలో ఒక మాక్ (mock) APIని పిలవడం సులభం. మీ ప్రొడక్షన్ CRMకి కనిష్ట-అధికార (least-privilege) క్రెడెన్షియల్స్తో ప్రామాణీకరించడం, ఒక రికార్డును రాయడం మరియు లావాదేవీని నమోదు చేయడం కష్టం. అది ఏ సిస్టమ్లను తాకుతుంది, ఏ కీలను కలిగి ఉంటుంది మరియు దాని ప్రభావ పరిధి (blast radius) ఎక్కడ ముగుస్తుంది అనేది మీరు ఖచ్చితంగా తెలుసుకోవాలి. పరిధి (Scope) పరిమితంగా ఉండాలి. ఒకవేళ ఏజెంట్కు డిఫాల్ట్గా ప్రొడక్షన్పై రైట్ యాక్సెస్ ఉంటే, అది ఏజెంట్ కాదు. అది ఒక బాధ్యత (liability).
సవరణ (Correction). వైఫల్యం తర్వాత అది తన తదుపరి చర్యను మారుస్తుందా? ఇక్కడే చాలా ప్రోటోటైప్లు విఫలమవుతాయి. మూడవ దశ 503 ఎర్రర్ను లేదా స్కీమా మిస్మ్యాచ్ను తిరిగి ఇచ్చినప్పుడు, ఏజెంట్ అనంతంగా లూప్లో ఉంటుందా, విజయవంతమైనట్లు భ్రమపడుతుందా (hallucinate), లేదా తన మార్గాన్ని సర్దుబాటు చేసుకుంటుందా? నిజమైన సవరణ అంటే వైఫల్యాన్ని గమనించడం, వర్క్ఫ్లో యొక్క మిగిలిన భాగాన్ని తిరిగి ప్లాన్ చేయడం మరియు నిబంధనలను ఉల్లంఘించకుండా కొత్త మార్గాన్ని అమలు చేయడం. ఆశావాదంతో కూడిన రీట్రై లూప్ (retry loop) సవరణ కాదు.
సందర్భం (Context). అది ప్రతి దశలోనూ నిబంధనలను (constraints) క్రియాశీలంగా ఉంచుతుందా? మెమరీ మాత్రమే సరిపోదు. ఒకవేళ మొదటి దశ "ఐదు వందల డాలర్ల బడ్జెట్ మించవద్దు" లేదా "EU కస్టమర్ డేటాను మినహాయించండి" వంటి కఠినమైన నియమాన్ని ఏర్పరిస్తే, ప్రాంప్ట్ సందర్భం మారినంత మాత్రాన ఏడవ దశ ఆ పరిమితిని విస్మరించకూడదు. ఇది కంప్లయన్స్ రూల్స్, బ్రాండ్ వాయిస్, అప్రూవల్ హైరార్చీలు మరియు యాక్సెస్ కంట్రోల్స్కు వర్తిస్తుంది. లాంగ్-కాంటెక్స్ట్ మోడల్స్ మరియు క్లాసికల్ స్టేట్ మేనేజ్మెంట్ కలవాల్సిన చోటు ఇదే.
పర్యవేక్షణ (Oversight). ఒక మనిషి ప్రక్రియను ఆపగలడా లేదా తిరిగి ప్రారంభించగలడా? మీకు కేవలం వర్చువల్ మెషీన్పై కిల్ స్విచ్ (kill switch) మాత్రమే కాకుండా, సూక్ష్మమైన (granular) సర్క్యూట్ బ్రేకర్లు అవసరం. ఎవరైనా రెండవ దశ తర్వాత ప్రణాళికను పరిశీలించి, మూడవ దశను ఆమోదించగలరా? ఒక బాహ్య డిపెండెన్సీ విఫలమైతే, మనిషి దానిని సరిచేసి, స్టేట్ను కోల్పోకుండా వర్క్ఫ్లోను తిరిగి ప్రారంభించగలరా? పర్యవేక్షణ అనేది విపత్తు జరిగిన తర్వాత మీరు చదివే ఆడిట్ లాగ్ కాదు. ఇది జోక్యం చేసుకోవడానికి ఒక ప్రత్యక్ష యంత్రాంగం (live mechanism).
ఆధారాలు చెక్బాక్స్ల కంటే మిన్న (Evidence Beats Checkboxes)
డెమో అనేది విశ్వసనీయత రేటు కాదు. విక్రేత పోలిక షీట్లోని చెక్బాక్స్ ఒక నిరూపణ కాదు. ఒక అకౌంట్ ఎగ్జిక్యూటివ్ ఉత్పత్తి "టెస్ట్ వైఫల్యం తర్వాత సవరించబడుతుంది" అని చెప్పినప్పుడు, మీ తదుపరి అడుగు 'ఎవిడెన్స్ కార్డ్' (evidence card) అడగడం కావాలి.
ఎవిడెన్స్ కార్డ్ అనేది చెక్బాక్స్ను నిర్దిష్టతతో భర్తీ చేస్తుంది. అది ఇలా ఉంటుంది:
- సామర్థ్యం (Capability): సవరణ (Correction)
- ప్రతిపాదన (Claim): టెస్ట్ వైఫల్యం తర్వాత సవరిస్తుంది
- ఆధారం (Evidence): పెండింగ్ కంట్రోల్డ్ ఫిక్చర్ (Pending controlled fixture)
- యజమాని (Owner): డెవలపర్-ఎక్స్పీరియన్స్ టీమ్
- ఆపవలసిన సందర్భం (Stop if): సవరణ ఆమోదించబడిన ఇంటర్ఫేస్ను మారుస్తే
ఈ ఫార్మాట్ స్పష్టతను కలిగిస్తుంది. ఇది మార్కెటింగ్ వాదనను మరియు నిరూపణను వేరు చేస్తుంది. ఇది బాధ్యతను (ownership) కేటాయిస్తుంది, తద్వారా ఏజెంట్ తన రివిజన్ ప్రయత్నంలో ఆమోదించబడిన ఇంటర్ఫేస్ను విచ్ఛిన్నం చేసినప్పుడు, ఏ టీమ్ను సంప్రదించాలో మీకు ఖచ్చితంగా తెలుస్తుంది. యజమాని లేకపోతే, జవాబుదారీతనం ఉండదు. స్టాప్ కండిషన్స్ (stop conditions) లేకపోతే, భద్రతా కవచం ఉండదు.
మీరు ఏదైనా పైలట్ (pilot) ప్రారంభించే ముందు, మూడు విషయాలను లిఖితపూర్వకంగా నిర్వచించండి. మొదటిది, మీ టాస్క్లు (tasks). ఇవి సింథటిక్ బెంచ్మార్క్ల నుండి కాకుండా, నిజమైన బిజినెస్ లాజిక్ నుండి తీసుకోబడాలి. రెండవది, మీ ఫెయిల్యూర్ టెస్ట్లు (failure tests). రన్ అవుతున్న సమయంలో API కీని రద్దు చేయడం, తప్పుగా ఉన్న JSON రెస్పాన్స్ను పంపడం లేదా ఆశించిన లాటెన్సీని (latency) రెట్టింపు చేయడం వంటివి చేయండి. మూడవది, మీ స్టాప్ కండిషన్స్ (stop conditions). ఇవి ఆటోమేటిక్గా ఉండాలి, ఎవరైనా గమనిస్తారని మీరు ఆశించే మాన్యువల్ పానిక్ బటన్ లాగా ఉండకూడదు.
వెండర్ క్లెయిమ్లను ఎలా ప్రశ్నించాలి
ఏజెంట్లకు ఐదు అంశాలు అవసరమని OpenAI ప్రతిపాదిస్తోంది: models, tools, instructions, guardrails, మరియు human intervention. వారి నిర్దిష్ట ఆర్కిటెక్చర్ను అనుసరించకుండానే, వెండర్లను ప్రశ్నించడానికి మీరు ఈ జాబితాను ఒక వొకాబులరీలా ఉపయోగించుకోవచ్చు.
కేవలం జనరేషన్ కాకుండా, ప్లానింగ్ను ఏ మోడల్ నిర్వహిస్తుందో అడగండి. ఏ టూల్ పర్మిషన్లు హార్డ్కోడెడ్ (hardcoded) చేయబడ్డాయి మరియు ఏవి డైనమిక్ (dynamic) అని అడగండి. గార్డ్రైల్స్ ఎక్కడ అమలు చేయబడతాయి—ప్రాంప్ట్ లేయర్లోనా లేదా ఆర్కెస్ట్రేషన్ ఇంజిన్లోనా అని అడగండి. హ్యూమన్ ఇంటర్వెన్షన్ అనేది ఒక బిల్ట్-ఇన్ చెక్పాయింటా లేదా ఏజెంట్ ఇప్పటికే మీ డేటాబేస్ను పాడు చేసిన తర్వాత పంపే పోస్ట్మార్టమ్ ఈమెయిలా అని అడగండి. మీరు OpenAI స్టాక్ కోసం షాపింగ్ చేయడం లేదు. వేరొకరి సిస్టమ్లోని లోపాలను బయటపెట్టడానికి మీరు వారి ఫ్రేమ్వర్క్ను ఉపయోగిస్తున్నారు.
MonkeyCode ఒక ఓపెన్-సోర్స్ మార్గాన్ని మరియు ఉచిత క్లౌడ్ వెర్షన్ను అందిస్తుంది. ఆ కలయిక పైలట్ను తక్కువ ఖర్చుతో ప్రారంభించడానికి వీలు కల్పిస్తుంది. కానీ తక్కువ ఖర్చుతో ప్రారంభించడం అంటే అది విజయవంతమైందని అర్థం కాదు. మీ స్వంత ఇన్ఫ్రాస్ట్రక్చర్పై మీ స్వంత టాస్క్లను రన్ చేసే వరకు సిస్టమ్లోని తెలియని భాగాలు తెలియకుండానే ఉంటాయి. కఠినమైన ప్రశ్నలకు సమాధానాలు దొరికాయని అనుకోవడానికి సున్నా డాలర్ల టికెట్ మిమ్మల్ని మోసం చేయనివ్వకండి.
బడ్జెట్ను ఆదా చేసే కొనుగోలు నియమం
ఏజెంటిక్ పైలట్ను ప్రొడక్షన్ కమిట్మెంట్గా విస్తరించడానికి నా నియమం సరళమైనది. కీలక సామర్థ్యాలకు నిరూపణ మరియు వైఫల్యాలకు స్పష్టమైన యజమాని ఉన్నప్పుడు మాత్రమే నేను స్కోప్ మరియు బడ్జెట్ను పెంచుతాను. రోడ్మ్యాప్ స్లైడ్ కాదు, సపోర్ట్ టికెట్ క్యూ కాదు. నిరూపణ అంటే మీ ఎన్విరాన్మెంట్ నుండి వచ్చే లాగ్స్ (logs). యజమాని అంటే ఆ నిర్దిష్ట వైఫల్యానికి బాధ్యత వహించే ఒక వ్యక్తి.
వెండర్ మీకు నిరూపణ చూపలేకపోతే, లేదా మీ అంతర్గత బృందం యజమానిని కేటాయించలేకపోతే, మీరు విస్తరించడానికి సిద్ధంగా లేరు. మీరు ఇంకా టెస్టింగ్ కొనసాగించడానికి మాత్రమే సిద్ధంగా ఉన్నారు.
గుర్తుంచుకోవలసినది: "Agentic" అనే పదం మీ మూల్యాంకనానికి ఒక ప్రారంభ సంకేతం మాత్రమే. అది ముగింపు రేఖ కాదు. కఠినమైన ప్రశ్నలు అడగడానికి, మరింత కఠినమైన పైలట్లను నిర్వహించడానికి మరియు మీ సంస్థలో ప్రాముఖ్యత కలిగిన ఆధారాలను కోరడానికి ఇది ఒక ప్రేరణగా భావించండి. ఒకవేళ ఉత్పత్తి మీ స్వంత వాతావరణంలో, మీ వైఫల్యాలతో ఐదు సామర్థ్య పరీక్షలను పాస్ చేయలేకపోతే, అది నిజంగా ఏజెంటిక్ కాదు. అది కేవలం మరొక డెమో మాత్రమే.
Source: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h
Optional learning community: https://t.me/GyaanSetuAi