التسويق الوكيلي في 2026: الأمور الأربعة التي يجب أن يكشفها أي نظام

الإجابة المختصرة: التسويق الوكيلي هو عمل تسويقي تؤديه برمجيات تختار خطوتها التالية بنفسها ثم تنفذها. عند هذا الحد تقريبًا ينتهي الاتفاق. جلبنا الصفحات الإحدى عشرة التي ظهرت لنا عند البحث عن المصطلح وصيغه المختلفة في 18 أغسطس 2026، وثمانٍ منها لا تذكر البروتوكول أو استدعاء الأدوات أو استدعاء الدوال إطلاقًا — وهي الطبقة التي يتوقف عندها الوكيل عن كونه نافذة محادثة ويصبح شيئًا قادرًا على تغيير مجتمعك أو حملتك أو سجلات عملائك. لذلك يعرّف هذا المقال التسويق الوكيلي بالأمور الأربعة التي يجب أن يكشفها أي نظام قبل أن يتمكن الوكيل من أداء أي عمل تسويقي على الإطلاق، ويقتبس من بروتوكول سياق النموذج (Model Context Protocol) سبب اعتبار التسميات التي تنشرها تلك الأنظمة عن نفسها غير موثوقة، ويقيّم واجهة الوكلاء الخاصة بـ Zealy مقابل هذا التعريف، بما في ذلك الجزء الذي نفشل فيه.

إفصاح: تنشر Zealy هذه الصفحة، وZealy تبيع الشيء الذي تتناوله. Zealy منصة مجتمع ومهام. اثنتان من ميزاتها وكلاء بالمعنى الذي يعرّفه هذا المقال: خادم MCP يمكن لذكاء اصطناعي خارجي تشغيله، ومراجع ذكاء اصطناعي داخل المنتج. تظهر الثلاثة أدناه. كل ما ورد هنا عن واجهة وكلاء Zealy نفسها هو من مصدر أولي: مقروء من مستودع Zealy، ومشغَّل مقابل خادم Zealy الخاص بها من قِبَلنا، ولم يدققه أحد غيرنا. ينبغي أن تقرأه بالتشكيك نفسه الذي تطبقه على أي بائع يصف منتجه.

آخر تحقق: 18 أغسطس 2026.

ما هو التسويق الوكيلي؟

التسويق الوكيلي هو عمل تسويقي تؤديه برمجيات تختار إجراءها التالي نحو هدف بدلًا من اتباع سير عمل رسمه شخص. ولا يستوفي النظام هذا الوصف إلا إذا كشف أربعة أمور: أدوات مسماة بدلًا من صندوق محادثة، وطريقة لاكتشافها قبل التصرف، وحدًا للموافقة مقصودًا، وحدًا للثقة فيما يعود من نتائج.

هذا التعريف تعريفنا، وهو مبني عمدًا على الآلية لا على الطموح. كل تعريف منشور قرأناه يصف ما تحاول البرمجيات فعله. ولا يصف أي منها ما يجب أن يكون صحيحًا في منظومتك قبل أن تتمكن من فعله. وفيما يلي الأجزاء الأربعة، بالترتيب الذي يجب أن يستوفيها به النظام.

1. أدوات مسماة، لا صندوق نص. يحتاج الوكيل إلى عمليات لها أسماء ووسائط وأشكال إرجاع، أشياء مثل create_campaign, list_members و send_message، لأن النموذج الذي لا يستطيع إنتاج سوى النثر لا يستطيع إنتاج سوى النثر. وبروتوكول سياق النموذج هو الطريقة الشائعة الحالية لنشر قائمة كهذه، وأدواته هي ما يسميه خاضعًا لتحكم النموذج: يكتشفها النموذج اللغوي ويستدعيها بنفسه، بناءً على السياق ومطالبة المستخدم. بدون هذه الطبقة لديك مساعد كتابة. وهذا منتج مفيد؛ لكنه ليس هذا المنتج.
2. الاكتشاف قبل التصرف. يجب أن يستطيع الوكيل السؤال عما هو موجود وما يفعله كل شيء، قبل أن يلتزم بأي شيء. أما التكامل المبرمج مسبقًا حيث اختار إنسان بالفعل الاستدعاءات الثلاثة فهو أتمتة مرتبطة بنموذج في النص.
3. حد للموافقة اختاره شخص عن قصد. كل إجراء إما يتوقف عند شخص أو لا يتوقف، وفي مكان ما قاعدة تحدد أيهما. ويمكن أن تكون القاعدة صارمة أو مرنة. لكن ما لا يمكن أن تكون عليه هو أن تُترك دون فحص.
4. حد للثقة فيما يعود من نتائج. نتائج الأدوات بيانات كتبها آخرون: أعضاء وعملاء ونماذج وصفحات مجمّعة. فإذا كان نص مُعاد قادرًا على إقناع الوكيل باستدعاء أداته التالية، فأنت قد بنيت نظامًا يتلقى التعليمات من أي شخص يملأ حقل تقديم المهمة لديك.

