அனைவரும் ப்ராம்ப்ட் (prompt) பற்றியே தீவிரமாகச் சிந்திக்கிறார்கள். அவர்கள் வரவேற்புச் செய்தியைச் செம்மைப்படுத்துகிறார்கள், தொனியை மாற்றியமைக்கிறார்கள், மற்றும் மாடல் போதுமான அளவு இதமாக இருக்கிறதா என்று கவலைப்படுகிறார்கள். அது ஒரு கவனச்சிதறல் மட்டுமே. ஒரு AI ஏஜென்ட் உண்மையான பயனர்களுக்கு உண்மையான மின்னஞ்சல்களை அனுப்பத் தொடங்கும் போது, ஆபத்து என்பது அது "Best regards" என்பதற்குப் பதிலாக "Cheers" என்று எழுதுவதில் இல்லை. ஆபத்து என்னவென்றால், ஏஜென்ட்டின் முடிவிற்கும், செய்தி பயனரின் இன்பாக்ஸை அடைவதற்கும் இடையில் என்ன நடந்தது என்பதை உங்களால் உறுதியாகச் சொல்ல முடியாது என்பதில் தான் உள்ளது. நான் முதலில் எல்லையை (boundary) பார்க்கிறேன். உற்பத்தி அமைப்புகள் (production systems) அமைதியாகத் தோல்வியடைவது அங்கேயே தான்.
ஒப்பந்தமே பலவீனமான புள்ளி
AI டெமோக்கள் மன்னிக்கக்கூடியவை. ஒரு பிரவுசர் விண்டோவில் நடக்கும் சுமூகமான உரையாடல், பல அனுமானங்களின் குழப்பத்தை மறைத்துவிடுகிறது. உற்பத்தி நிலையில் (production), உண்மையான பாதிப்பு மூன்று விஷயங்களுக்கு இடையிலான ஒப்பந்தத்தில் (contract) உள்ளது: ஏஜென்ட்டின் முடிவு, செயலைச் செயல்படுத்தும் கருவி (tool), மற்றும் முடிவைச் சரிபார்க்கும் படி (step). அந்த எல்லை மங்கலாக இருந்தால், அமைப்பு மிகச் சிறப்பாகச் செயல்படும், ஆனால் அது எப்போது வேண்டுமானாலும் செயலிழக்கலாம். அப்போது அது அமைதியாகத் தோல்வியடையும், ஒரு வாடிக்கையாளர் பிரிவினருக்குத் திரும்பத் திரும்பத் தவறான செய்திகளை அனுப்பும், அல்லது ஏன் என்று தெரியாமல் தவறான நேரத்தில் செய்திகளை அனுப்பும். ப்ராம்ப்ட் கவிதையைப் போல இருக்கலாம். ஆனால் அதன் அடியில் உள்ள கட்டமைப்பு (architecture) இன்னும் நூலால் கட்டப்பட்டிருக்கலாம்.
ஏஜென்ட்டை சுதந்திரமாக எழுத அனுமதிக்காதீர்கள்
மிகவும் பொதுவான தவறு ஏஜென்ட்டுக்கு ஒரு வெற்றுப் பக்கத்தைக் கொடுப்பதாகும். குழுக்கள் ஏஜென்ட்டை ஒரு மின்னஞ்சலை வெறும் உரையாக (raw text) விவரிக்கச் செய்கின்றன, பின்னர் அந்த உரையிலிருந்து நோக்கத்தைப் (intent) புரிந்துகொள்ள அடுத்தடுத்த கருவிகளை நம்பியிருக்கிறார்கள். இது மிகவும் பலவீனமானது. ஒரு LLM ஒரு நியாயமான நோக்கத்தைப் பரிந்துரைக்கலாம், ஆனால் உங்கள் உள்கட்டமைப்பிற்கு (infrastructure) படைப்பாற்றல் தேவையில்லை. அதற்கு ஒரு ஒப்பந்தம் தேவை. இயந்திரத்தால் குழப்பமின்றிச் சரிபார்க்கக்கூடிய குறிப்பிட்ட புலங்கள் (fields) தேவை.
ஒரு ஏஜென்ட் மின்னஞ்சல் கோரிக்கையை வெளியிடும் போது, அந்த வெளியீடு (output) குழாயமைப்புக்கு (plumbing) தேவையானவற்றைத் துல்லியமாகத் தாங்கியிருக்க வேண்டும்:
- Template version: மின்னஞ்சல் உடலின் எந்தப் பதிப்பு பயன்படுத்தப்படுகிறது என்பதைத் தெரிந்துகொள்ள இது உதவும், இதன் மூலம் பயனர் எதைப் பார்த்தார் என்பதை நீங்கள் அறியலாம்.
- Recipient scope: இதை யார் பெறுகிறார்கள் என்பது பயனர் ஐடிகள் (user IDs) அல்லது பிரிவு விதிகளால் (segment rules) வரையறுக்கப்பட வேண்டும்; "சமீபத்தில் பதிவு செய்த பயனர்" போன்ற இயற்கை மொழியால் அல்ல.
- Trace ID: ஏஜென்ட் முதல் உங்கள் இயக்கி (executor), மின்னஞ்சல் வழங்குநர் மற்றும் உங்கள் பதிவுகள் (logs) வரை இந்த கோரிக்கையைத் தொடரும் ஒரு தனித்துவமான அடையாளங்காட்டி.
- Time window: இந்த மின்னஞ்சல் எப்போது செல்லுபடியாகும் என்பதைக் குறிக்கும், இதனால் பழைய ஏஜென்ட் முடிவுகள் பல மணிநேரங்களுக்குப் பிறகு நள்ளிரவில் மின்னஞ்சல்களை அனுப்பத் தூண்டப்படாது.
- Idempotency: ஏஜென்ட் மீண்டும் முயற்சி செய்தாலோ அல்லது நெட்வொர்க் கோளாறு ஏற்பட்டாலோ, ஒரே செயல் மீண்டும் மீண்டும் நடப்பதைத் தடுக்கும் ஒரு சாவி (key).
வெறும் உரை (Raw text) என்பது ஒரு மோசமான API ஆகும். அது அவசரம், பார்வையாளர்கள் மற்றும் செயல்பாடு குறித்த தெளிவற்ற நிலையை உருவாக்குகிறது. குறிப்பிட்ட புலங்கள் இயந்திரம் வாசிக்கக்கூடியவை (machine-readable), தணிக்கை செய்யக்கூடியவை (auditable) மற்றும் சோதனை செய்யக்கூடியவை (testable). அவை ஒரு தெளிவற்ற கட்டளையைச் சரிபார்க்கக்கூடிய கட்டளையாக மாற்றுகின்றன.
உரை அல்ல, செயல்கள்
ஏஜென்ட்டுக்கு ஒரு திறந்தநிலை எழுதும் பணியைக் கொடுப்பதற்குப் பதிலாக, அனுமதிக்கப்பட்ட செயல்களின் பட்டியலுக்கு (menu of allowed actions) அதை மட்டுப்படுத்தவும். இதை ஒரு நிலையான enum கொண்ட உள் API போலக் கருதவும். ஏஜென்ட் ஒரு தலைப்பை (subject line) உருவாக்கவோ அல்லது வாழ்த்துச் சொற்களைப் பற்றி யோசிக்கவோ தேவையில்லை. அது send_review_request அல்லது send_retry_notice போன்ற ஒரு செயலைத் தேர்ந்தெடுக்கிறது. அதுதான் அதன் படைப்பாற்றல் சுதந்திரத்தின் எல்லை.
ஒரு தீர்மானிக்கத்தக்க இயக்கி (deterministic executor) அந்தச் செயலை எடுத்துக்கொண்டு, பதிப்புக் கட்டுப்பாட்டிலிருந்து (version control) சரியான டெம்ப்ளேட்டைப் பெற்று, சுத்திகரிக்கப்பட்ட தரவுகளுடன் (sanitized data) அதை நிரப்பி, சரிபார்க்கப்பட்ட மூலத்திலிருந்து பெறுநரின் பட்டியலைப் பூர்த்தி செய்து, இறுதி கட்டளையை உருவாக்குகிறது. என்ன நடக்க வேண்டும் என்பதை ஏஜென்ட் தீர்மானிக்கிறது. அது எப்படி நடக்க வேண்டும் என்பதைச் சலிப்பான, கணிக்கக்கூடிய குறியீடு (predictable code) தீர்மானிக்கிறது.
இந்தத் தனிமைப்படுத்தல் (separation) அமைப்பைச் சோதனை செய்ய எளிதாக்குகிறது. ஒரு LLM அனுமானத்தை (inference) இயக்காமலேயே, ஒரு குறிப்பிட்ட உள்ளீடு send_retry_notice-ஐ நம்பகமான முறையில் தூண்டுகிறதா என்பதை நீங்கள் சரிபார்க்க முடியும். உங்கள் யூனிட் டெஸ்ட்கள் (unit tests) வேகமாகவும் தீர்மானிக்கத்தக்கதாகவும் மாறும், ஏனெனில் அவை மாடலின் வெப்பநிலையை (model temperature) சோதிப்பதில்லை, மாறாக மேப்பிங் லாஜிக்கை (mapping logic) சோதிக்கின்றன. உங்கள் ஒருங்கிணைப்புச் சோதனைகள் (integration tests), மாடல் ஒரு நல்ல நாளில் இருந்ததா என்பதைச் சோதிப்பதில்லை, மாறாக இயக்கி அந்தச் செயலை மின்னஞ்சல் சேவைக்குச் சரியாக மேப் செய்கிறதா என்பதில் கவனம் செலுத்துகின்றன.
ஐந்து அடுக்குகளாக உருவாக்குங்கள்
ஒரு வலுவான அமைப்பு ஒரே ப்ராம்ப்ட்டிலிருந்து உருவாவதில்லை. அது அடுக்குகளாகக் கட்டமைக்கப்படுகிறது, மேலும் ஒவ்வொரு அடுக்கும் ஒரு தெளிவான பொறுப்பைக் கொண்டுள்ளது.
1. பேக்எண்ட் (backend) நிகழ்வை பாதுகாப்பான தரவாகக் குறைக்கிறது.
தூண்டுதல் (trigger) ஒரு வெப்ஹூக் (webhook), தரவுத்தள மாற்றம் அல்லது ஒரு திட்டமிடப்பட்ட வேலையாக இருந்தாலும், இந்த அடுக்கு உள்ளீடுகளைச் சுத்திகரிக்கிறது, எதிர்பாராத புலங்களை நீக்குகிறது மற்றும் ஏஜென்ட்டுக்குத் தேவையானதை மட்டும் வழங்குகிறது. ஒரு வெப்ஹூக் பேலோடில் (payload) இருபது புலங்கள் இருந்து, ஏஜென்ட்டுக்கு இரண்டு மட்டும் தேவைப்பட்டால், அந்த இரண்டை மட்டும் அனுப்பவும். எந்தவொரு மூல பயனர் உரையும் (raw user text) சரிபார்க்கப்படாமல் முடிவு அடுக்கை (decision layer) அடையக்கூடாது.
2. ஏஜென்ட் நிலையான ஸ்கீமாவிலிருந்து (fixed schema) ஒரு செயலைத் தேர்ந்தெடுக்கிறது.
அது சூழலைப் பார்த்து, ஒரு முடிவை எடுத்து, தேவையான மெட்டாடேட்டாவுடன் (metadata) முன் தீர்மானிக்கப்பட்ட செயல் விசைகளில் (action keys) ஒன்றைத் வெளியிடுகிறது. அது உரையை எழுதாது. அது பெறுநர்களைக் கணிக்காது. அடுத்த அடுக்கால் JSON ஸ்கீமாவுக்கு எதிராகச் சரிபார்க்கக்கூடிய ஒரு கட்டமைக்கப்பட்ட பேலோடை (structured payload) அது வழங்குகிறது.
3. The tool validates permissions and required fields.
Does this agent context have the right to trigger send_review_request for this user? Is the recipient scope non-empty and within allowed limits? Is the idempotency key present and unique in your log? Is the trace ID well-formed? Fail here, loudly, before any email service is ever touched.
4. The email service logs the send with a trace ID.
Every message that leaves your system should carry that trace identifier through the provider's API and into your observability stack. If a user complains they received two copies, you should be able to query one ID and see exactly where the duplication originated: a retried agent call, a flaky executor, or a misbehaving callback.
5. The end-to-end test checks the actual inbox for content and effect.
Open the rendered message in a real mailbox. Is the subject line populated correctly? Does the unsubscribe link resolve? Does clicking the primary call-to-action button land on the correct page with the correct user state? A passing unit test means the code ran. Only an inbox test tells you the email actually works for a human.
Evidence Over Guessing
When a test fails in this pipeline, you need four specific pieces of evidence. Accept nothing less.
- The original decision from the agent. What action did it choose, and what was the full input context?
- The normalized command from the tool. What did the deterministic executor build after applying the template, hydration logic, and validation rules?
- The message in the isolated inbox. Not a log of what you think you sent, but the real MIME message, headers and all, captured in a dedicated test mailbox.
- The final effect after clicking the link. The resulting page state, database change, or external event that proves the email achieved its purpose.
If one piece is missing, your team will fill the gap with assumptions. They will guess. Guessing in automation is expensive. It burns hours, erodes trust, and turns every incident into a forensic mystery instead of a