ਹਰ agent system ਨੂੰ ਇੱਕੋ ਜਿਹੀ ਅਸੁਖਾਵੀਂ ਚੁਣੌਤੀ (trade-off) ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਡੂੰਘਾ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਗਠਿਤ ਗਿਆਨ ਦਾ ਅਧਾਰ (knowledge base) ਚਾਹੁੰਦੇ ਹੋ ਜੋ code reviews ਅਤੇ git history ਵਿੱਚ ਬਚਿਆ ਰਹੇ। ਪਰ ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਚਾਹੀਦਾ ਹੈ ਕਿ runtime ਤੇਜ਼ ਰਹੇ ਅਤੇ ਕੇਂਦਰਿਤ ਰਹੇ। ਇਹ ਦੋਵੇਂ ਲੋੜਾਂ ਇੱਕ ਦੂਜੇ ਦੇ ਵਿਰੁੱਧ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਜਿੰਨੀਆਂ ਜ਼ਿਆਦਾ ਹਦਾਇਤਾਂ (instructions) ਨੂੰ ਸੰਭਾਲਦੇ ਹੋ, ਉੰਨਾ ਹੀ ਲੱਗਦਾ ਹੈ ਕਿ ਸਾਰੀਆਂ ਨੂੰ prompt ਵਿੱਚ ਪਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉਮੀਦ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਸਭ ਕੁਝ ਠੀਕ ਹੋ ਜਾਵੇਗਾ। ਉਹ ਉਮੀਦ ਮਹਿੰਗੀ ਪੈਂਦੀ ਹੈ।

Agent Project Context ecosystem ਵਿੱਚ, ਇਹ ਤਣਾਅ ਦੋ ਪਰਤਾਂ (layers) ਵਿੱਚ ਵੰਡਿਆ ਹੋਇਆ ਹੈ। APC ਟਿਕਾਊਪਨ (durability) ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। APX ਰਫ਼ਤਾਰ (speed) ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਉਹ ਕਿਵੇਂ ਇੱਕ ਦੂਜੇ ਨਾਲ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ—ਅਤੇ APX ਹਰ skill definition ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਲੋਡ (preload) ਕਰਨ ਤੋਂ ਕਿਉਂ ਮਨ੍ਹਾ ਕਰਦਾ ਹੈ—ਇਸ ਨੂੰ ਸਮਝਣਾ prompt engineering ਬਾਰੇ ਉਸ ਤੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਦੱਸਦਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ optimization guides ਦੱਸਦੇ ਹਨ।

The Archive and the Engine

APC ਦਾ ਕੰਮ ਸਥਾਈਤਾ ਹੈ। ਇਹ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾਣ ਯੋਗ skill files ਨੂੰ .apc/skills/ ਦੇ ਅਧੀਨ ਸਾਧਾਰਨ Markdown ਦਸਤਾਵੇਜ਼ਾਂ ਵਜੋਂ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ ਇਹ ਫਾਈਲਾਂ ਤੁਹਾਡੇ repository ਦੇ ਅੰਦਰ ਹੁੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਹ version control ਦੇ ਨਾਲ ਚਲਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਇੱਕ pull request ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ ਜੋ deployment procedure ਨੂੰ ਬਦਲਦੀ ਹੈ। ਤੁਸੀਂ ਛੇ ਹਫ਼ਤੇ ਪਹਿਲਾਂ ਦੇ security policy rollback ਦਾ diff ਦੇਖ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਬਿਲਕੁਲ ਆਡਿਟ ਕਰ ਸਕਦੇ ਹੋ ਕਿ agent ਨੂੰ ਕੀ ਜਾਣਨਾ ਚਾਹੀਦਾ ਸੀ ਅਤੇ ਕਦੋਂ। ਜਦੋਂ ਕੋਈ ਗਲਤ deployment ਲਾਈਵ ਹੋ ਜਾਂਦੀ ਹੈ ਜਾਂ ਕੋਈ compliance auditor ਸਵਾਲ ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ reviewability ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ।

