بناء عوامل ذكية (Agents) لا يزال أمرًا معقدًا رغم التقدم في مجال الذكاء الاصطناعي. على الرغم من توفر أدوات تطوير متعددة، مثل SDKs من OpenAI أو Anthropic، أو حلول أعلى مستوى مثل Vercel AI SDK أو Pydantic، إلا أن القيود تظهر بوضوح عند التطبيق العملي، خاصة عند استخدام الأدوات الحقيقية. تبين أن التفاصيل المفيدة في التصميم لا تُبنى بسهولة عبر الـ SDKs الافتراضية، لأن الاختلافات بين النماذج (مثل تصرفات التخزين المؤقت، التفاعل مع الأدوات، معالجة الأخطاء) تتطلب بنية مخصصة تُبنى من الصفر. الاختيار الأصلي لاستخدام Vercel AI SDK بقيوده المحدودة أثبت أنه غير مثالي، خصوصًا مع أدوات المزود (provider-side tools). فمثلاً، أداة البحث عبر الإنترنت من Anthropic تُدمّر تاريخ المحادثة عند استخدام Vercel SDK، دون سبب واضح. كما أن إدارة التخزين المؤقت في Anthropic تكون أكثر وضوحًا وفعالية عند التفاعل مباشرة مع SDK الخاص بهم، بينما تُصبح معقدة في البيئة المُوحّدة. التجربة أظهرت أن التحكم اليدوي في التخزين المؤقت (caching) أفضل بكثير من التخزين التلقائي. فباستخدام تخزين مُخصص بعد النص النظامي، ونقطتين في بداية المحادثة تتحركان مع تقدمها، يمكن التحكم بدقة في التكلفة وفعالية الاستخدام. كما يسمح هذا النهج بعمليات متعددة في نفس الوقت، أو تعديل السياق (context editing)، رغم أن هذه الأخيرة تُلغِي التخزين المؤقت وتزيد التكلفة. في دورة العامل، يُستخدم التغذية المرتدة (reinforcement) بشكل متكرر بعد كل أداة. لا يقتصر ذلك على إرسال النتائج، بل يشمل تذكير العامل بالهدف، توجيهه عند فشل أداة، أو إبلاغه بتغيرات خارجية (مثل بيانات تالفة). بعض الأدوات، مثل "todo write" في Claude Code، تعمل كأداة تغذية مرتدة بسيطة (echo)، لكنها تُسهم في تقدم العامل أكثر من مجرد تضمين المهام في السياق من البداية. لتجنب تراكم الأخطاء، يُفضل عزل الفشل داخل عوامل فرعية (subagents)، بحيث تُنفّذ المهام المتكررة بشكل منفصل، وتُعاد فقط النتيجة الناجحة مع ملخص للطرق الفاشلة. هذه الطريقة تُعزز التعلم، لكنها تتطلب بنية تخزين مشتركة، مثل نظام ملفات افتراضي، يسمح للعوامل المختلفة بالوصول إلى نفس البيانات (مثلاً: إنشاء صورة، ثم ضغطها في ملف ZIP، ثم تحليلها لاحقًا). هذا النظام يُعد حجر الأساس لتمكين التفاعل بين أدوات التوليد والتنفيذ. أحد التحديات المفاجئة هو تصميم أداة لإخراج الناتج النهائي. فعندما يُستخدم أداة منفصلة (output tool) لإرسال رسالة إلى المستخدم (مثلاً: بريد إلكتروني)، يصبح التحكم في الأسلوب والصيغة صعبًا مقارنةً بالكتابة المباشرة من العامل. تجربة استخدام نموذج فرعي (مثل Gemini 2.5 Flash) لتعديل النص فشلت بسبب تأخير كبير وفقدان جودة النص، وربما بسبب نقص السياق. كما أن بعض الأحيان لا تُستدعا الأداة، لذا نُضمن ذلك عبر إدخال تذكير في نهاية الدورة إذا لم تُستخدم. بالنسبة لاختيار النموذج، لا تزال نماذج Haiku وSonnet من Anthropic هي الأفضل في استدعاء الأدوات، وتوفر شفافية في التغذية المرتدة. أما في المهام الفرعية (كاستخراج معلومات من PDF أو صور)، فإن Gemini 2.5 يُظهر أداءً متميزًا، خصوصًا مع تجنب مصائد الأمان في نماذج Sonnet. ورغم أن التكلفة في الـ tokens قد تبدو أقل، فإن النموذج الأفضل يُقلل من عدد التكرارات، مما يجعله أكثر كفاءة على المدى الطويل. أصعب التحديات ما زال في الاختبار والتقييم. لا يمكن تقييم العامل كـ prompt بسيط، لأن سلوكه يعتمد على تفاعل ديناميكي مع البيئة. الحلول الحالية لا تُقنع، وتُعدّ من أكثر الجوانب إحباطًا في تطوير العوامل. في سياق تطوير الأدوات البرمجية، تجربة Amp تُظهر نهجًا مبتكرًا، خاصة في تكامل العوامل الفرعية (مثل Oracle) مع الدورة الرئيسية. تُعدّ هذه المقاربة مُلهمة، وتمكّن من تجربة تصميمات مختلفة بفعالية. كما أن الأدوات البسيطة (مثل CLI بسيط لاستخدام المتصفح) تُقدّم بديلًا مُبسطًا لـ MCP المُعقد، خصوصًا في المهام البسيطة. ونهايةً، تُظهر تجربة العمل أن Tmux أداة لا غنى عنها في الأنظمة التفاعلية.