ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਲਾਰਜ ਲੈਂਗੂਏਜ ਮਾਡਲ (LLM) ਨੂੰ ਅਜਿਹੇ ਵਰਕਫਲੋ ਵਿੱਚ ਜੋੜਦੇ ਹੋ ਜਿਸ ਲਈ ਇਮੇਲ ਰਾਹੀਂ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਅਕਸਰ ਮਾਡਲ ਕਾਰਨ ਸਮੱਸਿਆ ਨਹੀਂ ਆਉਂਦੀ। ਖਰਾਬੀ ਉੱਥੇ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਕੋਡ ਖਤਮ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਨਬਾਕਸ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਆਟੋਨੋਮਸ ਰਨ (autonomous run) ਇੱਕ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ। ਫਿਰ ਪਹਿਲੀ ਬੇਨਤੀ ਦੇ ਪੂਰਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਦੂਜੀ ਰਨ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਸਾਂਝਾ ਇਨਬਾਕਸ ਵੱਖ-ਵੱਖ ਪ੍ਰਕਿਰਿਆਵਾਂ ਤੋਂ ਥ੍ਰੈਡ ਇਕੱਠੇ ਕਰਦਾ ਹੈ। ਕੋਈ ਵਿਅਕਤੀ ਅਜਿਹੇ ਸੁਨੇਹੇ 'ਤੇ ਮਨਜ਼ੂਰੀ (approve) ਕਲਿੱਕ ਕਰ ਦਿੰਦਾ ਹੈ ਜੋ ਬਾਰਾਂ ਘੰਟੇ ਦੇਰੀ ਨਾਲ ਆਇਆ ਸੀ। ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਆਉਟਪੁੱਟ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਫੈਸਲਾ ਹੈ। ਪਰ ਤੁਸੀਂ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਕਿਸ ਰਨ ਨੇ ਕੀ ਪੈਦਾ ਕੀਤਾ, ਜਾਂ ਕੀ ਪ੍ਰਵਾਨਗੀ ਇਸੇ ਜਨਰੇਸ਼ਨ ਲਈ ਸੀ ਵੀ ਜਾਂ ਨਹੀਂ। ਮੈਂ ਇੰਨੀ ਅੰਦਰੂਨੀ ਆਟੋਮੇਸ਼ਨ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਸੁਧਾਰਿਆ ਹੈ ਕਿ ਮੈਂ ਇਸ ਪੈਟਰਨ ਨੂੰ ਜਾਣਦਾ ਹਾਂ। ਇਹ ਉਲਝਣ ਤੋਂ ਘਟਨਾ (incident) ਵਿੱਚ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਜਿੰਨੀ ਤੇਜ਼ੀ ਦੀ ਉਮੀਦ ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਕਰਦੀਆਂ ਹਨ।

ਕਾਰਜਸ਼ੀਲ ਸੀਮਾ (The Operational Boundary)

ਤੁਹਾਡੇ ਆਰਕੈਸਟ੍ਰੇਟਰ (orchestrator) ਅਤੇ ਤੁਹਾਡੇ ਈਮੇਲ ਪ੍ਰੋਵਾਈਡਰ ਵਿਚਕਾਰ ਦੀ ਸੀਮਾ ਸਿਰਫ਼ ਇੱਕ ਨੈੱਟਵਰਕ ਹੌਪ (network hop) ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਸਟੇਟ ਸੀਮਾ (state boundary) ਹੈ। ਜਦੋਂ LLM ਡਰਾਫਟ ਤਿਆਰ ਕਰਨਾ ਖਤਮ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਰਨ ਅਜੇ ਵੀ ਜਿਉਂਦਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਸਿਸਟਮ ਭੇਜਣ ਨੂੰ ਇੱਕ "ਫਾਇਰ-ਐਂਡ-ਫਾਰਗੇਟ" (fire-and-forget) ਘਟਨਾ ਵਜੋਂ ਮੰਨਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੰਟਰੋਲ ਗੁਆ ਚੁੱਕੇ ਹੋ।

