MCP schema drift लंबे समय तक चलने वाले agents को कैसे तोड़ता है

लंबे समय तक चलने वाले एजेंट एक गलत धारणा को बहुत महँगा बना देते हैं: session शुरू होने पर लोड किया गया tool description पूरे run में सही रहेगा। अक्सर ऐसा नहीं होता। एजेंट के कल वाले tool shape के आधार पर योजना बनाते समय सर्वर नया build deploy कर सकता है, account-specific capability चालू कर सकता है, upstream API बदल सकता है या result contract ठीक कर सकता है।

इसे MCP schema drift कहते हैं। यह कोई दुर्लभ protocol edge case नहीं है। यह उस client और server के बीच contract change है जिसने पहले ही योजना बना ली है और जो अब आगे बढ़ चुका है। यदि deployment के बाद आप केवल fresh connection test करते हैं, तो आसान स्थिति जाँच रहे हैं और खतरनाक स्थिति को छोड़ रहे हैं।

Model Context Protocol सर्वर को tool-list में बदलाव घोषित करने का तरीका देता है। यह पुराने client cache को नए contract में नहीं बदलता, model द्वारा पहले से प्रस्तावित tool calls को ठीक नहीं करता और यह तय नहीं करता कि पुरानी request अब भी सुरक्षित है या नहीं। ये engineering decisions हैं। इन्हें जानबूझकर लें और session चलने के दौरान test करें।

Tool description session state का हिस्सा है

Tool schema executable context है। एजेंट name, description, input schema, annotations और कभी-कभी output schema के आधार पर तय करता है कि कौन सी कार्रवाई माँगी जाए। कई clients tools/list को local structures में parse करते हैं, validators compile करते हैं या model context में संक्षिप्त tool description रखते हैं। सर्वर के किसी दूसरे version को deploy करने से इनमें से कोई copy अपने आप नहीं बदलती।

यह तब भी महत्वपूर्ण है जब wire protocol बिल्कुल सही तरीके से काम कर रहा हो। मान लें client ने इस tool के साथ शुरुआत की:

{
  "name": "deploy_preview",
  "description": "Deploy the current branch to a preview environment.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "branch": { "type": "string" }
    },
    "required": ["branch"],
    "additionalProperties": false
  }
}

एक घंटे बाद सर्वर operation बदल देता है और अब स्पष्ट region field जरूरी है। नया जुड़ने वाला client नया schema देखता है और उसे भेज सकता है। पुराना client अब भी मानता है कि {"branch":"fix-login"} पूरी request है।

यहाँ तीन अलग-अलग states हैं, जिन्हें teams अक्सर मिला देती हैं:

1. Advertised schema वह है जो सर्वर अभी tools/list से लौटाता है।
2. Client schema snapshot वह है जिसे किसी खास client ने पिछली बार tools list करते समय रखा था।
3. Execution contract वह है जिसे tools/call आने पर सर्वर स्वीकार करेगा और जिसके अनुसार काम करेगा।

सर्वर पहली state तुरंत बदल सकता है। वह यह मानकर नहीं चल सकता कि दूसरी state भी बदल गई है। तीसरी state को संभालने का तरीका उसे चुनना होगा।

इसे केवल cache invalidation problem कहना अधूरा है। Cache invalidation से stale display data का आभास होता है। Tool schema destination accounts, write scope, confirmation fields और result meanings तय कर सकता है। जब एजेंट के पास पुराना version हो, तो mismatch से काम विफल हो सकता है, retries दोहर सकते हैं या ऐसी request जा सकती है जिसका अर्थ model की मंशा से अधिक व्यापक हो।

सबसे सुरक्षित default सरल है: transition window के दौरान deployed tool का accepted input contract backward compatible रखें, जब तक पुराने input को स्वीकार करना action को असुरक्षित न बना दे। Safety और compatibility में टकराव हो तो पुराने shape को स्पष्ट रूप से reject करें और नया निर्णय माँगें।

tools/list_changed बदलाव बताता है, लेकिन sync नहीं करता

MCP specification उन servers के लिए notifications/tools/list_changed परिभाषित करती है जिनकी tool list बदलती है। सर्वर notification भेजता है और client tools/list से अपने tools refresh कर सकता है। Specification initialization के दौरान negotiated server tool capability में list-change notifications के support को भी model करती है।

