یادداشت‌هایی از ساخت سیستم‌های ایجنت
هارنس‌های ارزیابی، الگوهای ارکستراسیون، طراحی حافظه و شکست‌های پشت آن‌ها — نوشته‌شده در حالی که جزئیات هنوز تازه است.
قراردادهای سندباکس: آنچه یک عامل باید پیش از دست‌زدن به یک اندپوینت تولیدی اثبات کند
مهار عامل یک قرارداد مجوزها و راستی‌آزمایی است، نه یک پرامپت گاردریل. هر مرز ابزار به یک پیش‌شرط نیاز دارد که عامل نتواند در زمان اجرا بر سر آن چانه بزند.
داوری روی دستگاه: تصمیم‌گیری درباره اینکه کدام گام‌های عامل هرگز از گوشی خارج نشوند
یک داور محلی تصمیم می‌گیرد کدام گام‌های عامل روی گوشی اجرا شوند و کدام به ابر ارتقا یابند، که به‌صورت سیاست کدگذاری می‌شود نه به‌عنوان heuristicهای برنامه.
ردیابی حسابرسی برای ایجنت‌ها یک مسئلهٔ نوشتن پیش‌از‌اجراست، نه یک مسئلهٔ داشبورد
پاسخگویی ایجنت تنها زمانی قابل اثبات است که هر فراخوانی ابزار، استفاده از اعتبارنامه و گذار وضعیت پیش از اجرا ثبت شود و این کار لاگ را به یک وابستگی زمان اجرا تبدیل می‌کند.
هویت بدون قصد: چرا اعتباردهی به ایجنت‌ها آن‌ها را محدود نمی‌کند
احراز هویت یک ایجنت و محدودسازی دامنه توکن آن، آنچه را که در طول زنجیره‌ای از فراخوانی‌های ابزار انجام می‌دهد محدود نمی‌کند. سیاست در سطح قصد، که به ازای هر مسیر ارزیابی می‌شود، همان کنترلی است که شکاف ترکیب را می‌بندد.
ایجنت‌های بدون نظارت یک شکاف تله‌متری هستند، نه یک شکاف اعتماد
ایجنت‌ها بدون نظارت اجرا می‌شوند چون فریم‌ورک‌ها لاگ منتشر می‌کنند، نه تریس ساخت‌یافته. راه‌حل، observability به‌عنوان یک قرارداد زمان ساخت است، نه ابزار پس‌افتاده.
ارکستراتور یک دیسپچر است: چرا ازدحام‌های ایجنت روی صف‌بندی شکست می‌خورند، نه روی استدلال
بیشتر شکست‌های چند-ایجنی که به استدلال مدل نسبت داده می‌شوند، شکست‌های زمان‌بندی هستند. fan-out بی‌کران، نبود backpressure و نبود admission control یک ازدحام را به طوفان retry تبدیل می‌کند.
بدافزاری که حرکت بعدی خود را انتخاب می‌کند، دفاع مبتنی بر امضا را می‌شکند
وقتی ابزارهای نفوذ از مجموعه‌ای از مدل‌ها برای انتخاب اقدام بعدی خود استفاده می‌کنند، تشخیص باید از مصنوعات به رفتار تغییر کند — و پلتفرم‌های agent پیامدهای آن را به ارث می‌برند.
پذیرش انسانی یک مسیر جایگزین است، نه یک ویژگی
مسیریابی شکست‌های عامل به انسان تنها زمانی کار می‌کند که قرارداد تشدید صریح باشد: چه وضعیتی تحویل داده می‌شود، اپراتور چه چیزی را می‌تواند تغییر دهد، و چگونه اصلاح به عامل بازمی‌گردد.
مدیریت وضعیت بر حافظه پیروز می‌شود: یادداشتی طراحی درباره پایداری عامل
بیشتر شکست‌های «حافظه» عامل، شکست‌های مدیریت وضعیت هستند. بازیابی از نوبت‌های گذشته نمی‌تواند ناورداها را تضمین کند؛ یک گزارش تراکنش می‌تواند.