ਦੂਜੇ ਪਾਸੇ, APX ਮੌਜੂਦਾ ਸਮੇਂ ਵਿੱਚ ਜੀਉਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਅਤੇ ਮਾਡਲ ਵਿਚਕਾਰ ਅਸਲ ਗੱਲਬਾਤ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਉਦੇਸ਼ ਗਿਆਨ ਨੂੰ ਆਰਕਾਈਵ ਕਰਨਾ ਨਹੀਂ ਬਲਕਿ ਇਸਦੀ ਸਹੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ। ਜਦੋਂ APX skills ਨੂੰ ਸਥਾਈ ਬੋਝ ਵਜੋਂ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਸਾਰਾ ਸਿਸਟਮ ਹੌਲੀ ਹੋ ਜਾਂਦਾ ਹੈ। Context window ਭਰ ਜਾਂਦੀ ਹੈ। Token costs ਵਧ ਜਾਂਦੀਆਂ ਹਨ। ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ, ਮਾਡਲ ਦਾ ਧਿਆਨ ਉਹਨਾਂ ਹਦਾਇਤਾਂ ਵਿੱਚ ਖਿੰਡ ਜਾਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਮੌਜੂਦਾ ਬੇਨਤੀ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਹੁੰਦਾ।

ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ skill bodies ਮੰਗ ਅਨੁਸਾਰ (on demand) ਲੋਡ ਹੁੰਦੀਆਂ ਹਨ।

The True Cost of a Bloated Prompt

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਸਮਝਦੀਆਂ ਹਨ ਕਿ tokens ਦੀ ਕੀਮਤ ਹੁੰਦੀ ਹੈ। ਪਰ ਘੱਟ ਹੀ ਟੀਮਾਂ ਇਹ ਸਮਝਦੀਆਂ ਹਨ ਕਿ ਗੈਰ-ਜ਼ਰੂਰੀ tokens ਸਹੀ ਮੁਲਾਂਕਣ (accuracy) ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ।

ਜਦੋਂ APX ਹਰ ਮੌਕੇ 'ਤੇ ਹਰ ਉਪਲਬਧ skill ਨੂੰ inject ਕਰਦਾ ਹੈ, ਤਾਂ prompt ਸ਼ੋਰ ਵਾਲਾ (noisy) ਹੋ ਜਾਂਦਾ ਹੈ। ਮਾਡਲ ਨੂੰ deployment runbook, security guide, API style reference, testing checklist, ਅਤੇ onboarding FAQ ਸਭ ਇੱਕੋ ਸਮੇਂ ਮਿਲਦੇ ਹਨ। ਇੱਕ ਵੱਡੇ context window ਦੇ ਨਾਲ ਵੀ, ਜਦੋਂ ਮਾਡਲ ਨੂੰ ਸਹੀ ਜਾਣਕਾਰੀ ਲੱਭਣ ਲਈ ਪਹਿਲਾਂ ਸ਼ੋਰ ਵਿੱਚੋਂ ਛਾਣਨੀ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਤਰਕ ਦੀ ਗੁਣਵੱਤਾ ਘਟ ਜਾਂਦੀ ਹੈ। ਇਹ ਸਥਾਨਕ ਟੈਸਟ ਸੈੱਟਅੱਪ ਬਾਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਸਮੇਂ ਉਤਪਾਦਨ (production) deployments ਲਈ ਬਣਾਈ ਗਈ security requirement ਨੂੰ ਫੜ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕ ਸਧਾਰਨ ਬੱਗ ਫਿਕਸ ਵਿੱਚ ਰਿਲੀਜ਼ ਚੈੱਕਲਿਸਟ ਦੇ ਕਦਮਾਂ ਨੂੰ hallucinate ਕਰ ਸਕਦਾ ਹੈ। ਗੈਰ-ਸੰਬੰਧਿਤ ਟੈਕਸਟ ਦਾ ਹਰ ਵਾਧੂ ਪੈਰਾਗ੍ਰਾਫ ਇੱਕ ਭਟਕਾਅ ਹੈ।

ਗਣਿਤ ਬਹੁਤ ਸਿੱਧਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਵਾਰਾਂ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ skills ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ error log ਦੇ ਤੇਜ਼ ਫਿਕਸ ਲਈ ਪੁੱਛ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ deployment runbook ਜਾਂ security hardening guide ਦਾ ਪੂਰਾ ਟੈਕਸਟ ਨਹੀਂ ਚਾਹੀਦਾ। ਤੁਹਾਨੂੰ ਮਾਡਲ ਦੀ ਲੋੜ ਹੈ ਕਿ ਉਹ ਗਲਤੀ ਨੂੰ ਦੇਖੇ, ਤੁਹਾਡੇ project conventions ਨੂੰ ਸਮਝੇ, ਅਤੇ ਸਹੀ ਫਾਈਲ ਨੂੰ ਐਡਿਟ ਕਰੇ। ਗੈਰ-ਜ਼ਰੂਰੀ skill bodies ਨੂੰ ਲੋਡ ਕਰਨਾ ਮਾਡਲ ਦੀ ਇਸ ਕੰਮ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਮਾਡਲ ਨੂੰ ਤੁਹਾਡੀ ਅਸਲ ਸਮੱਸਿਆ 'ਤੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਫਾਲਤੂ ਡੇਟਾ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।

