Title: ਸਹਾਇਤਾ ਤੋਂ ਲੈ ਕੇ ਅਮਲ ਤੱਕ: ਆਰਕੀਟੈਕਚਰਲ ਤਬਦੀਲੀ

Microsoft ਦੀ 2026 ਦੀ “Agentic Transformation Patterns” ਪਲੇਅਬੁੱਕ ਇਹ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸਦੀ ਹੈ ਕਿ AI agents ਨੂੰ ਸਿਰਫ਼ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸਹਾਇਤਾ ਕਰਨ ਦੀ ਬਜਾਏ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਨ (execute ਕਰਨ) ਲਈ ਕਿਵੇਂ ਮੁੜ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਇਸ ਯਤਨ 'ਤੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਕੀਮਤ ਲਗਾਉਂਦੀ ਹੈ – ਇੱਕ ਸਿੰਗਲ execution-mode agent ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਖ ਬੁਨਿਆਦੀ ਢਾਂਚੇ (core infrastructure) ਲਈ 26 ਤੋਂ 60 ਇੰਜੀਨੀਅਰ-ਹਫ਼ਤੇ ਲੱਗ ਸਕਦੇ ਹਨ। ਜੋ ਕੰਪਨੀਆਂ ਇਸ ਤਬਦੀਲੀ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਅਜਿਹੇ ਕਮਜ਼ੋਰ ਟੂਲ ਬਣਾਉਣ ਦਾ ਖ਼ਤਰਾ ਹੈ ਜੋ ਆਪਣੇ ਆਪ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੇ।

ਉੱਦਮ (Enterprises) ਹੁਣ large-language-model (LLM) assistants ਨਾਲ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹਨ ਜੋ ਈਮੇਲ ਡਰਾਫਟ ਕਰਦੇ ਹਨ, ਕੋਡ ਸਨਿਪੇਟਸ (code snippets) ਸੁਝਾਉਂਦੇ ਹਨ, ਜਾਂ ਡੇਟਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਉਹ agents "assist" ਮੋਡ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ: ਇੱਕ ਇਨਸਾਨ ਹਰ ਆਉਟਪੁੱਟ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਥਿਨ ਵੈਪਰ (thin wrapper) ਮਾਡਲ ਨੂੰ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ। ਇਹ ਆਰਕੀਟੈਕਚਰ ਬਣਾਉਣ ਵਿੱਚ ਸਸਤਾ ਅਤੇ ਤੇਜ਼ ਹੈ, ਪਰ ਇਹ ਜਾਣਬੁੱਝ ਕੇ ਫੈਸਲਾ ਲੈਣ ਅਤੇ ਡੇਟਾ ਲਿਖਣ (data writes) ਦਾ ਕੰਮ ਉਪਭੋਗਤਾ 'ਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ।

ਜਦੋਂ ਕੋਈ ਸੰਸਥਾ ਚਾਹੁੰਦੀ ਹੈ ਕਿ agent ਇੱਕ ਪੂਰਾ ਵਰਕਫਲੋ (workflow) ਚਲਾਵੇ—ਜਿਵੇਂ ਕਿ ਡੇਟਾਬੇਸ ਭਰਨਾ, ਕਿਸੇ ਅਗਲੇ ਪ੍ਰਕਿਰਿਆ (downstream process) ਨੂੰ ਸ਼ੁਰੂ ਕਰਨਾ, ਜਾਂ ਲੈਣ-ਦੇਣ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣਾ—ਤਾਂ ਮਾਡਲ ਹੁਣ ਇੱਕ ਅਜਿਹਾ 'ਬਲੈਕ ਬਾਕਸ' ਨਹੀਂ ਹੋ ਸਕਦਾ ਜੋ ਸਿਰਫ਼ ਇਨਸਾਨ ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਆਪਣਾ ਜਵਾਬ ਦੇਵੇ। Agent ਨੂੰ ਇੱਕ ਖੁਦਮੁਖਤਿਆਰ (autonomous) ਸੇਵਾ ਵਜੋਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸਦੀ ਆਪਣੀ ਪਛਾਣ, ਸਥਾਈ ਸਥਿਤੀ (persistent state), ਅਤੇ ਇਨ-ਬਿਲਟ ਸੁਰੱਖਿਆ ਪ੍ਰਬੰਧ (safety nets) ਹੋਣ। Microsoft ਦਾ ਕਹਿਣਾ ਹੈ ਕਿ ਪੁਰਾਣੇ assist-only ਡਿਜ਼ਾਈਨ ਨੂੰ execution-ready ਸਿਸਟਮ ਵਿੱਚ ਸਿਰਫ਼ ਪੈਚ ਲਗਾ ਕੇ ਨਹੀਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ; ਇਸ ਲਈ ਸੱਤ ਆਰਕੀਟੈਕਚਰਲ ਪਿਲਰਾਂ (architectural pillars) ਦੇ ਆਧਾਰ 'ਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਡਿਜ਼ਾਈਨ ਦੀ ਲੋੜ ਹੈ।