यह उपयोगी है, लेकिन “can” शब्द बहुत कुछ छिपाता है। Notification का कोई response नहीं होता। केवल notification से सर्वर यह नहीं जान सकता कि client ने उसे पाया या नहीं, refresh किया या नहीं, उसका tool cache बदला या नहीं, या model ने पुराने description से call पहले ही तैयार कर ली थी या नहीं।

Notification को invalidation signal मानें, synchronization barrier नहीं।

Drift को ठीक से संभालने वाले client को notification मिलने के बाद चार काम करने चाहिए:

• tools/list फिर से माँगकर संबंधित local definitions को atomically बदलना।
• पहले से planned call को उस schema से जोड़ने के लिए पुराना snapshot कुछ समय तक रखना जिसने उसे बनाया था।
• भेजने से पहले हर queued call को refreshed schema के विरुद्ध फिर से validate करना।
• पुराने context से बनी call अब न चल सके तो model को ऐसा error देना जिसे वह ठीक कर सके।

तीसरे बिंदु पर clients अक्सर shortcut लेते हैं। वे दिखाई देने वाली tool list refresh करते हैं, लेकिन पहले से queued call को पुराने argument object के साथ भेज देते हैं। इससे race बनती है: UI कुछ और कहता है, agent कुछ और भेजता है और mismatch का समाधान server को करना पड़ता है।

Servers को भी समान अनुशासन चाहिए। Tool बदलने पर notification तभी भेजें जब नई tools/list response तैयार हो। नए contract की घोषणा करके पुराने process को मनमाने समय तक calls संभालने न दें। यदि आपकी deployment topology ऐसा कर सकती है, तो server response में स्पष्ट contract revision रखें और incompatible behavior वाले worker पर पहुँची calls को reject करें।

Notification उन clients की समस्या भी हल नहीं करता जो इसे support नहीं करते, event के दौरान disconnect हो जाते हैं या ऐसे intermediary से call करते हैं जिसका अपना cache है। tools/call पर compatibility अब भी जरूरी है। यदि server तभी काम करता है जब हर client notification पर सही प्रतिक्रिया दे, तो वह production में काम नहीं करता।

Input changes अलग-अलग तरह का breakage लाते हैं

Field जोड़ना बदलाव की एक ही category नहीं है। Risk इस पर निर्भर करता है कि field validation, meaning या authority में से क्या बदलता है।

Optional display preference जोड़ना आम तौर पर सुरक्षित है। पुराना caller उसे छोड़ देता है और server स्थिर default चुनता है। Optional filter भी सुरक्षित हो सकता है, यदि उसे छोड़ने पर वही result मिले जो पहले मिलता था।

deploy_preview में required region जोड़ना अलग बात है। पुराना caller validator को संतुष्ट नहीं करता। आप request reject कर सकते हैं या default दे सकते हैं। पहला विकल्प agent को रोकता है, लेकिन सच्चाई स्पष्ट रखता है। दूसरा तभी ठीक है जब वह default उस repository के लिए हमेशा से इच्छित region रहा हो और deployment को अधिक संवेदनशील environment में न भेज सके।

Field का अर्थ बदलना required field जोड़ने से भी खराब है। मान लें tool पहले project को human-readable project slug मानता था। बाद में server तय करता है कि project opaque organization identifier होगा। पुराना agent अब भी payments भेज सकता है और server उस string को अनपेक्षित namespace में resolve कर सकता है। Validation पास होती है, request सफल होती है और action गलत होता है। यह semantic break है, जो साफ validation error से अधिक खतरनाक है।

Input field हटाने में भी उतनी ही सावधानी चाहिए। JSON Schema का additionalProperties: false break को स्पष्ट बनाता है। पुराना client पहले valid argument भेजता है और failure पाता है। यदि server हटाए गए field को चुपचाप अनदेखा कर दे, तो call model की अपेक्षा से अलग अर्थ के साथ सफल हो सकती है।

“Be liberal in what you accept” जैसी लोकप्रिय सलाह action tools के लिए खराब है। यह इसलिए लोकप्रिय हुई क्योंकि इससे लापरवाह changes के दौरान integrations चलते रहते हैं। Read-only formatting preference के लिए यह सहनशीलता harmless हो सकती है। Credential-bearing HTTP request, SSH command, deploy, deletion या payment action में permissive parsing अस्पष्ट request को server-side guesswork में बदल देती है।

