ஒவ்வொரு தயாரிப்புத் திட்டத்திலும் (product roadmap) "AI Agent" என்ற ஒரு புள்ளி இருக்கும். அந்த வார்த்தை ஒரு முன்னேற்றத்தைப் போலத் தோன்றுகிறது. உங்கள் குழு எதிர்காலத்தை உருவாக்கி வருகிறது, தற்போதைய நிலையை மட்டும் பராமரிக்கவில்லை என்பதை அது தலைமைத்துவத்திற்குத் தெரிவிக்கிறது. ஆனால் பெரும்பாலான டெமோ வீடியோக்கள் உங்களுக்குக் காட்டாத ஒரு சங்கடமான உண்மை இங்கே உள்ளது: ஒரு வேலையை முடிப்பதற்கு ஏஜென்ட் (agent) என்பது மிகவும் செலவுமிக்க மற்றும் மிகக் குறைந்த கணிக்கக்கூடிய (least predictable) வழியாகும். பெரும்பாலான வணிகப் பணிகளுக்கு, அது முற்றிலும் தவறான கருவி. ஒரு ஏஜென்ட்டை உருவாக்கத் துரிதப்படுபவர்கள் சிறந்த பொறியாளர்கள் அல்ல. எப்போது நிறுத்த வேண்டும் என்று தெரிந்தவர்களே சிறந்த பொறியாளர்கள்.

வகைப்படுத்துதல் பொறி (The Classification Trap)

ஒரு குழு தங்களின் முதல் ஏஜென்ட்டைத் திட்டமிடுவதைப் பார்த்தால், பொதுவாக இது போன்ற ஒன்றை நீங்கள் காண்பீர்கள். ஒரு ஆதரவு மின்னஞ்சல் (support email) வருகிறது. ஒரு பெரிய மொழி மாதிரி (large language model) அதன் தலைப்பு மற்றும் உள்ளடக்கத்தைப் படித்து, அது ஒரு கட்டணக் கேள்வியா அல்லது தொழில்நுட்பப் பிழையா என்பதைத் தீர்மானித்து, அதைத் தகுந்த வரிசையில் (queue) சேர்க்கிறது. அந்த குழு இதை ஒரு ஏஜென்ட் என்று அழைக்கிறது. ஆனால் அது இல்லை.

அவர்கள் உருவாக்கியது ஒரு மாடல் அழைப்பை (model call) உள்ளடக்கிய ஒரு தீர்மானிக்கப்பட்ட ஓட்டம் (deterministic flow) மட்டுமே. அதன் படிகள் நிலையானவை: மின்னஞ்சலைப் பெறுதல், மாடலை அழைத்தல், வரிசையில் சேர்த்தல். அதில் எந்தத் தொடர்ச்சியான சுழற்சியும் (loop) இல்லை, கருவி பயன்பாடும் (tool use) இல்லை, முதல் முயற்சி தோல்வியடைந்தால் திட்டத்தை மறுபரிசீலனை செய்யத் தற்காலிகமாக நிற்கும் தருணமும் இல்லை. அது ஒரு அறிவுத் தளத்தைத் (knowledge base) தேடாது, குறியீட்டை எழுதாது அல்லது இடையில் ஒரு ஆர்டர் நிலையைச் சரிபார்க்காது. அது ஒரு முடிவை மட்டும் எடுத்துவிட்டு நகர்ந்துவிடும். அந்த ஒற்றை அழைப்பை ஒரு மைக்ரோ சர்வீஸில் (microservice) சுற்றியது அதை ஒரு ஏஜென்ட் ஆக்கிவிடாது.

ஒரு ஓட்டத்தை (flow) ஏஜென்ட் என்று தவறாகக் கருதுவதால் ஏற்படும் உண்மையான செலவு கூடுதல் உள்கட்டமைப்பு மட்டுமல்ல. எந்தப் பயனும் இன்றி நீங்கள் வரவழைத்த நிச்சயமற்ற தன்மையே (non-determinism) அதன் உண்மையான செலவாகும். செவ்வாய்க்கிழமை காலை வரும் அதே மின்னஞ்சல், புதன்கிழமை மதியம் வேறு விதமாக வகைப்படுத்தப்படலாம்; ஏனெனில் 'temperature' பூஜ்ஜியமாக இல்லாமல் இருக்கலாம் அல்லது 'prompt' மாறலாம். ஒரு வகைப்பாட்டுப் படிநிலை கொண்ட ஓட்டம் (flow) ஒரு சிக்கலை வேகமாகவும் மலிவாகவும் தீர்க்கும் போது, நீங்கள் தாமதம் (latency), டோக்கன் செலவுகள் மற்றும் மதிப்பீட்டுச் சுமை (evaluation overhead) ஆகியவற்றிற்காக ஏஜென்ட் விலையைக் கொடுக்கிறீர்கள்.

