🤖 AI

When Does Restricting a Coding Agent to execute_code Help? A Regime $\times$ Agent-Design Ablation

यह शोध पत्र प्रदर्शित करता है कि कोडिंग एजेंटों को केवल एक `execute_code` टूल तक सीमित रखना अक्सर टूल-समृद्ध वातावरण का उपयोग करने जितना ही प्रभावी और अक्सर उससे सस्ता होता है, जो यह प्रकट करता है कि इष्टतम टूल सतह (tool surface) अकेले किसी भी कारक के बजाय कार्य व्यवस्था (task regimes) और विशिष्ट एजेंट डिज़ाइनों के बीच परस्पर क्रिया द्वारा संयुक्त रूप से निर्धारित होती है।

मूल लेखक: Hong Yang, Qi Yu, Travis Desell

प्रकाशित 2026-07-14

📖 7 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Hong Yang, Qi Yu, Travis Desell

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आपके पास एक सुपर-स्मार्ट रोबोट असिस्टेंट है जिसका काम टूटे हुए कोड को ठीक करना या गणित की पहेलियाँ सुलझाना है। अभी, टेक की दुनिया में इस बात पर एक बड़ी बहस चल रही है कि यह रोबोट काम पूरा करने के लिए कंप्यूटर से कैसे बात करना चाहिए।

कुछ लोग कहते हैं, "इसे एक पूरा टूलबॉक्स दें जिसमें हर काम के लिए विशेष बटन हों!" (एक फैंसी IDE की तरह)।
दूसरे कहते हैं, "बस इसे एक कमांड लाइन दे दें और इसे शेल कमांड टाइप करने दें!" (एक फिल्म के हैकर की तरह)।
तीसरा समूह कहता है, "नहीं! बस रोबोट को एक पायथन स्क्रिप्ट लिखने दें और उसे एक साथ चलाने दें!" (execute_code वाला तरीका)।

यह पेपर एक विशाल, निष्पक्ष रेफरी की तरह है जो यह देखने के लिए एक दौड़ आयोजित करता है कि कौन सा तरीका वास्तव में पैसा बचाता है और काम को सफलतापूर्वक पूरा करता है। उन्होंने केवल अनुमान नहीं लगाया; उन्होंने बिल्कुल एक ही रोबोट (दो अलग-अलग मॉडल: क्लॉड और कोडेक्स) को बिल्कुल एक ही कार्यों पर चलाया, लेकिन केवल उन उपकरणों को बदल दिया जिनका उपयोग करने की उन्हें अनुमति थी।

यहाँ उन्हें क्या मिला, जिसे सरल कहानियों में तोड़कर बताया गया है।

मुख्य खोज: यह रोबोट और काम पर निर्भर करता है

सबसे बड़ा आश्चर्य? कोई एक "सर्वश्रेष्ठ" टूल नहीं है। विजेता इस बात पर बदल जाता है कि रोबोट कौन है और वह क्या कर रहा है।

इसे इस तरह सोचें:

"गणित की पहेली" वाला काम (आर्टिफैक्ट टास्क): यदि रोबोट गणना या डेटा क्रंचिंग कर रहा है, तो "एक स्क्रिप्ट लिखें और उसे चलाएं" वाला तरीका स्पष्ट विजेता है। यह एक ऐसे शेफ को काम पर रखने जैसा है जो बस एक आदर्श रेसिपी लिखता है और एक बार में पूरा भोजन तैयार करता है।
- Claude रोबोट के लिए, इस तरीके ने लागत में 24.6% की बचत की।
- Codex रोबोट के लिए, इसने लगभग 6.7% की बचत की (हालांकि पेपर कहता है कि यह थोड़ा संदिग्ध है, जैसे कि एक सिक्के का उछाल)।
- निर्णय: गणित और डेटा के लिए, स्क्रिप्ट वाला तरीका सस्ता है और समस्या को हल करने में उतना ही अच्छा है।
"एक अव्यवस्थित कोडबेस को ठीक करने" वाला काम (SWE-bench टास्क): यह वह जगह है जहाँ चीजें पेचीदा हो जाती हैं। इन कार्यों में एक जटिल प्रोजेक्ट में कई फाइलों को संपादित करना शामिल है।
- यदि आप Codex रोबोट का उपयोग करते हैं: स्क्रिप्ट वाला तरीका अभी भी चैंपियन है! इसने लागत में 19.9% की बचत की। क्यों? क्योंकि स्क्रिप्ट वाला तरीका रोबोट को कई छोटे अनुरोधों को एक बड़े पैकेज में समेटने की अनुमति देता है, जैसे कि 50 बार पैदल चलने के बजाय एक डिलीवरी ट्रक द्वारा 50 पैकेज ले जाना।
- यदि आप Claude रोबोट का उपयोग करते हैं: ओह! स्क्रिप्ट वाला तरीका वास्तव में अधिक महंगा ( 14.4% अधिक) हो गया, हालांकि पेपर नोट करता है कि यह एक सांख्यिकीय रूप से "सिद्ध" अंतर नहीं था, बस एक मजबूत रुझान था। क्यों? क्योंकि Claude के लिए, एक फ़ाइल को संपादित करने के लिए स्क्रिप्ट लिखना एक कार बदलने के लिए पहले नई कार बनाने की कोशिश करने जैसा है। इसमें बदलाव को कोड में समझाने के लिए बहुत अधिक शब्दों (टोकन) की आवश्यकता होती है, जिससे "एडिट फ्रिक्शन" (संपादन घर्षण) पैदा होता है।

