புதிய மாடல் பெஞ்ச்மார்க்குகளை (benchmarks) இயக்குவதை நிறுத்திவிட்டு, உங்கள் ஏஜென்ட் ஒரு சந்தாவை (subscription) ரத்து செய்ய முயற்சிப்பதைக் கவனிக்கத் தொடங்குங்கள். அந்த இரண்டு செயல்பாடுகளுக்கும் இடையிலான இடைவெளியில்தான் தயாரிப்பு அமைப்புகள் (production systems) செயலிழக்கின்றன. ஒரு ஒற்றை-சுற்று சோதனை (single-turn test) ஒரு பதில் இனிமையாக இருக்கிறதா என்று சொல்ல முடியும். ஆனால், அந்த ஏஜென்ட் தவறான வாடிக்கையாளருக்குத் திரும்பப் பணம் (refund) கொடுத்துவிட்டதா, காலண்டர் API-இல் பதினான்கு முறை சுழன்றுவிட்டதா அல்லது மோசடி சரிபார்ப்பைத் (fraud check) தவிர்க்க முடிவு செய்துவிட்டதா என்பதை அதனால் சொல்ல முடியாது. ஒரு ஏஜென்ட் உருவாக்கும் விஷயங்களில் உரை (text) என்பது மிகவும் குறைவான ஆபத்துடையது. உண்மையான ஆபத்துகள் அது பயன்படுத்தும் கருவிகளிலும், அது மாற்றியமைக்கும் தரவுகளிலும், மற்றும் உதவி கேட்க வேண்டிய தருணத்தில் உதவி கேட்காமல் தொடர்ந்து செயல்படும் தருணங்களிலும் ஒளிந்துள்ளன.
தயாரிப்புச் சூழலில் உரை பெஞ்ச்மார்க்குகள் ஏன் தோல்வியடைகின்றன
தரப்படுத்தப்பட்ட பெஞ்ச்மார்க்குகளில் அதிக மதிப்பெண்கள் பெறுவது ஒரு தவறான ஆறுதலைத் தரும் விஷயமாகிவிட்டது. நேர்த்தியான உரை எழுதும் ஒரு ஏஜென்ட், செயல்பாட்டு ரீதியாக ஒரு ஆபத்தாக இருக்கலாம். உங்கள் அமைப்பு சந்திப்புகளை முன்பதிவு செய்யும்போதோ, தரவுத்தளப் பதிவுகளைத் திருத்தும்போதோ அல்லது ஆதரவு டிக்கெட்டுகளை (support tickets) தாக்கல் செய்யும்போதோ, உருவாக்கப்பட்ட உரை என்பது அந்தப் பணிப்பாய்வின் (workflow) கண்ணுக்குத் தெரியும் மேற்பரப்பு மட்டுமே. அதற்கு அடியில், எந்த endpoint-ஐ அணுக வேண்டும், என்ன payload-ஐ அனுப்ப வேண்டும் மற்றும் எப்போது நிறுத்த வேண்டும் என்பது குறித்த உறுதியான முடிவுகளை ஏஜென்ட் எடுக்கிறது. அது வாசிப்புப் புரிதல் (reading-comprehension) தரவரிசைப் பட்டியலில் முதலிடம் பிடிக்கலாம், ஆனால் வளங்களை இரட்டை முன்பதிவு செய்வதன் மூலமோ, தவறான வரிசையை (row) மாற்றுவதன் மூலமோ அல்லது ஒரு லாக் கோப்பில் (log file) உணர்திறன் மிக்க தரவுகளைக் கசிய விடுவதன் மூலமோ உங்களுக்குப் பண இழப்பை ஏற்படுத்தலாம். நீங்கள் வெளியீட்டின் மெருகூட்டலை மட்டும் பார்க்காமல், வேலையின் நுட்பங்களை (mechanics) சரிபார்க்க வேண்டும். ஒரு ஏஜென்ட் ஆஃப்லைன் QA சோதனையில் நல்ல மதிப்பெண்களைப் பெற்று, அதே சமயம் சுழற்சி முறையில் செயல்படுவதன் மூலமோ அல்லது ஒரு கருவியை தவறாகப் பயன்படுத்துவதன் மூலமோ உங்கள் பணிப்பாய்வில் தோல்வியடைந்தால், உங்கள் மதிப்பீடு தவறான சிக்னல்களைப் பார்க்கிறது என்று அர்த்தம்.
ஐந்து சார்புநிலைகளை (Dependencies) வரைபடமாக்குதல்
Van Data Team குழுவினர் ஒவ்வொரு மதிப்பீட்டையும் ஐந்து குறிப்பிட்ட கட்டுப்பாட்டுப் புள்ளிகளை வரைபடமாக்குவதன் மூலம் தொடங்குகிறார்கள். இது கேள்வியையே முற்றிலும் மாற்றுகிறது. ஒரு மாடல் மற்றொன்றை விட புத்திசாலித்தனமானதுதானா என்று கேட்பதை நீங்கள் நிறுத்திவிட்டு, உங்கள் உண்மையான கட்டுப்பாடுகளின் கீழ் ஒரு ஏஜென்ட் உண்மையில் ஒரு தயாரிப்புப் பணியை முடிக்க முடியுமா என்று கேட்கத் தொடங்குகிறீர்கள்.
வணிக முடிவுகள் (Business outcomes). "முடிந்தது" என்பதன் பொருள் என்ன என்பதை டாலர்கள் மற்றும் வாடிக்கையாளர் தாக்கத்தின் அடிப்படையில் வரையறுக்கவும். ஏஜென்ட் ஒரு சுருக்கத்தை (summary) வழங்கியதாலேயே ஒரு பணி முடிந்துவிடாது. சரக்கு இருப்புப் பதிவு (inventory record) துல்லியமாக இருக்கும்போதும், சந்திப்பு உறுதி செய்யப்படும்போதும், வாடிக்கையாளர் சரியான கண்காணிப்பு எண்ணைப் (tracking number) பெறும்போதும் மட்டுமே அது முழுமையடைகிறது.
மாற்றக்கூடிய நிலை (Mutable state). ஏஜென்ட் எதை மாற்ற அனுமதிக்கப்படுகிறது என்பதைத் துல்லியமாகத் தெரிந்து கொள்ளுங்கள். எந்த அட்டவணைகள் (tables), எந்த நிலைகள் (statuses), எந்தக் கணக்கு கொடிகள் (account flags)? ஏஜென்ட் ரீஃபண்ட் வழங்கவோ, வேலைகளை மறுசீரமைக்கவோ அல்லது பில்லிங் முகவரிகளைப் புதுப்பிக்கவோ முடியும் என்றால், அது தொடும் ஒவ்வொரு புலத்தையும் (field) நீங்கள் பட்டியலிட வேண்டும்.
கருவி அனுமதிகள் (Tool permissions). எந்த API endpoints மற்றும் செயல்பாடுகள் (functions) வரம்பிற்குள் உள்ளன என்பதைத் தெளிவாகக் குறிப்பிடவும். தேடல் கருவி (search tool), எழுதும் கருவி (write tool) மற்றும் அறிவிப்பு கருவி (notification tool) ஆகியவற்றிற்கான அணுகல் கொண்ட ஒரு ஏஜென்ட், எல்லைகள் தெளிவற்றதாக இருந்தால் அவற்றை ஒன்றுடன் ஒன்று கலந்துவிடும். ஒவ்வொரு அனுமதியையும் ஒரு குறிப்பிட்ட செயல்பாட்டுத் தேவைக்கு இணையாக வரைபடமாக்குங்கள்.
தோல்வி மீட்பு (Failure recovery). காலண்டர் API காலாவதியாகும்போதோ (timeout), 500 பிழையைத் தரும்போதோ அல்லது தவறான JSON-ஐத் தரும்போதோ என்ன நடக்கும் என்பதைத் தீர்மானிக்கவும். ஏஜென்ட் பீதியடையவோ, ஒரு வெற்றிகரமான செய்தியைத் தவறாகக் கற்பனை செய்யவோ (hallucinate) அல்லது முடிவில்லாமல் மீண்டும் முயற்சிக்கவோ (retry) கூடாது. அதற்கு ஒரு தெளிவான மாற்றுப் பாதை (fallback path) தேவை.
மனித மறுஆய்வு வாயில்கள் (Human review gates). ஏஜென்ட் தொடர்வதற்கு முன் ஒரு நபர் ஒப்புதல் அளிக்க வேண்டிய தருணங்களைக் கண்டறியவும். இது தானியங்கி முறையில் உள்ள பலவீனம் அல்ல. இது அதிக தாக்கத்தை ஏற்படுத்தும் மாற்றங்களுக்கான ஒரு பாதுகாப்பு வால்வு (safety valve) மற்றும் உங்கள் மதிப்பீட்டு அளவுகோல்களுக்கான (rubrics) உண்மைத் தரவு ஆதாரமாகும்.
ஒரு உண்மையான மதிப்பீட்டுத் திட்டம் எப்படி இருக்கும்
சார்புநிலைகளை வரைபடமாக்கிய பிறகு, தயாரிப்புச் சூழலின் சிக்கல்களுக்குப் பொருந்தக்கூடிய ஒரு மதிப்பீட்டுத் திட்டம் உங்களுக்குத் தேவை. ஸ்லைடு-டெக் அளவீடுகள் (Slide-deck metrics) உங்களுக்கு இங்கே உதவாது.
செயற்கையான கேள்வி வங்கிகளிலிருந்து அல்லாமல், உண்மையான தயாரிப்புத் தோல்விகளிலிருந்து சோதனைத் தொகுப்புகளை (test sets) உருவாக்குங்கள். உங்கள் ஏஜென்ட் கடந்த செவ்வாய்க்கிழமை இரண்டு ஒத்த SKU-க்களைக் குழப்பியதால் தோல்வியடைந்தால், அந்தத் துல்லியமான குழப்பமே ஒரு நிரந்தர சோதனை நிகழ்வாக (test case) இருக்க வேண்டும். ஒவ்வொரு முறை ஒரு சம்பவம் உங்களுக்குப் புதிய விஷயத்தைக் கற்பிக்கும் போதும் உங்கள் மதிப்பீட்டுத் தொகுப்பு வளர வேண்டும்.
செயல்பாட்டு ரீதியான சொற்களில் வெற்றிகரமான முடிவை வரையறுக்கும் விதிமுறைகளை (rubrics) எழுதுங்கள். "உதவியாக" அல்லது "துல்லியமாக" போன்ற தெளிவற்ற அளவுகோல்கள் பயனற்றவை. ஒரு பயனுள்ள விதிமுறை என்பது, ஒரு ரீஃபண்ட் பணி என்பது அசல் கட்டண ஐடி (payment ID) குறிப்பிடப்பட்டிருந்தால், தொகை கோரிக்கையுடன் பொருந்தினால், உறுதிப்படுத்தல் மின்னஞ்சல் வரிசையில் வைக்கப்பட்டிருந்தால் மற்றும் பரிவர்த்தனை ஐடி (transaction ID) பதிவு செய்யப்பட்டிருந்தால் மட்டுமே வெற்றிகரமானது என்று கூற வேண்டும்.
கருவி அழைப்புகள் (tool calls) மற்றும் மறுமுயற்சிகளுக்கான (retries) தடய விவரக்குறிப்புகளை (trace specs) வரையறுக்கவும். ஏஜென்ட் என்ன திட்டமிட்டது, உண்மையில் எதை அழைத்தது, எத்தனை முறை மறுமுயற்சி செய்தது மற்றும் மறுமுயற்சி உத்தி பொருத்தமானதா என்பது குறித்த கண்காணிப்புத் திறன் (observability) உங்களுக்குத் தேவை. கருவி அளவிலான நுணுக்கங்கள் இல்லாத ஒரு தடயம் (trace) வெறும் அழகான கதை மட்டுமே.
எப்போது ஒரு மனிதருக்குத் தகவல் தெரிவிக்க வேண்டும் என்பதற்கான கொள்கைகளை (policies) அமைக்கவும். ஏஜென்ட் தனது சொந்த எல்லைகளைத் தெரிந்து கொள்ள வேண்டும். ஒரு கோரிக்கை ஒரு குறிப்பிட்ட டாலர் வரம்பைத் தாண்டினால், ஒரு VIP கணக்கைக் குறிப்பிட்டால் அல்லது அது இதற்கு முன் பார்த்திராத ஒரு நிலையைச் சந்தித்தால், அது யூகிக்காமல் அந்த விஷயத்தை மேல்நடவடிக்கைக்குக் கொண்டு செல்ல வேண்டும் (escalate).
Install release gates to block bad model upgrades. A new model is only an upgrade if it improves your specific outcomes. If it hallucinates tool arguments more often, increases latency, or introduces new safety risks, it does not ship. The gate keeps production stable even when the base model vendor ships a new version.
Runtime Grading: Watching the Agent Work
Anthropic has been pushing the industry to move beyond offline tests toward runtime grading. Instead of judging a transcript after the fact, runtime grading lets a system judge the agent's work while the task is still in flight. This creates a chance to catch errors before they harden into real problems.
Adding a grader costs tokens and latency. You cannot afford to grade every tiny step. The placement of each grader is a design decision. Put them where the mistakes are expensive. The most valuable checkpoints sit just before committing a state change to a database, just before capturing a payment, and just before sending a message to a customer. These are the moments where a bad decision becomes an irreversible action.
Watch out for a specific blind spot. If the same model performs the work and also grades the work, it may miss the same mistakes. The reasoning that produced an error can easily rationalize that error away during review. For high-impact tasks, keep human review inside the loop. Let people validate the grader's own judgment, especially when money or customer trust is on the line.
The goal here is operational control. Connect your incident data, your task rubrics, and your runtime traces into one feedback cycle. Evaluate the whole path: the plan, the tool use, the recovery behavior, and the final result. Use offline tests to catch known, reproducible errors before release. Use runtime traces to find the new failures you did not anticipate. Use human review to discover where your rubrics are naive and need tightening.
So ask yourself: where would you put a runtime grader in your workflow? Before a tool call, after a tool call, or only before a risky change? Most teams start too broad, grading everything, and then grind to a halt under the cost. Start narrow. Pick the one action that would hurt the most if it went wrong. Put a grader there first.
Start With One Expensive Mistake
Operational evaluation is not a research exercise. It is a way to sleep better once the agent is live. You do not need a perfect framework on day one. You need a single, well-defined workflow, a rubric written in plain business terms, and a grader placed at the exact moment where an error becomes expensive. Get that right, and you have a foundation you can actually trust.
If you want to dig deeper into agent evaluation and runtime grading with a community of practitioners, you can find the GyaanSetu learning community at https://t.me/GyaanSetuAi.