AI Chief of Staff:
як я це бачу і як збираю

Головне за хвилину

У вашому ТЗ 29 розділів, але технічно там три різні системи, які просто живуть під одним ім'ям.

Перша — асистент, який відповідає на ваші запити: голос у Telegram, задача в Notion, подія в календарі, briefing до наради. Реагує на вас. Це кістяк, і він робиться першим.

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

Третя — аналітик, який бачить закономірності: які відділи системно зривають строки, де ви провалюєтесь в операційку, які цілі не підкріплені часом у календарі. Ця частина має сенс лише тоді, коли перші дві попрацювали кілька місяців і накопичили історію. Раніше їй просто нема чого аналізувати.

Що я перевірив перед тим, як це писати

• Notion з вересня 2025 змінив модель API: база даних стала контейнером для data sources, і запити тепер ідуть до джерела, а не до бази. Актуальна версія API — 2026-03-11. Код, написаний за старою схемою, на ваших базах просто поверне помилку.
• Google Calendar вміє надсилати сповіщення про зміни сам, але підписка живе 7 діб, і її треба поновлювати — інакше через тиждень асистент тихо перестане бачити нові зустрічі.
• Telegram не дає боту завантажити файл, більший за 20 МБ. Для голосових це приблизно година безперервного запису — для підсумку наради вистачає, але межа існує.
• З українською мовою у великих моделей все добре на розумінні і гірше на граматиці: у замірах UNLP-2026 навіть найкращі комерційні моделі виправляють помилки гірше за спеціалізовані рішення. На практиці це означає, що текст від асистента треба перечитувати, а не публікувати наосліп.

Що ви отримаєте на виході

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

І окремо про те, чого не буде: асистент не пише в групи без вашого підтвердження, не створює задачі про всяк випадок і мовчить, коли сказати нема чого.

Що додають наступні етапи

• Другий — нарада замикається в коло: надиктували підсумок, отримали розібраний список задач з відповідальними, підтвердили, і далі система сама стежить за строками й піднімає ескалацію, коли задача стоїть.
• Третій — асистент починає відповідати по ваших документах з Диска і розрізняти конкретних людей, а не тільки відділи.
• Четвертий — з'являється погляд згори: чи підкріплені цілі часом у календарі, хто системно зриває строки, скільки вашого тижня з'їдає операційка.

Архітектура

Ключове рішення одне: асистент не зберігає у себе копію вашого бізнесу. Notion, Calendar і Drive залишаються джерелами правди, асистент лише читає їх і пише назад. Своя база в нього теж є, але зовсім про інше: пам'ять рішень, домовленостей, історія перенесень та журнал власних дій.

Це важливо практично: ваші співробітники продовжують працювати в Notion, як звикли, нічого не переносять і не дублюють. Якщо асистента завтра вимкнути, бізнес не помітить втрати даних.

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

Calendar, Notion, Drive

Кілька Google Calendar як одна зайнятість

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

Про зміни Google повідомляє сам, тому нова зустріч у календарі помічається за секунди. Підписка живе тиждень, тому поруч стоїть і звичайна звірка — на випадок, якщо сповіщення загубиться.

Notion: працюємо з вашими базами як є

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

Ви написали, що виконавець у вас — керівник відділу, а прізвища не обов'язкові. Це навіть спрощує справу: зв'язка йде через назву відділу, окрема база людей на першому етапі не потрібна. Коли захочете деталізацію до конкретних співробітників — це вже етап з оргструктурою з Диска.

Про головне обмеження чесно: Notion пускає близько трьох запитів на секунду. Для великих баз це означає, що збирати дані «на льоту» під час розмови повільно, тому асистент тримає у себе свіжий зліпок задач і оновлює його у фоні. Ви цього не помічаєте — briefing збирається миттєво.

Google Drive як корпоративна база знань

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

