Платформи на кшталт OpenClaw відкрили шлях до складних автономних AI‑агентів, але їхнє самостійне розгортання зазвичай вимагає API‑ключів, конфігурацій, інфраструктури та чимало часу. MiniMax пропонує іншу модель: Maxclaw — це їхній хостинговий сервіс на базі OpenClaw, який працює на власній моделі M2.7 і одразу постачається з інструментами для веб‑пошуку, генерації зображень і відео, виконання коду та інтеграціями з Telegram, Slack, мобільними й десктопними застосунками.

На цьому тлі особливо цікавою стає не лише технічна сторона, а й економіка таких агентів. Як саме MiniMax ціноутворює Maxclaw, що дають токен‑плани, і чи реально утримувати кілька повноцінних AI‑асистентів на одному акаунті без відчутних витрат?

Від фіксованої підписки до токенів: як MiniMax продає доступ до агентів

MiniMax пропонує два базові підходи до оплати: пряма підписка на агентів і універсальний токен‑план. Обидва варіанти працюють із Maxclaw, але орієнтовані на різні сценарії використання.

Перший підхід — це пряме ціноутворення за використання агентів MiniMax, включно з Maxclaw. Користувач оформлює підписку приблизно від 19 доларів на місяць і отримує пакет кредитів. Ці кредити витрачаються щоразу, коли запускається завдання на агентній платформі: спілкування з експертами, виконання задач Maxclaw, робота з вбудованими інструментами.

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

Такий формат особливо логічний для користувачів, які хочуть взаємодіяти з агентами переважно через готовий веб‑інтерфейс або застосунки, не заглиблюючись у API чи власні інтеграції. Підписка сприймається як плата за «готовий до роботи» сервіс: є Maxclaw, є понад 10 тисяч попередньо налаштованих експертів, є інтеграції з Telegram, Discord, Slack, мобільними клієнтами — і все це живиться з одного кредитного пулу.

Однак у міру того, як користувачі починають комбінувати агентів, кодування, генерацію зображень і відео, фіксована «агентна» підписка стає менш гнучкою. Саме тут у гру вступає токен‑план MiniMax.

Токен‑план як універсальний гаманець для тексту, голосу, зображень і відео

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

Стартовий рівень токен‑плану коштує приблизно 10 доларів на місяць. Це фактично вхідний квиток для індивідуальних користувачів, які хочуть спробувати Maxclaw, поекспериментувати з агентами, а заодно протестувати мультимодальні можливості — від генерації картинок до відео й голосу.

У межах токен‑плану MiniMax розподіляє квоти запитів між кількома напрямами:

по‑перше, це базові мовні моделі, які відповідають за текстові діалоги, логіку агентів, планування й аналіз;

по‑друге, моделі мовлення, що забезпечують синтез і, потенційно, розпізнавання голосу;

по‑третє, модулі генерації зображень, які використовуються як окремо, так і всередині Maxclaw‑експертів, орієнтованих на візуальний контент;

по‑четверте, Halo — відеогенераційні моделі, які дозволяють створювати відео на основі текстових описів чи інших вхідних даних.

Ключова ідея полягає в тому, що одна підписка покриває всі ці напрямки. Користувачеві не потрібно заводити окремі акаунти чи платити за кожен сервіс по‑різному. Якщо сьогодні більшість запитів іде в текстові моделі, а завтра — у генерацію зображень, усе це все одно списується з одного токен‑балансу.

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

Один токен‑план — кілька агентів: як працює зв’язка Maxclaw і MiniMax Plus

Окремий пласт — це інтеграція Maxclaw із токен‑планами через API‑ключ. MiniMax дозволяє «підв’язати» Maxclaw до існуючого токен‑абонемента, зокрема до Plus‑плану, так, щоб усі агенти й завдання використовували спільний пул токенів.

Технічно це виглядає просто: у Maxclaw є опція «підключитися до MiniMax coding / token plan». Користувач генерує API‑ключ у своєму акаунті MiniMax, вставляє його в інтерфейс Maxclaw — і з цього моменту агент працює не на окремій «агентній» підписці, а безпосередньо на токен‑балансі.

Це має кілька практичних наслідків.

По‑перше, зникає потреба оплачувати кожного агента окремо. Можна створити один Maxclaw для особистих задач, інший — для демонстрацій, третій — для конкретного проєкту чи навіть для іншої людини, і всі вони будуть «тягнути» ресурси з одного Plus‑плану.

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

По‑третє, це зручно для розробників, які хочуть поєднати Maxclaw із іншими сервісами MiniMax, зокрема з інструментами для кодування. Один і той самий токен‑план може одночасно живити й агентів, і бекенд‑скрипти, і мультимодальні експерименти.

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

Практична вартість: повноцінний асистент за «кілька доларів»

Теоретично універсальний токен‑план звучить зручно, але ключове питання — скільки це коштує в реальному використанні. Один із показових кейсів — персональний асистент Maxclaw, налаштований для нетехнічної користувачки, яка взаємодіє з ним щодня через Telegram.

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

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

Фактично це демонструє, що токен‑план може одночасно:

покривати особисті експерименти власника акаунта з Maxclaw і іншими сервісами;

живити кілька демонстраційних агентів;

обслуговувати окремого «клієнта» — у цьому випадку дівчину автора, яка користується асистентом як звичайним чат‑ботом у Telegram.

При цьому не виникає потреби купувати для неї окрему підписку чи налаштовувати індивідуальний білінг. Усе зводиться до одного рахунку за токен‑план, який, за рахунок гнучкого розподілу квот між моделями, виявляється достатньо містким навіть для кількох паралельних сценаріїв.

Чому модель «один план — багато можливостей» може стати стандартом

Підхід MiniMax до ціноутворення Maxclaw і супутніх сервісів показує, як може виглядати наступне покоління білінгу в екосистемах штучного інтелекту. Замість того, щоб змушувати користувача окремо рахувати токени для тексту, хвилини для голосу, кредити для зображень і відео, компанія пропонує єдиний токен‑гаманець, який розподіляється між усіма цими напрямами.

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

Для розробників і малих команд це спрощує планування витрат. Замість того, щоб прогнозувати споживання кожного окремого сервісу, достатньо оцінити загальне навантаження на платформу MiniMax і вибрати відповідний рівень токен‑плану. Якщо з часом з’являється потреба в більшій кількості запитів до мовних моделей чи Halo‑відеогенерації, можна просто перейти на вищий рівень без зміни архітектури.

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

Усе це не скасовує ролі прямої підписки на агентів за 19 доларів на місяць, яка залишається простим варіантом для тих, хто хоче мінімум налаштувань і не планує глибоко інтегруватися з API. Але для тих, хто дивиться на Maxclaw як на платформу для побудови власних сервісів, токен‑плани, особливо на рівні Plus, виглядають більш гнучким і в довгостроковій перспективі економнішим рішенням.

Висновок: Maxclaw як сервіс, а не як інфраструктурний проєкт

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

Пряма підписка на агентів із щоденними бонусами кредитів підходить тим, хто хоче просто мати потужного AI‑асистента «з коробки». Токен‑плани, що стартують приблизно з 10 доларів на місяць, перетворюють MiniMax на універсальний обчислювальний шар: один план покриває текст, голос, зображення, відео й кілька паралельних Maxclaw‑агентів, підключених через API‑ключ.

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

У результаті Maxclaw у поєднанні з токен‑планами MiniMax позиціонується не як інструмент для ентузіастів, готових будувати інфраструктуру з нуля, а як сервіс, який дозволяє швидко й відносно недорого запускати кілька повноцінних AI‑агентів для себе, своїх проєктів або навіть інших людей — без необхідності множити акаунти й підписки.

Джерело

YouTube: I Built an AI Agent in 20 Minutes – Here’s How

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

Офіс як прискорювач кар’єрного росту

Ключова ідея проста: на старті кар’єри людина найбільше вчиться «в тілі» команди. Безпосередня робота поруч із колегами дає:

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

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

Як середовище впливає на лояльність і мотивацію

Ще один аргумент стосується того, як фізична присутність впливає на стійкість до зовнішніх спокус — насамперед рекрутингових пропозицій.

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

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

Сила кросфункціональної взаємодії

Окрема лінія аргументації — про те, як офіс посилює роботу різних функцій, коли вони фізично поруч.

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

• «Нам не подобається ця кнопка»
• «Було б добре, якби це працювало інакше»

Такі сигнали не потрібно збирати через формальні звіти чи асинхронні тікети — вони стають частиною щоденного фону. Це:

• пришвидшує зворотний зв’язок;
• робить продуктові рішення більш чутливими до реальних болів користувачів;
• формує спільне відчуття відповідальності за результат.

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

Гібрид і ремоут: чому до них ставляться скептично

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

Ключовий закид до ремоуту — втрата ефекту присутності:

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

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

Джерело

The best young people want to be in office — 20VC with Harry Stebbings

У спільному воркшопі каналу AI Engineer Луї-Франсуа Бушар, Самріді Вайд та Пол Іуштін показують, як побудувати повноцінну систему для глибоких досліджень і технічного письма на базі LLM. Після гнучкого дослідницького агента, який збирає й структурує факти, у центрі уваги опиняється інша, набагато жорсткіша частина — конвеєр написання коротких технічних текстів на кшталт LinkedIn‑постів. Саме ця друга половина системи, разом із засобами спостереження, трасування та оцінки якості, визначає, чи перетвориться сирий артефакт дослідження на справді корисний контент, а не черговий шматок «AI‑slop».

Чому технічне письмо потребує іншої архітектури, ніж дослідження

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