How On-Demand Loading Works

ਇਹ ਵਿਧੀ ਸਰਲ ਪਰ ਜਾਣਬੁੱਝ ਕੇ ਬਣਾਈ ਗਈ ਹੈ। APC ਅਸਲ ਸੱਚਾਈ (ground truth) ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ। ਤੁਹਾਡੀਆਂ skill definitions ਉੱਥੇ ਹੀ ਰਹਿੰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਉਹ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: .apc/skills/<name>.md ਵਿੱਚ।

APX ਉਹਨਾਂ ਫਾਈਲਾਂ ਨੂੰ active memory ਵਿੱਚ ਮਿਰਰ (mirror) ਨਹੀਂ ਕਰਦਾ। ਇਸਦੀ ਬਜਾਏ, ਇਹ skill names ਦੀ ਇੱਕ ਸੰਖੇਪ ਰਜਿਸਟਰੀ (compact registry) ਤਿਆਰ ਕਰਦਾ ਹੈ। ਮਾਡਲ ਇਸ ਸੂਚੀ ਨੂੰ ਦੇਖਦਾ ਹੈ ਅਤੇ ਸਮਝਦਾ ਹੈ ਕਿ ਇੱਕ ਕੈਟਾਲਾਗ ਮੌਜੂਦ ਹੈ। ਜੇਕਰ ਇਸਨੂੰ ਇਹ ਦੇਖਣ ਜਾਂ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਸਮਰੱਥਾਵਾਂ ਉਪਲਬਧ ਹਨ, ਤਾਂ ਇਹ list_skills ਕਾਲ ਨੂੰ ਇਵੋਕ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਇਸਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਡੇਟਾ ਤੋਂ ਬਿਨਾਂ ਸਪੱਸ਼ਟਤਾ ਦਿੰਦਾ ਹੈ।

ਜਦੋਂ ਕੰਮ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕਿਸੇ skill ਫਾਈਲ ਵਿੱਚ ਮੌਜਦ ਸਹੀ syntax, ਵਿਸਤ੍ਰਿਤ ਕਦਮਾਂ, ਜਾਂ ਖਾਸ ਪਾਬੰਦੀਆਂ (constraints) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਮਾਡਲ load_skill ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਉਸ ਸਮੇਂ, ਅਤੇ ਸਿਰਫ਼ ਉਸੇ ਸਮੇਂ, APX, APC ਤੋਂ ਪੂਰੀ Markdown body ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ context ਵਿੱਚ inject ਕਰਦਾ ਹੈ। ਹਦਾਇਤ ਤੁਰੰਤ ਅਤੇ ਲੋੜ ਅਨੁਸਾਰ ਪਹੁੰਚਦੀ ਹੈ, ਇਸਦੀ ਵਰਤੋਂ ਇੱਕ ਵਾਰ ਇਸਦੇ ਨਿਰਧਾਰਤ ਉਦੇਸ਼ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਇਸਨੂੰ ਫਾਲਤੂ ਬੋਝ ਵਜੋਂ ਨਹੀਂ ਰੱਖਦਾ।

ਇੱਕ library ਨੂੰ import ਕਰਨ ਅਤੇ ਹਰ function definition ਨੂੰ ਆਪਣੀ ਮੁੱਖ ਫਾਈਲ ਵਿੱਚ ਪੇਸਟ ਕਰਨ ਦੇ ਅੰਤਰ ਬਾਰੇ ਸੋਚੋ। ਇੱਕ ਤਰੀਕਾ ਤੁਹਾਡੇ codebase ਨੂੰ ਸੁਖਾਲਾ ਰੱਖਦਾ ਹੈ। ਦੂਜਾ ਇੱਕ ਅਜਿਹੀ ਗੜਬੜ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਇਤਫ਼ਾਕ ਨਾਲ ਕੰਪਾਈਲ ਹੁੰਦੀ ਹੈ।

Who Wins When Skills Collide

ਜਦੋਂ APX skills ਨੂੰ ਲੋਡ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਸਪੱਸ਼ਟ ਤਰਜੀਹ ਕ੍ਰਮ (priority order) ਵੀ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਹਰ ਵਾਤਾਵਰਣ ਇੱਕੋ ਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਆਮ ਸਲਾਹ (generic advice) ਨੂੰ ਕਦੇ ਵੀ ਸਥਾਨਕ ਗਿਆਨ (local knowledge) ਉੱਤੇ ਹਾਵੀ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।