Compatibility adapter तभी इस्तेमाल करें जब आप उसका व्यवहार सटीक रूप से बता सकें। उदाहरण के लिए:

function normalizeDeployArgs(raw: unknown) {
  if (!isPlainObject(raw)) {
    throw executionError("Expected an object for deploy_preview.");
  }

  if (typeof raw.branch !== "string" || raw.branch.length === 0) {
    throw executionError("The branch field must be a non-empty string.");
  }

  if (raw.region === undefined) {
    return { branch: raw.branch, region: "us-east-preview", schemaRevision: 1 };
  }

  if (raw.region !== "us-east-preview" && raw.region !== "eu-preview") {
    throw executionError("region must be us-east-preview or eu-preview.");
  }

  return { branch: raw.branch, region: raw.region, schemaRevision: 2 };
}

इस adapter की एक स्वीकार्य विशेषता है: पुरानी request वही preview destination देती है जो पहले देती थी। यदि account ownership बदलने के बाद us-east-preview केवल सुविधाजनक अनुमान होता, तो यह adapter स्वीकार्य नहीं होता।

Incompatible change के लिए ऐसा error दें जिसका उपयोग agent कर सके। बताएँ कि server को कौन सा tool revision चाहिए, कौन सा field missing या obsolete है और client को tools refresh करना चाहिए। “invalid input” जैसा अस्पष्ट संदेश न लौटाएँ। Models अस्पष्ट errors पर छोटे बदलावों के साथ retry करते हैं। स्पष्ट errors repair का अवसर बनाते हैं।

Result-shape में बदलाव अगला निर्णय बिगाड़ सकता है

Teams input validation पर ध्यान देती हैं क्योंकि bad request server पर रुक जाती है। Result changes को कम जाँचती हैं क्योंकि action पहले ही पूरा हो चुका होता है। Agents के लिए यह उलटा है। अक्सर result ही अगली call का आधार बनता है।

मान लें original create_issue result यह था:

{
  "issue": {
    "id": "I-482",
    "url": "https://tracker.example/issues/I-482",
    "state": "open"
  }
}

Agent issue.id निकालकर working memory में रख सकता है और बाद में उस identifier के साथ add_comment call कर सकता है। यदि revised server id का नाम बदलकर issueId कर दे, result को data के भीतर रख दे या state को string से object बना दे, तो agent की अगली action मूल call से बहुत दूर जाकर विफल हो सकती है। इससे भी खराब स्थिति तब है जब text-only fallback में अब भी plausible sentence हो और model prose से identifier का अनुमान लगाने लगे।

MCP tool results में model के लिए content और programmatic use के लिए structured content दोनों हो सकते हैं। यदि आप output schema publish करते हैं, तो structured output को authoritative machine contract बनाएँ। Text को transcript पढ़ने वाले व्यक्ति के लिए संक्षिप्त और उपयोगी रखें, लेकिन clients से उसे भरोसेमंद ढंग से scrape करने की अपेक्षा न करें।

JSON Schema 2020-12 से जुड़ा MCP schema work यहाँ relevant है। Protocol की बाद की schema guidance dialect को स्पष्ट करती है और output schemas object-shaped JSON के छोटे subset से अधिक का वर्णन कर सकते हैं। इससे expressiveness बढ़ती है, लेकिन live result को लापरवाही से reshape करने की अनुमति नहीं मिलती। Client किसी खास draft, generated type या decoder से results validate कर सकता है, जिसे आपके नए union या array form की कोई tolerance न हो।

Result evolution के लिए ये नियम अपनाएँ:

1. Rename या remove करने से पहले fields जोड़ें।
2. Fields का meaning स्थिर रखें, खास तौर पर identifiers, status values और timestamps का।
3. जब कई interpretations साथ रखनी हों, तो structured output में schema_revision या result_version field रखें।
4. Execution विफल होने पर success result को unstructured apology में बदलने के बजाय पूरा structured error object लौटाएँ।
5. पुराने sessions खत्म होने या published migration window पूरी होने के बाद ही पुराना shape हटाएँ।

Result revision field सजावट नहीं है। इससे client अलग कर सकता है कि “server ने अधूरा पुराना response लौटाया” या “server ने नया response लौटाया जिसमें optional field अनुपस्थित है।” Agent retry करे, user से पूछे या consequential action जारी रखे, यह तय करते समय यह फर्क महत्वपूर्ण है।