ஏணியின் கீழ் மட்டத்திலிருந்து செயல்படுங்கள் (Work Down the Ladder)

பெரும்பாலான சிக்கல்களுக்கு அவற்றைச் சிறப்பாகத் தீர்க்கக்கூடிய எளிமையான மாற்று வழிகள் உள்ளன. இதை ஒரு ஏணி என்று நினைத்துக் கொள்ளுங்கள், அதன் அடிப்பகுதியிலிருந்து தொடங்குங்கள்.

செயல்முறையைச் சரிசெய்யுங்கள் (Fix the process). சில நேரங்களில் இரண்டு அமைப்புகள் முரண்படுவதால் மட்டுமே அந்த வேலை உருவாகிறது. உங்கள் CRM-இல் உள்ள ஒரு வாடிக்கையாளர் பதிவு உங்கள் டிக்கெட்டிங் தளத்துடன் (ticketing platform) ஒத்துப்போகவில்லை என்பதால், ஒவ்வொரு காலையிலும் ஒரு மனிதன் அந்த இடைவெளியை நிரப்ப வேண்டியுள்ளது. அந்த இடைவெளியை ஒரு ஏஜென்ட் மூலம் தானியக்கமாக்காதீர்கள். அதை முற்றிலுமாக நீக்குங்கள். தரவுப் பாதை (data pipeline) ஆரோக்கியமாக இருந்தால், அந்த வேலைவே மறைந்துவிடும்.

ஒரு வினவலைப் (query) பயன்படுத்துங்கள். பதில் என்பது ஒரு எளிய தேடல் அல்லது தொகுப்பு (aggregation) என்றால், அதை அப்படியே நடத்துங்கள். "கடந்த செவ்வாய்க்கிழமை நாம் எத்தனை ரீஃபண்டுகளை (refunds) செயல்படுத்தினோம்?" என்பதற்குத் தர்க்கரீதியான சிந்தனை (reasoning) தேவையில்லை. அதற்கு SQL தேவைப்படுகிறது. இயற்கை மொழியை SQL ஆக மாற்றும் ஒரு ஏஜென்ட் கேட்பதற்கு அழகாக இருக்கலாம், ஆனால் உங்கள் குழு ஒரு டேஷ்போர்டில் இருந்து இயக்கும் மூன்று ஆவணப்படுத்தப்பட்ட வினவல்களை (queries) எழுதுவதை விட, அதை பராமரிக்கும் சுமை அதிகமாக இருக்கும் என்பதை நீங்கள் உணரும் வரை அது அழகாகவே இருக்கும்.

ஒரு தீர்மானிக்கப்பட்ட ஓட்டத்தை (deterministic flow) உருவாக்குங்கள். விதிகள் நிலையானதாகவும், முடிவு மீண்டும் மீண்டும் கிடைப்பதாகவும் இருக்கும்போது, தெளிவான தர்க்கத்தைப் (explicit logic) பயன்படுத்துங்கள். ஒரு ஆர்டர் மதிப்பு ஒரு குறிப்பிட்ட வரம்பைத் தாண்டினால், அதை நிதித் துறைக்கு (finance) மாற்றவும். ஒரு பயனர் முப்பது நாட்களாகச் செயல்படவில்லை என்றால், மீண்டும் இணைவதற்கான மின்னஞ்சலை அனுப்பவும். குறியீடு (Code) இதை எந்த மாறுபாடும் இன்றி முழுமையான கண்காணிப்புடன் (observability) கையாளும். உங்களால் இதை யூனிட்-டெஸ்ட் (unit-test) செய்ய முடியும். ஒரு உணர்வை (vibe) உங்களால் யூனிட்-டெஸ்ட் செய்ய முடியாது.

