منبع: این نوشته برداشت و تحلیل فارسی نکست ادمین از مطلب Agents you can coach: how Asana builds human-agent teams with Claude است که Aleksandra Todorova و Kristen Swanson در ۲۹ سپتامبر ۲۰۲۶ بر پایه‌ی گفت‌وگو با Arnab Bose، مدیر ارشد محصول Asana، منتشر کرده‌اند. این سومین نوشته از مجموعه‌ی Anthropic درباره‌ی «تیم‌های انسان و ایجنت» است.
خلاصه در یک نگاه
- Asana برای هوش مصنوعی ساختار جداگانه نساخت. ایجنتها را داخل همان Work Graph گذاشت، یعنی مدلی که هدفها، پروژهها، تسکها و گفتوگوها را با مالک و وابستگیهایشان نگه می‌دارد.
- هر ایجنت مثل یک هم‌تیمی نقش، ابزار و دسترسی مشخص دارد و دسترسی‌اش در هر اجرا به دسترسی کسی محدود است که آن را صدا زده.
- کار کردن با ایجنت از آموزش دادنش جداست: همه میتوانند بازخورد بدهند، ولی فقط مدیران و ویرایشگرها حافظه‌ی دائمی ایجنت را تغییر می‌دهند.
- کار ایجنت در فضای مشترک و قابلدیدن انجام می‌شود، نه در گفتوگوی خصوصی؛ پس بازبینها میتوانند آن را هدایت کنند.
- سه کار واقعی به ایجنتها سپرده شده: پاسخ به سؤال‌های محصول از Slack، گزارش روزانه‌ی تمدیدهای پرریسک برای مدیران، و برنامه‌ریزی چرخه‌های مهندسی.
ایده‌ی اصلی: زمینهی موازی نسازید
خیلی از تیم‌ها وقتی سراغ ایجنت می‌روند، یک دنیای جدا برایش می‌سازند: یک پایگاه دانش تازه، یک چت‌بات جدا، یک مسیر کاری که با کار روزمره‌ی تیم ارتباطی ندارد. Asana مسیر برعکس را رفت. ساختاری که آدم‌ها با آن کار میکنند، یعنی پروژه و تسک و مالک و وابستگی، همان چیزی است که ایجنت هم با آن کار میکند. ایجنت تسک می‌گیرد، پیام می‌خواند و می‌نویسد و در فید فعالیت کنار هم‌کاران انسانی دیده می‌شود؛ فقط محافظ‌های بیشتری روی دسترسی و اشتراک‌گذاری دارد.
قدم اول: قبل از ایجنت، فکر و ساختار
در Asana، Claude ابزار پیش‌فرض کارکنان است و به Google Drive، Slack و خود Asana وصل است. روال کار این است که ورودی‌های بی‌ساختار، مثل یک ایده، یک رشته‌ی Slack، ضبط جلسه‌ی Zoom یا گزارش Databricks، با Claude بررسی می‌شوند تا قدم‌های بعدی روشن شود. بعد موارد قابل‌اقدام به پروژه و تسک تبدیل می‌شوند. از این‌جا به بعد ایجنتها میتوانند کار را جلو ببرند، چون سه چیز دارند: حافظه‌ی پایدار، اعتبارنامه‌ی خودشان و زمینهی مشترک.
توصیه‌ی مقاله ساده است: با فکر خودتان شروع کنید، تا وقتی قدم بعدی روشن نشده Claude را هم‌فکر نگه دارید، و بعد کارهای قابل‌اقدام را جایی ثبت کنید که هم‌کاران و ایجنتها ببینند.
هر ایجنت یک نقش، ابزار و دسترسی
ایجنت‌های Asana بر اساس نوع کار سازمان‌دهی شده‌اند: نویسنده‌ی محتوا، تحلیل‌گر بینش، مدیر پروژه، کارشناس پذیرش درخواست، تحلیل‌گر و هماهنگ‌کننده‌ی کمپین. هر کدام با مهارت‌های آماده (بر اساس پژوهش Asana درباره‌ی این‌که مشتری‌ها این کار را چطور انجام می‌دهند) و یکپارچگی‌هایی مثل HubSpot و درایو اسناد می‌آید. صفحه‌ی پروفایل هر ایجنت نام و هدف، کاربران، مدیران، دستورالعمل‌ها، مهارت‌ها، یکپارچگی‌ها و مجوزهایش را نشان می‌دهد.
دسترسی را می‌شود به پروژه‌های مشخص یا همه‌ی پروژهها، اسناد مشخص، اپ‌های مشخص یا ترکیبی از این‌ها محدود کرد. مهم‌ترین محافظ این است که دسترسی مؤثر ایجنت در هر اجرا به دسترسی کسی که آن را فعال کرده سقف دارد. ایجنت می‌تواند از محتوای عمومی وسیع استفاده کند، ولی چیزی را که در یک فضای خصوصی یاد گرفته به کسی که اجازه‌ی دیدنش را ندارد نشان نمی‌دهد.
کار کردن با ایجنت را از آموزش دادنش جدا کنید
Asana ایجنت‌هایش را «هم‌تیمی هوش مصنوعی» می‌نامد. این هم‌تیمی‌ها حافظه‌ی مشترک دارند: دستورهای قبلی را به خاطر می‌سپارند و چند کاربر میتوانند از همان حافظه استفاده کنند. ولی همه نمی‌توانند حافظه را عوض کنند. هر کسی می‌تواند روی یک تسک بازخورد بدهد و آن بازخورد فقط روی همان تسک اثر دارد؛ ثبت بازخورد در حافظه‌ی دائمی، یا برگرداندن و حذف آن، فقط کار مدیران و ویرایشگرهاست.
مثال مقاله گویاست: تیم ارتباطات صاحب لحن و صدای برند Asana است، پس مدیر هر ایجنتی است که متن می‌نویسد. مدیر ارشد محصول می‌تواند با همان ایجنت پیش‌نویس بنویسد، ولی نمی‌تواند رفتارش را تغییر دهد. نتیجه این‌که در هر تیم فقط یکی دو نفر لازم است در مهارت‌ها، رفتار و حافظه‌ی ایجنت عمیق شوند و بقیه از تنظیمات آن‌ها سود می‌برند.
- برای هر ایجنت مشخص کنید چه کسی آموزشش می‌دهد و چه کسی فقط با آن کار میکند.
- ویرایشگرها را از تیمی انتخاب کنید که صاحب همان استاندارد است، مثل لحن برند یا قواعد برنامه‌ریزی.
- حافظه را به‌تدریج بسازید: از ایجنت بخواهید تصمیم‌های ارزشمند را نگه دارد و موارد کهنه را حذف کند.
کار ایجنت باید دیده شود
وقتی تسکی به یک هم‌تیمی هوش مصنوعی سپرده می‌شود، همه‌ی کسانی که به آن دسترسی دارند می‌بینند ایجنت مشغول است. ایجنت برنامهی پژوهش و قدم‌هایش را منتشر میکند تا دیگران کامنت بگذارند و مسیرش را تصحیح کنند. در یک نمونه، یکی از اعضای تیم ارتباطات از ایجنت خواست یک سند توجیهی برای سخنرانی را بازبینی کند و متن سخنرانی قبلی‌اش را هم در آن بگنجاند. یک درخواست کوتاه با منشن ایجنت در تسک کافی بود، چون همه‌ی مطالب مرجع از قبل در Work Graph بود؛ و هم‌کارانش درخواست، پاسخ و رفت‌وبرگشت‌ها را می‌دیدند.
استدلال Bose این است که یک گفتوگوی خصوصی با ایجنت، حتی اگر نتیجه‌اش عالی باشد، پرامپت و تکرارها را از بازبینها پنهان میکند و آن‌ها نمی‌توانند روی راهنمایی‌ای که با آن مخالف‌اند هم‌نظر شوند. تسک مشترک درخواست، مخالفت‌ها و خروجی را یک‌جا نگه می‌دارد و بازبین می‌تواند دستورالعمل پشت خروجی را اصلاح کند.
سه کاری که Asana به ایجنتها سپرده
۱. پاسخ به سؤال‌های محصول از Slack
فروشنده‌ها و تیم موفقیت مشتری سؤال‌های محصول را در یک کانال مشترک Slack می‌پرسیدند؛ سؤال‌ها تکرار می‌شد و هر بار کارشناس‌ها صدا زده می‌شدند. پایگاه دانش هم جواب نمی‌داد، چون پاسخ‌ها ظرافت دارند و مدام عوض می‌شوند. حالا یک اپ Asana در کانال هر سؤال را به تسک تبدیل میکند و ایجنت آن را برمی‌دارد:
- اگر راهنمای تأییدشده وجود داشته باشد، با لینک منبع جواب می‌دهد.
- اگر جوابی نیست و سؤال یک کمبود محصول را نشان می‌دهد، در پروژه‌ی ورودی تیم محصول تسک می‌سازد و آن را به بک‌لاگ اضافه میکند.
- اگر همان سؤال مدام تکرار می‌شود، برای تیم توانمندسازی تسک می‌سازد تا آموزش و مستندات به‌روز شود.
۲. گزارش روزانه‌ی تمدیدهای پرریسک
مدیر ارشد مشتریان قبلاً هر هفته گزارشی دستی از تمدیدهای در خطر می‌گرفت که از به‌روزرسانی‌های مدیران موفقیت مشتری جمع می‌شد؛ با هزاران مشتری، کاری طاقت‌فرسا و واکنشی بود. حالا یک هم‌تیمی هوش مصنوعی به نام At-Risk Renewal همه‌ی تسک‌های تمدید پرریسک را با به‌روزرسانی‌ها، یادداشت‌های وضعیت و کامنت‌هایشان می‌خواند و هر صبح یک خلاصه‌ی ساختاریافته در سه دسته می‌فرستد: روند مثبت، روند منفی و پیگیری‌های پیشنهادی؛ اول نمای جهانی و بعد به تفکیک منطقه. گیرنده‌ها، یعنی مدیر ارشد مشتریان، مدیر ارشد درآمد و مدیران منطقه‌ای، میتوانند سؤال بعدی بپرسند و به ایجنت یاد بدهند در اجراهای بعد چه چیزی را به خاطر بسپارد. حرف Bose این است که گزارش یک‌باره را هر کسی می‌تواند از Claude بخواهد؛ هدف، گزارشی استاندارد در فضای مشترک است که با هر اجرا بهتر می‌شود.
۳. برنامه‌ریزی چرخه‌های مهندسی در Command
حلقه‌های خودکار کدنویسی Asana، که بازخورد مشتری را جمع و خلاصه می‌کردند و ایجنت‌های کدنویس را برای ساختن Pull Request راه می‌انداختند، باعث شدند چرخه‌ها و انتشارها عقب بیفتند؛ تغییرهای خودکار چرخه‌ها را شلوغ می‌کرد. جمع‌بندی Bose: تولید کد دیگر گلوگاه نیست؛ برنامه‌ریزی، تصمیم‌گیری و پالایش گلوگاه است.
در Command by Asana هر فضای تیمی ۱۰ تا ۱۲ مهندس را روی یک محصول پوشش می‌دهد. ایجنتها تابلوی کارهای برنامه‌ریزی‌نشده را از بازخورد مشتری و کانال بازخورد Slack پر میکنند، آدم‌ها تصمیم می‌گیرند چه چیزی وارد چرخه شود و Command زمان تکمیل را در سه حالت خوش‌بینانه، متعادل و محتاطانه پیش‌بینی میکند. هر تیکت به یک نفر یا یک ایجنت کدنویس سپرده می‌شود. مدیر می‌تواند در چت بپرسد چرا یک انتشار عقب افتاده و با چه بده‌بستانی جبران می‌شود، و چون داده‌ها از طریق سرور MCP شرکت در دسترس Claude است، حتی بدون باز کردن Command هم می‌شود وضعیت را پرسید.
برای تیم‌های ما چه معنایی دارد؟
این بخش برداشت خود ماست. بیشتر تیم‌ها ابزار مدیریت کار دارند، چه Asana و Jira باشد چه یک ابزار داخلی، و درس اصلی این مقاله به ابزار خاصی وابسته نیست:
- ایجنت را به ابزار کار فعلی‌تان بیاورید، نه برعکس. اگر کار تیم در تسک و تیکت ثبت می‌شود، ایجنت هم باید همان‌جا تسک بگیرد و گزارش بدهد. یک سرور MCP روی ابزار مدیریت کار معمولاً اولین قدم خوبی است.
- برای ایجنت حساب و هویت جدا بسازید. با توکن شخصی یک نفر کار نکند؛ این‌طوری معلوم است چه کسی چه کرده و دسترسی‌اش قابل محدود کردن است.
- دسترسی را به کاربر فراخواننده ببندید. اگر ایجنت به دادهی حساس (مالی، منابع انسانی، قرارداد) دسترسی دارد، هر پاسخ باید با سطح دسترسی همان کسی که پرسیده بررسی شود.
- یک «صاحب» برای رفتار ایجنت تعیین کنید. حافظه و دستورالعمل‌هایی که همه بتوانند عوضشان کنند، خیلی زود متناقض می‌شوند.
- با کارهای تکراری شروع کنید. سؤال‌های تکراری کانال پشتیبانی و گزارش‌های هفتگی دستی همان جاهایی‌اند که Asana هم از آن‌ها شروع کرد.
یک نکته‌ی منصفانه هم بگوییم: این مقاله مطالعه‌ی موردی خود شرکت است و عدد مشخصی درباره‌ی زمان صرفه‌جویی‌شده یا دقت ارائه نمی‌دهد؛ ادعاهایش درباره‌ی بهره‌وری کیفی‌اند.
پرسش‌های پرتکرار
Work Graph در Asana چیست؟
مدل دادهی Asana که هدفها، پروژهها، تسکها و گفتوگوها را همراه با مالک، مشارکتکنندهها و وابستگیهایشان به هم وصل میکند. ایجنتها در Asana روی همین مدل کار میکنند، نه روی یک زمینهی جداگانه.
چرا دسترسی ایجنت به دسترسی کاربر محدود می‌شود؟
چون ایجنت ممکن است در یک فضای خصوصی چیزی دیده باشد. اگر دسترسی‌اش به دسترسی کسی که آن را صدا زده سقف داشته باشد، اطلاعات به کسی که اجازه‌ی دیدنش را ندارد نشت نمی‌کند، در حالی که ایجنت همچنان از محتوای عمومی استفاده میکند.
فرق بازخورد دادن به ایجنت با آموزش دادن آن چیست؟
در Asana بازخورد هر کاربر فقط روی همان تسک اثر دارد. ثبت بازخورد در حافظه‌ی دائمی، که روی همه‌ی کارهای بعدی ایجنت اثر می‌گذارد، فقط از مدیران و ویرایشگرها ساخته است؛ معمولاً کسانی که صاحب همان استاندارد، مثل لحن برند، هستند.
چرا کار ایجنت باید در فضای مشترک انجام شود؟
در گفتوگوی خصوصی، پرامپت و تکرارها از بقیه پنهان است. در تسک مشترک درخواست، برنامهی ایجنت، کامنتها و خروجی کنار هماند و بازبینها میتوانند مسیر را اصلاح کنند و دستورالعمل را بهتر کنند.
آیا این رویکرد فقط با Asana شدنی است؟
نه. اصلها، یعنی ایجنت داخل ابزار کار فعلی، هویت و دسترسی جدا، کنترل حافظه و کار قابلدیدن، با هر ابزار مدیریت کار که API یا سرور MCP داشته باشد پیادهشدنی است.
منبع
Aleksandra Todorova و Kristen Swanson، Agents you can coach: how Asana builds human-agent teams with Claude، Claude by Anthropic، ۲۹ سپتامبر ۲۰۲۶. عددها و ادعاها از همین منبع است؛ نمودارها را نکست ادمین بر اساس توضیحات آن بازطراحی کرده و بخش «برای تیم‌های ما چه معنایی دارد؟» تحلیل خود ماست.