Дослідницький агент — це місце для автономії. Він планує стратегію, ходить у веб‑пошук, аналізує відео, фільтрує джерела за релевантністю та надійністю, а потім збирає все в структурований артефакт research.md. Тут корисні петлі зворотного зв’язку, можливість змінювати план, повертатися до попередніх кроків, додавати нові запити. Архітектура нагадує класичну агентну систему з інструментами, пам’яттю та гнучким плануванням.

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

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

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

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

Обмежений воркфлоу для LinkedIn‑рівня: як влаштований «писець»

Система письма в цьому проєкті свідомо оптимізована під короткий технічний контент — насамперед пости формату LinkedIn. Це не універсальний генератор статей, а вузькоспеціалізований інструмент, який працює в чітко окреслених рамках.

Перший принцип — повна залежність від артефакту дослідження. Вихід дослідницького агента — це Markdown‑файл research.md, де вже зібрані, структуровані та процитовані джерела. Саме цей файл стає головним (і по суті єдиним) вхідним контекстом для письменницького воркфлоу. Модель не ходить у веб, не викликає додаткових інструментів, не «домислює» відсутні факти. Вона працює з тим, що є.

Другий принцип — жорсткі інструкції. Воркфлоу задає:

• цільовий формат: короткий пост, а не довга стаття;
• орієнтацію на технічну аудиторію, а не на загальний маркетинговий текст;
• вимоги до структури: вступ, одна‑дві ключові ідеї, лаконічний висновок;
• заборону на розмиті формулювання, кліше й «AI‑слоп»;
• обов’язкову прив’язку до конкретних фактів із research.md.

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

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

Проста послідовність замість важкої оркестрації

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

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

Такий підхід має кілька наслідків.

По‑перше, зменшується інженерна складність. Розробникам не потрібно підтримувати окремий оркестраційний шар, налаштовувати складні DAG‑схеми чи інтегруватися з важкими workflow‑системами. Усе зводиться до керованого скрипта, який запускає два етапи один за одним.

По‑друге, чітко розділяються відповідальності. Дослідницький агент відповідає за повноту й якість фактів, письменницький воркфлоу — за форму й подачу. Якщо виникає проблема з точністю, дивляться на research.md. Якщо проблема зі стилем або структурою — на конвеєр письма.

По‑третє, спрощується налагодження. Оскільки між компонентами передається явний артефакт у вигляді Markdown‑файла, легко відтворити будь‑який запуск: достатньо зберегти research.md і прогнати його через актуальну версію письменницького воркфлоу.

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

Як система бореться з «AI‑slop»: контроль, петлі рев’ю та LLM‑суддя

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

По‑перше, модель жорстко обмежена в джерелах. Вона не має права виходити за межі research.md. Це автоматично відсікає значну частину галюцинацій, які виникають, коли LLM намагається «додумати» те, чого не знає.

По‑друге, інструкції прямо забороняють типові «слоп‑фрази» — на кшталт «швидко змінюваний ландшафт», «це не про X, а про Y» та інші шаблонні конструкції, які часто з’являються в згенерованих текстах. Модель не просто просять «писати краще», їй задають конкретні негативні приклади того, чого слід уникати.

По‑третє, у систему вбудовано рецензування. Воркфлоу письма реалізує патерн «writer/reviewer»: один виклик моделі виступає як «автор», інший — як «рецензент», який оцінює текст за низкою критеріїв: точність, повнота, ясність, відповідність формату. Якщо рецензент виявляє проблеми, текст може бути доопрацьований у наступній ітерації.

Щоб зробити цю оцінку не лише якісною, а й кількісною, у воркшопі демонструють окремий компонент — LLM‑суддю. Це ще один LLM, який працює поверх датасетів еталонних відповідей і обчислює метрики на кшталт F1‑міри. Система порівнює згенерований текст із «золотим стандартом» і рахує, наскільки добре збігаються ключові факти чи пункти.

Такий LLM‑суддя дозволяє:

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

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

Спостережуваність і трасування: навіщо Opik у конвеєрі письма

Ще один важливий шар — спостережуваність. Щоб розуміти, як поводяться і дослідницький агент, і письменницький воркфлоу, у проєкт інтегровано Opik — платформу для трасування й аналізу LLM‑запусків.

Opik дозволяє:

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

Для конвеєра письма це особливо важливо. Якщо LLM‑суддя показує падіння F1‑міри, а користувачі скаржаться на якість постів, без трасування складно зрозуміти, де саме все пішло не так: на етапі дослідження, при формуванні research.md чи вже в самому воркфлоу письма.

Opik дає можливість «розмотати» цей ланцюжок. Можна подивитися, який саме артефакт дослідження потрапив у систему письма, як виглядав промпт до моделі‑«писця», що повернув «рецензент», які рішення приймав LLM‑суддя. Це перетворює налагодження з інтуїтивного «підкручування промптів» на більш системну інженерію.

Крім того, спостережуваність важлива для освітнього аспекту проєкту. Оскільки система використовується для навчання студентів AI‑інженерії, можливість показати їм реальні трасування, розібрати помилки й покращення на конкретних прикладах стає частиною навчального контенту.

Витоки системи: автоматизація внутрішнього конвеєра Towards AI

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

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

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

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

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

Інфраструктура під капотом: Python, uv і Gitingest для GitHub‑контенту

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

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

Markdown‑подання коду добре вписується в загальну архітектуру, де основним артефактом є research.md. Дослідницький агент може інкорпорувати фрагменти з GitHub‑репозиторіїв у свій артефакт, а письменницький воркфлоу — використовувати їх для створення технічних постів, які посилаються на реальний код.

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

LLM‑суддя, датасети й F1: як вимірюють якість конвеєра

Щоб конвеєр письма не залишався суто евристичним, у воркшопі показують, як додати до нього кількісну оцінку. Для цього використовується LLM‑суддя, який працює поверх заздалегідь підготовлених датасетів.

Сценарій виглядає так: є набір завдань (наприклад, теми постів) і «золоті» еталонні відповіді, які вважаються правильними або бажаними. Система генерує свої відповіді, після чого LLM‑суддя порівнює їх із еталонами й обчислює F1‑міру — баланс між повнотою й точністю.

Цей підхід дозволяє:

• тестувати різні версії промптів для письменницького воркфлоу;
• порівнювати моделі між собою;
• відстежувати, як зміни в дослідницькому агенті впливають на кінцевий текст.

Важливо, що LLM‑суддя — це не «абсолютний арбітр істини», а інструмент для відносних порівнянь. Він добре підходить для того, щоб сказати: «ця версія системи в середньому краща за попередню», але не для того, щоб гарантувати ідеальну якість кожного окремого поста. Однак у поєднанні з трасуванням через Opik і ручним рев’ю це дає досить потужний набір інструментів для еволюції системи.

Висновок: технічне письмо як інженерна задача, а не побічний продукт LLM

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

Розділення на гнучкий дослідницький агент і жорстко обмежений воркфлоу письма, послідовний запуск через простий скрипт, явний артефакт research.md, інтеграція спостережуваності через Opik, використання LLM‑судді й F1‑метрик, інфраструктура на Python з Gitingest для роботи з GitHub — усе це елементи однієї картини. Вони показують, що якісний AI‑контент — це результат продуманої архітектури, а не просто «кращої моделі».

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

Джерело

Full Workshop: Build Your Own Deep Research Agents – Louis-François Bouchard, Paul Iusztin, Samridhi

Попри популярну думку, що штучний інтелект «з’їсть» юридичну професію, частина інвесторів та підприємців у сфері технологій прогнозує протилежне: кількість юристів зросте. В інтерв’ю на подкасті 20VC with Harry Stebbings пролунала аргументована позиція, чому саме так може статися в найближчі п’ять років.

Генерація юридичного контенту спростилася, але це лише половина процесу

Сучасні AI‑інструменти дозволяють будь-кому за лічені хвилини створити:

• проєкт договору;
• юридичний меморандум;
• аналіз судової практики чи «чернетку» позову.

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

Однак юридична робота не закінчується на написанні тексту. Ключове питання — не «чи можна це згенерувати», а «чи витримає це перевірку реальністю: судом, регулятором, контрагентом».

Справжнє вузьке місце — не контент, а кількість кваліфікованих юристів

Коли «кожен відчуває себе юристом» завдяки AI, обсяг юридичних документів у обігу різко зростає. Але:

• суди не почали працювати швидше;
• процесуальні вимоги не спростилися;
• стандарти доказовості та відповідальності не змінилися.

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

AI не отримує ліцензію, не несе відповідальності перед клієнтом і не виступає в суді. Усе, що він створює, має пройти через фільтр людини-юриста, якщо документ має хоч якусь юридичну вагу.

Чому це може призвести до зростання попиту на юристів

Поєднання двох трендів — масової генерації текстів і незмінних вимог правової системи — логічно веде до зростання попиту на юридичну експертизу:

1. Більше документів — більше перевірок. Кожен AI‑згенерований контракт чи меморандум, який клієнт хоче реально використати, потребує професійного рев’ю.
2. Зростання ризиків. Помилки в автоматично створених документах можуть коштувати бізнесу дорого. Це стимулює компанії частіше звертатися до юристів.
3. Формалізовані вимоги системи. Судові та регуляторні органи не приймають документи лише тому, що їх «написав AI». Важить відповідальність конкретного юриста або фірми.
4. Розширення доступу до права. Коли створити базовий документ стає легко, до юридичних інструментів звертаються ті, хто раніше взагалі не йшов до юристів. Це відкриває нові сегменти попиту.

У результаті AI не стільки «скорочує» юридичну професію, скільки змінює структуру роботи: менше рутинного набору тексту, більше — перевірки, корекції, стратегічного аналізу та відповідальності за кінцевий результат.

