Microsoft закликає не починати з агентів

«Лін перед агентами»: покроковий розбір

Плейбук ділить ШІ-трансформацію на три підходи: точкове озброєння окремих ролей інструментами (наприклад, Copilot для конкретної посади), перебудова наявного процесу під ШІ та побудова процесу з нуля, коли ШІ закладено в дизайн одразу. Для компаній, які переходять від копілотів до агентів, ключовий — другий підхід. Microsoft називає його «лін перед агентами» і описує як послідовність кроків, а не як разове рішення «додати агента».

• Картувати процес повністю, від початку до кінця, а не тільки ту ділянку, куди планують поставити агента
• Прибрати зайві погодження та передачі роботи між відділами
• Створити єдине джерело даних, на яке спиратимуться і люди, і агенти
• Призначити відповідальних за процес на стику функцій, а не в межах одного відділу
• Побудувати спільну інфраструктуру оркестрації та моніторингу, яку можна перевикористовувати для інших процесів
• Заздалегідь визначити, які рішення в процесі лишаються виключно за людиною

Причина такого порядку — власний досвід Microsoft. За словами Кетлін Гоган, директорки зі стратегії й трансформації компанії, спочатку ШІ впроваджували як звичайне ПЗ: розгортання, навчання, метрики використання. Виявилося, що доступ і активність самі собою не дають бізнес-результату. Звідси головне правило плейбука: ліцензія на інструмент для 100 000 співробітників сама собою не змінює, як виконується робота.

Ще два приклади: продуктова команда і відділ продажів

Команда з дев'яти людей, що будувала всередині Microsoft продукт під назвою Copilot Cowork, отримала завдання проєктувати процес розробки з чистого аркуша, а не додавати агентів до вже налагодженого циклу. Робота була побудована навколо трьох елементів: специфікацій, що описують намір, оцінок (evals), які визначають, як виглядає хороший результат, і контексту, який отримують агенти. Люди в команді фактично перейшли в ролі «мета-інженерів», «мета-дизайнерів» і «мета-менеджерів продукту», працюючи з агентами на основі спільного контексту й однакового набору критеріїв оцінки. Результат — 18 600 комітів (123 на день), 9,3 млн рядків коду і перший реліз продукту за 35 днів. Сама Microsoft застерігає: це показник одного окремого проєкту, а не орієнтир для розробки в компанії загалом.

Другий приклад — з продажів. У пілоті за перше півріччя 2024 року взяли участь 687 продавців Microsoft 365 Copilot: використання пріоритетних сценаріїв ШІ зросло втричі, дохід на одного акаунт-менеджера — на 9,4%, а частка закритих угод була на 20% вищою порівняно з продавцями, які користувалися Copilot менше. Дані спостережні, а не з контрольованого експерименту, тому Microsoft сама уточнює: не можна стверджувати, що саме Copilot спричинив усе покращення. Висновок компанії інший і практичніший: заклик «використовуйте ШІ більше» дає менше ефекту, ніж пошук конкретних моментів у роботі, де вузькоспеціалізований агент реально закриває задачу.

Три рівні автономності — де межа для агента

Плейбук пропонує модель із трьох рівнів. На першому співробітники працюють з ШІ-асистентом як з інструментом. На другому агенти стають повноцінними учасниками команди й відповідають за окремі завдання під керівництвом людини — приклад із ланцюга постачання, де агенти в межах заданих прав можуть самостійно оновлювати або скасовувати замовлення на закупівлю, це саме другий рівень. На третьому людина лише задає напрям, а агент виконує весь бізнес-процес і звітує, коли це потрібно.

Перехід на вищий рівень залежить не від того, наскільки розумна модель, а від готовності даних та інфраструктури, доступу агента до потрібних інструментів, чітко окреслених меж ризику і готовності змінити ролі людей у процесі. Один і той самий напрямок роботи, наприклад розробка ПЗ, може одночасно існувати на різних рівнях: частина завдань — з асистентом, інша частина — вже делегована автономному агенту.

На чому тримається перевага і що перевірити перед тим, як довіряти результату

Головний архітектурний аргумент плейбука: конкурентна перевага не повинна залежати від конкретної моделі. Microsoft виділяє чотири категорії власної інтелектуальної власності, які варто захищати: позицію компанії щодо свого ринку, власні дані й процеси, критерії якості («смак») і межі ризику, в яких агенту дозволено діяти самостійно. Ці критерії перетворюються на приватні оцінки (evals), проти яких безперервно звіряють роботу ШІ-систем — Microsoft називає цей контур «машиною для підйому в гору» (hill-climbing machine). У власній архітектурній схемі компанії базова модель прямо позначена як «взаємозамінна» — саме шар оцінок, контексту та контролю має лишатися постійним активом компанії.

Оцінювати варто не активність, а бізнес-результат, і на різних горизонтах: зміни на вході (навчання, готовність) видно вже за 2-4 тижні, зміни в самому процесі — за 1-3 місяці, ефект на продуктивність — за 3-6 місяців, а вплив на виручку чи задоволеність клієнтів — тільки після півроку й більше. Компанія, що судить про успіх ШІ за кількістю ліцензій чи промптів, побачить хибну картину задовго до появи реального результату.

Перш ніж довіряти результату, який пройшов внутрішню перевірку (evals), варто пам'ятати: за опитуванням 108 підприємств лише 13% повністю довіряють автоматизованій оцінці вже сьогодні. Серед компаній, де агент уже пройшов внутрішні критерії, але потім провалився перед клієнтом, довіру зберегли лише 4% — проти 24% серед тих, кого ще не «обпікало». Це аргумент на користь незалежної перевірки результату агента людиною, а не лише покладання на власні бали оцінки.