AI-інструменти для роботи й освіти

На чому Asana будує Agentic Work Management

У розмові на VB Transform 2026 директор із продукту Asana Арнаб Бозе пояснив, що Agentic Work Management, або AWM, задуманий не як ще один персональний чатбот, а як робоча система для команд, де AI-агенти діють поруч із людьми. Ключова відмінність — агент не обмежується одним запитом користувача, а підключений до спільного контексту компанії.

Цей контекст Asana бере з власної архітектури Work Graph, яку компанія розвиває 18 років. У ній найменша одиниця роботи — задача з відповідальним і дедлайном. Задачі входять у проєкти, проєкти — у портфелі, а портфелі пов’язані з цілями компанії. За описом Asana, такий граф дає змогу бачити, наприклад, як затримка дизайнерської задачі впливає на ціль із виручки.

• Work Graph працює як актуальний реєстр: хто що робить, до якого строку і навіщо.
• AWM використовує цей реєстр, щоб агент міг бачити цілі компанії, оновлювати статуси проєктів і працювати зі спільною пам’яттю.
• На відміну від стандартного copilоt, агент у такій моделі не прив’язаний лише до одного користувача або локального файлу.

Чому спільна пам’ять потребує обмежень

Головна управлінська проблема, яку описав Бозе, — як дозволити агенту вчитися з робочих процесів і людського фідбеку, але не допустити витоку контексту між співробітниками з різними правами доступу. Це особливо важливо для конфіденційних проєктів.

Приклад із джерела: якщо керівник використовує AWM для робочого процесу навколо секретної M&A-угоди, інший співробітник без доступу до цього проєкту не має отримати користь від тієї самої спільної пам’яті так, щоб розкрити прихований контекст. За словами Бозе, Asana спроєктувала систему контролю доступу, яка відрізняє ситуації, коли потрібно створювати пам’ять, від простого виконання задачі.

• Пам’ять агента формується не автоматично для всіх однаково, а з урахуванням прав доступу.
• Система має розділяти виконання конкретної дії та збереження нового знання для майбутніх взаємодій.
• Для бізнесу це означає, що AI-агент у командній роботі потребує таких самих правил доступу, як і людина в корпоративній системі.

Як система обирає модель і знімає prompt engineering із користувача

Ще одна деталь із розмови — динамічний вибір моделей. Ідея Asana в тому, щоб працівник не мусив сам думати, який запит написати, який контекст прикріпити і яку модель використати. Користувач ставить задачу AI-колезі, а система сама підбирає потрібні джерела й рівень моделі.

У наведеному прикладі, якщо агенту доручають підготувати опис вакансії генерального менеджера, він звіряється з публічними вакансіями, внутрішнім style guide Asana і документами з продуктовими вимогами. Для складних задач запит може піти до важкої frontier-моделі; Бозе назвав як приклади Anthropic Opus і моделі OpenAI. Простіші задачі система спрямовує до швидших і дешевших моделей.

• Складні задачі отримують потужнішу модель.
• Легші задачі можуть виконуватися дешевше й швидше.
• Користувачеві не потрібно вручну збирати prompt, контекст та вкладення.

Що вже відомо про доступність — і що ні

AWM уже працює в production: за словами Бозе, у Asana є кілька клієнтів, які вже користуються системою і мають успішні результати. Окремо згадано FedEx, яка опублікувала власний case study про перехід.

Водночас у наданому джерелі немає конкретної дати запуску для всіх клієнтів, умов підключення, переліку тарифів або ціни. Також не наведено повного списку доступних моделей, технічних лімітів чи вимог до розгортання. Тому практичний висновок обережний: для компаній, які вже працюють в Asana і хочуть агентів у реальних процесах, AWM показує напрямок — AI має бути підключений до робочого графа, прав доступу та корпоративної пам’яті. Але застосувати це поза умовами, які Asana окремо не описала в матеріалі, за цим джерелом поки неможливо.