ਹਰ ਕੋਈ ਪ੍ਰੋਂਪਟ ਦੇ ਪਿੱਛੇ ਪਾਗਲ ਹੈ। ਉਹ ਸਵਾਗਤ (greeting) ਨੂੰ ਬਰੀਕੀ ਨਾਲ ਸੈੱਟ ਕਰਦੇ ਹਨ, ਲਹਿਜੇ ਨੂੰ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਚਿੰਤਾ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਮਾਡਲ ਕਾਫ਼ੀ ਨਿੱਘਾ ਲੱਗ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਹ ਸਭ ਇੱਕ ਭਟਕਾਅ ਹੈ। ਜਦੋਂ ਇੱਕ AI ਏਜੰਟ ਅਸਲ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਅਸਲ ਈਮੇਲਾਂ ਭੇਜਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਖ਼ਤਰਾ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਉਹ "Cheers" ਦੀ ਬਜਾਏ "Best regards" ਲਿਖਦਾ ਹੈ। ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਯਕੀਨ ਨਾਲ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਏਜੰਟ ਦੇ ਫੈਸਲੇ ਅਤੇ ਇਨਬਾਕਸ ਵਿੱਚ ਮੈਸੇਜ ਪਹੁੰਚਣ ਦੇ ਵਿਚਕਾਰ ਕੀ ਹੋਇਆ। ਮੈਂ ਪਹਿਲਾਂ ਸੀਮਾ (boundary) ਵੱਲ ਦੇਖਦਾ ਹਾਂ। ਉੱਥੇ ਹੀ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੇ ਹਨ।
ਕੰਟਰੈਕਟ ਹੀ ਕਮਜ਼ੋਰ ਬਿੰਦੂ ਹੈ
AI ਡੈਮੋ ਮਾਫ਼ ਕਰ ਦਿੰਦੇ ਹਨ। ਬ੍ਰਾਊਜ਼ਰ ਵਿੰਡੋ ਵਿੱਚ ਇੱਕ ਸੁਚਾਰੂ ਗੱਲਬਾਤ ਕਈ ਅੰਦਾਜ਼ਿਆਂ ਦੇ ਗੁੰਝਲਦਾਰ ਜਾਲ ਨੂੰ ਲੁਕਾ ਲੈਂਦੀ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ, ਅਸਲ ਕਮਜ਼ੋਰੀ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦੇ ਵਿਚਕਾਰਲੇ ਕੰਟਰੈਕਟ ਵਿੱਚ ਹੁੰਦੀ ਹੈ: ਏਜੰਟ ਦਾ ਫੈਸਲਾ, ਉਹ ਟੂਲ ਜੋ ਐਕਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਕਦਮ ਜੋ ਨਤੀਜੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਉਹ ਸੀਮਾ ਅਸਪਸ਼ਟ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਉਦੋਂ ਤੱਕ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਉਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਫਿਰ ਇਹ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ, ਪੂਰੇ ਗਾਹਕ ਸੈਗਮੈਂਟ ਨੂੰ ਡੁਪਲੀਕੇਟ ਮੈਸੇਜ ਭੇਜ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਬਿਨਾਂ ਕਿਸੇ ਸਪਸ਼ਟ ਰਿਕਾਰਡ ਦੇ ਗਲਤ ਸਮੇਂ 'ਤੇ ਮੈਸੇਜ ਭੇਜ ਦਿੰਦਾ ਹੈ। ਪ੍ਰੋਂਪਟ ਸ਼ਾਇਦ ਕਵਿਤਾ ਵਾਂਗ ਲੱਗੇ, ਪਰ ਉਸਦੇ ਹੇਠਾਂ ਦਾ ਆਰਕੀਟੈਕਚਰ ਅਜੇ ਵੀ ਰੱਸੀਆਂ ਨਾਲ ਬੰਨ੍ਹਿਆ ਹੋਇਆ ਹੋ ਸਕਦਾ ਹੈ।
ਏਜੰਟ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਾ ਬੰਦ ਕਰੋ
ਸਭ ਤੋਂ ਆਮ ਗਲਤੀ ਏਜੰਟ ਨੂੰ ਇੱਕ ਖਾਲੀ ਪੰਨਾ ਦੇਣਾ ਹੈ। ਟੀਮਾਂ ਇਸਨੂੰ ਕੱਚੇ ਟੈਕਸਟ ਵਿੱਚ ਈਮੇਲ ਦਾ ਵਰਣਨ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਫਿਰ ਇੱਕ ਡਾਊਨਸਟ੍ਰੀਮ ਟੂਲ 'ਤੇ ਭਰੋਸਾ ਕਰਦੀਆਂ ਹਨ ਕਿ ਉਹ ਉਸ ਲਿਖਤ ਵਿੱਚੋਂ ਇਰਾਦੇ (intent) ਨੂੰ ਸਮਝ ਲਵੇਗਾ। ਇਹ ਬਹੁਤ ਕਮਜ਼ੋਰ ਤਰੀਕਾ ਹੈ। ਇੱਕ LLM ਇੱਕ ਵਾਜਬ ਇਰਾਦਾ ਸੁਝਾ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਡੇ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਨੂੰ ਰਚਨਾਤਮਕਤਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਕੰਟਰੈਕਟ ਦੀ ਲੋੜ ਹੈ। ਇਸਨੂੰ ਖਾਸ ਫੀਲਡਾਂ ਦੀ ਲੋੜ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਮਸ਼ੀਨ ਬਿਨਾਂ ਕਿਸੇ ਅਸਪਸ਼ਟਤਾ ਦੇ ਵੈਰੀਫਾਈ ਕਰ ਸਕੇ।
ਜਦੋਂ ਇੱਕ ਏਜੰਟ ਈਮੇਲ ਦੀ ਬੇਨਤੀ ਜਾਰੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਆਉਟਪੁੱਟ ਵਿੱਚ ਉਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਪਲੰਬਿੰਗ (plumbing) ਨੂੰ ਲੋੜ ਹੈ:
- Template version: ਈਮੇਲ ਬਾਡੀ ਦਾ ਕਿਹੜਾ ਵਰਜ਼ਨ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਉਪਭੋਗਤਾ ਨੇ ਕੀ ਦੇਖਿਆ।
- Recipient scope: ਇਹ ਕਿਸ ਨੂੰ ਮਿਲੇਗਾ, ਜੋ ਯੂਜ਼ਰ ਆਈਡੀ (user IDs) ਜਾਂ ਸੈਗਮੈਂਟ ਨਿਯਮਾਂ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਹੋਵੇ, ਨਾ ਕਿ "ਉਹ ਉਪਭੋਗਤਾ ਜਿਸਨੇ ਹੁਣੇ ਸਾਈਨ ਅੱਪ ਕੀਤਾ ਹੈ" ਵਰਗੀ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਦੁਆਰਾ।
- Trace ID: ਇੱਕ ਵਿਲੱਖਣ ਪਛਾਣਕਰਤਾ ਜੋ ਇਸ ਬੇਨਤੀ ਨੂੰ ਏਜੰਟ ਤੋਂ ਲੈ ਕੇ ਤੁਹਾਡੇ ਐਗਜ਼ੀਕਿਊਟਰ, ਈਮੇਲ ਪ੍ਰਦਾਤਾ, ਅਤੇ ਤੁਹਾਡੇ ਲੌਗਸ ਤੱਕ ਫੋਲੋ ਕਰਦਾ ਹੈ।
- Time window: ਇਹ ਭੇਜਣਾ ਕਦੋਂ ਵੈਧ ਹੈ, ਤਾਂ ਜੋ ਪੁਰਾਣੇ ਏਜੰਟ ਫੈਸਲੇ ਘੰਟਿਆਂ ਬਾਅਦ ਅੱਧੀ ਰਾਤ ਨੂੰ ਈਮੇਲਾਂ ਭੇਜਣ ਲਈ ਟ੍ਰਿਗਰ ਨਾ ਹੋ ਜਾਣ।
- Idempotency: ਇੱਕ ਅਜਿਹੀ ਕੀ (key) ਜੋ ਇੱਕੋ ਹੀ ਲੌਜੀਕਲ ਭੇਜਣ ਨੂੰ ਦੋ ਵਾਰ ਹੋਣ ਤੋਂ ਰੋਕਦੀ ਹੈ ਜੇਕਰ ਏਜੰਟ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜਾਂ ਨੈੱਟਵਰਕ ਵਿੱਚ ਕੋਈ ਖਰਾਬੀ ਆਉਂਦੀ ਹੈ।
ਕੱਚਾ ਟੈਕਸਟ ਇੱਕ ਬਹੁਤ ਹੀ ਮਾੜਾ API ਹੈ। ਇਹ ਜ਼ਰੂਰੀਤਾ, ਸਰੋਤ (audience), ਅਤੇ ਕਾਰਵਾਈ ਬਾਰੇ ਅਸਪਸ਼ਟਤਾ ਲਈ ਜਗ੍ਹਾ ਛੱਡਦਾ ਹੈ। ਖਾਸ ਫੀਲਡਾਂ ਮਸ਼ੀਨ-ਪੜ੍ਹਨਯੋਗ, ਆਡਿਟ ਕਰਨ ਯੋਗ, ਅਤੇ ਟੈਸਟ ਕਰਨ ਯੋਗ ਹੁੰਦੀਆਂ ਹਨ। ਉਹ ਇੱਕ ਅਸਪਸ਼ਟ ਹਦਾਇਤ ਨੂੰ ਇੱਕ ਵੈਰੀਫਾਈ ਕਰਨ ਯੋਗ ਕਮਾਂਡ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।
ਗਦ (Prose) ਨਹੀਂ, ਐਕਸ਼ਨਜ਼
ਏਜੰਟ ਨੂੰ ਇੱਕ ਖੁੱਲ੍ਹੀ ਲਿਖਣ ਦੀ ਟਾਸਕ ਦੇਣ ਦੀ ਬਜਾਏ, ਇਸਨੂੰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਐਕਸ਼ਨਜ਼ ਦੇ ਮੀਨੂ ਤੱਕ ਸੀਮਤ ਰੱਖੋ। ਇਸਨੂੰ ਇੱਕ ਫਿਕਸਡ enum ਵਾਲੇ ਅੰਦਰੂਨੀ API ਵਾਂਗ ਸਮਝੋ। ਏਜੰਟ ਵਿਸ਼ਾ ਲਾਈਨ (subject line) ਨਹੀਂ ਲਿਖਦਾ ਜਾਂ ਸਵਾਗਤ ਦੇ ਸ਼ਬਦਾਂ ਬਾਰੇ ਨਹੀਂ ਸੋਚਦਾ। ਇਹ send_review_request ਜਾਂ send_retry_notice ਵਰਗਾ ਇੱਕ ਐਕਸ਼ਨ ਚੁਣਦਾ ਹੈ। ਉਸਦੀ ਰਚਨਾਤਮਕ ਆਜ਼ਾਦੀ ਇੱਥੇ ਹੀ ਖਤਮ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਡਿਟਰਮਨਿਸਟਿਕ (deterministic) ਐਗਜ਼ੀਕਿਊਟਰ ਫਿਰ ਉਸ ਐਕਸ਼ਨ ਕੀ ਨੂੰ ਲੈਂਦਾ ਹੈ, ਵਰਜ਼ਨ ਕੰਟਰੋਲ ਤੋਂ ਸਹੀ ਟੈਂਪਲੇਟ ਕੱਢਦਾ ਹੈ, ਇਸਨੂੰ ਸਾਫ਼ ਕੀਤੇ ਹੋਏ (sanitized) ਡੇਟਾ ਨਾਲ ਭਰਦਾ ਹੈ, ਵੈਰੀਫਾਈ ਕੀਤੇ ਸਰੋਤ ਤੋਂ ਪ੍ਰਾਪਤਕਰਤਾ ਸੂਚੀ ਭਰਦਾ ਹੈ, ਅਤੇ ਅੰਤਿਮ ਕਮਾਂਡ ਬਣਾਉਂਦਾ ਹੈ। ਏਜੰਟ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਬੋਰਿੰਗ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਕੋਡ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਹ ਵੱਖਰੇਕਰਨ ਸਿਸਟਮ ਨੂੰ ਟੈਸਟ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ ਦਿੱਤੀ ਗਈ ਇਨਪੁਟ ਸਟੇਟ ਬਿਨਾਂ ਕਿਸੇ LLM ਇਨਫਰੈਂਸ (inference) ਦੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ send_retry_notice ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੀ ਹੈ। ਤੁਹਾਡੇ ਯੂਨਿਟ ਟੈਸਟ (unit tests) ਤੇਜ਼ ਅਤੇ ਨਿਸ਼ਚਿਤ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਮਾਡਲ ਟੈਂਪਰੇਚਰ (model temperature) ਦੀ ਬਜਾਏ ਮੈਪਿੰਗ ਲੌਜਿਕ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ। ਤੁਹਾਡੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ (integration tests) ਇਸ ਗੱਲ 'ਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦੇ ਹਨ ਕਿ ਕੀ ਐਗਜ਼ੀਕਿਊਟਰ ਐਕਸ਼ਨ ਨੂੰ ਈਮੇਲ ਸੇਵਾ ਨਾਲ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਮੈਪ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਇਸ 'ਤੇ ਕਿ ਮਾਡਲ ਦਾ ਦਿਨ ਕਿਹੋ ਜਿਹਾ ਸੀ।
ਪੰਜ ਪਰਤਾਂ ਵਿੱਚ ਬਣਾਓ
ਇੱਕ ਮਜ਼ਬੂਤ ਸਿਸਟਮ ਇੱਕ ਸਿੰਗਲ ਪ੍ਰੋਂਪਟ ਤੋਂ ਨਹੀਂ ਉੱਭਰਦਾ। ਇਹ ਪਰਤਾਂ ਵਿੱਚ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹਰੇਕ ਪਰਤ ਦੀ ਇੱਕ ਸਿੰਗਲ, ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦੀ ਹੈ।
1. ਬੈਕਐਂਡ ਘਟਨਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਡੇਟਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਭਾਵੇਂ ਟ੍ਰਿਗਰ ਇੱਕ ਵੈੱਬਹੂਕ (webhook) ਹੋਵੇ, ਡੇਟਾਬੇਸ ਵਿੱਚ ਬਦਲਾਅ ਹੋਵੇ, ਜਾਂ ਇੱਕ ਸ਼ਡਿਊਲਡ ਜੌਬ ਹੋਵੇ, ਇਹ ਪਰਤ ਇਨਪੁੱਟਸ ਨੂੰ ਸਾਫ਼ ਕਰਦੀ ਹੈ, ਅਣਚਾਹੇ ਫੀਲਡਾਂ ਨੂੰ ਹਟਾਉਂਦੀ ਹੈ, ਅਤੇ ਏਜੰਟ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਦਿੰਦੀ ਹੈ ਜਿਸਦੀ ਉਸਨੂੰ ਲੋੜ ਹੈ। ਜੇਕਰ ਇੱਕ ਵੈੱਬਹੂਕ ਪੇਲੋਡ ਵਿੱਚ ਵੀਹ ਫੀਲਡ ਹਨ ਪਰ ਏਜੰਟ ਨੂੰ ਸਿਰਫ਼ ਦੋ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਦੋ ਹੀ ਭੇਜੋ। ਕੋਈ ਵੀ ਕੱਚਾ ਯੂਜ਼ਰ ਟੈਕਸਟ ਬਿਨਾਂ ਜਾਂਚ ਕੀਤੇ ਡਿਸੀਜ਼ਨ ਲੇਅਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ।
2. ਏਜੰਟ ਨਿਰਧਾਰਤ ਸਕੀਮਾ ਵਿੱਚੋਂ ਇੱਕ ਐਕਸ਼ਨ ਚੁਣਦਾ ਹੈ।
ਇਹ ਸੰਦਰਭ (context) ਨੂੰ ਦੇਖਦਾ ਹੈ, ਫੈਸਲਾ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਲੋੜੀਂਦੇ ਮੈਟਾਡਾਟਾ ਦੇ ਨਾਲ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਐਕਸ਼ਨ ਕੀਜ਼ ਵਿੱਚੋਂ ਇੱਕ ਆਉਟਪੁੱਟ ਕਰਦਾ ਹੈ। ਇਹ ਗਦ (prose) ਨਹੀਂ ਲਿਖਦਾ। ਇਹ ਪ੍ਰਾਪਤਕਰਤਾਵਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾਉਂਦਾ। ਇਹ ਇੱਕ ਸਟ੍ਰਕਚਰਡ ਪੇਲੋਡ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਅਗਲੀ ਪਰਤ JSON ਸਕੀਮਾ ਦੇ ਵਿਰੁੱਧ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੀ ਹੈ।
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