خواندن درست شکاف
الگویی تکرارشونده در گزارش‌های هوش مصنوعی سازمانی، نسبت گسترده میان صندلی‌های تخصیص‌یافته و نشست‌هایی است که واقعاً تکمیل می‌شوند. عدد تیتر بسته به نظرسنجی تغییر می‌کند، اما شکل آن ثابت است: لایسنس‌های زیاد، وظایف تمام‌شده‌ی کم. غریزه این است که این را مسئله‌ی اشتیاق بخوانیم — به کاربران دسترسی داده شد و از آن استفاده نکردند. این خوانش معمولاً غلط است.
نسبت بزرگ میان صندلی‌ها و نشست‌های تکمیل‌شده، نشانه‌ای درباره‌ی طراحی وظیفه است. وقتی یک agent به گردش‌کاری متصل می‌شود که شرط تکمیل روشنی ندارد، نشست با صدای بلند شکست نمی‌خورد. متوقف می‌شود. کاربر ابزار را باز می‌کند، نتیجه‌ی میانی قابل‌قبولی می‌گیرد، نمی‌تواند تشخیص دهد کار تمام شده یا نه، و به روش قبلی برمی‌گردد. لایسنس مصرف می‌شود. هیچ‌چیز تکمیل نمی‌شود. معیاری که لایسنس‌ها را می‌شمارد، تدارکات را ثبت می‌کند، نه اینکه آیا agent چیزی را تمام کرده یا نه.
این شکاف در میان فروشندگان و نسل‌های مدل پایدار می‌ماند. اگر مسئله‌ی کیفیت محصول بود، با بهتر شدن مدل‌ها باریک می‌شد. به‌تناسب باریک نشده است. این پایداری به علتی ساختاری اشاره می‌کند: واحد کاری که به agent داده شده، اندازه‌ی اشتباهی دارد.
پیش از واگذاری، تجزیه کن
پیش از انتخاب مدل، گردش‌کار را تجزیه کن. تقسیم‌بندی مفید بر اساس دپارتمان یا ابزار نیست. بر اساس این است که آیا یک گام شرط تکمیل قابل‌راستی‌آزمایی دارد یا نه.
یک گام شرط تکمیل قابل‌راستی‌آزمایی دارد وقتی شخص ثالثی — یک اسکریپت، یک بازبین، یک بررسی schema — بتواند به خروجی نگاه کند و بر سر تمام‌شدن یا نشدن آن توافق کند. مثال‌ها: استخراج این دوازده فیلد از این سند به این schema؛ دسته‌بندی این تیکت‌ها بر اساس این طبقه‌بندی؛ نوشتن پیش‌نویس پاسخی که فقط به منابع موجود در این corpus ارجاع می‌دهد؛ تطبیق این دو فهرست و علامت‌گذاری ناهمخوانی‌ها. این گام‌ها را می‌توان به agent سپرد، چون agent را می‌توان روی خود گام ارزیابی کرد، نه روی کل کار.
یک گام شرط تکمیل قابل‌راستی‌آزمایی ندارد وقتی تعریف تمام‌شدن در ذهن یک فرد یا در یک هنجار نانوشته زندگی می‌کند. مثال‌ها: تصمیم درباره‌ی قابل‌قبول بودن این قرارداد؛ انتخاب یکی از سه استراتژی برای پیگیری؛ قضاوت درباره‌ی در خطر بودن این مشتری. این گام‌ها به یک نقطه‌ی تصمیم انسانی نیاز دارند، یا باید باریک شوند تا خروجی قابل‌بررسی داشته باشند. «تصمیم درباره‌ی قابل‌قبول بودن این قرارداد» به «استخراج بندهایی که با قالب استاندارد تفاوت دارند و علامت‌گذاری آن‌ها» تبدیل می‌شود — که قابل‌بررسی است — و پس از آن یک تصمیم انسانی.
بیشتر استقرارهای شکست‌خورده، agent را به یک گردش‌کار کامل متصل می‌کنند نه به یک گام کران‌دار درون آن. از agent خواسته می‌شود یک فرایند را سرتاسر مالک شود. چون فرایند شرط تکمیل واحدی ندارد، agent نمی‌تواند بداند کجا باید بایستد، و کاربر هم نمی‌تواند. نشست در ابهام پایان می‌یابد، که به‌عنوان عدم‌استفاده ثبت می‌شود.
یک سازوکار مشخص: قرارداد گام کران‌دار
یکی از راه‌های عملیاتی‌کردن این موضوع، قرارداد گام کران‌دار است. برای هر گام نامزد، پیش از انتخاب هر مدلی، چهار چیز را بنویس:
- ورودی‌ای که گام مصرف می‌کند، در شکلی ثابت؛
- خروجی‌ای که گام تولید می‌کند، در شکلی ثابت؛
- بررسی‌ای که تعیین می‌کند خروجی قابل‌قبول است یا نه؛
- مسیر ارجاع (escalation) وقتی بررسی شکست می‌خورد.
اگر هر یک از این چهار مورد نوشته نشود، گام برای agent آماده نیست. این عمداً کسل‌کننده است. تجزیه را وادار می‌کند در زمان طراحی رخ دهد، نه اینکه در جریان یک پایلوت کشف شود.
قرارداد همچنین چیزی به شما می‌دهد که بتوانید آن را ابزارگذاری کنید. چون شکل خروجی و بررسی صریح‌اند، می‌توانید ثبت کنید که گام کجا شکست خورد، نه فقط اینکه شکست خورد. این تفاوت میان استقراری است که می‌توانید اشکال‌زدایی کنید و استقراری که فقط می‌توانید رهایش کنید.
ابزارگذاری ریزش
داشبوردهای پذیرش معمولاً ثبت می‌کنند که آیا نشست با موفقیت پایان یافت یا نه. این کم‌فایده‌ترین سیگنال 
نشستی که در گام دو رها می‌شود، سیگنالی متفاوت از نشستی است که در گام نه رها می‌شود. رهاشدن در گام دو معمولاً یعنی گام اشتباه تعریف شده بود — شکل ورودی با واقعیت نمی‌خواند، یا برآورده‌کردن بررسی ناممکن بود. رهاشدن در گام نه معمولاً یعنی گام درست تعریف شده بود اما گردش‌کار پیرامونی آماده نبود: خروجی جایی برای رفتن نداشت، یا نقطه‌ی تصمیم انسانی پایین‌دست نیروی انسانی نداشت.
تلمتری در سطح مسیر (trajectory)، آمار پذیرش را به ورودی طراحی تبدیل می‌کند. به‌جای پرسیدن «آیا کاربران ابزار را پذیرفتند»، می‌پرسید «کدام گام در این گردش‌کار نشست‌ها را از دست می‌دهد، و آن گام چه اشتراکی با دیگر گام‌هایی دارد که نشست‌ها را از دست می‌دهند». پرسش دوم پاسخی دارد که طراحی را تغییر می‌دهد. پرسش اول ندارد.
یک الگوی عملی این است که شاخص گام را در پایان نشست، همراه با نتیجه‌ی بررسی در آن گام ثبت کنید. طی چند هفته این کار منحنی ریزش به‌ازای هر گام را برای گردش‌کار تولید می‌کند. گام‌هایی با ریزش بالا و بررسی شکست‌خورده، خطاهای تجزیه‌اند. گام‌هایی با ریزش بالا و بررسی موفق، خطاهای یکپارچه‌سازی‌اند. این دو به اصلاحات متفاوتی نیاز دارند، و یک پرچم موفقیت/شکست نمی‌تواند آن‌ها را از هم تشخیص دهد.
نتیجه‌گیری ناخوشایند
برخی گردش‌کارها اصلاً نباید agent داشته باشند. گفتن این حرف ارزان‌تر از یک پایلوت دیگر است. پایلوتي که یک فصل طول می‌کشد و نتیجه می‌گیرد «کاربران آن را نپذیرفتند» همان‌قدر هزینه دارد که یک بازبینی طراحی که نتیجه می‌گیرد «این گردش‌کار گام کران‌داری ندارد که ارزش خودکارسازی داشته باشد» — با این تفاوت که بازبینی طراحی زودتر تمام می‌شود و گردش‌کار را دست‌نخورده باقی می‌گذارد.
این بده‌بستان واقعی است و ارزش دارد صریح گفته شود. تجزیه پیش از تحویل هر ارزشی زمان می‌برد، و می‌تواند به این نتیجه برسد که پاسخ منفی است. استقرار به رهبری فروشنده، دسترسی را فوراً تحویل می‌دهد و پرسش را به تعویق می‌اندازد. برای تیمی تحت فشار برای نشان‌دادن پیشرفت، گزینه‌ی دوم جذاب‌تر است. همچنین همان گزینه‌ای است که شکاف مصرف را تولید می‌کند.
فروشندگان انگیزه دارند صندلی‌ها را گزارش کنند، چون صندلی‌ها چیزی است که می‌فروشند. خریداران باید واحدهای کاری تکمیل‌شده را گزارش کنند، چون کار تکمیل‌شده چیزی است که مصرف می‌کنند. این دو معیار واگرا خواهند شد، و این واگرایی رسوایی نیست. یک ناهمخوانی اندازه‌گیری است که تنها زمانی مسئله می‌شود که خریدار معیار فروشنده را به‌عنوان معیار خود بپذیرد.
معیاری که باید زیر نظر گرفت، استفاده‌ی مکرر از همان گام کران‌دار است. ورودهای هفته‌ی اول کنجکاوی را می‌سنجند. استفاده‌ی مکرر از گامی با خروجی قابل‌بررسی می‌سنجد که آیا آن گام با حضور agent واقعاً بهتر است یا نه. اگر گامی یک‌بار استفاده و رها شود، تجزیه اشتباه بوده است. اگر همان افراد مکرراً از آن استفاده کنند، گام درست تعریف شده و قرارداد پابرجاست.
این روش کندتری برای پذیرش agentهاست. همچنین تنها راه تشخیص تفاوت میان گردش‌کاری است که به مدل بهتری نیاز دارد و گردش‌کاری که به شکلی متفاوت نیاز دارد.