यह पेपर किसे खारिज करता है

पेपर स्पष्ट रूप से इस विचार का खंडन करता है कि एक टूल हमेशा सभी के लिए बेहतर होता है।

यह खारिज करता है: "विशेष IDE बटन हमेशा आवश्यक होते हैं।" (क्योंकि स्क्रिप्ट विधि Codex पर जीती)।
यह खारिज करता है: "Bash कमांड हमेशा पर्याप्त होते हैं।" (क्योंकि गणित कार्यों के लिए Claude के लिए स्क्रिप्ट विधि सस्ती थी)।
यह खारिज करता है: "कोड निष्पादन (Code execution) हमेशा सबसे सस्ता होता है।" (क्योंकि जटिल कोड सुधारों के लिए यह Claude के लिए अधिक महंगा था)।

लेखक बहुत स्पष्ट हैं: आप केवल टूल के आधार पर टूल नहीं चुन सकते। आपको रोबोट के दिमाग और काम के प्रकार के संयोजन को देखना होगा।

"पास रेट" का आश्चर्य

यहाँ सबसे महत्वपूर्ण बात है: लागत बदल गई, लेकिन सफलता दर नहीं।

दो धावकों की कल्पना करें। एक भारी जूतों में दौड़ता है (महंगे उपकरण), और दूसरा स्नीकर्स में दौड़ता है (सस्ते उपकरण)। पेपर ने पाया कि दोनों धावक बिल्कुल एक ही गति से दौड़ पूरी करते हैं।

चाहे रोबोट ने फैंसी टूलबॉक्स का उपयोग किया हो, Bash कमांड का, या स्क्रिप्ट विधि का, उनके द्वारा सही ढंग से हल किए गए कार्यों का प्रतिशत लगभग समान था ( 3 प्रतिशत अंक के भीतर)।
"स्क्रिप्ट" विधि ने रोबोट को स्मार्ट या मूर्ख नहीं बनाया; इसने बस फिनिश लाइन तक पहुँचने के उसके तरीके को बदल दिया। कभी-कभी वह चलना एक स्प्रिंट (सस्ता) था, और कभी-कभी वह लड़खड़ाहट (महंगा) था।

लागत क्यों बदली?

पेपर इस बात की गहराई में जाता है कि स्क्रिप्ट विधि सस्ती या महंगी क्यों थी।