وينتج عن ذلك نتيجتان، وهما سبب تكبدنا عناء كتابة تعريف أصلًا. أي شيء يفتقد الجزء الأول هو روبوت محادثة بتسويق أفضل. و أي شيء يفتقد الجزء الثالث لم يتخذ قرارًا بشأن الاستقلالية — بل وقع عليه قرار. حد الموافقة الذي لم تختره ليس موقفًا تصميميًا، بل حادث لم يكلفك شيئًا بعد.

التعريفات الموجودة، وأين يرسم كل منها خط الاستقلالية

تتفق التعريفات المنشورة على أن الوكيل يخطط ويتصرف بنفسه، وتختلف حول مقدار المشاركة البشرية المسموح ببقائها. تسمح كلية فيلريك لإدارة الأعمال بتدخل أدنى. وتصف Braze أنظمة تدرك وتقرر وتتصرف. وتضع Young Urban Project وNetcore كلتاهما الحد عند موافقة بشرية على كل خطوة. وتفصل Forrester بين الوكلاء والذكاء الاصطناعي الوكيلي تمامًا.

اقرأ العمود الأوسط قبل العمود الأيمن. فمن يعرّف الفئة يخبرك بالكثير عن أين يضع الحد.

تمت مطابقة كل نص في العمود الأيمن مع النص الخام للصفحة المرتبطة كما جُلب في 18 أغسطس 2026، بدلاً من قراءته من نتيجة بحث. تعذّرت قراءة ست صفحات تتصدر نتائج هذا المصطلح كلياً. أعادت Salesforce وIBM وGartner وBCG الخطأ 403 في كل محاولة، وانتهت مهلة McKinsey وAdobe. لا شيء منها مقتبس هنا.

ثلاث من الصفحات ترسم أيضاً حدوداً قابلة للاستخدام مقابل مصطلح مجاور، وهذه هي الثلاث الوحيدة التي وجدناها جديرة بالاحتفاظ.

مقابل أتمتة التسويق. تكتب Treasure Data أن "التسويق الوكيلي أضيق من التسويق بالذكاء الاصطناعي ومختلف عن أتمتة التسويق"، لأن "أتمتة التسويق تنفّذ سير عمل ثابتاً يحدده الإنسان". الاختبار ليس فيما إذا كان البرنامج يتصرف دونك. فأداة بريدك الإلكتروني تفعل ذلك بالفعل. الاختبار هو فيما إذا كان شخص قد اختار تسلسل الخطوات مسبقاً.

مقابل الذكاء الاصطناعي التوليدي. تطرحه Optimove كمقارنة بين محفّزين: "الذكاء الاصطناعي التوليدي ينشئ محتوى بناءً على مطالبات بشرية"، بينما "الذكاء الاصطناعي الوكيلي يتخذ إجراءات مستقلة دون انتظار المطالبات." أي على شكل مطالبة مقابل على شكل هدف، وهو تمييز حقيقي ونادراً ما يُحترم.

مقابل مساعد. الجملة الأكثر حدة التي كتبها أي شخص في المجموعة تعود إلى Docket's Arjun Pillai: "المساعد ينتظر مستخدماً، ويساعد في مهمة، ويعيش داخل سير عمل بشري." أما نصفه الوكيلي فهو "الوكيل يتصرف نحو هدف، ويتخذ قرارات محدودة، ويطلق سير عمل، ويملك جزءاً من التنفيذ تحت الإشراف." ويوفّر مقطع منفصل في الصفحة نفسها الآلية التي تفتقدها تلك العبارة: البشر "يحددون الأهداف وقواعد التصعيد وقيود الموضوع وحدود الموافقة. يعمل الوكيل داخل تلك الحدود. وعندما يقع شيء خارجها، يصعّد." التصعيد هو حد الموافقة في تعريفنا، موصوفاً من جانب الوكيل.