Оргструктура і штатний розпис — окремий випадок. Їх недостатньо «проіндексувати»: з них треба дістати саме зв'язки ПІБ → посада → відділ → керівник і покласти у звичайну таблицю, щоб асистент відповідав однозначно, а не переказував документ. Коли файл змінюється, таблиця перебудовується.

Telegram і голос

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

Голосові українською

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

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

Друге — ваші власні назви й прізвища. Асистент отримує словник відділів і людей ще до розпізнавання, а потім звіряє почуте з реальною структурою. Якщо прозвучало прізвище, якого немає, він не вигадає задачу, а перепитає.

Чому підтвердження перед кожною дією — це правильно

Ви заклали це в ТЗ, і я б наполягав на цьому, навіть якби не заклали. Модель добре витягує задачі з живої мови, але саме на строках і відповідальних вона іноді додає те, чого не було. Тому між «почув» і «створив у Notion» завжди стоїть ваш екран підтвердження зі списком задач, де все можна виправити однією фразою.

Пам'ять асистента

Це те, що відрізняє Chief of Staff від бота з кнопками, і одночасно те, що найчастіше роблять погано.

Пам'ять у нас подвійна. Факти — люди, відділи, підпорядкування, задачі, рішення, дати перенесень — лежать у звичайній базі як таблиці. Тому на питання «скільки разів переносили цю задачу» відповідь буде точна, а не приблизна: це запит до бази, а не пригадування моделі.

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

Практично це виглядає так: ви питаєте, чому три місяці тому вирішили не запускати напрям, і отримуєте дату наради, формулювання рішення і посилання на протокол, а не переказ.

Цикл наради

Ваш пункт 15 — найцінніше місце в ТЗ, бо саме він перетворює набір інтеграцій на систему. Ось як замикається коло.

• За добу асистент бачить у календарі нараду, визначає напрям і керівника, збирає задачі відділу: прострочені, ті, що горять, і ті, що стоять без руху.
• За годину вам приходить briefing: що зроблено з минулого разу, що ні, де затори між відділами, і перелік питань, які варто поставити. Не звалище даних, а короткий список того, що потребує вашої уваги.
• Після наради асистент пише вам сам і чекає підсумку. Ви надиктовуєте, як вийде, без структури.
• Через хвилину ви бачите розібраний список: задача, відповідальний, строк, пріоритет. Строки, які ви не назвали, він пропонує сам, дивлячись на зміст, пріоритет і дату наступної наради.
• Після вашого «так» задачі лягають у потрібні бази Notion, а в групу напряму йде підсумок для команди.
• Далі починається контроль: проміжні точки для довгих задач, нагадування виконавцю, ескалація керівнику і тільки в критичних випадках — вам.
• До наступної наради усе це вже лежить у briefing як історія: що обіцяли, що зробили, що переносять удруге.

Про ескалації — найтонше місце

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

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

Правила, права, журнал

Права доступу

Проста і сувора модель: у кожного джерела є позначка рівня — особисте, напрям, керівники, загальне. Перед відправкою в будь-яку групу асистент перевіряє рівень, і якщо в матеріалі є щось не для цієї аудиторії, він не ріже текст на свій розсуд, а показує його вам. Це єдиний спосіб не отримати колись витік особистого календаря в групу відділу.

Тут є нюанс, про який краще сказати одразу: Telegram не дає боту побачити склад групи. Перевірити конкретну людину він може, а отримати список усіх учасників — ні, це закрито з боку самого Telegram. Тому рівень доступу прив'язується до групи цілком: ви один раз кажете, що ця група бачить, а хто саме туди доданий — зона вашого контролю. Інакше вийшла б ілюзія безпеки, а вона гірша за її відсутність.

Захист від шуму

Ваш пункт 27 я вважаю найважливішим у всьому ТЗ, бо саме на ньому вмирає більшість таких систем. Правило просте: критичне — одразу, важливе — у найближчий briefing, решта — тільки за запитом. За замовчуванням асистент мовчить. Якщо за тиждень від нього більше п'яти-шести повідомлень на день, значить, налаштування треба міняти, і це буде видно зі статистики.