"एडिट फ्रिक्शन" टैक्स (Claude के लिए): जब Claude को एक फ़ाइल को ठीक करने के लिए स्क्रिप्ट विधि का उपयोग करना पड़ा, तो उसे केवल "लाइन 5 बदलें" कहने के लिए एक लंबी पायथन स्क्रिप्ट लिखनी पड़ी। इसने बहुत सारे "आउटपुट टोकन" (शब्द जो रोबोट को टाइप करने थे) का उपयोग किया। यह हर बार पेज पलटने के लिए टोल देने जैसा था। यह ज्यादातर उन कार्यों पर हुआ जहाँ रोबोट विफल हुआ या संघर्ष कर रहा था, जिससे वे विशिष्ट रन बहुत महंगे हो गए।
"बैचिंग" बोनस (Codex के लिए): जब Codex ने स्क्रिप्ट विधि का उपयोग किया, तो वह एक स्क्रिप्ट में कई छोटे कमांड पैक कर सका। कंप्यूटर से "फ़ाइल A पढ़ें," फिर "फ़ाइल B पढ़ें," फिर "फ़ाइल C पढ़ें" (तीन अलग-अलग यात्राएं) पूछने के बजाय, उसने एक बार में "A, B और C पढ़ें" पूछा। इसने बहुत सारे "इनपुट टोकन" (शब्द जो रोबोट को पढ़ने थे) की बचत की।
"डूम्ड रन" (विफल रन) प्रभाव: कोड-फिक्सिंग कार्यों पर Claude के लिए अतिरिक्त लागत मुख्य रूप से तब हुई जब रोबोट पहले से ही विफल होने वाला था। यह एक कार के चक्कर काटते समय ईंधन खत्म होने जैसा था। स्क्रिप्ट विधि ने विफलता का कारण नहीं बनाया; इसने केवल असफल प्रयास को अधिक महंगा बना दिया।

हम कितने आश्वस्त हैं?

लेखक गणित कार्यों और Codex रोबोट परिणामों के बारे में बहुत आश्वस्त हैं। उन्होंने इन परीक्षणों को 93 गणित कार्यों और 100 कोड-फिक्सिंग कार्यों पर चलाया, प्रत्येक के लिए तीन "सीड्स" (रैंडम शुरुआती बिंदु) का उपयोग किया ताकि यह सुनिश्चित हो सके कि परिणाम केवल भाग्य नहीं थे। कोड-फिक्सिंग कार्यों पर Codex के लिए बचत सांख्यिकीय रूप से महत्वपूर्ण थी (एक 19.9% की गिरावट, p-वैल्यू 2.0 × 10⁻⁹ के साथ, जो मूल रूप से रैंडम होने की शून्य संभावना है)।

हालाँकि, कोड-फिक्सिंग कार्यों पर Claude रोबोट के लिए, परिणाम थोड़ा धुंधला है। लागत 14.4% बढ़ गई, लेकिन सांख्यिकीय परीक्षण ने कहा कि यह एक "स्लैम डंक" प्रमाण नहीं था (p-वैल्यू 0.12)। लेखक इसे "दिशात्मक" कहते हैं, जिसका अर्थ है कि रुझान मौजूद है, लेकिन उन्हें 100% सुनिश्चित होने के लिए इसे और अधिक बार चलाने की आवश्यकता होगी कि यह कोई इत्तेफाक नहीं है।

निचोड़

यदि आप एक कोडिंग एजेंट बना रहे हैं:

अनुमान न लगाएं। "सर्वश्रेष्ठ" टूल आपके विशिष्ट रोबोट और आपके विशिष्ट कार्य पर निर्भर करता है।
गणित/डेटा के लिए: "स्क्रिप्ट लिखें" विधि को आजमाएं। यह सस्ता है और उतना ही अच्छा काम करता है।
कोड सुधार के लिए: यह निर्भर करता है। यदि आप Codex का उपयोग करते हैं, तो स्क्रिप्ट विधि बेहतरीन है। यदि आप Claude का उपयोग करते हैं, तो आप मानक संपादन उपकरणों को बनाए रखना चाह सकते हैं, विशेष रूप से कठिन समस्याओं के लिए, क्योंकि स्क्रिप्ट विधि "एडिट फ्रिक्शन" में फंस सकती है।
बुद्धिमत्ता की चिंता न करें: टूल्स को बदलने से आपका रोबोट स्मार्ट या मूर्ख नहीं बनेगा; यह केवल यात्रा के मूल्य टैग को बदल देगा।

पेपर निष्कर्ष निकालता है कि एजेंट चलाने का "सबसे सस्ता" तरीका एक सार्वभौमिक नियम नहीं है; यह एक पहेली है जहाँ आपको टूल को रोबोट और कार्य के साथ मिलाना होता है।

तकनीकी सारांश: कोडिंग एजेंट को `execute_code` तक सीमित करने से कब मदद मिलती है?

समस्या विवरण