ثمة خلاف واحد يستحق النشر بدلاً من التملّس منه. فورستر، على صفحة عن حالات استخدام وكلاء الذكاء الاصطناعي يرد فيها اسم Craig Le Clair، تفصل بين المصطلحين اللذين تعاملها كل صفحة بائع أعلاه كمترادفين: وكلاء الذكاء الاصطناعي يعملون وفق "قواعد محددة مسبقاً"، بينما "يقدّم الذكاء الاصطناعي الوكيلي استقلالية وقدرة على التكيّف أوسع". تحذير مشروع بشأن هذا الاقتباس — فهو صفحة هبوط لبودكاست، لا مذكرة بحثية منشورة، ونقتبسه كإطار عمل لشركة تحليل واحدة لا كنتائج.

الطبقة التي تغفلها ثمانية من التعريفات الأحد عشر

من بين الصفحات الإحدى عشرة التي جلبناها لهذا المصطلح في 18 أغسطس 2026، لا تذكر ثمانٍ منها قط بروتوكول سياق النموذج أو استدعاء الأدوات أو استدعاء الدوال. تلك الطبقة هي الفرق بين نموذج يكتب لك موجز حملة ونموذج يستطيع إنشاء مهمة مجتمعية أو حظر عضو أو توجيه تدفق أحداثك إلى مكان جديد.

الثماني التي لا تذكر أي من تلك النصوص: braze.com وcdp.com وdocket.io وforrester.com وnetcore.ai وtofuhq.com وvlerick.com وyoungurbanproject.com. ومن الثلاث المتبقية، تذكر hubspot.com بروتوكول سياق النموذج لكنها ليست صفحة تعريفية. Optimove هي التي بقيت معنا: فالنص MCP لا يظهر على صفحتها إلا في قائمة التنقل، بعبارة "The Optimove MCP"، ولا يظهر قط في متن المقال الذي يشرح الفئة. بائع يوفّر خادم MCP، ولا يصل شرحه الخاص للتسويق الوكيلي إلى الشيء الذي يوفّره. هذا تصريح عن إحدى عشرة صفحة في يوم واحد، لا عن الفئة بأكملها — لكنه صحّ في كل صفحة فحصناها.

صفحتان في المجموعة تسمّيان الطبقة المفقودة، وكلتاهما تفعل ذلك جيداً.

Duncan Lennox من HubSpot يكتب: "لكن الوكلاء لا ينقرون عبر لوحات المعلومات ولا يتنقلون في الواجهات؛ بل يستدعون واجهات برمجة التطبيقات، ويقرؤون المخرجات المهيكلة، ويتخذون إجراءات." وتصوغ الصفحة نفسها النطاق بأنه "ما يستطيع الوكلاء قراءته وكتابته والتصرف بناءً عليه"، وهي الوحدة الصحيحة. ليس "هل يستطيع القيام بالتسويق"، بل أي الأسماء وأي الأفعال.

تقدّم Real Story Group، وهي شركة أبحاث في تقنيات التسويق تبيع تقييمات البائعين، الجملة التي تنهي الجدل. في مقال عن MCP بتاريخ 11 يونيو 2025، يصفه المحلل الرئيسي Scott Simmons بأنه "طبقة تجريد عالمية لواجهات برمجة التطبيقات مبنية لوكلاء الذكاء الاصطناعي"، ويستنتج أن الوكيل "لا يكون أقوى إلا بقدر ما يختار البائع كشفه."

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

لماذا قائمة الأدوات دليل ووسم الأداة مجرد تلميح

يجيب بروتوكول سياق النموذج عن سؤال ما يستطيع الوكيل فعله بك بأن يطلب منك قراءة قائمة أدوات الخادم، ثم يخبر العملاء بألا يثقوا بما تقوله تلك القائمة عن نفسها. والملاحظة التي تنص على ذلك تقع في المخطط لا في النثر، وهذا جزء من سبب قلة من قرأها.

إليك المقطع، من واجهة ToolAnnotations في مخطط المواصفة عند المراجعة 2026-07-28:

ملاحظة: جميع الخصائص في ToolAnnotations هي تلميحات. ولا يُضمن أن تقدّم وصفًا أمينًا لسلوك الأداة (بما في ذلك خصائص وصفية مثل title).

وعن الموضوع نفسه، من صفحة الأدوات:

من أجل الثقة والسلامة والأمان، يجب على العملاء أن يعتبروا تعليقات الأدوات غير موثوقة ما لم تصدر عن خوادم موثوقة.

تأمّل شكل ذلك لحظة. جواب البروتوكول عن سؤال «كيف أعرف ما يمكن أن تفعله بي هذه الأداة» هو: اقرأ القائمة. وتعليمته التالية مباشرة هي: القائمة ادعاء من الطرف الذي تقيّمه. فأسماء الأدوات والمخططات و البيانات الوصفية هي عناصر حاملة للثقل، لأن النموذج يستدعيها وعلى الخادم أن يلتزم بها. أما تسميات المخاطر المرفقة بها فهي وصف الخادم لسلوكه هو.

هناك أربع تسميات من هذا النوع — readOnlyHint, destructiveHint, idempotentHint و openWorldHint — واثنتان منها، destructiveHint و openWorldHint، تُضبطان افتراضيًا على true. لذا تُفترض في الأداة غير الموسومة أنها مدمّرة وأنها تلامس العالم الخارجي، وهذا هو الخيار الصحيح وعكس ما يتوقعه معظم الناس.

التسمية التي تهم في تعريف التسويق الوكيلي هي destructiveHint، بسبب ما لا تسأل عنه. فهي تفصل الكتابة فوق البيانات عن الإضافة إليها. أما الضرر فهو محور مختلف ولا يخصص له المخطط عمودًا، لذا قد تكون استدعاءة إضافية بحتة أهم شيء يفعله وكيل بمكدّسك التقني ومع ذلك يوسمها خادم يعمل بحسن نية تام بالطريقة الآمنة. وما تعنيه كل علامة عمليًا، وكيف تبدو قائمة حقيقية بعد تطبيق القيم الافتراضية، هو الشرح التفصيلي المجاور.

وهذه أيضًا هي النسخة الأمينة مما يسميه المسوّقون غسل الوكلاء. ويسميه Young Urban Project بدقة: «الفشل الأكثر شيوعًا هو غسل الوكلاء، أي أخذ منتج أتمتة أو روبوت محادثة قائم وإعادة تسميته وكيليًا دون إضافة طبقة التخطيط أو القرار تحته»، ويضيف أن «العرض التجريبي مكتوب سلفًا ليخفي بالضبط الفجوة المهمة». وقائمة الأدوات أصعب بكثير في كتابتها سلفًا من عرض تجريبي. وهي أيضًا الأثر الوحيد في هذه الفئة كلها الذي يستطيع المشتري التحقق منه دون تعاون البائع، ولهذا كتبنا شرحًا تفصيليًا منفصلًا عن كيفية تعداد أدوات أي خادم MCP قبل الاتصال به.

أين تقع حدود الموافقة، ومن المفترض أن يضعها هناك

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

الجملة الحرفية:

من أجل الثقة والسلامة والأمان، ينبغي أن يكون هناك دائمًا إنسان في الحلقة قادر على رفض استدعاءات الأدوات.

ويطلب قسم الأمان نفسه من العملاء «عرض مدخلات الأدوات للمستخدم قبل استدعاء الخادم، لتجنّب تسريب البيانات الخبيث أو العَرَضي» و«التحقق من نتائج الأدوات قبل تمريرها إلى LLM». وكلاهما موجّه إلى العميل: الشيء الذي يعمل على جانبك، Claude أو ChatGPT أو أداة داخلية تحمل النموذج. لذا فبقراءة مباشرة للبروتوكول، فإن سلامة تسويقك الوكيلي هي مهمة عميلك، والخادم الذي اتصلت به لا يدين لك بشيء يتجاوز قائمة أدوات أمينة.

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