हर output को versioned envelope में न बदलें। Revision marker वहाँ रखें जहाँ अलग-अलग deploy किए गए consumers को इसकी जरूरत हो। छोटे private server और एक bundled client के लिए additive stable shape पर्याप्त हो सकता है। कई agent hosts, workers और plugins में साझा tool के लिए explicit revision information incident के दौरान कई दिनों का अनुमान बचा सकती है।

Test करने लायक failure है: नए server के सामने पुराना plan

नए server के सामने fresh client बताता है कि नया schema valid है। यह drift के बारे में कुछ नहीं बताता। आपको ऐसा test चाहिए जिसमें client snapshot ले, server बदले और फिर snapshot से बनी calls चलाई जाएँ।

Test को दो server fixtures के आसपास बनाएँ। Fixture A पुरानी tool definition दिखाए। Fixture B नई definition दिखाए और यह नियंत्रित करे कि वह पुराने arguments के साथ क्या करेगा। Handoff के दौरान client connected रहे। यदि server restart के बिना behavior नहीं बदल सकता, तो timing को deployment system से दोहराने के बजाय tool registry के पीछे deterministic test switch रखें।

यह न्यूनतम उपयोगी transcript है:

1. Client initializes and receives tools.listChanged capability.
2. Client calls tools/list and stores deploy_preview revision 1.
3. Client prepares arguments: {"branch":"fix-login"}.
4. Server switches to revision 2, where region is required for new clients.
5. Server emits notifications/tools/list_changed.
6. Client sends the already prepared revision 1 call.
7. Client refreshes tools/list.
8. Client retries only if its repair policy permits it.
9. Client calls revision 2 with {"branch":"fix-login","region":"us-east-preview"}.

Test में केवल success या failure न देखें। वास्तविक JSON-RPC messages, server के normalized arguments, external-effect stub calls और client का event log capture करें। यदि server साफ error लौटाता है लेकिन external deployment पहले ही शुरू कर चुका है, तो test विफल है।

Append-only request log वाले fake downstream service का उपयोग करें। वह method, path, authorization के लिए महत्वपूर्ण headers, request body और test correlation ID दर्ज करे। फिर assert करें कि stale call को fail closed होना चाहिए था तो उसने downstream request नहीं की।

एक compact table expected behavior की समीक्षा आसान बनाती है:

केवल happy retry test न करें। Agents retries में अच्छे होते हैं और इसी वजह से खराब migration को बढ़ा सकते हैं। Repeated stale calls, queue में call आने के बाद पहुँचा notification, विफल refresh और transition के बीच reconnect करने वाले client को test करें।

In-flight tool call कठिन स्थिति है। Server को हर call एक coherent contract revision के अनुसार execute करना चाहिए। Revision 1 के तहत validation शुरू करके configuration reload और revision 2 के तहत downstream request न बनाएँ। Call admission पर handler configuration का snapshot लें। यदि operation इतना लंबा चल सकता है कि target contract ही बदल जाए, तो durable job दिखाएँ या irreversible phase से पहले call reject करें। एक action में दो revisions को न मिलाएँ।

Client repair logic को retries के चारों ओर सीमा चाहिए

जब server stale request reject करता है, तो client के पास कई विकल्प हैं: refresh करना, model से arguments repair कराना, mapped request के साथ retry करना या user input के लिए रुकना। सही विकल्प इस बात पर निर्भर करता है कि बदलाव केवल syntax पर असर डालता है या action की authority पर भी।

Automatically refresh और retry तभी करें जब ये सभी बातें सही हों:

• Server स्पष्ट रूप से obsolete schema revision या missing field बताता हो।
• Refreshed tool definition unambiguous, non-sensitive default या deterministic mapping देती हो।
• Original action उसी target और permission boundary के भीतर रहती हो।
• पहली कोशिश से कोई external side effect न हुआ हो।

बाकी हर स्थिति में नया निर्णय चाहिए। यदि revision environment, account_id, repository, host, user या confirmation text जोड़ता है, तो automatic retry action को व्यापक या अलग target पर भेज सकता है। Model संभावित उत्तर का अनुमान लगा सके तब भी उसे नया context या human approval लेना चाहिए।

