ప్రతి ప్రొడక్ట్ రోడ్మ్యాప్లో "AI Agent" అనే ఒక బుల్లెట్ పాయింట్ ఉంటుంది. ఆ పదం పురోగతిలా అనిపిస్తుంది. ఇది మీ టీమ్ భవిష్యత్తును నిర్మిస్తోందని, కేవలం వర్తమానాన్ని కాపాడుకోవడమే కాదని నాయకత్వానికి సంకేతం ఇస్తుంది. కానీ చాలా డెమో వీడియోలు మీకు చూపించని అసౌకర్యకరమైన నిజం ఏమిటంటే: ఒక పనిని పూర్తి చేయడానికి ఏజెంట్ అనేది అత్యంత ఖరీదైన మరియు తక్కువ అంచనా వేయగలిగే మార్గం. మెజారిటీ వ్యాపార పనులకు, ఇది పూర్తిగా తప్పు సాధనం. ఉత్తమ ఇంజనీర్లు ఒక దానిని నిర్మించడానికి తొందరపడేవారు కాదు. ఎప్పుడు ఆపాలో తెలిసినవారే నిజమైన ఇంజనీర్లు.
వర్గీకరణ ఉచ్చు (The Classification Trap)
ఒక టీమ్ వారి మొదటి ఏజెంట్ను ఎలా ప్లాన్ చేస్తుందో గమనిస్తే, సాధారణంగా ఇలా ఉంటుంది. ఒక సపోర్ట్ ఈమెయిల్ వస్తుంది. ఒక లార్జ్ లాంగ్వేజ్ మోడల్ దాని సబ్జెక్ట్ మరియు బాడీని చదివి, అది బిల్లింగ్ ప్రశ్న లేదా టెక్నికల్ బగ్ అని నిర్ణయించి, దానిని తగిన క్యూ (queue) లోకి పంపిస్తుంది. టీమ్ దీనిని ఏజెంట్ అని పిలుస్తుంది. కానీ అది ఏజెంట్ కాదు.
వారు నిర్మించింది దాని లోపల ఒకే ఒక మోడల్ కాల్ ఉన్న ఒక డిటర్మినిస్టిక్ ఫ్లో (deterministic flow). దశలు స్థిరంగా ఉంటాయి: ఈమెయిల్ తీసుకోవడం, మోడల్ను పిలవడం, క్యూకి పంపడం. ఇందులో లూప్ లేదు, టూల్ వాడకం లేదు, మొదటి ప్రయత్నం విఫలమైనప్పుడు తన ప్లాన్ను పునరాలోచించడానికి సిస్టమ్ ఆగే సందర్భం లేదు. ఇది నాలెడ్జ్ బేస్ను బ్రౌజ్ చేయదు, కోడ్ రాయదు లేదా మధ్యలో ఆర్డర్ స్టేటస్ను తనిఖీ చేయదు. ఇది ఒక నిర్ణయం తీసుకుని ముందుకు వెళ్తుంది. ఆ సింగిల్ కాల్ను ఒక మైక్రోసర్వీస్లో చుట్టడం వల్ల అది ఏజెంట్ అయిపోదు.
ఒక ఫ్లోను ఏజెంట్గా పొరబడటం వల్ల కలిగే నిజమైన ఖర్చు కేవలం అదనపు ఇన్ఫ్రాస్ట్రక్చర్ మాత్రమే కాదు. అది ఎటువంటి ప్రయోజనం లేకుండా మీరు ఆహ్వానించిన నాన్-డిటర్మినిజం (non-determinism). టెంపరేచర్ (temperature) సున్నా కాకపోవడం వల్ల లేదా ప్రాంప్ట్ మారడం వల్ల మంగళవారం ఉదయం వచ్చిన అదే ఈమెయిల్ బుధవారం మధ్యాహ్నం వేరే విధంగా రూట్ చేయబడవచ్చు. ఒక క్లాసిఫికేషన్ స్టెప్ ఉన్న ఫ్లో సమస్యను వేగంగా మరియు చౌకగా పరిష్కరిస్తుంటే, మీరు లేటెన్సీ (latency), టోకెన్ ఖర్చులు మరియు ఎవాల్యుయేషన్ ఓవర్హెడ్ కోసం ఏజెంట్ ధరలు చెల్లిస్తున్నారు.
మెట్ల ద్వారా పనిని క్రమబద్ధీకరించండి (Work Down the Ladder)
చాలా సమస్యలకు వాటిని అంతే సమర్థవంతంగా పరిష్కరించే సరళమైన మార్గాలు ఉంటాయి. దీనిని ఒక మెట్లుగా భావించి, కింద నుండి ప్రారంభించండి.
ప్రక్రియను సరిదిద్దండి. కొన్నిసార్లు రెండు సిస్టమ్ల మధ్య విభేదాల వల్ల మాత్రమే ఆ పని అవసరమవుతుంది. మీ CRM లోని కస్టమర్ రికార్డ్ మీ టికెటింగ్ ప్లాట్ఫామ్తో సింక్ అవ్వకపోతే, ప్రతిరోజూ ఒక మనిషి ఆ గ్యాప్ను మాన్యువల్గా పూరించాల్సి వస్తుంది. ఆ గ్యాప్ను ఏజెంట్తో ఆటోమేట్ చేయకండి. దానిని పూర్తిగా తొలగించండి. డేటా పైప్లైన్ సరిగ్గా ఉంటే, ఆ పని అవసరమే ఉండదు.
క్వరీని ఉపయోగించండి. సమాధానం కేవలం ఒక సింపుల్ లుకప్ లేదా అగ్రిగేషన్ అయితే, దానిని అలాగే扱ండి. "గత మంగళవారం మేము ఎన్ని రీఫండ్లను ప్రాసెస్ చేశాము?" అనే ప్రశ్నకు రీజనింగ్ అవసరం లేదు. దానికి SQL అవసరం. నేచురల్ లాంగ్వేజ్ను SQLగా మార్చే ఏజెంట్ వినడానికి బాగుంటుంది, కానీ మీ టీమ్ డాష్బోర్డ్ నుండి రన్ చేసే మూడు డాక్యుమెంటెడ్ క్వరీలను వ్రాయడం కంటే దాని మెయింటెనెన్స్ భారం ఎక్కువగా ఉంటుందని మీరు గ్రహించే వరకు.
డిటర్మినిస్టిక్ ఫ్లోను నిర్మించండి. నియమాలు స్థిరంగా ఉన్నప్పుడు మరియు ఫలితం పునరావృతమయ్యేలా ఉన్నప్పుడు, స్పష్టమైన లాజిక్ను ఉపయోగించండి. ఆర్డర్ విలువ ఒక పరిమితిని మించితే, ఫైనాన్స్కు పంపండి. యూజర్ ముప్పై రోజుల పాటు యాక్టివ్గా లేకపోతే, రీ-ఎంగేజ్మెంట్ ఈమెయిల్ పంపండి. కోడ్ దీనిని సున్నా వేరియెన్స్తో మరియు పూర్తి అబ్జర్వబిలిటీతో నిర్వహిస్తుంది. మీరు దీనిని యూనిట్-టెస్ట్ చేయవచ్చు. మీరు ఒక 'వైబ్' (vibe) ను యూనిట్-టెస్ట్ చేయలేరు.
ఒకే ఒక మోడల్ కాల్ ఉన్న ఫ్లోను ఉపయోగించండి. క్లాసిఫికేషన్, సెంటిమెంట్ ట్యాగింగ్ లేదా డేటా ఎక్స్ట్రాక్షన్ వంటివి ఇక్కడ ఉంటాయి. మోడల్ ఒక రిజిడ్ స్క్రిప్ట్ లోపల ఒకే ఒక నిర్ణయం తీసుకుంటుంది. మీరు ఒక డాక్యుమెంట్ను తీసుకుని, ఇన్వాయిస్ నంబర్ను వెలికితీసి, దానిని డేటాబేస్లో రాస్తారు. చుట్టూ ఉన్న దశలు హార్డ్కోడ్ చేయబడతాయి. మోడల్ తర్వాత ఏమి చేయాలో ఎంచుకోదు; అది చూసిన దానికి కేవలం లేబుల్ మాత్రమే వేస్తుంది. ఇది ఒక శక్తివంతమైన ప్యాటర్న్, కానీ ఇది ఇంకా ఒక ఫ్లో మాత్రమే.
ఏజెంట్ను చివరగా నిర్మించండి. మోడల్ రన్ అవుతున్నప్పుడు కొత్తగా ఏమి తెలుసుకుంటుందో దానిపై తదుపరి చర్య ఆధారపడి ఉన్న పనుల కోసం మాత్రమే ఈ దశను ఉంచండి. సిస్టమ్ ఒక ఈమెయిల్ చదవాలి, లాజిస్టిక్స్ API లో షిప్మెంట్ను చూడాలి, షిప్మెంట్ ఆలస్యమైందని తెలుసుకోవాలి మరియు ఆ తాజా డేటా ఆధారంగా ఒక కస్టమ్ రెస్పాన్స్ను డ్రాఫ్ట్ చేయాలి అంటే, మీరు ఏజెంట్ పరిధిలోకి వచ్చారు. ప్రతి కొత్త వాస్తవం తర్వాత మోడల్ ఏమి చేయాలో నిర్ణయిస్తుంది కాబట్టి, మార్గాన్ని ముందుగానే గీయలేము.
వైట్బోర్డ్ టెస్ట్ (The Whiteboard Test)
మీటింగ్ లో చర్చను ముగించడానికి ఒక వేగవంతమైన మార్గం ఉంది. మీ టీమ్ను వైట్బోర్డ్పై నిర్ణయ బ్రాంచ్లను (decision branches) గీయమని అడగండి.
మోడల్ రన్ కావడానికి ముందే మీరు ప్రతి మార్గాన్ని మ్యాప్ చేయగలిగితే, ఒక ఫ్లోను నిర్మించండి. డైమండ్ ఆకారాలను గీయండి, if-statements రాయండి మరియు పని పూర్తి చేయండి. ప్రిడిక్టబిలిటీ (Predictability) అనేది ఒక ఫీచర్, పరిమితి కాదు.
తదుపరి దశ ఏమిటో మోడలే నిర్ణయించాల్సి వస్తే, అది టూల్ను ఎంచుకోవాల్సి వస్తే, పారామీటర్లను సెట్ చేయాల్సి వస్తే మరియు మళ్ళీ ఆలోచించడానికి లూప్ చేయాల్సి వస్తే, అప్పుడు మీకు ఏజెంట్ అవసరం. ఆ డైనమిక్ రూటింగ్ (dynamic routing) అనేది విభజన రేఖ. మీరు కొత్త APIని ఉపయోగించాలనుకోవడం వల్ల పొరపాటున ఆ రేఖను దాటకండి.
దాగి ఉన్న పన్ను (The Hidden Tax)
డెమోలు ఏజెంట్లను ఎటువంటి ఇబ్బంది లేనివిగా చూపుతాయి. కానీ ప్రొడక్షన్ (Production) లో వేగంగా పెరిగిపోయే నాలుగు రకాల ఖర్చులు (taxes) బయటపడతాయి.
నాన్-డిటర్మినిజం.