والنسخة الجديرة بالدفاع ليست «الاستقلالية الكاملة» ولا «الموافقة على كل شيء». بل إن الحدود إعداد لكل قرار وله كلفة على الجانبين، وأن الآلية التي تفرضه هي نفسها برمجية قابلة للفشل — وهو ما أظهره فشل الإشراف على Discord في وقت سابق من هذا العام، حيث كانت خطوة المراجعة البشرية موجودة في التصميم المنشور فأخرجها خطأ برمجي من المسار. وقد كتبنا عن ما يعنيه ذلك للسماح لوكيل بإدارة مجتمع بشكل منفصل، لأنه يستحق أكثر من بند.

وهناك الآن جواب مقيس عن أي الاستدعاءات تستحق البوابة، وهو ليس ما يوحيه الحدس. SABER: Small Actions, Big Errors — Safeguarding Mutating Steps in LLM Agents، لأليخاندرو كوادرون وبينغفي يو ويانغ ليو وأربيت غوبتا، المقدَّم في 26 نوفمبر 2025، يدرس أين تكلّفك فعليًا انحرافات مسار وكيل يستخدم الأدوات. ويذكر أن «في المقابل، لا يكاد يكون للانحرافات في الإجراءات غير المعدِّلة أي أثر». والجملة التي تسبقها مباشرة تعطي الجانب الآخر: كل انحراف إضافي في إجراء معدِّل يقلل احتمالات النجاح بما يصل إلى 92% في أحد مجالي دراسته وبما يصل إلى 96% في الآخر، بالنسبة لأحدث النماذج. فالفشل يتركّز في الاستدعاءات التي تغيّر الحالة.

الاستنتاج التصميمي غير مبهر ورخيص: أغلق عمليات الكتابة، واترك عمليات القراءة وشأنها، وتوقف عن التعامل مع "الإنسان في الحلقة" كمقبض واحد بإعداد واحد. يعمل خادم Zealy بهذه الطريقة، ويجب أن نكون واضحين بأننا لم نستخلص ذلك من هذه الورقة — فقد وصلت الورقة بعد التصميم وتتفق معه، وهذا أضعف من هندسة تقودها الأدلة وأقوى من لا شيء. هناك تحفظ واحد يرافق الاستشهاد: توثّق SABER أخطاء التعليقات التوضيحية في المعيار الذي تبني عليه وتنشر نسخة مصححة، وهذا سبب وجيه لعدم اقتباس درجات معايير وكلاء الأدوات الأقدم وكأنها ما تزال تصف النماذج الحالية. السبب الآخر للحرص مع رقم واحد هنا هو أن فشل الوكيل مشكلة تباين إلى حد كبير — فـ البحث متعدد الجولات يقسم التدهور إلى خسارة طفيفة في القدرة وارتفاع كبير في عدم الموثوقية، وهي مشكلة إدارية مختلفة عن نموذج ببساطة ليس جيداً بما يكفي.

النمط نفسه "متروك للمنفّذ" يمتد طبقة واحدة للأسفل، عند الجزء الرابع من تعريفنا. نزّلنا سبع صفحات مواصفات وأمان في 18 أغسطس 2026 وبحثنا فيها: نموذج التهديد في المواصفات هو نموذج تهديد للتفويض والنقل، يغطي المندوب المرتبك وتمرير الرموز وتزوير الطلبات من جانب الخادم وخادم محلي مخترق بين عدة أمور أخرى، بينما يُترك الهجوم على طبقة النموذج للمنفّذين. في الصفحات التي نزّلناها، لا تظهر عبارة "حقن المطالبات"؛ والمطابقات الأربع لـ"حقن" في وثيقة أفضل ممارسات الأمان هي البرمجة النصية عبر المواقع وحقن أوامر الصدفة والتنفيذ البرمجي عن بُعد. هذا ليس شكوى بشأن مواصفات نقل، فمن حقها تحديد نطاقها. إنه بيان عن أي نصف من المشكلة ترثه لحظة توصيل شيء ما، وعن سبب وجوب أن تكون حدود الثقة على البيانات المُعادة مهمة صريحة لشخص ما بدلاً من كونها خاصية مفترضة في البروتوكول.

يفشل Zealy في تعريفه الخاص، وهنا حيث

بأكثر التعريفات صرامة في هذا المقال — تعريف Young Urban Project "دون أن يوافق إنسان على كل خطوة فردية" وتعريف Netcore "دون اشتراط موافقة بشرية في كل خطوة" — فإن Zealy لا يمارس التسويق الوكيلي. كل عملية كتابة عبر واجهة وكلاء Zealy تتوقف من أجل شخص، وعمليات الكتابة معطلة حتى يشغّلها مشغّل.