कोडिंग एजेंटों का क्षेत्र वर्तमान में एक "टूल सरफेस" (एजेंट को दिए गए इंटरफेस का सेट) के इष्टतम होने के संबंध में तीन परस्पर असंगत दावों के तहत कार्य कर रहा है:

विशेषज्ञ IDE प्रिमिटिव्स (Primitives) आवश्यक हैं: संरचित इंटरफेस (जैसे एजेन्ट-कंप्यूटर इंटरफेस या ACI) कच्चे शेल एक्सेस की तुलना में काफी बेहतर प्रदर्शन करते हैं, जैसा कि SWE-agent द्वारा तर्क दिया गया है।
Bash पर्याप्त है: न्यूनतम bash-only स्कैफोल्ड्स बिना IDE प्रिमिटिव्स के सॉफ्टवेयर इंजीनियरिंग बेंचमार्क पर प्रतिस्पर्धी प्रदर्शन प्राप्त कर सकते हैं।
कोड निष्पादन (Code Execution) इष्टतम है: मॉडल कॉन्टेक्स्ट प्रोटोकॉल (MCP) के माध्यम से एजेंट कार्यों को एक एकल execute_code टूल के माध्यम से रूट करने से सीधे नेटिव टूल्स को कॉल करने की तुलना में टोकन का उपयोग काफी कम हो जाता है।

पूर्व के कार्यों ने इन विरोधाभासों को हल करने में विफलता दिखाई है क्योंकि मौजूदा अध्ययन एक एकल चर (जैसे एक विशिष्ट मॉडल पर ACI बनाम शेल की तुलना करना) को फिक्स करते हैं, बिना टास्क रिजीम (कंप्यूटेशन बनाम कोड मॉडिफिकेशन) और एजेंट डिजाइन (अलग-अलग मॉडल परिवार) को क्रॉस किए। फलस्वरूप, क्षेत्र के पास इस बात की एकीकृत समझ की कमी है कि किन स्थितियों में कौन सा टूल सरफेस अनुकूल होता है।

कार्यप्रणाली (Methodology)

लेखक एक "मिसिंग क्रॉस्ड कंपैरिजन" (missing crossed comparison) आयोजित करते हैं जो एक इंटीग्रिटी-क्लीन, थ्री-आर्म एब्लेशन स्टडी है। प्रायोगिक डिजाइन एक $3 \times 2 \times 2$ फैक्टोरियल स्ट्रक्चर है:

तीन टूल सरफेस:
- बेसलाइन (Baseline): एजेंट का डिफॉल्ट टूल सरफेस (जैसे Read, Grep, Edit, Write, Bash)।
- Bash_Only: केवल नेटिव bash और रीड-ओनली ब्राउजिंग (Read, Glob, Grep) तक सीमित; सभी फाइल-एडिटिंग प्रिमिटिव्स (Edit, Write) हटा दिए गए हैं।
- Code_Only: संपूर्ण नेटिव सरफेस को एक एकल MCP टूल (mcp__codebox__execute_code) द्वारा बदल दिया गया है जो एक पर्सिस्टेंट Python+Bash REPL चलाता है। सभी नेटिव बिल्ट-इन्स को प्रतिबंधित कर दिया गया है।
दो एजेंट: Claude Code (मॉडल claude-sonnet-4-6) और OpenAI Codex CLI (मॉडल gpt-5.5)।
दो टास्क रिजीम (Task Regimes):
- कंप्यूटेशन (Computation): एक नया "आर्टिफैक्ट" (Artifact) सूट ( $n=93$ ) जिसमें एक वर्कस्पेस, हिडन ग्रेडर और रेफरेंस आउटपुट से परिभाषित स्व-निहित कार्य शामिल हैं।
- मॉडिफिकेशन (Modification): SWE-bench Mini ( $n=100$ ), जो रिपॉजिटरी मॉडिफिकेशन कार्यों का एक क्यूरेटेड सबसेट है।

प्रायोगिक नियंत्रण (Experimental Controls):