Розбіжність із домінуючим на ринку поглядом

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

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

Джерело

We will have MORE lawyers in 5 years not LESS — 20VC with Harry Stebbings

У подкасті Confluent Developer 28‑річний інженер з Кіто, Еквадор, Матео Рохас розповідає про свій досвід побудови реальних банківських систем на ранніх версіях Kafka Streams. Почавши кар’єру з Kafka приблизно у 20 років, він опинився в ситуації, коли потрібно було керувати грошима клієнтів на технології, яка ще тільки формувалася. Сьогодні Матео працює в LittleHorse над workflow‑рушієм поверх Kafka, але саме перші проєкти з політиками ануїтетів дали йому найжорсткіші уроки — від join‑вікон і відсутності exactly‑once до болючих питань безпеки та шифрування.

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

Вікна join у Kafka Streams: коли «на всяк випадок» означає «на роки»

Одна з ключових задач платформи ануїтетів, над якою працював Матео, полягала в тому, щоб активувати поліс лише тоді, коли виконані всі перевірки: KYC, AML та очищення коштів банком. Архітектурно це виглядало як три окремі потоки подій, кожен з яких сигналізував про завершення свого етапу. Для ухвалення рішення про активацію потрібно було «зібрати» три події з різних топіків за одним і тим самим ідентифікатором поліса.

Команда обрала природний для Kafka Streams підхід — join потоків за ключем (policy ID). Проблема виявилася в тому, що join у Kafka Streams працює лише в межах конфігурованого вікна часу. Якщо одна з подій приходить надто пізно, за межами цього вікна, join просто не відбудеться, навіть якщо всі три повідомлення фізично присутні в топіках.

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

Щоб уникнути пропущених join‑ів, команда пішла шляхом, який сьогодні сам Матео називає далеким від ідеалу: вікно join було налаштоване на гігантське значення, вимірюване роками. Ідея була простою — зробити вікно настільки великим, щоб жодна реалістична затримка зовнішніх сервісів не могла призвести до пропуску join.

Технічно це працювало: якщо подія KYC приходила через тиждень, місяць чи навіть значно пізніше, вона все ще потрапляла в межі вікна, і join відбувався. Але така конфігурація мала очевидні мінуси. Величезне вікно означає довготривале зберігання проміжного стану, більший обсяг state store, складніший дебаг і менш передбачувану поведінку в разі збоїв. До того ж це маскувало справжню проблему — відсутність чітко визначених SLA для зовнішніх систем і відсутність явної бізнес‑логіки для обробки надто пізніх подій.

Цей досвід сформував у Матео стійке небажання покладатися на складні join‑и в критичних грошових сценаріях. Він прямо говорить, що сьогодні намагався б уникати join‑ів у подібній системі, делегуючи оркестрацію спеціалізованому workflow‑рушію, а Kafka Streams використовував би радше для трансформації даних чи аналітики.

Життя без exactly‑once: як KTable‑дедуплікація замінювала гарантії

Якщо проблема з join‑вікнами була неприємною, то відсутність exactly‑once семантики в Kafka Streams на той момент була відверто небезпечною. Мова йшла про систему, яка нараховує відсотки за реальними грошима. Подвійна обробка одного й того самого повідомлення могла означати подвоєне нарахування відсотків або інші фінансові аномалії.

На той час Kafka Streams не надавала вбудованої exactly‑once семантики. Команда була змушена самостійно наближатися до цієї гарантії, будуючи дедуплікацію поверх наявних примітивів. Вибір упав на KTable як механізм зберігання стану.

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

Цей підхід дозволяв захиститися від повторної доставки, яка могла виникнути, наприклад, якщо споживач не встиг закомітити офсет до збою, і Kafka повторно відправляла те саме повідомлення. Завдяки KTable‑дедуплікації повторна подія не призводила до повторної бізнес‑операції.

Однак ціна такого рішення була високою. Платформа складалася приблизно з двадцяти мікросервісів, кожен з яких споживав багато топіків і мав власну логіку дедуплікації. Фактично кожен сервіс реалізовував свій варіант «саморобного exactly‑once», що збільшувало складність системи, ускладнювало супровід і тестування.

До того ж дедуплікація на рівні KTable не є повним еквівалентом exactly‑once семантики, яку сьогодні надає Kafka Streams. Вона захищає від повторної обробки за конкретним ID, але не вирішує всіх можливих сценаріїв, пов’язаних із транзакційністю, консистентністю між топіками та атомарністю записів.

Попри це, для того часу це був практичний компроміс: використати наявні інструменти Kafka Streams, щоб максимально наблизитися до поведінки exactly‑once у критичній фінансовій системі.

Мікросервіси, eventual consistency і тестування, яке ловить гонки

Архітектура платформи ануїтетів була типовою для епохи масового захоплення мікросервісами: близько двадцяти сервісів, кожен з яких споживає події, реагує на них і генерує нові. У теорії це мало забезпечити гнучкість і масштабованість. На практиці команда зіткнулася з класичними проблемами eventual consistency.

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

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

Щоб мати хоч якийсь контроль над цією eventual consistency, команда побудувала автоматизовані тести консистентності, які порівнювали дані між мікросервісами. Ідея полягала в тому, щоб через певний час після обробки подій перевіряти, чи всі сервіси врешті‑решт дійшли до узгодженого стану. Це не усувало гонки, але дозволяло виявляти сценарії, де «остаточна» консистентність так і не досягалася.

Такий підхід підкреслює важливу практичну істину: у подієво‑орієнтованих мікросервісних системах eventual consistency — не просто теоретична властивість, а джерело дуже конкретних багів. І без явних механізмів перевірки узгодженості між сервісами команда ризикує роками жити з прихованими розбіжностями в даних.

Цей досвід також вплинув на погляд Матео на роль Kafka в архітектурі. У тому проєкті Kafka фактично виконувала роль джерела істини, а відтворення топіків використовувалося для відновлення стану застосунків. Але чим складнішою ставала система, тим очевиднішими ставали ризики такого підходу — особливо в поєднанні з питаннями безпеки.

Шифрування та незмінність: чому Kafka — погане місце для вічних секретів

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

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

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

У підсумку команда обрала більш «інфраструктурний» підхід до безпеки: шифрування дисків на рівні AWS EC2 у поєднанні з TLS для трафіку. Тобто дані в Kafka зберігалися у відкритому вигляді на рівні payload, але були захищені на транспортному рівні та на рівні фізичного зберігання.

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

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

Чи повинна Kafka бути джерелом істини?

Досвід Матео з ранніми банківськими системами на Kafka Streams підводить до фундаментального питання, яке й сьогодні хвилює багато команд: чи варто робити Kafka джерелом істини?

У проєкті з ануїтетами відповідь була фактично «так»: Kafka розглядалася як основне сховище подій, з якого можна відтворити стан усієї системи. Це давало потужні можливості для відновлення після збоїв і аналітики, але водночас створювало серйозні виклики:

подієві join‑и з гігантськими вікнами, які складно дебажити;

відсутність вбудованої exactly‑once семантики, що змушувала будувати складні схеми дедуплікації на KTable‑ах у кожному з приблизно двадцяти мікросервісів;

гонки та eventual consistency між сервісами, які доводилося ловити автоматизованими тестами консистентності;

питання шифрування чутливих банківських даних у незмінних топіках, які врешті‑решт вирішувалися інфраструктурним, а не застосунковим шифруванням.

Сьогодні, працюючи над workflow‑рушієм поверх Kafka в LittleHorse, Матео дивиться на ці рішення значно критичніше. Він схиляється до моделі, де Kafka виконує роль потужного транспортного шару з відносно коротким retention, а довгострокове джерело істини для чутливих даних розміщується в інших системах, які краще пристосовані до ротації ключів, пере‑шифрування та керування життєвим циклом даних.

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

Висновок: уроки ранніх банківських систем на Kafka Streams

Історія Матео Рохаса — це концентрат уроків, які багато команд проходять роками:

join‑и в Kafka Streams мають часові вікна, і спроба «підстрахуватися» вікном на роки лише маскує архітектурні проблеми;

відсутність exactly‑once у критичних системах змушує будувати саморобні механізми дедуплікації, що різко підвищує складність;

eventual consistency між десятками мікросервісів — не абстракція, а джерело реальних гонок, які потребують окремих інструментів для виявлення;

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

Звідси народжується більш стриманий, прагматичний підхід: використовувати Kafka як високопродуктивний транспортний шар із TLS і шифруванням дисків, обмежувати retention, обережно ставитися до join‑ів у грошових сценаріях і не покладатися на Kafka як єдине довгострокове джерело істини для секретних даних.

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

Джерело

Building Banking Systems with Kafka Streams with Mateo Rojas | Ep. 28 | Confluent Developer Podcast

У дискусіях про безпеку штучного інтелекту й критичних інфраструктур часто звучить проста і приваблива ідея: отримати доступ до нового потужного інструмента — і «разом оновити все». В одному з випусків подкасту 20VC з Гаррі Стеббінгсом на прикладі гіпотетичної системи Mythos пояснюється, чому такий підхід є хибним спрощенням і чому позиція про «одноразове велике оновлення» програє більш реалістичному баченню тривалого, поетапного процесу.

Міф про «магічний момент» повного оновлення

Популярний аргумент виглядає так: якщо отримати ранній доступ до потужної системи (умовно — Mythos), можна швидко оновити всі наявні системи безпеки, «закрити дірки» й надовго зафіксувати перевагу над зловмисниками.

Проблема в тому, що це уявлення ігнорує реальну складність інфраструктури:

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

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