نفضّل قول ذلك على خسارة الحجة لاحقاً. إليك بطاقة التقييم الكاملة مقابل أجزائنا الأربعة، من الطرف الأول وغير مدققة.

الأربعة كلها موجودة، وهذا هو الجزء السهل. الثالث مضبوط في الاتجاه المعاكس للتسمية. يضع خادم Zealy بوابة الموافقة على جانب الخادم، وهو أكثر مما يطلبه البروتوكول من خادم وأكثر مما يسمح به تعريف صارم للتسويق الوكيلي. سطح الأدوات نفسه كبير بما يكفي ليستحق التدقيق — 72 أداة مسمّاة وقت إحصائها — لكن الرقم ليس المقصد. الإعداد هو المقصد.

ولا يحق لنا أيضاً ادعاء الاتساق عبر المنتج بأكمله. يشحن Zealy أيضاً مراجعاً بالذكاء الاصطناعي يغلق مطالبة مهمة بنفسه، دون أي شخص في ذلك المسار: الشركة نفسها، الإعداد المعاكس، على قرار يمس ما إذا كان العضو يتقاضى أجراً. كلا الخيارين قابل للدفاع؛ وما لا يمكننا قوله بصدق هو أن هناك إجابة واحدة على مستوى الشركة بشأن مقدار الاستقلالية المناسب.

إذن أزل التسمية. ما يقدمه Zealy فعلاً هو سطح مقروء للوكيل مع خطوة إقرار بشري، وهو اسم ممل للشيء الذي ينبغي أن تريده معظم الفرق أولاً. إذا أردت آليات توصيله، فإن وثائق تكامل MCP هي المرجع المعتمد وهذا المقال لا يعيد ذكرها عمداً؛ وإذا أردت السطح الأقدم والأوسع تحتها، فإن وثائق API تغطيه. وإذا لم تستخدم المنتج قط، فإن ما هو Zealy هو الطريق الأقصر للدخول.

ما يجب أن تسأل عنه قبل شراء شيء يُسمى التسويق الوكيلي

اطلب قائمة الأدوات. البائع الذي يبيع تسويقاً وكيلياً إما أن يعرض عليك العمليات المسمّاة التي يحصل عليها الوكيل، مع الأذونات المرفقة، أو لا يستطيع. كل ما عدا ذلك، لغة التخطيط ولغة السعي نحو الأهداف والعرض التجريبي، متوافق مع روبوت محادثة موصول بنموذج، ولدى Young Urban Project اسم لذلك.

خمسة أسئلة، بالترتيب الذي يمنحك أكبر قدر من المعلومات بأقل وقت اجتماع:

1. "أي العمليات يحصل عليها الوكيل، بالاسم؟" إذا كان الجواب جملة قدرات بدلاً من قائمة، فقد حصلت على جوابك. وإذا كانت قائمة، اقرأها بحثاً عن الأفعال. قراءة، كتابة، حذف، إرسال، نشر، دفع.
2. "أي منها يمكنه التصرف دوني؟" ليس "هل هناك إنسان في الحلقة": ذلك السؤال يحصل على نعم من الجميع. اسأل أي الاستدعاءات تحديداً تتجاوز الشخص، ومن اختار ذلك التقسيم.
3. "ماذا يحدث للنص الذي كتبه عميل عندما يقرأه الوكيل؟" أنت تسأل عما إذا كانت نتائج الأدوات تُعامَل كبيانات أم كتعليمات محتملة. البائع الذي فكّر في هذا سيجيب فورًا، لأن هذا هو نمط الفشل الذي يُبقي مهندسيه مستيقظين.
4. "ماذا تعني تسميات المخاطر لديكم؟" ثم تحقّق من الإجابة مقابل المواصفات لا مقابل عرض البيع، واسأل عن الإعدادات الافتراضية — فمعظم الناس يخمّنونها بالعكس.
5. "ما الذي لا يستطيع فعله؟" قائمة الحدود هي أرخص إشارة مصداقية ممكنة ولا يكاد أحد ينشرها. غيابها ليس دليلًا على شيء. أما وجودها فقيمته كبيرة.

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