इंटीग्रिटी (Integrity): हार्नेस एक सख्त SWE-bench प्रोटोकॉल लागू करता है जहाँ टेस्ट पैच एजेंट के समाप्त होने के बाद लागू किए जाते हैं। क्रॉस-कंटैमिनेशन को रोकने के लिए fuse-overlayfs का उपयोग करके आर्म्स के बीच फाइल सिस्टम स्टेट्स को आइसोलेट किया गया है।
लागत लेखांकन (Cost Accounting): सर्वर-साइड प्रॉम्प्ट कैशिंग परिवर्तनशीलता को संबोधित करने के लिए, लेखक एक "कैश-एडजस्टेड कॉस्ट" मीट्रिक का उपयोग करते हैं। यह पहले टर्न के इनपुट टोकन पर एक मीडियन-फ्लोर एडजस्टमेंट लागू करता है, जो पूर्ण कैश आइसोलेशन का दावा किए बिना "वॉर्म/कोल्ड" कैश लॉटरी को सामान्य बनाता है।
सांख्यिकीय कठोरता (Statistical Rigor): अनुमान की इकाई कार्य (task) है, न कि सीड (seed)। परिणामों का विश्लेषण तीन स्वतंत्र सीड्स के माध्यम से प्रति-कार्य अंतर पर पेयर्ड विल्कोक्सन साइन्ड-रैंक टेस्ट का उपयोग करके किया जाता है।

मुख्य योगदान

1. एक फोर-सेल एजेंट-कंडीशनल कॉस्ट स्ट्रक्चर

अध्ययन प्रकट करता है कि एजेंट को execute_code तक सीमित करने की लागत-प्रभावशीलता सार्वभौमिक नहीं है, बल्कि टास्क रिजीम और एजेंट डिजाइन द्वारा संयुक्त रूप से निर्धारित होती है।

चार में से तीन सेल code_only के पक्ष में हैं:
- Artifact/Claude: महत्वपूर्ण लागत कमी ( $-24.6\%$ , $p=7.4 \times 10^{-14}$ )।
- Artifact/Codex: दिशात्मक लागत कमी ( $-6.7\%$ , महत्वपूर्ण नहीं)।
- SWE-bench/Codex: महत्वपूर्ण लागत कमी ( $-19.9\%$ , $p=2.0 \times 10^{-9}$ )।
एक सेल ट्रेंड को उलट देता है:
- SWE-bench/Claude: code_only दिशात्मक रूप से अधिक महंगा है ( $+14.4\%$ , महत्वपूर्ण नहीं)।

यह निष्कर्ष दर्शाता कि साहित्य के तीन पूर्ववर्ती दावे विरोधाभासी नहीं हैं, बल्कि वे विशिष्ट (रिजीम, एजेंट) संयोजनों के तहत ही सत्य हैं।

2. थ्री-मैकेनिज्म कॉज़ल डिकंपोज़िशन (Three-Mechanism Causal Decomposition)

लेखक देखे गए लागत अंतरों को तीन अलग-अलग तंत्रों में विभाजित करते हैं:

पाथ-कॉस्ट (Edit Friction): SWE-bench के लिए Claude पर, code_only प्रत्येक फाइल एडिट को पायथन स्क्रिप्ट के रूप में व्यक्त करने के लिए मजबूर करता है। यह एडिट वॉल्यूम के साथ आउटपुट टोकन को स्केल करता (Spearman $\rho=0.488$ ), जिससे उच्च-एडिट कार्यों पर एक "टैक्स" लग जाता है।
फेलियर-कॉस्ट (Failure-Cost): Claude के लिए SWE-bench पर लागत ओवररन "डूम्ड-रन" (doomed-run) ट्रेजेक्टरीज (ऐसे उदाहरण जहाँ सभी आर्म्स विफल हो जाते हैं) तक सीमित है। उन उपसमूहों पर जहाँ सर्वसम्मति से पास होने वाले परिणाम मिले, लागत अंतर $+14.4\%$ से घटकर $+4.1\%$ (महत्वपूर्ण नहीं) रह गया।
प्राइसिंग एसिमेट्री (बैचिंग): SWE-bench के लिए Codex पर, code_only मुख्य रूप से इनपुट टोकन में कमी ( $-24.8\%$ ) के माध्यम से महत्वपूर्ण बचत प्राप्त करता है। यह टूल-कॉल बैचिंग (एक पायथन स्क्रिप्ट कई नेटिव टूल कॉल्स की जगह लेती है) और प्रोग्रामेटिक आउटपुट सप्रेशन (एजेंट आउटपुट वॉल्यूम को नियंत्रित करता है, जिससे नेटिव टूल्स की हार्ड आउटपुट कैप्स से बचा जा सकता है) द्वारा संचालित है।

