Протягом тривалого часу операційна модель формувалася популярними на той час інструментами. Asana, Jira та Linear вбудовували спринти, щотижневе планування та канбан у ритуали, які компанії могли систематично впроваджувати для керування процесами. Інструменти формували операційну модель, а операційна модель формувала інструменти. Це була не найкраща операційна модель, а просто найкраща модель, яку підтримували наявні інструменти. Коли інструмент стає таким гнучким, як Buzz, ці обмеження зникають. Тепер операційна модель має наздогнати можливості, які надає інструмент.
Коли обговорення в Buzz стає діагностикою, завданням, виправленням і обговоренням проблеми, воно об'єднує те, що раніше вимагало різних інструментів, в одну тему, яку може переглянути кожен. Це повний контекст, який дозволяє користувачеві зрозуміти, чому було прийнято рішення. Також існують CLI-команди для всього в Buzz, що дозволяє агентам створювати власні канали, оновлювати власну пам'ять та виконувати інші дії на рівні користувача. Користувачі можуть налаштовувати поведінку, інструменти, моделі та механізми, що керують кожним агентом, а також встановлювати правила для агентів, специфічні для каналу або теми обговорення. Якщо цього недостатньо, додаток також має відкритий код, тому користувачі можуть змінювати, покращувати або робити внесок, щоб зробити Buzz стандартним інтерфейсом для роботи.
Buzz настільки гнучкий, що питання не в тому, чи може він робити те чи інше, а в тому, як його налаштувати, щоб він робив саме те, що вам потрібно. Я експериментував з агентами, які створюють дошку для кожного обговорення та діляться нею між усіма агентами, що працюють у цьому обговоренні. Це забезпечує кращу передачу контексту без додаткових зусиль з мого боку, оскільки правила взаємодії визначені в каналі. Існує набагато більше способів експериментувати.
З такою гнучкістю вузьким місцем стає операційна модель. Як організувати свої ритми та процеси, щоб максимізувати результативність за допомогою доступних інструментів? Яка цінність інструменту відстеження проєктів, якщо користувачі можуть відстежувати завдання безпосередньо як обговорення в Buzz? Що потребує відстеження, якщо все вже зафіксовано в обговоренні людьми та агентами?
Обмежувальним фактором більше не є швидкість, з якою користувач може копіювати та вставляти з одного інструменту в інший. Ми експериментували з цим кілька місяців і ще не визначили операційну модель, яка максимізує цінність Buzz для організації. Робота над Buzz за допомогою Buzz поставила новий набір запитань, яких ми раніше не ставили: Яка правильна модель співпраці між агентами? Як це змінюється для роботи, не пов'язаної з інженерією? Який найкращий рівень абстракції для ефективної роботи агентів? Як визначити, як команда агентів може добре співпрацювати без вас? Якщо агенти можуть створювати власні канали та запрошувати лише інших агентів, наскільки далеко команда може зайти в автоматизації?
Особисто для мене було чудово працювати над новими способами співпраці. Найочевидніше те, що нам ще багато потрібно спробувати.
Так багато нашої роботи потребує співпраці, і це не обов'язково має закінчуватися на ШІ. Вигадуйте нові способи роботи з Buzz як інтерфейсом та координаційним рівнем, що об'єднує все це - buzz.xyz / github.com/block/buzz