Request identity को retry identity से अलग रखें। यदि client को response मिलने से पहले tool call external system तक पहुँच सकती है, तो schema refresh के बाद उसे अंधाधुंध दोबारा न भेजें। Downstream API support करे तो idempotency token इस्तेमाल करें। SSH में generic idempotency mechanism उपलब्ध नहीं होता, इसलिए commands को इस तरह बनाएँ कि दोबारा चलना सुरक्षित हो या पहचाना जा सके। Schema migration यह पता लगाने का खराब समय है कि timeout duplicate work बनाता है।

अच्छा client error model को जानकारी देता है, लेकिन उसे झूठा instruction नहीं देता। उदाहरण के लिए:

{
  "isError": true,
  "content": [
    {
      "type": "text",
      "text": "deploy_preview rejected this request because its input contract changed. Refresh tools before retrying. The current schema requires branch and region. No deployment was started."
    }
  ],
  "structuredContent": {
    "error_code": "STALE_TOOL_SCHEMA",
    "tool": "deploy_preview",
    "required_action": "refresh_tools",
    "side_effect_started": false,
    "current_revision": 2
  }
}

Exact error envelope आपका design है, लेकिन facts optional नहीं हैं। बताएँ कि effect शुरू हुआ या नहीं, refresh मदद कर सकता है या नहीं और server revisions दिखाता हो तो current revision क्या है। Model इन facts का उपयोग कर सकता है। Generic transport error नहीं कर सकता।

Schema validation problem को transport failure न कहें। MCP specification protocol-level failures और tool execution failures में अंतर करती है। मौजूदा guidance invalid tool input के लिए tool execution errors को प्राथमिकता देती है, ताकि model self-correct कर सके। इस अंतर का उपयोग करें। Unknown JSON-RPC method और stale arguments reject करने वाला known tool एक ही घटना नहीं हैं।

Security review में केवल secrets नहीं, meaning भी देखें

Schema drift security issue तब बनता है जब पुराना description संकेत के रूप में नए action को authorize करने लगे। यह defaults, renamed fields, added scopes और जरूरत से अधिक helpful server adapters के जरिए होता है।

मान लें run_report नाम का tool पहले { "team": "sales" } लेता था। Server बदलकर ऐसा target string स्वीकार करता है जो team, saved report या raw query का नाम हो सकता है। पुराना agent अब भी team भेजता है। यदि adapter उसे target: "sales" में बदल दे, तो उसने क्या authorize किया? Team, sales नाम की report या query alias? Server ने action boundary पर ambiguity पैदा कर दी है। इसे reject करें और अलग tool या स्पष्ट migration path publish करें।

Credentials risk बढ़ाते हैं। API keys सीधे रखने वाला agent अपने process और logs में schema repair को secret handling के साथ मिला सकता है। इससे stale plan को नुकसान पहुँचाने की अधिक गुंजाइश मिलती है। Sallyport HTTP और SSH credentials को अपने encrypted vault में रखता है और credential agent को सौंपने के बजाय action execute करता है। इससे बदला हुआ tool contract अपने आप सुरक्षित नहीं हो जाता, लेकिन वास्तविक request, authorization point और audit record की जाँच आसान होती है।

Approval उस concrete action से जुड़ी होनी चाहिए जो अभी होने वाली है, किसी पुराने tool description से नहीं। यदि tool एक host से flexible host selector में बदलता है, तो पहले की code identity पर आधारित per-session approval नए target के लिए पर्याप्त नहीं है। Sensitive action के लिए fresh per-call approval माँगें या नया tool name इस्तेमाल करें जो बढ़ी हुई authority को स्पष्ट करे।

यहीं audit records उपयोगी साबित होते हैं। Tool name, उपलब्ध होने पर declared schema revision, प्राप्त raw arguments, उपयोग किए गए normalized arguments, server build या handler revision, approval decision और downstream target दर्ज करें। Raw arguments को normalized ones से overwrite न करें। Incident के दौरान आपको देखना होगा कि client ने पुराना shape भेजा या नहीं, adapter ने उसे बदला या नहीं और external request adapter के वादे से मेल खाती थी या नहीं।

Sallyport का activity journal और sessions journal agent run को individual external calls से अलग देखने के अच्छे उदाहरण हैं। Drift tests के लिए दोनों views चाहिए: एक record कि run authorized था और दूसरा हर HTTP या SSH action का, जिसने machine छोड़ी या नहीं छोड़ी।