ਮੈਂ ਅਜਿਹੀਆਂ ਪਾਈਪਲਾਈਨਾਂ ਦੇਖੀਆਂ ਹਨ ਜਿੱਥੇ ਇੱਕ ਸਿੰਗਲ ਰਨ ਦੋ ਵੱਖ-ਵੱਖ ਪ੍ਰਵਾਨਗੀ ਬੇਨਤੀਆਂ ਪੈਦਾ ਕਰ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਰੀਟ੍ਰਾਈ ਪਾਲਿਸੀ (retry policy) ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਮਲਾਵਰ ਸੀ। ਮੈਂ ਇੱਕ ਹੋਰ ਰਨ ਦੇਖਿਆ ਹੈ ਜਿਸਨੇ ਇੱਕ ਮੇਲਬਾਕਸ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਿਸ ਵਿੱਚ ਅਜੇ ਵੀ ਪਿਛਲੇ ਹਫ਼ਤੇ ਦੇ ਸੁਨੇਹੇ ਸਨ। ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਦੇਣ ਵਾਲਾ ਵਿਅਕਤੀ ਰਨ IDs ਨਹੀਂ ਦੇਖਦਾ। ਉਹ ਸਿਰਫ਼ ਇੱਕ ਵਿਸ਼ਾ (subject line) ਅਤੇ ਇੱਕ ਬਟਨ ਦੇਖਦਾ ਹੈ। ਬਿਨਾਂ ਕਿਸੇ ਢਾਂਚੇ ਦੇ, ਉਹ ਉਸੇ ਇਨਬਾਕਸ ਵਿੱਚ ਅੰਦਾਜ਼ਾ ਲਗਾ ਰਹੇ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਮਾਰਕੀਟਿੰਗ ਨਿਊਜ਼ਲੈਟਰ ਅਤੇ ਮਾਨੀਟਰਿੰਗ ਅਲਰਟ ਹੁੰਦੇ ਹਨ।

ਉਪੇਖਿਤ ਕਦਮ (The Neglected Step)

ਟੀਮਾਂ ਪ੍ਰੋਂਪਟਸ (prompts) ਨੂੰ ਟਿਊਨ ਕਰਨ, ਗਾਰਡਰੇਲ (guardrails) ਜੋੜਨ ਅਤੇ ਆਉਟਪੁੱਟ ਦਾ ਬੈਂਚਮਾਰਕਿੰਗ ਕਰਨ ਵਿੱਚ ਹਫ਼ਤਿਆਂ ਬਿਤਾਉਣਗੀਆਂ। ਫਿਰ ਉਹ ਪ੍ਰਵਾਨਗੀ ਕਦਮ ਨੂੰ ਇੱਕ Slack ਚੈਨਲ ਜਾਂ ਸਾਂਝੇ ਸਪੋਰਟ ਇਨਬਾਕਸ ਨਾਲ ਜੋੜ ਦਿੰਦੇ ਹਨ ਅਤੇ ਕਹਿ ਦਿੰਦੇ ਹਨ ਕਿ ਕੰਮ ਹੋ ਗਿਆ। ਇਹ ਤਿੰਨ ਅਨੁਮਾਨਿਤ ਨੁਕਸਾਨ ਪੈਦਾ ਕਰਦਾ ਹੈ:

  • ਇੱਕ ਸਾਂਝਾ ਇਨਬਾਕਸ ਕਈ ਰਨਾਂ ਤੋਂ ਆਉਣ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਲਈ ਇੱਕ ਡੰਪਿੰਗ ਗਰਾਊਂਡ ਬਣ ਜਾਂਦਾ ਹੈ। ਸੰਦਰਭ (context) ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਥ੍ਰੈਡਸ ਨੂੰ ਖੋਲ੍ਹੇ ਅਤੇ ਮੈਨੂਅਲੀ ਟਾਈਮਸਟੈਂਪ ਦੀ ਜਾਂਚ ਕੀਤੇ ਬਿਨਾਂ ਇਹ ਪਤਾ ਨਹੀਂ ਲਗਾ ਸਕਦੇ ਕਿ ਕਿਹੜਾ ਸੁਨੇਹਾ ਕਿਸ ਵਪਾਰਕ ਲੈਣ-ਦੇਣ ਨਾਲ ਸਬੰਧਤ ਸੀ।
  • ਰੀਟ੍ਰਾਈਜ਼ (Retries) ਸਬੂਤਾਂ ਨੂੰ ਮਿਟਾ ਦਿੰਦੇ ਹਨ। ਜੇਕਰ ਕੋਈ ਰਨ ਆਪਣੀ ਪ੍ਰਵਾਨਗੀ ਬੇਨਤੀ ਦੁਬਾਰਾ ਭੇਜਦਾ ਹੈ, ਤਾਂ ਅਸਲ ਸੁਨੇਹਾ ਦਬ ਸਕਦਾ ਹੈ, ਡਿਲੀਟ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਉਤਸ਼ਾਹੀ ਈਮੇਲ ਕਲਾਇੰਟ ਦੁਆਰਾ ਡੁਪਲੀਕੇਟ ਵਜੋਂ ਮਾਰਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਆਡਿਟ ਟ੍ਰੇਲ (audit trail) ਖਰਾਬ ਹੋ ਜਾਂਦੀ ਹੈ।
  • ਮਨੁੱਖੀ ਫੈਸਲੇ ਸਿਸਟਮ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦੇ ਹਨ। ਕੋਈ ਵਿਅਕਤੀ ਕਿਸੇ ਟਿਕਟ ਜਾਂ ਸਿੱਧੇ ਸੰਦੇਸ਼ ਵਿੱਚ "looks good" ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਉਹ ਭਾਵਨਾ ਵਰਕਫਲੋ ਦੇ ਅੰਦਰ ਕਦੇ ਵੀ ਸੰਰਚਿਤ ਡੇਟਾ (structured data) ਨਹੀਂ ਬਣਦੀ। ਏਜੰਟ ਕੋਲ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕਿਸਨੇ ਕੀ ਕਿਹਾ, ਜਾਂ ਕਦੋਂ ਕਿਹਾ।

ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਅਫਵਾਹਾਂ ਮਿਲਦੀਆਂ ਹਨ। "ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਉਹ ਸਹੀ ਈਮੇਲ ਸੀ।" ਯਾਦਦਾਸ਼ਤ, ਟ੍ਰੇਸੇਬਿਲਟੀ (traceability) ਨਹੀਂ ਹੈ। ਇੱਕ ਆਡਿਟ ਲੌਗ ਕਿਸੇ ਅੰਦਾਜ਼ੇ ਨੂੰ ਨਹੀਂ ਸਮਝ ਸਕਦਾ।