Чому «закрити все назавжди» неможливо

Навіть якщо припустити, що Mythos або подібна система дає суттєву перевагу захисникам, є кілька фундаментальних обмежень.

1. Неможливо тримати ключові технології закритими десятиліттями

Щоб сценарій «раз оновили — і спимо спокійно» спрацював, довелося б надовго зберігати доступ до Mythos вкрай обмеженим. У розмові прямо підкреслюється: якщо не тримати таку систему закритою «наступне десятиліття», не буде жодного унікального вікна, коли захисники назавжди випередять атакувальників.

У реальному світі:

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

2. Безпека — це постійне «перестрибування» між атакою і захистом

Стан системи безпеки ніколи не є статичним. Її описують як безкінечний процес «leapfrogging» — коли:

• захисники впроваджують нові засоби й підходи;
• атакувальники адаптуються, знаходять обхідні шляхи, використовують ті ж самі або подібні інструменти;
• захисники знову відповідають оновленнями.

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

• нові вразливості з’являються разом із новими технологіями;
• старі системи залишаються в експлуатації й тягнуть за собою «технічний борг»;
• людський фактор і організаційні помилки нікуди не зникають.

Чому бінарне мислення шкодить стратегії безпеки

Один із ключових висновків розмови — критика бінарного підходу: «або ми все оновили й безпечні, або ні». Такий спосіб мислення небезпечний із кількох причин:

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

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

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

Висновок: ставка на процес, а не на «чарівну кнопку»

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

Тому замість очікування «магічного моменту», коли все стане безпечним, варто:

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

Джерело

YouTube: Why Dwarkash was wrong and Jensen was right on upgrading systems — 20VC with Harry Stebbings

У новому відео на каналі Tech With Tim розробник демонструє, наскільки швидко сьогодні можна створити корисного AI‑агента на базі платформи Maxclaw від MiniMax. Показовий кейс — персональний асистент для його нетехнічної дівчини, якого вдалося налаштувати приблизно за п’ять хвилин, після чого вона щодня користується ним зі смартфона через Telegram. На цьому прикладі та через огляд вбудованих «експертів» Maxclaw стає видно, як агентні системи виходять за межі середовища розробників і стають інструментом для будь‑якої людини.

Асистент за 5 хвилин: коли технічні деталі більше не мають значення

Класичний підхід до побудови AI‑агента на базі OpenClaw передбачає чималий обсяг технічної роботи: налаштування API‑ключів, деплой моделей, конфігурація MCP, пам’яті, інтеграцій інструментів, лімітів запитів. Для ентузіастів це цікавий проєкт, але для більшості користувачів, які просто хочуть «щоб працювало», такий поріг входу є надто високим.

Maxclaw фактично прибирає цей бар’єр. Це хостингова версія OpenClaw, що працює на інфраструктурі MiniMax і вже має налаштовані моделі, інструменти та інтеграції. У практиці це означає, що створення агента перетворюється на кількахвилинну процедуру замість повноцінного інженерного проєкту.

Показовий приклад — AI‑асистент для дівчини автора відео. Весь процес налаштування зайняв близько п’яти хвилин: було підключено Telegram‑бота, після чого вона почала спілкуватися з агентом без жодного занурення в технічні деталі. Вона не знає, що таке OpenClaw, не розуміє, як працює оркестрація інструментів, і, за великим рахунком, їй це не потрібно. Для неї це просто «крутий AI‑асистент у Telegram», який завжди під рукою.

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

Персоналізація через файли: to‑do, «ідентичність» і логотипи агенції

Щоб агент був по‑справжньому корисним, йому потрібен контекст про людину, для якої він працює. У випадку з дівчиною автора це не просто абстрактний чат‑бот, а інструмент, вбудований у її повсякденне життя та професійні плани.

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

• список справ (to‑do list), який агент може використовувати для нагадувань, планування та пріоритизації;
• документ з «ідентичністю» — описом того, як асистент має себе поводити, яким тоном говорити, які цілі користувача підтримувати;
• згенеровані логотипи для її UGC‑агенції, створені за допомогою вбудованих можливостей генерації зображень.

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

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

Фактично Maxclaw тут виступає як «операційна система» для персонального AI‑асистента: файли, пам’ять, інструменти й інтеграції зібрані в одному місці, а користувач взаємодіє з цим через звичний інтерфейс — у цьому випадку Telegram.

10 000+ експертів: як Maxclaw упакував складні сценарії в один клік

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

Платформа пропонує понад 10 000 таких експертів. Частина з них створена командою MiniMax, інша — спільнотою користувачів. Це означає, що екосистема постійно розширюється: з’являються нові вузькоспеціалізовані ролі, які можуть бути корисні в конкретних нішах.

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

Користувач може спілкуватися з цими експертами безпосередньо з інтерфейсу MiniMax, як із окремими агентами. Але ключова можливість — використати їх як «мозок» для власного Maxclaw‑агента. Під час розгортання системи можна обрати, який саме експерт буде її основою.

Наприклад, якщо потрібен агент для мультиагентного трейдингу, достатньо вибрати відповідного експерта. Якщо завдання — галузеві дослідження, обирається експерт з industry research. Якщо ж потрібен універсальний асистент «на всі випадки життя», можна взяти дефолтного експерта з широким набором навичок.

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

Вибір експерта при деплої: як налаштувати поведінку агента під конкретну задачу

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

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

Кожен із цих експертів уже містить попередньо налаштовані навички, інструменти та конфігурації. Користувачеві не потрібно розуміти, які саме API викликаються, як організована пам’ять або як налаштовано ліміти запитів. Усе це приховано за шаром абстракції «експерт».

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

Інструменти «з коробки»: як експерт із генерації зображень сам керує веб‑пошуком і аналізом

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

Це добре видно на прикладі експерта з генерації зображень, якого автор розгорнув як окремого Maxclaw‑агента. Після деплою він просто надіслав запит: згенерувати AI‑зображення «Tech With Tim» у вигляді мультяшного персонажа, попередньо знайшовши інформацію про те, як він виглядає.

Далі система діяла повністю автономно. Агент автоматично викликав інструмент веб‑пошуку, почав шукати інформацію про канал Tech With Tim, аналізувати знайдені дані, а потім запустив генерацію зображення. Користувач не налаштовував жодних інструментів, не вказував, які саме API слід викликати, не конфігурував ланцюжки дій. Усе це — частина внутрішньої оркестрації Maxclaw.

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

Цей приклад показує, як Maxclaw використовує свою модель MiniMax M2.7, оптимізовану під роботу з великою кількістю інструментів. За даними MiniMax, M2.7 зберігає 97% відповідності викликам інструментів у сценаріях, де моделі надається багато навичок і функцій, тоді як порівнювані моделі демонструють близько 74%. Для агентних систем, де від правильного вибору й послідовності інструментів залежить успіх задачі, це критично.

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

Інтеграції в повсякденне життя: від Telegram до десктопу

Ще один аспект, який робить Maxclaw придатним для реального щоденного використання, — широка підтримка інтеграцій. Платформа працює через веб‑інтерфейс, десктопні застосунки для macOS і Windows, мобільні клієнти для iOS та Android, а також через популярні месенджери й робочі середовища, зокрема Telegram, Discord і Slack.

У кейсі з дівчиною автора ключовим каналом став саме Telegram. Після початкового підключення бота вона спілкується з асистентом виключно зі свого смартфона, як із будь‑яким іншим чат‑ботом. Вона не заходить у веб‑панель, не працює з файлами напряму, не змінює конфігурації — усі технічні можливості Maxclaw залишаються «за лаштунками».

При цьому платформа дозволяє за потреби розширити присутність агента в інших середовищах. Наприклад, той самий агент можна підключити до Slack або Discord, просто попросивши систему допомогти з інтеграцією. Maxclaw крок за кроком пояснює, що потрібно зробити, зокрема створити бота в Telegram чи налаштувати доступ у Slack.

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

Висновок: агентні системи виходять за межі кола розробників

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

Maxclaw поєднує кілька ключових елементів, які роблять це можливим: хостингову версію OpenClaw на інфраструктурі MiniMax, модель M2.7 з високою надійністю виклику інструментів, каталог із понад 10 000 експертів, підтримку файлів для персоналізації та широку мережу інтеграцій — від вебу до Telegram і Slack. У результаті AI‑агенти перестають бути «іграшкою для розробників» і стають реальним робочим інструментом для людей, які не мають жодного інженерного бекграунду.

Персональний асистент для UGC‑креаторки, який живе в Telegram, знає її задачі, має доступ до її to‑do списку, «ідентичності» та логотипів агенції, і при цьому коштує кілька доларів на місяць, — це вже не футуристичний сценарій, а буденність. І саме такі приклади показують, куди рухається наступний етап розвитку AI: від моделей і API до готових, персоналізованих агентів, які можна запустити за п’ять хвилин.

Джерело

YouTube: I Built an AI Agent in 20 Minutes – Here’s How

У позачерговому випуску подкасту MVC #25 на каналі «УТ‑2» ведучі обговорюють один із найгучніших інцидентів у світі веб‑інфраструктури останнього часу — злам платформи Vercel. Це той самий «модний сервіс для деплою», тісно пов’язаний із Next.js, на якому сьогодні живе величезна кількість сучасних фронтенд‑ і AI‑проєктів. Історія виявилася показовою не лише масштабом компрометації, а й тим, як саме зловмисники зайшли в інфраструктуру — через сторонній сервіс Context AI (Delve/Context), який формально мав SOC 2‑аудит від Deloitte.

Що сталося з Vercel: доступ «до всього, що було»

Vercel — це платформа, яка знімає з розробників біль класичного деплою: замість ручної конфігурації серверів достатньо підключити репозиторій, налаштувати кілька параметрів — і застосунок опиняється в продакшені. Саме тому сервіс став де-факто стандартом для Next.js‑проєктів і популярним вибором для AI‑демок та стартапів.

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

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

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

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

Ланцюгова атака: як Context AI відкрив двері до інфраструктури

Найцікавіша й найтривожніша частина історії — це початкова точка входу. Злам Vercel не починався з прямого штурму їхніх серверів чи вразливості в самому хмарному середовищі. Першою ланкою в ланцюгу став сторонній сервіс Context AI (також згадується як Delve/Context).

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

Через те, що Context AI мав доступ до документів у цьому акаунті, зловмисники змогли використати його як трамплін. Компрометація Context AI дала їм змогу прочитати те, що бачив співробітник Vercel, і далі розширювати привілеї. У результаті це призвело до подальшого доступу до внутрішньої інфраструктури Vercel.

Це класичний приклад ланцюгової атаки на сучасну SaaS‑екосистему. Компанія може ретельно захищати свої власні системи, але вразливість або компрометація одного з численних інтегрованих сервісів відкриває обхідний шлях. У цьому випадку саме Context AI став слабкою ланкою, через яку вдалося обійти зовнішній периметр безпеки Vercel.

Особливо показово, що ключовим ресурсом, який використали зловмисники, стали документи в Google‑акаунті. Внутрішні документи часто містять не лише бізнес‑інформацію, а й технічні деталі: схеми мережі, описи ролей і доступів, фрагменти конфігів, інструкції з онбордингу, де можуть фігурувати URL‑адреси внутрішніх панелей, назви сервісних акаунтів, навіть приклади токенів або ключів. Усе це — золота жила для атакувальника, який уміє будувати подальший ланцюг експлуатації.

Що мають зробити користувачі Vercel прямо зараз

На тлі обмеженої офіційної інформації від Vercel, практичні рекомендації для користувачів стають критично важливими. Ведучі MVC #25 формулюють їх максимально прямо й без дипломатії: усім, хто користується Vercel, варто негайно відкликати доступи до GitHub та інших інтеграцій, а також змінити всі секрети, які будь‑коли зберігалися у Vercel.

Йдеться не лише про активні токени. Якщо в середовищі Vercel колись зберігалися секрети — API‑ключі, токени до сторонніх сервісів, доступи до баз даних, приватні ключі, — їх варто вважати потенційно скомпрометованими. Навіть якщо ви вже не використовуєте конкретний проєкт або інтеграцію, історичні дані могли бути доступні зловмисникам у момент, коли вони мали контроль над інфраструктурою.

Окремий акцент — на GitHub‑інтеграції. Типовий сценарій роботи з Vercel передбачає, що сервіс отримує доступ до репозиторіїв, аби автоматично деплоїти застосунок при кожному пуші. Якщо токен доступу до GitHub опинився в руках зловмисників, це відкриває їм шлях до вихідного коду, приватних репозиторіїв, CI‑конфігурацій, а іноді й до секретів, які зберігаються в репо всупереч кращим практикам.

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

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

SOC 2 під питанням: коли аудит не рятує від реальної атаки

Окремий вимір цієї історії — це репутація та реальна цінність сертифікацій на кшталт SOC 2. Delve/Context AI, через які почався злам, мали SOC 2‑аудит від Deloitte. Формально це означає, що сервіс відповідає певним стандартам безпеки, процесів і контролів, які мають знизити ризики інцидентів.

Факт, що саме через цей сервіс зламали Vercel, неминуче ставить під сумнів ефективність таких аудитів у практичному вимірі. SOC 2 часто сприймається як «знак якості» для B2B‑SaaS‑продуктів: наявність сертифікації спрощує продажі, відкриває двері до корпоративних клієнтів, знімає частину запитань від відділів безпеки.

Однак у реальності SOC 2 — це, передусім, про відповідність процесів певним вимогам на момент аудиту. Це не гарантія відсутності вразливостей, не страховка від людських помилок і не щит від складних ланцюгових атак. Історія з Context AI демонструє, що навіть сервіс із формальною відповідністю SOC 2 може стати точкою входу для масштабного зламу іншої компанії.

У розмові згадується ще один важливий аспект: на ринку існують SaaS‑рішення, які за підписку й кілька тисяч доларів допомагають компаніям «стати SOC 2 compliant». Це створює враження, що сертифікація перетворюється на формальність, яку можна «купити» як сервіс: заповнити шаблони політик, налаштувати мінімальні контролі, пройти чек‑лист аудитора.

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

Інцидент із Vercel і Context AI — це наочний кейс, який демонструє розрив між «комплаєнсом» і фактичною стійкістю до атак. Для індустрії це сигнал, що SOC 2 не може бути єдиним або головним критерієм довіри до сервісу. Потрібен глибший аналіз архітектури безпеки, моделі доступів, управління інтеграціями та сценаріїв найгірших випадків.

Ланцюг SaaS‑довіри: коли кожен інтегрований сервіс — потенційна дірка

Сучасні компанії будують свою роботу на довгому ланцюгу SaaS‑інструментів. Vercel сам по собі є таким сервісом, який працює поверх AWS, перепродуючи інфраструктуру Amazon із націнкою й додаючи власний рівень зручності, автоматизації та інтеграцій. До нього підключаються GitHub, CI‑системи, аналітика, APM‑інструменти, секрет‑менеджери, AI‑сервіси на кшталт Context AI.

Кожна така інтеграція — це новий вектор атаки. У випадку з Vercel саме сторонній сервіс, який мав доступ до Google‑акаунта співробітника, став точкою входу. Але в іншій компанії це може бути будь‑що: календарний сервіс, HR‑платформа, інструмент для управління знаннями, внутрішній чат‑бот.

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

Інцидент із Vercel оголює ще одну слабкість: внутрішні документи в Google‑акаунтах співробітників часто стають неформальним «центром правди» про інфраструктуру. Там описують, як усе влаштовано, які сервіси з чим інтегровані, де які ключі зберігаються, як налаштовуються доступи. Для атакувальника це готова карта місцевості.

У такій реальності компаніям доведеться переосмислити, як вони працюють із SaaS‑ланцюгами. Формальний комплаєнс на кшталт SOC 2 може залишатися важливим елементом, але вже точно не єдиним. Потрібні обмеження прав доступу для інтеграцій, сегментація даних, мінімізація чутливої інформації в документах загального доступу, регулярні рев’ю того, які сервіси до чого мають доступ.

Висновок: Vercel як симптом глибшої проблеми безпеки SaaS‑екосистеми

Злам Vercel — це не просто черговий інцидент із великою хмарною платформою. Це концентрований приклад того, як сучасна інфраструктура, побудована на десятках взаємопов’язаних SaaS‑сервісів, може впасти через одну скомпрометовану ланку. У цьому випадку нею став Context AI, який, попри SOC 2‑аудит від Deloitte, став воротами до внутрішньої інфраструктури Vercel.

Для користувачів платформи наслідки вже очевидні: дампи профілів у даркнеті, вимоги викупу від хакерів, необхідність терміново відкликати токени GitHub та інших інтеграцій, змінювати всі секрети, які будь‑коли зберігалися у Vercel. Для індустрії в цілому це ще й привід переглянути ставлення до сертифікацій на кшталт SOC 2, які дедалі частіше виглядають як формалізований бар’єр для продажів, а не як реальний індикатор стійкості до атак.

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

Джерело

ЯК ПОВʼЯЗАНІ Ожін де Пуатрин і Річ Хікі! mvc #25 — УТ‑2

Швидкість, з якою лабораторії виявляють нові мішені для ліків і перевіряють гіпотези, дедалі більше залежить від інструментів штучного інтелекту. На цьому тлі OpenAI у відео про GPT‑Rosalind і Life Sciences Research Plugin для Codex демонструє, як спеціалізована модель для наук про життя може не лише аналізувати дані, а й пропонувати конкретні кроки для наступних експериментів.

Від пріоритизації мішеней до конкретного експерименту

Класичний цикл у фармацевтичних і біомедичних дослідженнях виглядає так:
1) визначити потенційні мішені (наприклад, білки чи сигнальні шляхи),
2) розставити пріоритети,
3) спроєктувати експерименти для перевірки гіпотез.

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

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

Автоматизоване проєктування perturbation assay

Наступний крок — постановка завдання моделі: спроєктувати perturbation assay (дослід із цілеспрямованим «збуренням» системи) з конкретними параметрами. Йдеться про експеримент, у якому змінюють активність або рівень певної мішені (наприклад, TSLP), щоб оцінити наслідки для клітин чи тканин.

Модель отримує запит на:

• розробку саме perturbation assay;
• врахування заданих параметрів тесту (assay parameters), які можуть включати тип клітин, концентрації, часові точки, методи вимірювання тощо.

У відповідь система формує структуру експерименту, яка може включати:

• гіпотезу, яку перевіряє дослід;
• опис умов «збурення» (наприклад, інгібування чи активація мішені);
• контрольні групи;
• параметри проведення тесту, потрібні для відтворюваності.

Таким чином, AI‑модель виступає як асистент‑методист, що допомагає швидко перейти від абстрактної ідеї до формалізованого протоколу.

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

У відео окремо підкреслюється, що зі «зняттими біобезпековими обмеженнями» модель здатна:

• генерувати нові гіпотези;
• проєктувати експерименти;
• оптимізувати наявні протоколи.

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

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

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

Від генерації гіпотез до замкненого циклу «мокрої» лабораторії

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

• конкретний наступний крок у лабораторії;
• основу для подальшого аналізу результатів;
• базу для майбутньої оптимізації assay.

Це створює передумови для так званого wet lab feedback loop — циклу, у якому:

1. Модель аналізує дані й формує гіпотези.
2. Модель допомагає спроєктувати експеримент.
3. Лабораторія проводить дослід і отримує результати.
4. Дані повертаються в систему для аналізу та подальшої оптимізації протоколів.

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

Джерело

Відео: «Designing faster life sciences experiments», OpenAI

У Sunil Pai, розробника AI-агентів у Cloudflare та автора open source-інструмента Partykit для реального часу, є амбіційна мета: зробити так, щоб великі мовні моделі не просто «розмовляли» з API, а писали й виконували реальний код у контрольованому середовищі. У межах підходу Code Mode, який Cloudflare зараз активно експериментально розвиває, це середовище отримало окрему назву — harness. Саме воно стає ключовою частиною нової архітектури: безпечний, керований та повністю спостережуваний «простір», де працює згенерований агентами код.

Цей матеріал розбирає, як влаштований цей harness і sandbox Cloudflare: на чому він побудований, як реалізовано capability-based безпеку, чому за замовчуванням усе заборонено, як забезпечується повна спостережуваність, а також навіщо компанія дивиться в бік довготривалих workflow та генеративних інтерфейсів користувача.

Від «агента на ноутбуці» до керованого harness: навіщо потрібен новий шар архітектури

За останні місяці ринок AI-агентів переживає хвилю експериментів: моделі навчають писати код, запускати його локально, керувати файлами, браузером, сервісами. Часто це виглядає як «запустіть агента на Mac Mini, він усе зробить». Але за цією картинкою ховається фундаментальна проблема: відсутність чітко окресленого, безпечного та керованого середовища виконання.

Cloudflare формулює відповідь на це через поняття harness. Ідея проста, але радикальна в деталях: замість того, щоб дозволяти агенту виконувати код «деінде», йому надають спеціальний простір, де:

• код може виконуватися, але спочатку не має жодних можливостей, окрім самого факту виконання;
• усі можливості (доступ до API, мережі, стану) видаються явно, як окремі capability;
• кожна дія може бути спостережена, задокументована й проаналізована постфактум.

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

Такий розворот особливо важливий у контексті Code Mode, де LLM не просто викликає окремі інструменти, а генерує повноцінні програми (здебільшого JavaScript), які можуть взаємодіяти з широкою API-поверхнею Cloudflare, виконувати цикли, тримати стан, паралелізувати запити. Потужність цього підходу вимагає настільки ж потужної моделі безпеки.

V8 isolates як основа sandbox: чому Cloudflare робить ставку саме на них

Технічне ядро harness у Cloudflare — це V8 isolates. Це окремі ізольовані контексти виконання JavaScript у межах рушія V8, які компанія вже багато років використовує в Cloudflare Workers. Для Code Mode це природний вибір: моделі генерують JavaScript, а Cloudflare має десятирічний досвід у безпечному запуску JS-коду на своїй глобальній інфраструктурі.

Isolates дають кілька критично важливих властивостей.

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

По-друге, глибоко відпрацьована модель безпеки. Cloudflare роками запускає сторонній код у V8 isolates у масштабі глобальної мережі, і цей досвід безпосередньо переноситься в Code Mode. Для компанії це не експериментальний sandbox, а еволюція вже перевіреної платформи.

По-третє, чіткий контроль над тим, що саме доступно всередині ізолята. На відміну від контейнера, де за замовчуванням є файлові системи, мережа, системні виклики, тут можна буквально вирішити, які глобальні об’єкти й API будуть видимі для згенерованого коду. Це ідеально лягає на capability-based підхід, який Cloudflare робить базовим принципом свого harness.

При цьому компанія не обмежується лише isolates. Для деяких сценаріїв, де потрібні інші гарантії або сумісність, Cloudflare має sandbox SDK, що використовує контейнери й віртуальні машини. Але саме для Code Mode й агентського коду V8 isolates — основний робочий інструмент: швидкий, легкий, добре захищений.

Capability-based безпека: код стартує «голим» і отримує можливості по мірі довіри

Ключова відмінність harness Cloudflare від звичних «пісочниць» — радикально мінімалістичний стартовий стан. Коли згенерований агентом код потрапляє в sandbox, він не може нічого, крім як виконуватися. Немає доступу до мережі, немає fetch, немає жодних API, немає прихованих «стандартних» можливостей.

Далі вступає в дію capability-based модель. Кожна можливість — це окремий, явно наданий capability. Якщо потрібно дозволити коду звертатися до певного API, у harness додається відповідний інтерфейс. Якщо потрібен доступ до мережі — це теж окрема, контрольована можливість, а не щось, що «й так є».

Cloudflare прямо формулює рекомендований дефолт: жодних довільних вихідних fetch. Замість цього згенерованому коду варто надавати лише контрольовані API, які реалізують потрібні дії. Це знімає одразу кілька ризиків.

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

По-друге, спрощується аудит і відповідність політикам. Коли кожен API, доступний агенту, описаний як окремий capability, легше відповісти на питання: «Що саме цей агент може зробити? До яких даних він має доступ? Які операції дозволені?». Це важливо як для внутрішньої безпеки, так і для регуляторних вимог.

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

Цей підхід контрастує з типовою практикою запуску агентів «на повному доступі» до локальної машини чи хмари. Там безпека часто спирається на припущення про «розумність» моделі або на загальні обмеження інфраструктури. У harness Cloudflare безпека вбудована в саму архітектуру: спочатку нічого, потім — лише те, що явно дозволено.

Повна спостережуваність: чому для AI-коду важливо бачити кожне рішення

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

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

У контексті Code Mode це особливо важливо. На відміну від класичного tool calling, де кожен виклик інструмента — це окремий, відносно простий крок, тут модель може згенерувати складну програму з циклами, умовами, паралельними запитами. Без глибокої спостережуваності така програма перетворюється на ще одну «чорну скриньку» поверх LLM.

Повна прозорість виконання дає кілька практичних переваг.

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

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

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

Усе це перетворює harness не просто на «пісочницю для коду», а на повноцінний операційний шар для AI-програм: із журналами, трасуванням, історією рішень.

Довготривалі workflow: коли згенерований код живе місяцями

Ще один напрямок, який Cloudflare досліджує в рамках свого harness, — це довготривалі workflow. Ідея полягає в тому, що згенеровані програми не обов’язково мають бути короткоживучими скриптами «запустив — виконав — забув». Вони можуть зберігати стан і продовжувати роботу протягом днів, місяців, а потенційно й років.

У традиційній моделі взаємодії з LLM кожен запит — це окрема сесія, а стан доводиться відновлювати через контекст або зовнішні сховища. У Code Mode з harness з’являється інша можливість: програма, яку згенерував агент, може стати довгоживучим компонентом системи, що постійно працює в контрольованому середовищі, реагує на події, оновлює дані, взаємодіє з іншими сервісами.

Це відкриває кілька цікавих сценаріїв.

Наприклад, можна уявити агента, який відповідає за певний аспект інфраструктури — моніторинг DDoS-подій, управління конфігураціями, синхронізацію даних. Замість того щоб щоразу генерувати новий код для кожної задачі, модель одного разу створює програму, яка потім живе в harness, має обмежені capability, повну спостережуваність і може еволюціонувати за потреби.

Або інший сценарій: персоналізовані агенти для користувачів, які «знають» історію взаємодії, зберігають локальний стан і можуть працювати як довготривалі співрозмовники й помічники, але при цьому виконують код лише в чітко окресленому sandbox із capability-based безпекою.

Для інфраструктури це означає перехід від одноразових «запитів до моделі» до постійно працюючих, але керованих AI-компонентів. І саме harness із його ізольованим виконанням, явними capability та спостережуваністю робить такий перехід технічно й безпеково прийнятним.

Генеративні інтерфейси: коли UI створює й оновлює агент у межах harness

Окремий вектор, який Cloudflare розглядає в контексті свого harness, — це генеративні UI-патерни. Ідея полягає в тому, що інтерфейс користувача більше не є статичною, наперед спроєктованою частиною застосунку. Замість цього його може динамічно створювати й змінювати агентський код, який працює всередині harness.

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

Harness тут відіграє подвійну роль.

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

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

У перспективі така модель може розмити межу між «бекендом» і «фронтендом» у AI-застосунках. Замість того щоб окремо розробляти API й інтерфейс, система може складатися з набору capability, доступних у harness, і агентського коду, який одночасно керує логікою й формує UI. Але ключовою умовою залишається те саме: усе це відбувається в ізольованому, спостережуваному середовищі з capability-based безпекою.

Висновок: harness як новий базовий шар для епохи AI-програм

Підхід Cloudflare до Code Mode показує, що перехід від JSON-based tool calling до генерації й виконання коду — це не лише про ефективність чи зручність для розробників. Це про необхідність нового базового шару інфраструктури, який дозволяє таким програмам існувати безпечно, керовано й прозоро.

Harness у виконанні Cloudflare — це:

• V8 isolates як швидке й перевірене середовище виконання JavaScript;
• capability-based модель, де код стартує без жодних можливостей і отримує їх лише явно;
• рекомендований дефолт без довільних вихідних fetch, із доступом лише до контрольованих API;
• повна спостережуваність, що дозволяє аналізувати минулі виконання й рішення AI-програм;
• основа для довготривалих workflow і генеративних UI, де згенерований код може жити довго й формувати досвід користувача.

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

Джерело

Code Mode: Let the Code do the Talking – Sunil Pai, Cloudflare

У промові на каналі AI Engineer інженер Anthropic Девід Сорія Парра окреслює роль Model Context Protocol (MCP) у майбутній інфраструктурі агентів. На відміну від чергового «плагінного» стандарту чи SDK, MCP тут постає як семантичний протокол підключення: шар, який дозволяє клієнтам і серверам не просто обмінюватися HTTP‑запитами чи RPC‑викликами, а справді розуміти, що саме вони один одному передають. Саме ця семантика, а не транспорт, робить MCP претендентом на фундаментальний елемент майбутнього стеку агентів.

Від виклику інструментів до спільної мови: що таке «семантичний» протокол

Більшість сьогоднішніх інтеграцій для AI‑агентів зводяться до двох речей: транспорту (HTTP, WebSocket, gRPC) та набору API‑ендпойнтів. Це працює, доки агенту потрібно лише викликати окремі інструменти — умовно, «запусти цей скрипт», «зроби POST на цей URL». Але щойно мова заходить про складніші сценарії, цього виявляється замало.

MCP пропонує інший рівень абстракції. Його ключова ідея — спільна семантика між клієнтом і сервером. Не просто «ось JSON‑відповідь», а чітко визначені сутності: інструменти, ресурси, задачі, UI‑компоненти, довготривалі операції, механізми авторизації. Клієнт не вгадує, що з цим робити, — протокол описує, як саме це слід інтерпретувати.

Це особливо помітно на прикладі MCP‑застосунків. Сервер може «віддавати» не лише набір інструментів, а повноцінний застосунок із власним інтерфейсом. Клієнт — чи то хмарний продукт, чи ChatGPT‑подібний інтерфейс, чи IDE на кшталт VS Code або Cursor — не просто отримує HTML або довільний JSON, а знає, що це саме UI, як його рендерити, як пов’язати з діями агента та інструментами.

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

Чому «просто API» більше не вистачає

У нинішній екосистемі AI‑інструментів більшість рішень зосереджені або на транспорті, або на зручності розробки SDK. Є REST‑інтерфейси, є gRPC‑сервіси, є обгортки для популярних мов. Але майже ніщо з цього не визначає спільну семантичну модель для агента й сервера.

Типовий підхід виглядає так: є REST‑API, до нього додають «шар для агента» — опис функцій у форматі tool calling, OpenAPI‑специфікацію чи власний формат. Далі кожен клієнт інтерпретує це по‑своєму. У результаті:

• кожен продукт будує власну модель інструментів;
• немає єдиного способу описати UI, довготривалі задачі, ресурси чи політики доступу;
• переносити агента між середовищами означає фактично переписувати інтеграцію.

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

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

MCP як стабільний шар абстракції для агентів

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

Коли MCP‑сервер постачає застосунок або набір інструментів, він не «знає», де саме буде запущений клієнт. Це може бути хмарний продукт, ChatGPT‑подібний інтерфейс, редактор коду чи будь‑який інший MCP‑клієнт. Завдяки спільній семантиці:

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

Це радикально відрізняється від класичних інтеграцій, де кожна платформа вимагає окремого плагіна або адаптера. У світі MCP сервер один, а клієнтів може бути багато. Агентська логіка, інструменти, ресурси й навіть інтерфейс «переїжджають» між середовищами разом із сервером, а не переписуються під кожну нову платформу.

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

Багаті взаємодії замість вузьких плагінів

Ще одна відмінність MCP — він задуманий як протокол для багатих, довготривалих взаємодій, а не як вузький механізм «функція‑виклик‑відповідь». Це особливо помітно, якщо подивитися, які типи можливостей MCP підтримує вже зараз.

По‑перше, MCP не обмежується інструментами. Сервер може одночасно:

• надавати інструменти для моделі;
• віддавати UI‑застосунок для людини;
• працювати з довготривалими задачами, які не вкладаються в один запит‑відповідь;
• управляти ресурсами — наприклад, файлами, документами, артефактами обробки.

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

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

По‑третє, протокол підтримує примітиви на кшталт задач і еліцитації (elicitation) — механізмів, які дозволяють агенту структуровано запитувати додаткову інформацію, керувати багатокроковими процесами, не зводячи все до одного гігантського запиту. Це знову ж таки семантика, а не просто транспорт: клієнт розуміє, що перед ним не «черговий POST», а саме задача з життєвим циклом.

У сукупності це робить MCP придатним для сценаріїв, де агент — не просто «розумний виклик API», а повноцінний учасник робочого процесу: з інтерфейсом для людини, довгими операціями, складними правами доступу й потребою працювати в різних середовищах.

Семантика як відповідь на «контекстний хаос» і оркестрацію

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

Одна з ключових ідей — прогресивне виявлення (progressive discovery). Замість того, щоб одразу завантажувати в контекст усі доступні інструменти, клієнт може спочатку дати моделі «інструмент для пошуку інструментів». Коли модель розуміє, що їй потрібен певний тип можливостей, вона викликає пошук, і лише тоді клієнт підвантажує відповідні інструменти.

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

Ще один приклад — програмна оркестрація інструментів. Якщо дати моделі можливість писати код у контрольованому середовищі (наприклад, у V8‑ізольованому рантаймі чи іншому інтерпретаторі), вона може сама будувати сценарії, які комбінують кілька інструментів за один крок. MCP додає до цього структурований вивід: сервер може описати, який тип даних повертає інструмент, і модель використовує цю інформацію для коректної композиції викликів.

Знову ж таки, це семантика, зафіксована в протоколі. Без неї кожен клієнт змушений був би вигадувати власні способи опису типів, залежностей і сценаріїв. MCP натомість пропонує спільну модель, яку можуть розділяти різні клієнти й сервери.

MCP у майбутньому стеку підключення агентів

У візії Anthropic майбутній стек підключення агентів у 2026 році складається з трьох основних компонентів: навичок (skills), MCP і CLI/«computer use». Кожен із них відповідає за свій клас задач, і MCP тут займає чітко окреслене місце.

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

CLI‑підключення — ідеальний варіант для локальних кодерських агентів, де є пісочниця, можливість виконувати код і доступ до інструментів, які вже знайомі моделі з препродакшн‑даних (Git, GitHub‑CLI тощо). Тут немає потреби в багатій семантиці — достатньо того, що модель вміє працювати з командним рядком.

MCP, своєю чергою, стає правильним вибором там, де потрібні:

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

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

Висновок: MCP як фундамент, а не ще один плагінний формат

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

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

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

Джерело

The Future of MCP — David Soria Parra, Anthropic

У спільноті AI-інженерів дедалі частіше звучить запит на системи, які не просто «генерують текст», а проводять справжнє дослідження: шукають джерела, перевіряють факти, аналізують відео й збирають усе це в структурований, цитований матеріал. Команда освітнього проєкту Towards AI, яку очолює CTO та співзасновник Луї-Франсуа Бушар разом із інженером і технічним автором Самрідхі та розробником і автором «LLM Engineer’s Handbook» Полом Юстіном, побудувала саме таку систему — і перетворила її на практичний воркшоп.

Цей матеріал розбирає технічне ядро їхнього підходу: як спроєктований глибокий дослідницький агент, як використовується Model Context Protocol (MCP), які інструменти підключені через FastMCP, чому обрано Gemini як рушій пошуку й аналізу YouTube, і як усе це в підсумку виводить один артефакт — файл research.md, що стає основою для подальшого технічного письма.

Дві половини однієї системи: гнучкий дослідник і детермінований письменник

У виробничій версії свого пайплайна Towards AI розділили систему на два чітко різні компоненти. Перший — це гнучкий, агентний дослідницький модуль, другий — більш детермінований, жорстко структурований модуль письма.

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

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

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

Глибокий дослідницький агент як цільовий цикл: план, пошук, інспекція, поворот

У центрі дослідницької частини — агент, спроєктований як цільовий дослідницький цикл. Його завдання — не просто відповісти на запит, а пройти повний шлях від постановки цілі до структурованого, цитованого артефакту.

Архітектурно це виглядає як петля, у якій модель:

формулює або уточнює дослідницьку мету, виходячи з вхідної теми;

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

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

інспектує знайдені матеріали, оцінює їхню релевантність і довіру, відкидає слабкі або підозрілі джерела;

за потреби «поворочує» — змінює напрямок пошуку, додає нові підзапити, заглиблюється в окремі аспекти або шукає альтернативні точки зору;

ітеративно уточнює власне розуміння теми, накопичуючи проміжні нотатки, витяги й висновки.

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

Щоб зробити таку поведінку керованою й розширюваною, команда спирається на Model Context Protocol (MCP) — стандарт, який дозволяє описувати інструменти, ресурси й промпти як сервіс, до якого підключається агент.

MCP як клейова тканина: FastMCP, Claude Code і сервер інструментів

Model Context Protocol у цьому проєкті виконує роль «контракту» між агентом і зовнішнім світом. Замість того, щоб жорстко вшивати виклики API в код агента, інструменти описуються й публікуються MCP-сервером. Агент, який працює в середовищі Claude Code, виступає як MCP-клієнт: він бачить доступні інструменти, їхні сигнатури, опис і може автономно вирішувати, коли й як їх викликати.

Щоб не витрачати час на ручну реалізацію протоколу, команда використовує бібліотеку FastMCP. Вона бере на себе більшу частину низькорівневої роботи: обробку запитів і відповідей MCP, реєстрацію інструментів, серіалізацію параметрів. Розробнику залишається описати бізнес-логіку кожного інструмента — наприклад, як саме викликати Gemini API для веб-пошуку чи аналізу відео.

