Як три команди будують спільний AI — і що з цього беремо ми

Крамер розкладає «спільний AI» на чотири частини — і каже, що команди провалюються не на моделі, а на трьох інших:

• Інструмент — де саме AI працює (Claude Code, Cowork, свій конструктор агентів).
• Контекст — знання компанії, які туди заходять: стратегії, дані, документи.
• Уміння — навички, агенти, підключення до інструментів, робочі процеси.
• Спільність — звички й процеси, завдяки яким покращення однієї людини з’являється в наступному прогоні у всіх.

Головна теза листа: скопіювати чужу систему не вийде — кожна з трьох команд виграє на СВОЇЙ перевазі, і саме тому їхні системи виглядають зовсім по-різному.

Контекст. Внутрішня база знань і публічна документація живуть на одній інфраструктурі — різниця лише в правах доступу. Файли в теках, версії під контролем, редагувати може будь-хто з команди.

Оновлення себе. Система стежить за подіями — зміна в продукті, коміт, реліз-ноут, оновлення інструмента — і сама пише чернетку правки. Людина її затверджує. Це весь механізм: тригер → чернетка → тап людини.

Нова роль. Ітан почав технічним письменником, став «інженером знань»: його робота — не писати документи, а будувати й затверджувати ці автоматизації. Співзасновник каже, що така роль стане стандартною в кожній компанії, що швидко росте.

Замір, що вражає. Під час переїзду на нову базу знань — 419 внесків за 66 днів, і кожен у команді щось написав.

Уміння, що роблять роботу. Спільний «маркетинговий мозок» у Cowork, що черпає з бази знань; бренд-система в Claude Design; підключення до CRM, записів дзвінків і трекера продукту; агент, що кожні пів години дивиться реєстрації й активність на сайті та кидає сигнали продавцям у Slack; наскрізні агенти компанії — від «звернення в підтримку → правка в коді» до ранкової зведки для продажів.

Ще один висновок, суто маркетинговий. Агентський трафік на сайти документації вже 66% — у січні було 15%. Тобто в кожного тексту тепер два читачі: людина й агент.

Контекст. Агенти не читають підготовлені документи, а ходять по інструментах напряму через їхні інтерфейси — CRM, сховище даних, збагачувачі. Свіжий контекст збирається на КОЖНОМУ прогоні, а не лежить готовий. Поверх цього — кілька написаних людьми документів-настанов (наприклад, як інакше поводитися з теплим і холодним лідом).

Що це дає в цифрах. Агент для продавців сам бере нового ліда, перевіряє історію листування, досліджує компанію по вебу й інструментах і кладе чернетку в особистий Slack продавцю. Результат за їхніми словами: конверсія в кваліфікованого ліда виросла в 3,5 раза, воронка втричі, повернено близько 40 годин на місяць, щотижня ним користуються 86% команди.

Агент, що лагодить агентів. Окремий механізм дивиться на збої, збирає їх у названі проблеми, читає код, знаходить причину й пише виправлення на затвердження команди. Одне таке виправлення здешевило прогін збагачення десь на 60%.

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

Стандарт якості агента (від керівника їхньої GTM-інженерії): легкий у вжитку · не прив’язаний до однієї моделі · простежуваний, тобто ти можеш зрозуміти й полагодити · такий, що сам себе покращує.

Контекст. Живе в Notion, бо команда там і так працює. Кожен напрямок має власника, який записує свою стратегію документом за ЄДИНИМ стартовим шаблоном — однакова структура робить документи читними для агента без зайвих зусиль автора. Навичка звітності спершу читає стратегічний документ свого напрямку, потім рахує.

Щомісячний прохід проти протухання. Окремий процес перевіряє джерела й пінгує кожного власника документа освіжити свій. Це не разова акція, а рутина.

Уміння, що роблять роботу. Місячні звіти по кожному напрямку; правки сайту (питання-відповіді, заміна картинок, тести) без розробника; пошук веток на Reddit, які найчастіше цитують AI-пошуковики; лагодження биті посилань — перший прогін зрізав 87% внутрішніх; агент, що веде чергу партнерських заявок із щоденним людським переглядом.

Як шириться. Кожен будує локально зі стартових шаблонів. Що вийшло добре — переглядає одна людина-«тримач стандарту» і викочує в спільний набір, звідки воно автоматично з’являється у всіх. Що будується — видно в задачнику, про готове пишуть у спільному каналі.

• Дві полиці умінь. Ті, що роблять роботу, і ті, що доглядають саму систему. Автор прямо каже: зрілі команди відрізняються НАЯВНІСТЮ другої полиці.
• Контекст іде поперед умінь. Усі троє почали з шару знань, а не зі списку навичок.
• Людина затверджує все, що йде назовні. Без винятків у всіх трьох.
• Проти протухання — рутина, не пильність. Місячний прохід, автоматичні чернетки, або агент, що сам ловить збої.
• Один відповідальний на кожну з чотирьох частин. Модель різна — одна людина, мала команда, чи розподілено з центральним переглядом — але безхазяйних частин немає.
• Технічність не потрібна. Директорка з комунікацій Buffer прийшла «нетехнічною» і за тиждень зібрала шість інструментів.
• Локальне рішення — нормально. Його зводять у спільне лише коли випадок доріс, а не одразу.

У нас понад пів сотні навичок і нуль даних про те, які з них справді викликаються. LangChain має теплову карту; Buffer її НЕ має саме тому, що навички запускаються в кожного локально — і автор називає це прямою вадою такого устрою. У нас той самий устрій. Поки лічильника немає, питання «де дублі, а де прогалини» не має відповіді — тільки здогади.

Наші навички, що доглядають систему, вже існують — перевірка збірки, ревізії, спостерігач за навичками, архітектурна приймання. Але вони перемішані в одному переліку з робочими, тому перекос не видно. Один рядок «робота / догляд» у кожній навичці дає карту зрілості за пів години.

Легкий у вжитку · не прив’язаний до однієї моделі · простежуваний · самополіпшуваний. Це вже сформульований чотирипунктовий фільтр, який можна прикласти до нашої приймальної перевірки нового компонента. Особливо «простежуваний»: чи можу я зрозуміти й полагодити це через місяць.

Механізм Mintlify майже точно збігається з нашим: зміна відбулась → система пише чернетку → Юра затверджує. Різниця в тому, що в них тригери прив’язані до подій у продукті (реліз, коміт, оновлення інструмента), а в нас — переважно до розкладу. Прив’язка до подій дає свіжість без зайвих прогонів.

У нас збої вже збираються, але списком. Крок, якого бракує, — кластеризація в кілька названих проблем із причиною, а не сотні окремих рядків. Саме це перетворює журнал збоїв на чергу виправлень.

Buffer тримає всі стратегічні документи на одному стартовому шаблоні — не заради краси, а щоб агент їх однаково розбирав. У нас шаблони є, але для нотаток; для опорних документів, які агенти читають першими, єдиної форми немає.

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