Compatibility windows इस्तेमाल करें, फिर जानबूझकर हटाएँ

Backward compatibility की end date होनी चाहिए, भले ही वह calendar के बजाय release train या session lifetime से जुड़ी हो। वरना हर obsolete input mapper हमेशा बना रहेगा और server ऐसी assumptions का संग्रह बन जाएगा जिन्हें कोई सुरक्षित रूप से edit नहीं कर सकता।

पहले change को classify करें।

Additive change पुराने call को valid रखता है और उसका meaning बचाता है। वही tool name रखें, list change announce करें और active sessions के समाप्त होने तक दोनों shapes स्वीकार करें।

Constrained migration syntax बदलता है, लेकिन safe deterministic mapping देता है। Tool name तभी रखें जब mapper को पूरी तरह test कर सकें और उसके उपयोग का log रख सकें। नए clients को current schema बताएँ और थोड़ी अवधि तक ही पुराना input स्वीकार करें।

Semantic या authority change के लिए नया tool name चाहिए। deploy_preview और deploy_environment implementation साझा कर सकते हैं, लेकिन contract साझा नहीं करना चाहिए यदि एक ज्ञात preview destination चुनता है और दूसरा production चुन सकता है। Tool list कुछ लंबी लगेगी, फिर भी यह उस agent से सस्ता है जो मानता है कि उसने संकीर्ण operation call किया था।

Removal को साफ तौर पर fail होना चाहिए। Replacement tool का नाम बताने वाला execution error लौटाएँ या कहें कि capability समाप्त हो गई है। ऐसा tool name बनाए न रखें जो कुछ नहीं करता। Automated work में silent success poison की तरह है, क्योंकि agent completion दर्ज कर लेता है जबकि इच्छित effect हुआ ही नहीं।

Adapter हटाने का समय तय करने के लिए telemetry इस्तेमाल करें, लेकिन केवल aggregate success counts न जुटाएँ। हर पुराने revision से normalized calls, rejected stale calls, automatic client repairs और human intervention वाली calls गिनें। पुराने input की मात्रा कम हो सकती है, फिर भी वह सबसे लंबे या सबसे privileged agent jobs से आ सकता है।

Removal से पहले drift test उलटे क्रम में चलाएँ: old version वाला client शुरू करें, server को compatibility window से आगे update करें और पुष्टि करें कि failure स्पष्ट, side-effect free और reconnect या tool refresh से recoverable है। शांत reinterpretation से साफ break बेहतर है।

ऐसा release gate जो users से पहले drift पकड़ ले

हर action-capable MCP server के release gate में schema drift शामिल करें। पहले दिन बहुत बड़ा matrix बनाने की जरूरत नहीं है। हर contract change class के लिए एक disciplined fixture पर्याप्त है।

हर बदले हुए tool के लिए pull request या release review में इन सवालों के उत्तर दें:

1. क्या existing session अब भी पिछले valid arguments submit कर सकता है?
2. यदि हाँ, तो क्या उन arguments का action meaning बिल्कुल वही है?
3. यदि नहीं, तो क्या rejection किसी external effect से पहले होता है?
4. क्या server notifications/tools/list_changed तभी emit करता है जब replacement list उपलब्ध हो?
5. क्या client missing authority का आविष्कार किए बिना repair path समझा सकता है?

फिर इन answers को executable बनाएँ। पुराने और नए tools/list fixtures test के साथ रखें। Sequence को old client snapshot के साथ चलाएँ। केवल MCP responses नहीं, downstream requests भी validate करें। Migration के बाद regression fixture रखें, क्योंकि अगला refactor compatibility branch हटा सकता है और किसी को याद नहीं रहेगा कि वह क्यों थी।

सबसे पहले एक बेहद छोटा test जोड़ें: tool list करें, एक required parameter बदलें, पुरानी call भेजें और साबित करें कि server या तो पुराना सुरक्षित behavior बनाए रखता है या कुछ भी नहीं करता। यह test उस सवाल को सामने लाता है जिससे अधिकांश deployments बचते हैं: tool को अपने नीचे बदलने के बाद पहले से चल रहे agent को वास्तव में किस अर्थ की अनुमति है?