ஒரு மாடல் அழைப்பு கொண்ட ஓட்டத்தைப் பயன்படுத்துங்கள். வகைப்படுத்துதல் (classification), உணர்வுத் தெரிவு (sentiment tagging) அல்லது தரவுப் பிரித்தெடுத்தல் (data extraction) போன்றவை இங்குதான் அமையும். ஒரு கடுமையான ஸ்கிரிப்ட்டிற்குள் மாடல் ஒரு ஒற்றை முடிவை எடுக்கிறது. நீங்கள் ஒரு ஆவணத்தைப் பெற்று, இன்வாய்ஸ் எண்ணைப் பிரித்தெடுத்து, அதை ஒரு தரவுத்தளத்தில் (database) எழுதுகிறீர்கள். அதைச் சுற்றியுள்ள படிகள் முன்கூட்டியே தீர்மானிக்கப்பட்டவை (hardcoded). அடுத்து என்ன செய்ய வேண்டும் என்பதை மாடல் முடிவு செய்யாது; அது பார்ப்பதை லேபிளிட்டு (label) மட்டுமே செய்யும். இது ஒரு சக்திவாய்ந்த முறைதான், ஆனால் இது இன்னும் ஒரு ஓட்டம் (flow) தான்.

ஏஜென்ட்டை இறுதியாக உருவாக்குங்கள். மாடல் இயங்கும் போது கண்டறியும் விஷயத்தைப் பொறுத்து அடுத்த நடவடிக்கை உண்மையாகவே அமையும் பணிகளுக்கு மட்டுமே இந்த படிநிலையை ஒதுக்குங்கள். ஒரு அமைப்பு மின்னஞ்சலைப் படிக்க வேண்டும், ஒரு லாஜிஸ்டிக்ஸ் API-இல் ஷிப்மென்ட்டைத் தேட வேண்டும், ஷிப்மென்ட் தாமதமாகிவிட்டது என்பதைக் கண்டறிய வேண்டும், பின்னர் அந்தப் புதிய தரவின் அடிப்படையில் ஒரு தனிப்பயனாக்கப்பட்ட பதிலை உருவாக்க வேண்டும் என்றால், நீங்கள் ஏஜென்ட் territory-இல் இருக்கிறீர்கள். ஒவ்வொரு புதிய உண்மையையும் கண்டறிந்த பிறகு என்ன செய்ய வேண்டும் என்பதை மாடல் முடிவு செய்வதால், பாதையை முன்கூட்டியே வரைய முடியாது.

ஒயிட்போர்டு சோதனை (The Whiteboard Test)

ஒரு கூட்டத்தில் விவாதத்தை விரைவாக முடிவுக்குக் கொண்டுவர ஒரு வழி உள்ளது. உங்கள் குழுவிடம் ஒரு ஒயிட்போர்டில் முடிவெடுக்கும் கிளைகளை (decision branches) வரையச் சொல்லுங்கள்.

மாடல் இயங்குவதற்கு முன்பே ஒவ்வொரு பாதையையும் உங்களால் வரைபடமாக்க முடிந்தால், ஒரு ஓட்டத்தை (flow) உருவாக்குங்கள். வைர வடிவங்களை வரையவும், if-statements-களை எழுதவும், அவ்வளவுதான். கணிக்கக்கூடிய தன்மை (Predictability) என்பது ஒரு வசதி, அது ஒரு வரம்பு அல்ல.

அடுத்த கட்டம் என்ன என்பதை மாடலே தீர்மானிக்க வேண்டும் என்றால், அது கருவியைத் தேர்ந்தெடுக்க வேண்டும், அளவுருக்களை (parameters) அமைக்க வேண்டும் மற்றும் மீண்டும் சிந்திப்பதற்காகச் சுழற்சி முறையில் இயங்க வேண்டும் என்றால், உங்களுக்கு ஒரு ஏஜென்ட் தேவைப்படுகிறது. அந்த மாறும் வழித்தடம் (dynamic routing) தான் பிரிக்கும் கோடு. ஒரு புதிய API-ஐப் பயன்படுத்த வேண்டும் என்பதற்காகத் தெரியாமல் அந்த எல்லையைத் தாண்டாதீர்கள்.

மறைமுக வரி (The Hidden Tax)

டெமோக்கள் ஏஜென்ட்களைத் தடையற்றதாகக் காட்டுகின்றன. ஆனால் தயாரிப்புச் சூழலில் (production), விரைவாகக் கூடும் நான்கு வகையான வரிகள் (taxes) வெளிப்படும்.

நிச்சயமற்ற தன்மை (Non-determinism). அதே