Execution-ready AI agents ਦੇ ਸੱਤ ਪਿਲਰ

  • Authority (ਅਧਿਕਾਰ) – "user-delegated" ਇਜਾਜ਼ਤਾਂ ਤੋਂ ਹਟ ਕੇ ਸਥਾਈ agent ਪਛਾਣਾਂ ਵੱਲ ਵਧਣਾ ਜੋ ਸੀਮਤ ਪਹੁੰਚ ਅਧਿਕਾਰ (scoped access rights) ਰੱਖਦੀਆਂ ਹਨ। Agent ਨੂੰ ਇਨਸਾਨ ਦੇ ਟੋਕਨ ਤੋਂ ਬਿਨਾਂ ਆਪਣੇ ਆਪ ਨੂੰ downstream services ਲਈ ਪ੍ਰਮਾਣਿਤ (authenticate) ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
  • Boundaries (ਸੀਮਾਵਾਂ) – ਉੱਚ-ਜੋਖਮ ਵਾਲੀਆਂ ਗਣਨਾਵਾਂ ਲਈ ad-hoc ਮਾਡਲ ਤਰਕ ਦੀ ਬਜਾਏ ਨਿਸ਼ਚਿਤ (deterministic) ਕੋਡ ਪਾਥਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ। ਕੋਈ ਵੀ ਚੀਜ਼ ਜਿਸ ਵਿੱਚ ਸ਼ੁੱਧਤਾ ਦੀ ਲੋੜ ਹੋਵੇ—ਜਿਵੇਂ ਵਿੱਤੀ ਗਣਿਤ, ਕੰਪਲਾਇੰਸ ਚੈੱਕ—ਉਸਨੂੰ ਮਾਡਲ ਦੇ ਆਉਟਪੁੱਟ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਬਜਾਏ ਪ੍ਰਮਾਣਿਤ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਚਲਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
  • Schemas (ਸਕੀਮਾਵਾਂ) – Loosely-typed ਡੇਟਾ ਐਕਸਚੇਂਜ ਤੋਂ ਹਟ ਕੇ ਇੱਕ ਮਿਆਰੀ (canonical) schema ਵੱਲ ਵਧਣਾ ਜਿਸਦਾ ਮਾਲਕ ਇੱਕ ਨਿਯੁਕਤ ਡੇਟਾ ਸਟੈਵਰਡ (data steward) ਹੋਵੇ। ਇਹ agent ਨੂੰ ਗਲਤ ਰਿਕਾਰਡ ਲਿਖਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ downstream ਸਿਸਟਮ ਨਹੀਂ ਵਰਤ ਸਕਦੇ।
  • Failure Detection (ਅਸਫਲਤਾ ਦੀ ਪਛਾਣ) – ਇਨਸਾਨੀ ਨਿਗਰਾਨੀ ਦੀ ਬਜਾਏ ਲਗਾਤਾਰ ਟੈਲੀਮੈਟਰੀ (telemetry) ਅਤੇ ਕਾਰੋਬਾਰੀ-ਨਤੀਜਿਆਂ ਦੀ ਨਿਗਰਾਨੀ ਨੂੰ ਅਪਣਾਉਣਾ। ਸਿਸਟਮ ਨੂੰ ਆਪਣੇ ਆਪ ਅਨੋਮਲੀਆਂ (anomalies), ਜਿਵੇਂ ਕਿ ਅਚਾਨਕ ਲੈਣ-ਦੇਣ ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਵਾਧਾ, ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਜੇਕਰ ਸੀਮਾਵਾਂ (thresholds) ਟੁੱਟਦੀਆਂ ਹਨ ਤਾਂ agent ਨੂੰ ਰੋਕ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।
  • State (ਸਥਿਤੀ) – ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਾਲੇ ਚੈਟ ਸੈਸ਼ਨਾਂ ਦੀ ਬਜਾਏ ਸਥਾਈ, ਕੇਸ-ਸੀਮਤ ਸਥਿਤੀ (case-scoped state) ਨੂੰ ਇੱਕ ਸਿਸਟਮ ਆਫ ਰਿਕਾਰਡ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ। ਇੱਕ execution agent ਨੂੰ ਦਿਨਾਂ ਜਾਂ ਹਫ਼ਤਿਆਂ ਦੇ ਅੰਤਰਾਲ ਵਿੱਚ ਪਿਛਲੇ ਕਦਮਾਂ, ਆਡਿਟ ਟ੍ਰੇਲਜ਼, ਜਾਂ ਉਪਭੋਗਤਾ ਦੀਆਂ ਪਸੰਦਾਂ ਨੂੰ ਯਾਦ ਰੱਖਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
  • Rollback (ਵਾਪਸੀ) – "re-run the prompt" ਦੀ ਬਜਾਏ event-sourcing ਜਾਂ compensating transactions ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜੋ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕਾਰਵਾਈਆਂ ਨੂੰ ਵਾਪਸ ਲੈ ਸਕਣ। ਜੇਕਰ agent ਕੋਈ ਗਲਤੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਪਲੇਟਫਾਰਮ ਨੂੰ ਮਨੁੱਖੀ ਦਖਲਅੰਦਾਜ਼ੀ ਤੋਂ ਬਿਨਾਂ ਉਸਦੇ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਪਹਿਲਾਂ ਵਰਗਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
  • Auditability (ਆਡਿਟ ਕਰਨ ਯੋਗਤਾ) – ਸਧਾਰਨ ਚੈਟ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟਾਂ ਤੋਂ ਅੱਗੇ ਵਧ ਕੇ ਹਰ ਕਾਰਵਾਈ ਲਈ ਲੌਗਸ (logs) ਤਿਆਰ ਕਰਨਾ ਜੋ ਹਰ ਆਪਰੇਸ਼ਨ ਨੂੰ ਇੱਕ ਖਾਸ agent ਵਰਜ਼ਨ ਅਤੇ ਪਛਾਣ ਨਾਲ ਜੋੜਦੇ ਹਨ। ਨਿਯਮ ਲਾਗੂ ਕਰਨ ਵਾਲੇ (regulators) ਅਤੇ ਅੰਦਰੂਨੀ ਆਡਿਟਰ ਇਸ ਤਰ੍ਹਾਂ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹਨ ਕਿ agent ਨੇ ਕੀ ਕੀਤਾ, ਕਦੋਂ ਕੀਤਾ, ਅਤੇ ਕਿਸ ਨੀਤੀ ਦੇ ਤਹਿਤ ਕੀਤਾ।

ਇਹ ਤਬਦੀਲੀਆਂ ਕੋਈ ਵਿਕਲਪਿਕ ਵਾਧਾ ਨਹੀਂ ਹਨ; ਇਹ AI-ਅਧਾਰਿਤ ਆਟੋਮੇਸ਼ਨ ਲਈ ਇੱਕ ਨਵਾਂ ਸੰਚਾਲਨ ਮਾਡਲ (operating model) ਹਨ। Microsoft ਦਾ ਅਨੁਮਾਨ ਹੈ ਕਿ ਇਸ ਬੁਨਿਆਦ ਨੂੰ ਬਣਾਉਣ ਵਿੱਚ 26 ਤੋਂ 60 ਇੰਜੀਨੀਅਰ-ਹਫ਼ਤੇ ਲੱਗਣਗੇ।

ਲਾਗਤ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