ਪ੍ਰੋਜੈਕਟ ਸਕਿੱਲਜ਼ (Project skills) ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਫਾਈਲਾਂ ਤੁਹਾਡੀ ਮੌਜੂਦਾ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ .apc/skills/ ਦੇ ਅਧੀਨ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਤੁਹਾਡੀ ਟੀਮ ਦੇ ਵਿਸ਼ੇਸ਼ ਰਿਵਾਜਾਂ, ਤੁਹਾਡੇ ਕਸਟਮ ਵੈਪਰਜ਼ (wrappers), ਤੁਹਾਡੇ ਪੁਰਾਣੇ ਨਾਮਕਰਨ ਦੇ ਮਿਆਰਾਂ, ਅਤੇ ਤੁਹਾਡੇ ਖਾਸ ਟੂਲਚੇਨ (toolchain) ਨੂੰ ਕੈਪਚਰ ਕਰਦੀਆਂ ਹਨ। ਜੇਕਰ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਡਾਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਸੰਭਾਲਣ ਦਾ ਆਪਣਾ ਤਰੀਕਾ ਤੈਅ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਪਰਿਭਾਸ਼ਾ ਹੀ ਮਾਨਤਾ ਪ੍ਰਾਪਤ ਕਰੇਗੀ।

ਇਸ ਤੋਂ ਬਾਅਦ ਗਲੋਬਲ ਸਕਿੱਲਜ਼ (Global skills) ਆਉਂਦੀਆਂ ਹਨ। ਇਹ ਸੰਗਠਨ-ਵਿਆਪੀ ਪੈਟਰਨਾਂ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ ਜੋ ਉਦੋਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਪ੍ਰੋਜੈਕਟ ਖੁਦ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦਿੰਦਾ। ਇਹ ਇੱਕ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਵਜੋਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।

ਬਿਲਟ-ਇਨ ਰਨਟਾਈਮ ਸਕਿੱਲਜ਼ (Built-in runtime skills) ਫਾਲਬੈਕ (fallback) ਵਜੋਂ ਸਭ ਤੋਂ ਹੇਠਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਉਹ ਆਮ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਸੰਭਾਲਦੀਆਂ ਹਨ ਜੋ ਹਰ ਏਜੰਟ ਨੂੰ ਸਮਝਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਪਰ ਕਿਸੇ ਖਾਸ ਪ੍ਰੋਜੈਕਟ ਨੇ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਸਮਝੀ।

ਇਹ ਲੇਅਰਡ (layered) ਪਹੁੰਚ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀ ਰਿਪੋਜ਼ਟਰੀ ਆਪਣੇ ਵਿਵਹਾਰ 'ਤੇ ਕੰਟਰੋਲ ਰੱਖਦੀ ਹੈ। ਕੋਈ ਗਲੋਬਲ ਜਾਂ ਬਿਲਟ-ਇਨ ਸਕਿੱਲ ਗਲਤੀ ਨਾਲ ਉਸ ਵਰਕਫਲੋ (workflow) ਨੂੰ ਹਾਈਜੈਕ ਨਹੀਂ ਕਰ ਸਕਦੀ ਜਿਸ ਨੂੰ ਤੁਹਾਡੀ ਟੀਮ ਨੇ ਜਾਣਬੁੱਝ ਕੇ ਕਸਟਮਾਈਜ਼ ਕੀਤਾ ਹੈ।

ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ

ਇੱਕ ਆਮ ਰੱਖ-ਰਖਾਅ (maintenance) ਦੇ ਕੰਮ ਦੀ ਕਲਪਨਾ ਕਰੋ। ਇੱਕ ਸਾਥੀ ਚੈਟ ਵਿੱਚ ਇੱਕ ਐਰਰ ਲੌਗ (error log) ਪੇਸਟ ਕਰਦਾ ਹੈ। ਟ੍ਰੇਸਬੈਕ (traceback) ਇੱਕ ਯੂਟੀਲਿਟੀ ਮੋਡੀਊਲ ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ null ਰੈਫਰੈਂਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਹੱਲ ਸ਼ਾਇਦ ਡਿਫੈਂਸਿਵ ਕੋਡਿੰਗ ਦੀਆਂ ਦੋ ਲਾਈਨਾਂ ਹੋਵੇਗਾ।

ਆਨ-ਡਿਮਾਂਡ ਲੋਡਿੰਗ (on-demand loading) ਤੋਂ ਬਿਨਾਂ ਵਾਲੇ ਸਿਸਟਮ ਵਿੱਚ, APX ਉਸ ਸਾਰੇ ਕੰਟੈਕਸਟ (context) ਨੂੰ ਭਰ ਦੇਵੇਗਾ ਜੋ ਉਹ ਜਾਣਦਾ ਹੈ। ਹੁਣ ਮਾਡਲ ਕੋਲ ਉਹਨਾਂ ਦੋ ਲਾਈਨਾਂ ਨੂੰ