تحول مطورو تطبيقات تحويل اللغة الطبيعية إلى استعلامات قواعد بيانات SQL من النماذج أحادية الوكيل إلى بنية متعددة الوكلاء لمعالجة قيود الأداء المعروفة في السيناريوهات المعقدة. أظهرت الاختبارات الميدانية أن الاعتماد على نموذج واحد لإتمام جميع المراحل يؤدي إلى تدهور الدقة مع زيادة تعقيد الطلبات، حيث يحاول الوكيل الواحد تحليل النوايا، ومطابقة المخطط، وتوليد الكود، ومراجعة المخرجات في نافذة سياق واحدة، مما يسبب تضارباً داخلياً وتكراراً للتعديلات غير الفعالة بعد محاولات الإعادة. لحل هذه المعضلة، اعتمد النظام الجديد بنية موزعة تشمل وكلاء متخصصين لكل مرحلة عمل. يتولى وكيل تحليل النوايا تفكيك السؤال إلى مهام تحليلية منفصلة بدقة، بينما يركز وكيل المخطط على ربط هذه المهام بجداول وأعمدة قاعدة البيانات الفعلية لتجنب الهلاوس. يقوم وكيل بناء الاستعلام بتحويل البيانات المطابقة إلى كود SQL دقيق، ويخضع الناتج لوكيل مراجعة نقدية مستقل يفحص الدلالة المنطقية والشروط الزمنية قبل الاعتماد النهائي. يعمل مواءم محدد مسبقاً على توجيه تدفق البيانات بين هذه المكونات دون الاعتماد على ذكاء اصطناعي في اتخاذ قرارات التوجيه الثابتة، مما يضمن سرعة وثبات المعالجة. تُدار عملية التنسيق عبر إطار عمل LangGraph الذي يوفر تحكماً صريحاً في حالة النظام وتدفق البيانات بين العقد البرمجية. تتضمن بنية الحالة حقلاً مخصصاً لتتبع مصدر الفشل، مما يسهل التشخيص السريع عند رفض الاستعلام. تعتمد آلية الإعادة على تزويد وكيل البناء بملاحظات المراجعة النقدية مباشرة بدلاً من إعادة التشغيل بالصفر، مما يضمن تحسين المحاولة التالية فعلياً. يُفرض حد أقصى لمحاولات الإعادة يمنع الحلقات اللانهائية ويضمن عرض أفضل نتيجة متاحة عند تجاوز العتبة، مع حفظ البيانات لمراجعتها لاحقاً. تبرز تجربة النشر الفعلي عدة تحديات إنتاجية تستدعي الانتباه. يؤدي تمرير الحالة الكاملة بين الوكلاء إلى تسرب سياق قد يخفي أخطاء التحليل المبكرة حتى تصل لمرحلة المراجعة دون تصحيح جذري. كما يتطلب التعامل مع المخططات الضخمة اعتماد استرجاع قائم على البحث المتجهي لحد حجم السياق ومنع إرباك النموذج. تزداد تكاليف الرموز بشكل مضطرد نظراً لتنفيذ طلبات متعددة وتسلسلية، مما يستدعي استخدام نماذج أخف للمهام التقييمية، بالإضافة إلى ضرورة تغليف عمليات تحليل النصوص ببنية JSON بأوامر معالجة أخطاء تمنع انهيار النظام عند مخرجات غير متوافقة. يؤكد الخبراء أن هذه البنية المتعددة الوكلاء ليست حلاً شاملاً لكل السيناريوهات. تفوق النماذج أحادية الوكيل ذات التوجيه الجيد الأداء في النطاقات البسيطة من حيث التكلفة وزمن الاستجابة وقابلية الصيانة. لذلك، تُوصي الممارسات المعتمدة بالبدء بتصميم وكيل واحد مركزي واختباره ضد الأحمال الحقيقية، ثم إدخال التخصص التدريجي عند ظهور حدود واضحة لا يمكن تجاوزها بتحسين المطالبات النصية. يضمن هذا المسار بناء بنية قابلة للتطوير مع الحفاظ على الشفافية التشغيلية وقابلية التتبع عند الأعطال الطارئة في بيئات الإنتاج.