تصور کنید در یک پلتفرم عامل‌محور بالغ هستید، جایی که تیم‌های تجاری می‌توانند اپلیکیشن‌های سطح تولیدی (Production-grade) مبتنی بر هوش مصنوعی را بدون نوشتن حتی یک خط کد مستقر کنند. در ۲۳ ژوئن ۲۰۲۶، وب‌سایت blog.owulveryck.info از یک چرخش ساختاری بنیادین در این سامانه‌ها پرده برداشت: انتقال «بار پیش‌بینی» (Anticipation Burden). بار پیش‌بینی یعنی آن الزام سخت‌گیرانه که انسان باید تمام خطاهای احتمالی عامل را پیش از اجرا پیش‌بینی کند. در این مدل جدید، این بار به جای دوش فرد، توسط خودِ سامانه جذب می‌شود.
این تحول در حالی رخ می‌دهد که سازمان‌ها با بحران «توان عملیاتی شناختی» (Cognitive Throughput) دست‌وپنجه نرم می‌کنند. در نرم‌افزارهای سنتی، پیچیدگی به‌صورت گسترده بین نقش‌های مختلف توزیع می‌شد. طراحان، معماران، تست‌کنندگان و متصدیان استقرار (Deployers) طی هفته‌ها روی یک پروژه کار می‌کردند و هر نقش در زمان مقرر، سؤالات تخصصی خود را می‌پرسید. اما عامل‌ها (Agents) — همان برنامه‌های کوچکی که می‌توانند به‌طور مستقل هدف را بفهمند و ابزارها را اجرا کنند — این معادله را به‌طور کلی تغییر دادند. آن‌ها پاسخ‌ها را فوراً تولید می‌کنند و بدون خستگی یا استراحت کار می‌کنند. این سرعت در عین قوت، تله‌ای مرگبار است.
عامل‌ها سؤال نمی‌پرسند؛ آن‌ها صرفاً اجرا می‌کنند. این ویژگی، بازه زمانی تصمیم‌گیری را چنان فشرده می‌کند که اپراتور انسانی مجبور است تمام حالت‌های خاص (Edge Case) را به‌صورت موازی و در همان پنجره زمانی کوتاه نوشتن یک پرامپت پیش‌بینی کند. اگر چارچوب پرامپت به‌درستی طراحی نشده باشد، عامل سرعتش را کم نمی‌کند تا از شما سؤال بپرسد؛ بلکه صرفاً با سرعت زیاد، نتایجی کاملاً دور از هدف تولید می‌کند. این موضوع نشان می‌دهد که اتکای صرف به کلمات در پرامپت کافی نیست و هویت و ساختار مدل در استخراج قضاوت‌های سطح خبره نقش تعیین‌کننده‌ای دارد. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی مدیریت توهمات مدل‌ها اشاره کردیم، بار شناختی با ورود هوش مصنوعی حذف نمی‌شود، بلکه تغییر شکل می‌دهد و به یک «بار پیش‌بینی» و جریانی مداوم از تصمیمات در طول زمان تبدیل می‌شود. چالش اصلی این نیست که پیچیدگی رشد می‌کند، بلکه این است که پیچیدگی روی دوش یک فرد در بازه زمانی بسیار کوتاهی فشرده می‌شود که او قادر به جذب تنها نیست.
پلتفرم‌های عامل‌محور (Agentic Platforms) با تبدیل خود به محیطی که توسط خودِ عامل قابل پرس‌وجو باشد، این بار را جذب می‌کنند. طبق گزارش owulveryck.info، وقتی پلتفرم تضمین کند که عامل می‌تواند در مورد نحوه پیشروی در مسائل امنیتی از سامانه سؤال کند، کاربر انسانی دیگر نیازی ندارد تمام آسیب‌پذیری‌های احتمالی را در پرامپت پیش‌بینی کند. در این ساختار، کنترل‌های قطعی (Deterministic) در مراحل پایین‌دستی (Downstream)، خروجی را تحمیل و اصلاح می‌کنند.
این رویکرد به معنای حذف تفکر نیست. در عوض، این کار مجموعه‌ی سؤالاتی را که انسان باید به دوش بکشد، محدود و باریک می‌کند. این امر به انسان‌ها اجازه می‌دهد تا بر روی تصمیمات ساختاری و مورد مناقشه تمرکز کنند؛ یعنی جایی که قضاوت انسانی همچنان جایگزین‌ناپذیر است. در حالی که متفکرانی چون اسکلتون (Skelton) و پائیس (Pais)، بار شناختی را مقداری می‌دانند که باید بین تیم‌ها توزیع شود، در دنیای عامل‌محور، این بار در واقع یک «توان عملیاتی» است که باید در طول زمان تنظیم و مدیریت شود.
این چارچوب با تکیه بر مفهوم «کارخانه عامل‌محور» (Agentic Factory) — مکایزمی که در آن عامل‌ها برنامه‌ریزی، کدنویسی، تست و استقرار را انجام می‌دهند — و استفاده از Team Topologies (پیکربندی تیم‌ها)، مسئولیت‌ها را توزیع می‌کند. هدف اصلی این است که هیچ تیمی بیشتر از ظرفیت جذبش، پیچیدگی تحمل نکند. پلتفرم پیچیدگی‌های فنی را جذب می‌کند تا تیم‌های تجاری فقط بار شناختیِ حوزه تخصصی (Domain) خود را مدیریت کنند. در واقع، نقش توسعه‌دهنده از «سازنده اپلیکیشن» به «سازنده پلتفرمی» تغییر می‌کند که دیگران را قادر به تولید اپلیکیشن می‌کند. در این مسیر، به جای تمرکز بر مهندسی پرامپت، بهینه‌سازی حلقهٔ عامل (Agent Loop) به ابزاری کلیدی برای جایگزینی روش‌های سنتی تبدیل شده است.
به نقل از این مستندات، تطبیق مدل Team Topologies برای دنیای عامل‌ها نیازمند چند تغییر کلیدی در مدل اصلی است. اگرچه اصول راهنمای بار شناختی، چهار نوع تیم و سه حالت تعاملی بدون تغییر باقی می‌مانند، اما تغییرات زیر ضروری است:
- تیم‌های هم‌سو با جریان (Stream-aligned) غیرفنی: این تیم‌ها اکنون می‌توانند تحت رهبری مستقیم مدیران تجاری باشند، زیرا پلتفرم بار فنی را جذب کرده و حذف کرده است.
- جداسازی عملیاتی: تیم‌های هم‌سو با جریان دیگر مسئولیت‌های عملیاتی سرتاسری (مانند اجرای سیستم و مدیریت حوادث/Incidents) را بر عهده ندارند، زیرا پلتفرم این توابع را جذب می‌کند.
- توانمندسازی ساختاری: نقش تیم‌های توانمندساز دیگر صرفاً گذرا نیست؛ بلکه چون تولیدکننده نهایی یک توسعه‌دهنده نیست، پلتفرم به‌صورت ساختاری این کمبود مهارت را جبران می‌کند.
- بار پویا: بار شناختی به عنوان یک توان عملیاتی در نظر گرفته می‌شود که باید در طول زمان تنظیم شود، در حالی که پلتفرم، «بار پیش‌بینی» را در مراحل پیش از تولید (Upstream) جذب می‌کند.
برای مدیریت این انتقال، مدل چهار نوع نقش تخصصی را در زنجیره تولید تعریف می‌کند تا مشخص شود چه کسی چه چیزی را ارائه می‌دهد و تعاملات چگونه است:
۱. تیم‌های هم‌سو با جریان (Stream-aligned teams): این‌ها عمدتاً تیم‌های تجاری هستند (متخصصان حوزه، مدیران محصول، تحلیل‌گران) که ارکستراتور هوش مصنوعی را هدایت می‌کنند. آن‌ها «قصد تجاری» (Business Intent) را تعریف کرده و زمینه پویا (Dynamic Context) شامل مشخصات فنی، حفاظ‌های خاص محصول و دانش دامنه را تأمین می‌کنند. برخلاف توپولوژی‌های کلاسیک، آن‌ها مسئولیت‌های عملیاتی (اجرا و حوادث) را بر عهده ندارند. پلتفرم «چگونگی» (استقرار، نظارت، بازگشت به نسخه قبل/Rollback) را جذب می‌کند، در حالی که این تیم‌ها مالک «چیستی» (قصد و کیفیت تجاری) هستند. وظیفه On-call بین این دو تقسیم می‌شود: تیم پلتفرم حوادث سیستمی را مدیریت می‌کند و تصمیمات تجاری (مانند حذف محتوا) نزد تیم جریان باقی می‌ماند. این مرز نفوذپذیر است؛ برای مثال، ثبات برند یک دغدغه تجاری (چیستی) است، اما تأیید آن توسط پلتفرم به‌صورت خودکار انجام می‌شود (چگونگی).
۲. تیم‌های پلتفرم (Platform teams): این تیم‌ها سه ستون سیستمی را به‌صورت «X-as-a-Service» ارائه می‌دهند تا تضمین شود تلاش طراحی یک‌بار صورت گرفته و برای تمام پروژه‌ها اعمال شود:
- زمینه سیستمی (Systemic context): دستورالعمل‌ها، نقش‌ها، دانش تجاری مشترک، حافظه، نمونه‌ها و الگوها.
- حفاظ‌های سیستمی (Systemic guardrails): امنیت، قابلیت اطمینان، ثبات برند و کنوانسیون‌ها.
- ابزارها و مهارت‌ها: سرورهای MCP، خطوط لوله CI/CD، ارزیابی‌ها (Evaluations) و مهارت‌های مشترک.
۳. تیم‌های توانمندساز (Enabling teams): این‌ها مانند یک پل موقت عمل می‌کنند که تیم‌های تجاری را در زمینه بسته‌بندی زمینه (Context Packaging)، حفاظ‌ها و عملیات ارکستراتور آموزش می‌دهند. آن‌ها تسهیل‌گر «تغییر به چپ» (Shift-left) در عملکردهایی مانند امنیت و تست هستند تا زمانی که پلتفرم بتواند این‌ها را کپسوله کند. با افزایش مهارت تیم‌های محصول، نقش آن‌ها کاهش می‌یابد، هرچند به‌طور ساختاری کمبود مهارت فنی تولیدکنندگان را جبران می‌کنند.
۴. تیم‌های زیرسیستم پیچیده (Complicated subsystem teams): متخصصان ارشد زیرساخت‌های عمیق AI. این تیم برای سازمان‌هایی که مدل‌های خود را مدیریت می‌کنند، هزینه‌های استنتاج را بهینه می‌کنند یا با محدودیت‌های حاکمیتی (Sovereignty) مواجه‌اند، ضروری است. تمرکز آن‌ها بر ارزیابی، تیم قرمز (Red-teaming)، مهندسی پیشرفته RAG، تنظیم دقیق (Fine-tuning)، مدیریت KV Cache و استخراج حاکمیتی است. خروجی کار آن‌ها هرگز مستقیماً به تیم‌های محصول نمی‌رسد، بلکه از طریق پلتفرم جریان می‌یابد و با تیم پلتفرم روی بهره‌وری مدل‌ها همکاری می‌کنند.
بر اساس گزارش owulveryck.info، یک پلتفرم تنها زمانی «بالغ» محسوب می‌شود که پنج معیار مشاهده‌پذیر را برآورده کند. تا پیش از رسیدن به این سطح، پلتفرم نمی‌تواند به‌طور کامل مسئولیت‌های عملیاتی تیم‌های جریان را جذب کند:
۱. پوشش حفاظ‌ها (Guardrail coverage): ابعاد حیاتی (امنیت، قابلیت اطمینان، ثبات برند) باید به‌صورت خودکار پوشش داده شوند، نه از طریق توافقات شفاهی.
۲. قابلیت اطمینان خط لوله (Pipeline reliability): نرخ موفقیت استقرار باید قابل اندازه‌گیری باشد و از طریق SLAهای داخلی ردیابی شود.
۳. سهم سرویس‌های خودکار (Self-service share): اکثریت استقرارها باید بدون دخالت مستقیم تیم پلتفرم انجام شوند.
۴. مستندات (Documentation): هر قابلیت ارائه شده باید مستند باشد و با نمونه‌های عینی و نسخه‌بندی (Versioning) همراه باشد.
۵. ردپای تصمیمات (Decision traceability): حفاظ‌ها باید یک ردپای حسابرسی (Audit Trail) تولید کنند که توضیح دهد چرا یک استقرار مسدود شد، کدام قانون اعمال شد و کدام آستانه (Threshold) نقض گردید. برای این منظور، می‌توان از رویکردهایی مانند پروتکل CHAP استفاده کرد تا تعاملات انسان و عامل به مدارکی قابل حسابرسی تبدیل شوند و شفافیت تصمیمات را تضمین کرد.
مدل تعاملی در این سیستم نیز در طول زمان تکامل می‌یابد. Team Topologies سه حالت تعاملی را تعریف می‌کند:
- تسهیل‌گری (Facilitating): توسط تیم‌های توانمندساز برای حرکت تیم‌های محصول به سمت خودکفایی استفاده می‌شود. این یک تعامل موقتی برای آموزش است.
- سرویس‌دهی (X-as-a-Service): حالت هدف برای مقیاس‌پذیری است، جایی که پلتفرم قابلیت‌ها را به‌صورت خودکار ارائه می‌دهد.
- همکاری (Collaboration): بین تیم‌های زیرسیستم پیچیده و تیم‌های پلتفرم در مرحله ساخت استفاده می‌شود. در بلوغ کامل، این حالت به X-as-a-Service تبدیل می‌شود زیرا قابلیت‌های بهره‌وری AI به سرویس‌های مصرفی تبدیل می‌شوند.
این تکامل در دو محور «بلوغ تیم» و «بلوغ پلتفرم» حرکت می‌کند. در مرحله استارتاپی، تیم‌های محصول در حال کشف نحوه بسته‌بندی زمینه هستند و توانمندسازی همه‌جاست. قابلیت‌های پلتفرم ابتدایی و خط لوله شکننده است. در مرحله بلوغ، تیم‌های محصول در اصول تسلط می‌یابند و توانمندسازی هدفمند می‌شود. حفاظ‌های پلتفرم گسترش یافته و مستندات شکل می‌گیرند. در نهایت در مرحله خودکفایی (Autonomy)، تیم‌های محصول کاملاً مستقل هستند. تعامل غالب X-as-a-Service است و تیم‌های توانمندساز چون مأموریت خود را با موفقیت به پایان رسانده‌اند، ناپدید می‌شوند.
برای جلوگیری از رکود پلتفرم، «قانون سه» برای ارتقای حفاظ‌ها به کار می‌رود. اگر یک حفاظ خاص (مثلاً بررسی تضاد رنگی WCAG که توسط یک تیم مارکتینگ پیاده شده) توسط حداقل سه تیم مختلف تکرار شود، کاندیدای سیستمی شدن می‌شود. مالک محصول پلتفرم سپس آن را تعمیم داده، قابل پیکربندی می‌کند و برای همه مستند می‌کند. تیم‌های جریان در اینجا به‌عنوان «حسگر» عمل می‌کنند که فرآیند ارتقا را تغذیه می‌کنند.
این تمرکز‌گرایی همچنین ریسک «IT سایه صنعتی» (Industrialized Shadow IT) را حل می‌کند. اگر تیم‌های غیرفنی بتوانند در مقیاس بالا اپلیکیشن بسازند، خطر گسترش کنترل‌نشده وجود دارد. پلتفرم دید سیستمی روی کل سبد اپلیکیشن‌ها فراهم می‌کند. با متمرکز کردن استقرار و نظارت، مالک پلتفرم می‌تواند اپلیکیشن‌های فعال را ردیابی کند، موارد رها شده را شناسایی کرده و برنامه‌هایی که تست‌های امنیتی را رد می‌کنند، حذف یا بازنشسته کند.
اما یک ریسک حیاتی وجود دارد: مالک محصول پلتفرم می‌تواند به یک گلوگاه (Bottleneck) تبدیل شود. او باید بین بک‌لاگ فنی، ارتقای حفاظ‌ها و حاکمیت سبد محصولات تعادل ایجاد کند. چون یک فرد نمی‌تواند به‌صورت دستی نیازهای ده‌ها تیم محصول را داوری کند، پلتفرم باید از ابزارهایی برای شناسایی خودکار کاندیداهای ارتقا، اولویت‌بندی بر اساس میزان مصرف و ردیابی سبد محصولات استفاده کند.
در نهایت، مالکیت به‌دقت بین موارد «خاص» و «سیستمی» تقسیم می‌شود تا هیچ قابلیتی از قلم نیفتد:
- مالکیت تیم‌های جریان: زمینه پویا، حفاظ‌های خاص محصول و دانش تجاری (چیستی - The What).
- مالکیت تیم پلتفرم: زمینه سیستمی، حفاظ‌های سازمانی، ابزارها و ارکستراتور (چگونگی - The How).
برای مثال، تیم مارکتینگ قصد کمپین و پیام‌های کلیدی را تأمین می‌کند. همزمان، پلتفرم دستورالعمل‌های برند و قوانین دسترسی‌پذیری را تزریق می‌کند. اگر تیم زیرسیستم KV Cache را بهینه کرده باشد، محتوای برند — که قبلاً توکن‌بندی شده — به‌جای محاسبه مجدد، از حافظه کش سرو می‌شود و هزینه هر تولید کاهش می‌یابد. تیم مارکتینگ بدون اینکه بداند CI/CD چیست، به صفحه‌ای امن و مطابق استاندارد می‌رسد. با این حال، تصمیمات حفاظ‌ها باید شفاف بمانند تا تیم‌ها بتوانند درباره مرتبط بودن آن‌ها قضاوت کنند.
این تغییر، فرض بنیادین تولید AI را عوض می‌کند: تمرکز از «مهندسی پرامپت» به «مهندسی سازمانی» تغییر می‌کند. مزیت رقابتی دیگر در بهترین پرامپت نیست، بلکه در پلتفرمی است که بتواند بار شناختی را به‌طور بهینه‌تر جذب کند.
سازمان‌هایی با ۳ تا ۵ تیم محصول معمولاً به نقطه‌ای می‌رسند که هزینه تجمعی بازاختراع (ساخت مجدد زمینه و حفاظ‌ها) بیشتر از سرمایه‌گذاری در یک پلتفرم مشترک می‌شود. بدون این مرزها، پلتفرم یا به‌ناچار گلوگاه می‌شود و یا به سایت درگیری‌های سیاسی بر سر مسئولیت‌پذیری تبدیل می‌گردد.
برای حرکت به جلو، رهبران باید «بار پیش‌بینی» فعلی خود را ارزیابی کنند. اگر توسعه‌دهندگان شما بیشتر از اینکه ویژگی بسازند، مشغول جلوگیری از توهمات مدل هستند، سازمان شما احتمالاً فاقد حفاظ‌های سیستمی یک پلتفرم بالغ است. توسعه‌دهنده ناپدید نمی‌شود؛ بلکه از تولید اپلیکیشن به سمت ساخت پلتفرمی حرکت می‌کند که کسب‌وکار را قادر می‌سازد به‌طور ایمن تولید کند.
گام بعدی شما
- بار پیش‌بینی (Anticipation Burden) فعلی تیم خود را ارزیابی کنید؛ اگر توسعه‌دهندگان شما بیشتر از اینکه ویژگی بسازند، مشغول جلوگیری از توهمات مدل هستند، شما با کمبود حفاظ‌های سیستمی مواجهید.
- ساختار تیم‌های خود را بر اساس چهار نقش ذکر شده (هم‌سو با جریان، پلتفرم، توانمندساز و زیرسیستم) بازبینی کنید.
- فهرستی از حفاظ‌های تکراری بین تیم‌های مختلف تهیه کنید تا کاندیداهای سیستمی‌سازی پلتفرم را شناسایی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو