Особисті AI-агенти вже давно вийшли за межі «чат-бота в Telegram». Один із розробників OpenClaw, Radek Sienkiewicz, кілька місяців послідовно розширював повноваження свого агента — від простого чату до системи, яка читає пошту, керує файлами, оновлює себе вночі, стежить за власним «здоров’ям» і готує робочі відповіді клієнтам. Його досвід показує, як виглядає життя, коли «ключі від комп’ютера» віддають ШІ — але роблять це не стрибком, а десятками дрібних кроків.

Інкрементальний підхід: від одного каналу до «ключів від життя»
Ключовий принцип — ніяких «великих запусків». Система не з’являється одразу як всесильний асистент, що керує всім. Вона росте разом із користувачем:
- старт з одного каналу (спочатку WhatsApp, потім Telegram, зараз Discord) — просто чат;
- додавання однієї простої задачі поверх цього каналу;
- ще один маленький workflow, ще одна автоматизація — і так далі.
Такий підхід дає дві важливі переваги:
- Мінімум катастрофічних збоїв. Якщо щось ламається, можна «відкотитися» на один крок назад, зрозуміти причину, зафіксувати, щоб не повторювалося, і рухатися далі.
- Непомітне ускладнення системи. Ззовні здається, що це «простий сетап», але в якийсь момент виявляється, що він уже складніший і функціональніший, ніж більшість публічних прикладів.
Цей же інкрементальний принцип спрацював і на рівні участі в проєкті: від користувача — до людини, що час від часу надсилає pull request, а потім до мейнтейнера.
Знання в Obsidian як ядро: коли ШІ бачить усе
Переломний момент — підключення особистої бази знань. У цьому випадку це Obsidian з приблизно 3 000 markdown-нотаток:
- робочі матеріали;
- особисті записи;
- задачі й проєкти;
- дослідження;
- статті;
- «вхідна» папка з посиланнями.
Усе це стає доступним агенту через кілька рівнів пошуку й пам’яті:
- звичайний пошук;
- QMD-пошук по Obsidian;
- окремі memory-файли для робочого простору.
На цьому шарі починається «магія» — не у вигляді абстрактних LLM-концепцій, а в дуже практичних сценаріях.
Автоматичне збагачення закладок
Один із показових прикладів — робота з посиланнями, які раніше просто «гнили» в закладках:
- Користувач кидає в «inbox» посилання — це може бути твітер-тред, стаття чи відео.
- Агент:
- аналізує вміст;
- додає теги;
- прописує контекст;
- шукає, що вже є в базі знань на цю тему;
- створює зв’язки з іншими нотатками.
Результат: замість мертвих закладок формується жива, пов’язана база знань. До того ж агент може проактивно підсвічувати старі нотатки, коли з’являється новий матеріал на близьку тему: «у тебе вже є ось це, це і це — подивись, як воно пов’язане». Часто це повертає до важливих ідей, про які користувач уже встиг забути.
Нічна зміна: що робить агент, поки ви спите
Між приблизно 3:00 і 6:00 ранку агент працює в «фоновому режимі», готуючи систему до нового дня. Серед типових задач:
- індексація всього вмісту (зокрема Obsidian і QMD-індексів);
- бекапи, щоб у разі збою втратити максимум кілька годин роботи;
- оновлення OpenClaw із власними скриптами:
- що можна оновлювати автоматично;
- що може зламатися і чому;
- як перевірити систему перед перезапуском;
- як гарантувати, що gateway повернеться онлайн.
У підсумку вранці користувач отримує:
- оновлену систему;
- свіжі індекси;
- готові дайджести пошти й календаря (якщо вони налаштовані).
Це і є «ambient operations» — фонові операції, про які не хочеться думати, але які мають відбуватися регулярно й надійно.
Три типи роботи агента: фон, фільтрація уваги й виконання
Щоб зрозуміти, як саме агент «веде життя» користувача, зручно розкласти його роботу на три основні типи задач.
1. Ambient operations: технічна «сантехніка» системи
Це все, що:
- має відбуватися регулярно;
- не потребує участі людини;
- критично для стабільності системи.
Сюди входять:
- оновлення;
- резервні копії;
- реіндексація;
- технічні перевірки «здоров’я» системи.
LLM тут часто взагалі не потрібна — достатньо скриптів «якщо сталося X — зроби Y».
2. Фільтрація уваги: що справді важливо просто зараз
Один із найпрактичніших шарів — attention filtering. Агент має доступ до:
- пошти;
- календаря;
- бази знань в Obsidian (де зберігається контекст про проєкти, дедлайни, домовленості).
Це дозволяє йому:
- розуміти, які листи й події справді термінові й важливі;
- співвідносити нові сигнали з поточними проєктами й завданнями.
Конкретні приклади:
- збій оплати Netflix — агент помічає лист, сигналізує в Discord, проблема вирішується за кілька хвилин;
- наближення продовження домену — замість того, щоб загубитися в інбоксі, подія підсвічується, домен вчасно продовжується;
- робочі листи по проєктах — агент читає лист, співставляє з нотатками в Obsidian і готує чернетку відповіді, яка вже чекає в папці Drafts.
Фактично це шар, де ШІ бере на себе роль «секретаря», який знає весь контекст і вміє відфільтрувати шум.
3. Execution: коли агент не лише радить, а й діє
Третій тип роботи — виконання задач. Тут агент:
- отримує інструкцію;
- використовує контекст із бази знань;
- запускає скрипти й інструменти;
- повертає результат або доводить задачу до кінця (у межах дозволених повноважень).
Для цього використовується набір Discord-каналів, кожен із яких відповідає певному типу роботи:
#general— стартові розмови, з яких часто народжуються нові окремі канали;#inbox— посилання для поповнення бази знань;#consulting— робота з клієнтами, проєктами, комерційними пропозиціями, дедлайнами й наступними кроками;#video-research— дослідження YouTube-контенту для наступних епізодів;#briefing— ранкові брифінги;#instagram— підготовка постів для соцмереж;#youtube— допомога у створенні відео;#openclaw— задачі мейнтейнера;#playground— полігон для експериментів з моделями, workspace’ами й конфігураціями пам’яті.
Якщо експеримент у #playground виявляється вдалим, його «підвищують» до постійної частини системи. Якщо ні — просто відкидають.
Архітектура: LLM для судження, скрипти для дій, пам’ять як вузьке місце
Система складається з кількох ключових компонентів, які мають працювати разом.
LLM як «мозок» для судження
Модель використовується там, де потрібні:
- розуміння тексту (листи, нотатки, статті);
- побудова зв’язків між сутностями;
- прийняття рішень, що робити далі.
Приклади:
- визначити, чи лист терміновий;
- знайти релевантні нотатки в Obsidian;
- сформулювати чернетку відповіді.
Скрипти як «м’язи» для дій
Скрипти відповідають за:
- конкретні дії без потреби в «розумінні»;
- повторювані процедури (бекапи, оновлення, перевірки).
Формула проста: «якщо сталося X — зроби Y». У таких випадках LLM можна взагалі не залучати.
Пам’ять: soulm, agents.md і critical-rules.md
Окремий пласт роботи — оптимізація пам’яті:
soulm— файл із «душею» агента (довгострокові установки й контекст);agents.md— опис агентів і їхніх ролей;critical-rules.md— файл із критичними правилами, які не можна ігнорувати.
На практиці виявилося, що:
- навіть якщо правила прописані в
agents.mdчиsoulm, агент може їх «забути»; - винесення ключових обмежень у
critical-rules.mdі розміщення посилань на нього високо вagents.mdпідвищує надійність виконання.
Система пам’яті еволюціонувала:
- від одного великого memory-файла;
- до цілого memory-фолдера;
- із додаванням механізмів на кшталт «dreaming» — просування важливих спогадів.
Перевага OpenClaw у тому, що все це — звичайні markdown-файли: їх можна читати, редагувати, перевіряти, як будь-який текст.
Слабкі місця: погана пам’ять, крихкі автоматизації й «шумні» нотатки
Чим складніша система, тим більше в ній потенційних проблем. Серед головних викликів:
Погана пам’ять, що накопичує помилки
Якщо:
- пам’ять налаштована невдало;
- кількість нотаток і спогадів зростає до тисяч;
— помилки починають накопичуватися й підсилюватися. Це вимагає:
- регулярної роботи з memory-файлами;
- продуманого структурування бази знань.
Крихкі автоматизації
Особливо небезпечні багатокрокові (10+ кроків) сценарії:
- вони майже гарантовано ламаються в якийсь момент;
- відлагоджувати їх складно.
Рекомендації:
- ділити складні сценарії на простіші;
- додавати ефективні guardrails (перевірки, валідації, fallback-логіку).
«Шумні» нотатки
З часом у базі знань накопичуються:
- застарілі;
- дубльовані;
- малокорисні записи.
Їх потрібно регулярно чистити, щоб не перетворити пам’ять на смітник, який заважає агенту знаходити справді важливе.
Слабкі межі й правила
Якщо:
- правила розмиті;
- файли на кшталт
soulmіcritical-rules.mdне продумані;
— агент може:
- робити зайве;
- не робити критично важливого.
Тому межі повноважень і поведінки потрібно оптимізувати під власні потреби, а не копіювати чужі конфігурації.
Оптимізація під «майбутнього себе»
Останній, але концептуально важливий принцип — оптимізувати систему не під «теперішнього себе», а під «майбутнього».
Мислення виглядає так:
- «минуле я» — лінивий, нічого не зробив, усе доводиться розгрібати зараз;
- «майбутнє я» — майже міфічна істота, яка «якось потім усе зробить».
Завдання агента — стати союзником майбутнього «я»:
- зробити максимум роботи наперед;
- підготувати контекст, відповіді, структуру;
- щоб, прокинувшись завтра, людина отримала світ, у якому «якнайбільше вже зроблено кимось іншим».
Це не про повну делегацію життя ШІ, а про системне зняття з себе рутинних і технічних навантажень — через десятки маленьких кроків, а не один великий стрибок.
Джерело
YouTube: I Gave an AI Agent the Keys to My Life (Here’s What Happened)


