وقتی یک دستیار به ابزارهای کاری متصل می‌شود، تفاوت میان پیشنهاد و اقدام اهمیت بیشتری پیدا می‌کند. نوشتن متن یک پیام در گفتگو، با ارسال همان پیام به مشتری یکسان نیست. خواندن وضعیت پروژه نیز با تغییر وضعیت آن تفاوت دارد.
برای سارا ایجنت، هر اتصال باید یک قابلیت مشخص با مسئولیت روشن باشد؛ نه عنوانی کلی برای دسترسی به همه بخش‌های یک نرم‌افزار.
از کار موردنیاز شروع کنیم
پیشنهاد ما این است که ابتدا عمل موردنیاز تعریف شود: خواندن یک گزارش، ساختن پیش‌نویس یا ثبت یک درخواست تأییدشده. سپس همان عمل به ابزار و مجوز مناسب متصل شود. اتصال عمومی با اختیارات اضافه، نباید انتخاب پیش‌فرض باشد.
OWASP در بحث Excessive Agency، اعطای قابلیت، مجوز یا استقلال بیش از نیاز را از عوامل خطر برای سامانه‌های مبتنی بر مدل زبانی می‌داند. ۱ این موضوع نشان می‌دهد کیفیت یک اتصال را نباید فقط با تعداد کارهایی که انجام می‌دهد سنجید.
تأیید باید درباره اقدام مشخص باشد
در یک سناریوی توضیحی برای ارسال پیام، کاربر باید بداند گیرنده چه کسی است و چه متنی ارسال خواهد شد. اجازه تهیه پیش‌نویس، نباید خودبه‌خود اجازه ارسال تعبیر شود. همچنین تغییر محتوای مهم پس از تأیید، می‌تواند نیازمند بازبینی دوباره باشد.
این مثال، الگوی پیشنهادی طراحی است. وجود چنین گردش کاری در یک خدمت خاص، به اتصال فعال، سیاست دسترسی و پیاده‌سازی همان استقرار وابسته است.
پاسخ ابزار را جایگزین حدس کنیم
پس از درخواست یک اقدام، گزارش ایجنت باید بر نتیجه واقعی ابزار تکیه کند. «آماده شد»، «برای اجرا ارسال شد» و «با موفقیت انجام شد» وضعیت‌های متفاوتی‌اند. وقتی نتیجه روشن نیست، نباید موفقیت قطعی اعلام شود.
همچنین پیشنهاد می‌کنیم برای اقدام‌های قابل‌تکرار، روش جلوگیری از ثبت یا ارسال تکراری در طراحی بررسی شود. بازگشت ناقص پاسخ نباید بدون بررسی، به اجرای دوباره همان کار منجر شود.
توسعه سارا ایجنت را با این معیار دنبال می‌کنیم: کاربر باید بداند چه اختیاری واگذار کرده و چه اتفاقی واقعاً افتاده است. اتصال بیشتر زمانی ارزش دارد که مسئولیت هر اقدام، مرز دسترسی و نتیجه آن همچنان روشن بماند.