ਡਿਲੀਵਰੀ ਦੇ ਵੇਰਵੇ ਤੋਂ ਚੈੱਕਪੁਆਇੰਟ ਤੱਕ

ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਤਬਦੀਲੀ ਦੀ ਲੋੜ ਹੈ। ਈਮੇਲ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਡਿਲੀਵਰੀ ਵੇਰਵੇ ਵਜੋਂ ਦੇਖਣਾ ਬੰਦ ਕਰੋ। ਇਸ ਨੂੰ ਇੱਕ ਸਿਸਟਮ ਚੈੱਕਪੁਆਇੰਟ ਵਜੋਂ ਮੰਨਣਾ ਸ਼ੁਰੂ ਕਰੋ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ ਸੁਨੇਹਾ ਇੱਕ ਸਟੇਟ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ (state transition) ਹੈ, ਅਤੇ ਹਰ ਸਟੇਟ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਨੂੰ ਪਛਾਣ, ਅਧਿਕਾਰ ਅਤੇ ਸਬੂਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਸੋਚ ਬਣਾ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਸਵਾਲ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਤੁਸੀਂ ਇਹ ਪੁੱਛਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਕਿ ਕੀ ਈਮੇਲ ਸਫਲਤਾਪੂਰਵਕ ਭੇਜੀ ਗਈ ਸੀ। ਤੁਸੀਂ ਇਹ ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਕਿ ਕਿਸ ਰਨ ਨੇ ਇਸਨੂੰ ਭੇਜਿਆ, ਇਸਨੇ ਕੀ ਸਬੂਤ ਛੱਡੇ, ਅਤੇ ਕਿਸ ਨਿਯਮ ਨੇ ਵਰਕਫਲੋ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਲਈ ਅਧਿਕਾਰ ਦਿੱਤਾ। ਏਜੰਟ ਬਿਲਕੁਲ ਈਮੇਲ ਦਾ ਮੁੱਖ ਭਾਗ ਲਿਖ ਸਕਦਾ ਹੈ। ਪਰ ਤੁਹਾਡੇ ਪਲੇਟਫਾਰਮ ਨੂੰ ਪਛਾਣ ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਮਾਰਗਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। LLM ਲੇਖਕ ਹੈ। ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਨੋਟਰੀ ਹੈ।

ਇੱਕ ਨਿਊਨਤਮ ਡਿਜ਼ਾਈਨ (A Minimum Design)

ਇਸ ਨੂੰ ਬਣਾਉਣ ਲਈ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੱਡੀ ਰਕਮ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਮੇਰਾ ਨਿਊਨਤਮ ਵਿਵਹਾਰਕ (minimum viable) ਵਰਜ਼ਨ ਪੰਜ ਸੋਚ ਸਮਝ ਕੇ ਚੁਣੇ ਗਏ ਹਿੱਸਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

  • ਆਰਕੈਸਟ੍ਰੇਟਰ ਵਰਕਫਲੋ ਸ਼ੁਰੂ ਹੋਣ ਦੇ ਸਹੀ ਸਮੇਂ 'ਤੇ ਇੱਕ run_id ਤਿਆਰ ਕਰਦਾ ਹੈ। ਇਹ ਪਛਾਣਕਰਤਾ ਹਰ ਅਗਲੇ ਕਾਰਵਾਈ ਦੀ ਰੀੜ੍ਹ ਦੀ ਹੱਡੀ ਹੈ। ਇਹ ਕਦੇ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ ਇਸਦੀ ਦੁਬਾਰਾ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।
  • ਹਰ ਈਮੇਲ ਐਕਸ਼ਨ ਵਿੱਚ ਤਿੰਨ ਫੀਲਡ ਹੁੰਦੀਆਂ ਹਨ: run_id, ਇੱਕ message_type ਲੇਬਲ ਜਿਵੇਂ ਕਿ "approval_request" ਜਾਂ "evidence_notification," ਅਤੇ ਇੱਕ policy_version ਸਟ੍ਰਿੰਗ ਜੋ ਪਛਾਣਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਗਵਰਨੈਂਸ ਨਿਯਮ ਸਰਗਰਮ ਹਨ। ਇਹ ਇੱਕ ਸਾਧਾਰਨ ਸੁਨੇਹੇ ਨੂੰ ਇੱਕ ਟਾਈਪਡ ਇਵੈਂਟ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
  • ਸਬੂਤ (Evidence) ਇੱਕ ਅਜਿਹੇ ਇਨਬਾਕਸ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ ਜੋ ਰਨ ਦੁਆਰਾ ਅਲੱਗ ਕੀਤਾ ਗਿਆ ਹੋਵੇ। ਇਸਦਾ ਮਤਲਬ ਹਮੇਸ਼ਾ ਹਰ ਰਨ ਲਈ ਇੱਕ ਵੱਖਰਾ ਈਮੇਲ ਖਾਤਾ ਨਹੀਂ ਹੁੰਦਾ। ਇਸਦਾ ਮਤਲਬ ਇੱਕ ਸਮਰਪਿਤ ਲੇਬਲ, ਇੱਕ ਸਬ-ਫੋਲਡਰ, ਜਾਂ ਇੱਕ ਰੂਟਿੰਗ ਨਿਯਮ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਥ੍ਰੈਡਸ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਵੰਡਦਾ ਹੈ ਕਿ ਇੱਕ ਰਨ ਦਾ ਪੱਤਰ-ਵਿਹਾਰ ਦੂਜੇ ਨਾਲ ਨਹੀਂ ਉਲਝਦਾ।
  • ਪ੍ਰਵਾਨਗੀ ਦੀ ਪ੍ਰਤੀਕਿਰਿਆ ਇੱਕ ਸੰਰਚਿਤ ਇਵੈਂਟ (structured event) ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਖੁੱਲ੍ਹਾ "ok" ਟੈਕਸਟ। ਮਨੁੱਖ ਅਜੇ ਵੀ ਕਲਿੱਕ ਕਰਦਾ ਹੈ ਜਾਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਪਰ ਸਿਸਟਮ ਉਸ ਕਾਰਵਾਈ ਨੂੰ ਇੱਕ ਮਸ਼ੀਨ-ਪੜ੍ਹਨਯੋਗ ਪੇਲੋਡ (machine-readable payload) ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜੋ run_id, ਫੈਸਲੇ ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ।
  • ਪ੍ਰਵਾਹ (flow) ਉਦੋਂ ਹੀ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ ਜੇਕਰ ਸਬੂਤ ਅਤੇ ਫੈਸਲਾ ਮੇਲ ਖਾਂਦੇ ਹਨ। ਵਰਕਫਲੋ ਇਕੱਲੇ ਪ੍ਰਵਾਨਗੀ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ। ਇਹ LLM ਆਉਟਪੁੱਟ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਪਹੁੰਚਣ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਬੇਨਤੀ ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਵਾਨਗੀ ਪੇਲੋਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ।

ਇੱਕ ਲਾਭਦਾਇਕ ਚੈੱਕਪੁਆਇੰਟ ਕੀ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ

A useful checkpoint enforces four conditions before it accepts a human decision.

  • The recipient must belong to the run context. If the approver is not the assigned reviewer for this specific workflow instance, the system rejects the signal.
  • The subject or routing metadata must match the current flow state. An approval for step three does not bypass step two.
  • The timestamp must fall within an expected window. A decision that arrives after a timeout should trigger a fresh review, not an automatic pass.
  • The evidence must not have been reused by another run. If the same message ID or token shows up in two separate approval requests, that is a collision, and the system should halt.

The Real Cost

This pattern is not free. You store more metadata. You add a policy layer that someone must maintain. You force your team to log human decisions as structured data instead of offhand comments. It looks like bureaucracy. In practice, it is an excellent trade.

You are trading speed for clarity.