Журнал і відкат

Кожна дія записується: що створено чи змінено, коли, за якою вашою командою, кому пішло повідомлення. Відкат є, але чесно про його межу: свою частину асистент відкотить повністю, а от повідомлення, яке вже прочитали в групі, скасувати неможливо — Telegram дозволяє видалити його, але не стерти з пам'яті людей. Тому дії, які видно іншим, завжди йдуть тільки після вашого підтвердження.

Стек і моделі

Нічого екзотичного: усе перевірене, з підтримкою і без ризику залишитись із мертвою бібліотекою через рік.

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

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

Чому 12 днів на перший етап — це не оптимізм

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

Писати з нуля доведеться саме інтеграції — Notion і Google Calendar — та вашу логіку: як визначається напрям наради і що вважати простроченим. Тобто дванадцять днів ідуть на вашу задачу, а не на фундамент.

Перевірка і здача

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

Спершу на копіях, не на живому

Уся розробка йде на тестовому просторі Notion і окремому календарі. Ваші робочі бази підключаються тоді, коли поведінка вже зрозуміла, і першими — тільки на читання. Зіпсувати задачі відділів у процесі просто нічим.

Автотести саме на тонкі місця

Не покриття заради покриття, а перелік випадків, на яких такі системи ламаються найчастіше:

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

Як приймаєте ви

До здачі я даю список сценаріїв, які ви проходите руками зі свого телефона: надиктувати задачу, перенести зустріч, отримати briefing, скасувати дію, подивитись журнал. Кожен пункт або працює, або ні, без «загалом усе гаразд». Приблизно на шостий день у вас уже є живий бот з календарем і задачами, тому перевіряти ви починаєте задовго до кінця етапу.

Вартість AI/API щомісяця

Це ваші прямі витрати на сервіси, не пов'язані з моєю роботою. Рахунок нижче — за офіційними цінами на серпень 2026, для сценарію: 4 наради з briefing щодня, близько 15 звернень до асистента, ранковий план, вечірній підсумок і тижневий аналіз.

Плюс сервер — близько $10 на місяць. У гривнях це приблизно тисяча щомісяця за помірного користування і десь півтори-дві за активного. Так чи інакше, це найдешевша частина всієї історії.

Обмеження, про які варто знати заздалегідь

Це не застереження на всяк випадок, а речі, з якими доведеться жити. Краще знати про них зараз, ніж під час здачі.

Етапи і бюджет

Порядок не випадковий: кожен наступний етап спирається на дані, які накопичив попередній. І кожен можна зупинити — те, що вже працює, працювати не перестане.

Кожен етап оплачується окремо, перед своїм стартом. Ви не берете на себе всю суму зараз: після першого ви дванадцять днів дивитесь на живого асистента і вже потім вирішуєте, чи потрібен другий.

Ціна першого етапу фіксована і не зміниться: 15 000 грн, як у моїй ставці. Другий порахований так само по роботах, тому теж твердий. А от цифри третього і четвертого позначені як орієнтовні свідомо — я ще не бачив ваш Диск і не знаю реального обсягу нарад. Точні назву після другого етапу, коли буде на чому їх обґрунтувати.

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

Що потрібно від вас для старту

• Доступ до Notion для інтеграції — до тих баз, які має бачити асистент.
• Доступ до Google Calendar: до всіх календарів, які входять у вашу зайнятість.
• Бот у Telegram і права адміністратора в групах напрямів, з якими він працюватиме.
• Півгодини вашого часу на початку: показати, які бази за що відповідають і як у вас називаються напрями. Це швидше, ніж я вгадуватиму зі структури.
• Ваші правила календаря: робочі години, скільки нарад на день прийнятно, що вважати особистим часом.

Доступи потрібні після резервування коштів у Сейфі — до того часу нічого передавати не треба.