3. क्षमता अपरिवर्तनीयता (Capability Invariance)

सभी चार सेल और तीन टूल सरफेस केAcross, पास रेट्स सांख्यिकीय रूप से समान (tied) हैं (अंतर $<3$ प्रतिशत अंक, सभी महत्वपूर्ण नहीं)।

एग्रीमेंट मैट्रिक्स दिखाता है कि अधिकांश उदाहरणों ( $\ge 91\%$ बहुमत वोट के तहत) के लिए, सभी आर्म्स या तो एक साथ पास होते हैं या विफल होते हैं।
यह पुष्टि करता है कि टूल सरफेस का चयन कार्य को हल करने की पथ और लागत को बदलता है, लेकिन इसे हल करने की क्षमता को नहीं, जो "कैपेबिलिटी ओवरलैप प्रिंसिपल" के अनुरूप है।

परिणामों का सारांश

पेपर code_only कब फायदेमंद है, इसका एक "एट-ए-ग्लांस" मैप प्रदान करता है:

कंप्यूटेशन टास्क (Artifact): execute_code तक सीमित करना दोनों एजेंटों के लिए सस्ता है, जिसमें Claude के लिए महत्वपूर्ण जीत है।
मॉडिफिकेशन टास्क (SWE-bench) Codex के साथ: इनपुट टोकन बैचिंग और आउटपुट कंट्रोल के कारण execute_code तक सीमित करना काफी सस्ता है।
मॉडिफिकेशन टास्क (SWE-bench) Claude के साथ: code_only दिशात्मक रूप से अधिक महंगा है। यह "एडिट फ्रिक्शन" (एडिट्स के लिए उच्च आउटपुट टोकन) और "फेलियर कॉस्ट" (महंगे विफल ट्रेजेक्टरीज) द्वारा संचालित है, न कि सफल एडिट्स पर दंड के कारण।

महत्व और दावे

पेपर यह दावा करता है कि यह क्षेत्र के "तीन विरोधाभासी दावों" को यह प्रदर्शित करके हल करता है कि कोई भी एकल टूल सरफेस सभी संदर्भों में इष्टतम नहीं है।

लागत बनाम क्षमता (Cost vs. Capability): टूल सरफेस चयन का मुख्य संकेत लागत है, न कि पास रेट। चूंकि पास रेट अपरिवर्तनीय हैं, इसलिए टूल सरफेस का चुनाव एक क्षमता वृद्धि के बजाय एक लागत-इंजीनियरिंग निर्णय है।
संयुक्त निर्धारण (Joint Determination): इष्टतम सरफेस टास्क रिजीम (कंप्यूटेशन बनाम मॉडिफिकेशन) और विशिष्ट एजेंट के कार्यान्वयन (यह बैचिंग, आउटपुट कैप्स और एडिट प्रिमिटिव्स को कैसे संभालता है) के प्रतिच्छेदन द्वारा निर्धारित होता है।
अनुभवजन्य प्रमाण (Empirical Receipt): अध्ययन कोडिंग एजेंटों में पहले "टूल-यूज़ टैक्स" असमानता का अनुभवजन्य प्रमाण प्रदान करता है: एक टूल सरफेस केवल तभी शुद्ध लाभ देता है जब उसकी कार्य-विशिष्ट क्षमता लाभ उसके परिभाषा के प्रति-कॉल लागत से अधिक हो।

लेखक स्पष्ट रूप से कहते हैं कि उनके निष्कर्ष लागत-इंजीनियरिंग दावे हैं, न कि क्षमता के दावे। वे यह प्रस्ताव नहीं देते कि code_only सार्वभौमिक रूप से बेहतर है, न ही वे दावा करते हैं कि उनके परिणाम बिना और सत्यापन के सभी मॉडलों या बाहरी MCP टूल्स पर सामान्यीकृत होते हैं। महत्व उस पद्धतिगत ढांचे में निहित है जो एजेंट डिजाइन और रिजीम प्रभावों के विसंकरण (disambiguation) की अनुमति देता है, जिससे क्षेत्र उपाख्यानात्मक उद्योग रिपोर्टों से नियंत्रित, क्रॉस्ड एब्लेशन अध्ययनों की ओर बढ़ता है।