وقتی یک محصول AI فقط پاسخ نمی‌دهد و کاری هم انجام می‌دهد، باید مشخص باشد کدام تصمیم را مستقل می‌گیرد و کجا اجازه می‌خواهد. Zapier در روایت توسعه Sidekick، فضای کاری AI خود، توضیح می‌دهد چرا دو سر این طیف مشکل دارند: سؤال‌های پی‌درپی به تأیید بی‌توجه تبدیل می‌شوند و اقدام بدون اجازه هم ممکن است با یک اتفاق غیرمنتظره اعتماد را از بین ببرد.
در نسخه نخست، agent برای خواندن اطلاعات مستقل عمل می‌کرد، اما کارهایی مثل نوشتن، ویرایش یا حذف را برای تأیید متوقف می‌کرد. درخواست‌ها ابتدا فقط در پنجره باز مرورگر وجود داشتند و انتخاب «Always» با refresh فراموش می‌شد. Zapier تأییدها را روی server ذخیره کرد. درخواست‌های تکراری پس از شکست عملیات، پنهان‌شدن آن‌ها در بخش‌های بسته گفتگو و متن مبهم دکمه‌ها هم از مشکلات این مرحله بودند.
مسئله عمیق‌تر، وجود دو سیستم جداگانه برای permission بود: یکی برای قابلیت‌های داخلی و دیگری برای برنامه‌های کوچکی که Sidekick برای کار با appها می‌نوشت و اجرا می‌کرد. قواعد نیز به tool وابسته بودند؛ درحالی‌که دغدغه کاربر محافظت از یک پوشه، سند یا حساب Slack بود.
در بازطراحی بعدی، قاعده به منبع محافظت‌شده متصل شد: فایل، app متصل، وب‌سایت یا automation. حالا محدودیتی مثل «هیچ‌چیز این پوشه را تغییر نده» مستقل از روش اقدام Sidekick اعمال می‌شود. ترتیب تصمیم هم روشن است: اگر هر قاعده‌ای منع کند، اقدام متوقف می‌شود؛ در غیر این صورت، قاعده «اول بپرس» درخواست تأیید ایجاد می‌کند. تنها وقتی هیچ‌کدام مانع نباشند، اقدام بدون سؤال انجام می‌شود. همچنین agent نمی‌تواند مجوز کلی اجرای تمام code را پیشنهاد کند.
مرحله بعد، قابل‌فهم‌کردن درخواست‌ها بود. نمایش JSON خام قواعد جای خود را به ردیف‌های خوانا با وضعیت Allow، Ask first یا Deny، محدوده و شرط داد. نام حساب‌ها جای شناسه اتصال را گرفت و محدوده واقعی زیر برچسب توضیحی agent باقی ماند. تنظیم permission نیز به یک گفتگوی جانبی منتقل شد تا گفتگوی اصلی را متوقف نکند.
در نهایت، درخواست تأیید، سؤال‌ها و برنامه‌های پیشنهادی از میان پیام‌های chat به panel کنار محل نوشتن منتقل شدند. این panel بیرون از chat، مثلاً هنگام ویرایش سند، هم کار می‌کند و وقتی چیزی نیازمند بررسی باشد باز می‌شود. تأییدهای منتظر نیز در inbox قابل‌دسترسی از سراسر Sidekick نمایش داده می‌شوند.