У воркшопі Claude Code використовується як «агентний хрестовий ключ»: це середовище, де модель Anthropic може діяти як агент, бачити MCP-інструменти й викликати їх у процесі діалогу. Така конфігурація дозволяє учасникам воркшопу будувати власний MCP-сервер локально, а потім підключати його до вже готового агентного інтерфейсу без необхідності створювати складну інфраструктуру з нуля.

У результаті архітектура виглядає так: локальний MCP-сервер, реалізований через FastMCP, експонує набір інструментів; Claude Code підключається до цього сервера як клієнт; агент у Claude Code, керований промптами, запускає дослідницький цикл, використовуючи ці інструменти для пошуку, аналізу й компіляції.

Три інструменти, одна мета: від вебу й YouTube до research.md

MCP-сервер у цьому проєкті надає три основні інструменти, які разом покривають повний шлях від сирих даних до структурованого дослідження.

Перший — інструмент глибокого дослідження, який використовує Gemini API для веб-пошуку. На відміну від простого пошуку, він повертає не лише текстову відповідь, а й прив’язані джерела. Це критично для завдання, де потрібно не просто «щось написати», а обґрунтувати твердження посиланнями. Команда раніше покладалася на Perplexity як зовнішній сервіс для пошуку, але згодом мігрувала на Gemini з функцією grounding, щоб мати більш точний контроль над відповідями й джерелами в межах власної інфраструктури.

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

Третій — інструмент компіляції дослідження. Він не звертається до зовнішніх API, а працює з локальними проміжними результатами. Його завдання — прочитати всі збережені в процесі дослідження файли, нотатки й витяги, а потім зібрати їх у фінальний Markdown-документ research.md. Саме цей файл стає основним артефактом, який споживає наступний модуль системи — технічний письменник.

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

Локальна пам’ять як журнал і страховка: папка memory і верифікація

Щоб зробити роботу агента прозорою й перевірюваною, усі проміжні результати дослідження записуються в локальну папку пам’яті. Це можуть бути окремі файли з відповідями веб-пошуку, витяги з відео, чернеткові конспекти або структуровані нотатки за підтемами.

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

По-друге, локальна пам’ять дає можливість верифікації. Людина може відкрити конкретний файл, звірити цитати з джерелами, перевірити, чи не було перекручень або помилкових узагальнень. У контексті боротьби з «AI slop» — поверхневим, неконтрольованим контентом — це принципова відмінність: тут є слід, який можна перевірити.

По-третє, така структура спрощує роботу інструмента компіляції. Замість того, щоб покладатися на довгу контекстну історію в одному виклику моделі, система працює з набором файлів, які можна читати, сортувати, фільтрувати й комбінувати. У результаті фінальний research.md стає не просто «відповіддю моделі», а синтезом явно зафіксованих проміжних артефактів.

Файл research.md оформлюється в Markdown-форматі, що робить його зручним як для людей (читання, редагування), так і для подальшої машинної обробки. Саме цей документ потім споживає модуль письма, який перетворює його на короткі пости, конспекти чи інші формати.

Gemini як рушій дослідження: Pro, Flash і ставка на YouTube

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

Gemini Pro застосовується там, де потрібне глибше міркування, складніший аналіз або робота з великими обсягами інформації. Gemini Flash, своєю чергою, корисний для швидких, менш ресурсомістких операцій, де важливіше швидкість і вартість, ніж максимальна глибина.

Вибір Gemini був зумовлений кількома практичними міркуваннями. По-перше, моделі вміють безпосередньо обробляти YouTube-URL, що знімає потребу в окремому скрейпері чи транскрипційному сервісі. Це спрощує архітектуру й зменшує кількість рухомих частин у системі.

По-друге, наявність безкоштовного тарифу робить Gemini привабливим для студентів і учасників воркшопу. Оскільки кодова база доступна у відкритому GitHub-репозиторії, важливо, щоб кожен міг відтворити систему без значних витрат на інфраструктуру. Безкоштовний рівень дозволяє експериментувати з глибоким дослідженням навіть тим, хто лише починає працювати з LLM.

По-третє, перехід від Perplexity до Gemini з grounding дав команді більше контролю над тим, як саме формуються відповіді й як прив’язуються джерела. Замість чорної скриньки зовнішнього сервісу, вони отримали можливість будувати власну логіку поверх API, інтегруючи її в MCP-сервер і агентний цикл.

Окремим компонентом у ширшій системі є інструмент для інжесту GitHub-контенту через бібліотеку Gitingest, яка перетворює репозиторії на Markdown і може працювати з приватними репозиторіями через токен. Хоча цей аспект виходить за рамки базового воркшопу, він демонструє, як та сама MCP-архітектура може масштабуватися на інші джерела, крім вебу й YouTube.

Від внутрішнього пайплайна до відкритого репозиторію

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

Звідси й прагматичні рішення в архітектурі: розділення дослідження й письма, ставка на MCP як універсальний шар інтеграції, використання локальної пам’яті для верифікації, обережне застосування агентності лише там, де вона справді додає цінність.

Для воркшопу команда спростила продакшн-систему, зосередившись на компактнішому дослідницькому агенті й письменнику, орієнтованому на короткі пости. Водночас ключові ідеї залишилися незмінними: агент як цільовий дослідницький цикл, MCP як спосіб підключення інструментів, Gemini як рушій пошуку й аналізу, research.md як центральний артефакт.

Кодова база доступна у відкритому GitHub-репозиторії, посилання на який надається учасникам через QR-код і README. Це дозволяє не лише повторити приклад, а й розширити його: додати власні MCP-інструменти, інтегрувати інші API, змінити стратегію дослідження або формат фінального артефакту.

Висновок: дослідницькі агенти як інженерна дисципліна, а не магія

Історія цього глибокого дослідницького агента показує, що «агентність» у LLM-системах не обов’язково означає складні багатошарові оркестратори чи десятки взаємодіючих моделей. Натомість це може бути чітко спроєктований цикл, де модель має доступ до обмеженого, але добре описаного набору інструментів через MCP, працює з прозорою локальною пам’яттю й завершує роботу конкретним, перевірюваним артефактом.

Розділення на гнучкий дослідницький агент і детермінований модуль письма дозволяє поєднати автономію там, де вона потрібна, з контролем там, де він критичний. Використання Gemini як універсального рушія для вебу й YouTube, разом із FastMCP і Claude Code, робить систему доступною для відтворення й навчання.

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

Джерело

Full Workshop: Build Your Own Deep Research Agents – Louis-François Bouchard, Paul Iusztin, Samridhi

OpenAI у відеодемонстрації GPT‑Rosalind показує, як спеціалізована Life Sciences‑модель у середовищі Codex допомагає науковим командам у фармі та біотеху переходити від сирих даних до обґрунтованих рішень у дослідницьких програмах.

Від сирих даних до пріоритизації таргетів

Life Sciences‑модель працює як надбудова над типовим discovery‑процесом: вона поєднує структурований пошук даних, роботу з науковою літературою та аналітику в єдиний повторюваний робочий процес.

У продемонстрованому сценарії система отримує завдання порівняти й пріоритизувати три терапевтичні мішені для лікування астми: IL‑33, TSLP та IL‑1 RA1. Вихідною точкою стає внутрішній «evidence package» — пакет доказів, який включає:

• результати внутрішніх біологічних асайїв;
• стратегію щодо біомаркерів;
• оцінку «tractability» (наскільки реально працювати з таргетом з точки зору хімії, біології, формату молекули тощо);
• дані з безпеки;
• цільовий профіль продукту (target product profile).

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

Плагіни та спеціалізовані навички для біонаук

Life Sciences‑модель інтегрована з Life Sciences Research Plugin — плагіном, який дає змогу підтягувати додаткові релевантні дані з зовнішніх джерел. Модель навчена не лише виконувати окремі «навички» (skills), а й вирішувати, коли саме їх доцільно викликати та як синтезувати результати.

Це дозволяє:

• комбінувати внутрішні дані компанії з публічними базами;
• автоматизувати літературний пошук;
• будувати цілісну картину доказів навколо кожного таргету;
• уникати ручного «копання» в численних джерелах.

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

Субагенти: розділити лінії доказів, а потім об’єднати

Одна з ключових можливостей Codex у цьому сценарії — запуск субагентів (sub‑agents), кожен з яких відповідає за окрему «лінію» доказів. Для аналізу астматичних таргетів окремо виділяються:

• людська генетика;
• трансляційна біологія;
• регуляторний контекст;
• інші критерії, важливі для прийняття рішень у R&D.

Наприклад, агент «Pascal» отримує відповідальність за всю людську генетичну доказову базу, релевантну для порівняння трьох таргетів. Він формує перелік навичок, які потрібно задіяти, щоб зібрати «правильний» рівень генетичних даних.

Такий підхід дозволяє:

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

Після того як усі шість субагентів завершують свою роботу, їхні результати синтезуються в єдину фінальну пріоритизацію таргетів.

Вихід на «bio‑intelligence»: як модель працює з контекстом

Завдяки доступу до різних баз даних Life Sciences‑модель здатна:

• відновлювати контекст «locus‑to‑gene» — зв’язок між генетичними локусами та конкретними генами;
• відстежувати сигнали через різні когорти пацієнтів;
• підтягувати таргет‑дизіз‑евіденс — дані про зв’язок мішені з конкретним захворюванням;
• працювати з літературою для розв’язання суперечливих або неоднозначних сигналів.

Модель описується як «primed with greater thinking and bio‑intelligence» — налаштована на глибше міркування в межах складних наукових задач. У практичному вимірі це означає, що система не просто агрегує дані, а будує логічний ланцюжок: від сирих сигналів до структурованих, відтворюваних рішень для дослідницьких команд.

Джерело

Відео: Turning scattered evidence into discovery decisions for life sciences