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 — та вашу логіку: як визначається напрям наради і що вважати простроченим. Тобто дванадцять днів ідуть на вашу задачу, а не на фундамент.

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

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

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

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

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

Етапи

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

Бюджет і строки етапів 2–4 чесно рахувати після першого: коли я побачу ваші реальні бази, документи й обсяг нарад, цифра буде обґрунтована, а не взята зі стелі. Називати її зараз означало б або перестрахуватись, або потім прийти по добавку.

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

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

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

Живі приклади моїх робіт

Все нижче можна відкрити просто зараз і потикати — це робочі системи, а не скріншоти.