У межах воркшопу на каналі AI Engineer інженери Google DeepMind Тор Шефф і Філіп Шмід показують, як будувати розмовні агенти на базі Gemini. Центральним елементом стає новий Interactions API, який поєднує моделі, вбудовані агенти та мультимодальні контент-блоки в єдину систему. На цій основі вони демонструють, як безкоштовна модель Gemini 1.5 Flash Free, агент Deep Research і генеративні моделі на кшталт Nano Banana можуть працювати в одному кодовому шляху, виконуючи складні, довгі й багатокрокові завдання.
Gemini 1.5 Flash Free як робоча конячка для коду й планування
У практичній частині воркшопу саме Gemini 1.5 Flash Free (часто її називають Gemini Free Flash) обрана як модель «за замовчуванням» для всіх кодових і агентних сценаріїв. Це не випадковий вибір, а чітка позиція: Flash Free подається як швидка й економна модель, яка добре підходить для кодування, планування та керування інструментами — за умови, що розробник дає їй якісні інструкції та грамотно налаштовує навички агента.
У цьому підході важливий акцент: мова не про «найпотужнішу» модель, а про оптимальний баланс швидкості, вартості й достатньої якості для більшості прикладних задач. Коли йдеться про агентів, які мають читати файли, запускати bash-команди, будувати плани дій або координувати інші моделі, латентність і вартість кожного запиту стають критичними. Саме тут Flash Free виглядає логічним вибором: вона дозволяє багаторазово викликати модель у межах одного сценарію, не виходячи за рамки безкоштовного тарифу, на який орієнтований увесь воркшоп.
Показово, що організатори спеціально підкреслюють: усі приклади вміщуються в безкоштовний рівень Gemini API. Це задає тон для розробників: складні агентні системи з інструментами, плануванням і мультимодальністю вже не є прерогативою дорогих корпоративних тарифів — їх можна будувати й тестувати на безкоштовній моделі, якщо правильно спроєктувати воркфлоу.
Модель, яка не знала про Interactions API: роль навичок і документації
Цікавий нюанс полягає в тому, що Gemini 1.5 Flash Free тренували ще до появи Interactions API. Це означає, що модель не «знає» про цей API з навчальних даних і не має вбудованого досвіду роботи з ним. Її здатність коректно викликати інструменти, працювати як агент і використовувати нові можливості API спирається не на попереднє навчання, а на те, як розробник описує навички, інструкції й структуру взаємодії.
Фактично, Interactions API виступає як шар оркестрації поверх моделі. Flash Free генерує текст і структуровані виклики функцій, але розуміння того, що таке «агент», «інтеракція» чи «попередній interactionId», приходить до неї через системні інструкції, схеми інструментів і документацію, яку розробник вбудовує в контекст.
Це зміщує фокус відповідальності: замість очікувати, що модель «сама все знає», розробник має чітко описати:
як виглядає інтерфейс інструментів і агентів;
які кроки потрібно виконати в межах одного завдання;
які обмеження й очікування щодо відповіді.
У результаті Flash Free перетворюється на універсальний «двигун міркування», а вся «агентність» — це наслідок того, як її вбудовують у Interactions API. Такий підхід добре узгоджується з трендом на «skills» і «tools» як окремі сутності, які можна оновлювати й комбінувати без ретренінгу моделі.
Єдиний кодовий шлях для моделей і агентів
Ключова ідея Interactions API — уніфікація. Замість того, щоб мати окремі ендпоїнти й клієнти для «чистих» моделей і для агентів, API пропонує один і той самий інтерфейс. Різниця лише в тому, що в запиті розробник вказує: звертається він до конкретної моделі чи до агента.
У найпростішому випадку це означає заміну ідентифікатора: замість model: “gemini-1.5-flash-free” можна вказати agent: “deep-research” або інший агентний ID. Решта структури запиту — контент-блоки, параметри, інструкції — залишається тією самою. Для розробника це означає, що один і той самий кодовий шлях може:
спочатку викликати модель для швидкого планування чи кодування;
потім передати результат у вбудованого агента для довготривалого дослідження;
а далі — знову повернутися до моделі для генерації тексту, коду чи промптів для інших систем.
Ця взаємозамінність особливо важлива в контексті складних воркфлоу, де потрібно поєднувати кілька типів завдань: від коротких інтерактивних діалогів до багатохвилинних бекграунд-процесів. Раніше такі сценарії часто вимагали окремих сервісів, черг завдань і ручної синхронізації. Тепер значна частина цієї логіки може бути інкапсульована в самому Interactions API.
Deep Research як вбудований агент для довгих завдань
Одним із перших агентів, які Google DeepMind виніс у Interactions API, став Deep Research. Це знайома користувачам Gemini функція: користувач формулює запит, а система будує план, відвідує сотні сайтів і протягом 10–15 хвилин збирає структурований результат.
У контексті Interactions API Deep Research поводиться як повноцінний агент, до якого можна звернутися так само, як до моделі. Різниця в тому, що замість миттєвої відповіді розробник отримує довготривале завдання, яке виконується у фоновому режимі. Це змінює сам підхід до проєктування застосунків:
користувацький інтерфейс більше не прив’язаний до однієї HTTP-сесії;
дослідження можна запускати «в один клік» і повертатися до них пізніше;
результати можна автоматично підхоплювати іншими компонентами системи.
Deep Research стає своєрідним «бекендом для розумних запитів», який можна вбудувати в будь-який продукт: від корпоративних панелей до споживчих застосунків, що потребують глибокого аналізу інформації з відкритих джерел.
Асинхронність, опитування й вебхуки: як працюють довгі агенти
Щоб такі агенти, як Deep Research, були практично корисними, Interactions API вводить повноцінну асинхронну модель виконання. Замість того, щоб тримати HTTP-з’єднання відкритим хвилинами, розробник:
ініціює інтеракцію з агентом;
отримує ідентифікатор завдання чи інтеракції;
далі або періодично опитує API, або (коли це стане доступним) отримує сповіщення через вебхуки.
У воркшопі окремо наголошують: тримати HTTP-запит відкритим довше 10 секунд — погана практика для веб-додатків. Тому Interactions API спроєктовано так, щоб довгі завдання природно переходили в асинхронний режим. Це дозволяє:
масштабувати бекенд без блокувальних запитів;
будувати UI, який показує прогрес, проміжні стани або просто повідомляє користувача, коли дослідження завершено;
комбінувати кілька довгих агентних викликів у складні пайплайни, не перевантажуючи клієнт.
Модель асинхронності доповнюється серверним станом: API зберігає історію інтеракцій, а клієнт може посилатися на попередній interactionId, не пересилаючи весь контекст щоразу. Це важливо не лише для зручності, а й для вартості: завдяки кращому кешуванню вхідних токенів старі частини контексту стають значно дешевшими, а стартапи, які вже перейшли на цей підхід, бачать у 2–3 рази кращі показники кеш-хітів.
Мультимодальні контент-блоки як клей між моделями й агентами
Ще одна фундаментальна ідея Interactions API — уніфікований формат контент-блоків. Кожен вхід і вихід описується як блок із полем type, яке може позначати текст, аудіо, відео, зображення, function_call або thought_signature. Це означає, що:
одна й та сама структура використовується для звичайних текстових діалогів;
мультимодальні сценарії (аудіо, відео, зображення) не потребують окремих форматів;
виклики функцій і результати інструментів так само вписуються в загальну модель контенту.
Для розробника це означає менше спеціальних випадків у коді. Якщо агент повертає function_call, це просто ще один контент-блок, який можна обробити, виконати відповідну функцію й додати результат як новий блок у наступну інтеракцію. Якщо модель повертає зображення чи аудіо, це так само блок із відповідним типом.
У контексті складних воркфлоу це критично: коли один агент повертає текстовий звіт, інший — промпт для зображення, а третій — аудіо-коментар, усе це проходить через один і той самий API й одну й ту саму модель даних.
Ланцюжок Deep Research → Nano Banana: приклад складного воркфлоу
На базі цих принципів у воркшопі демонструють показовий сценарій: як за допомогою Interactions API зв’язати між собою Deep Research і модель Nano Banana для генерації зображень.
Схема виглядає так:
спочатку розробник ініціює інтеракцію з агентом Deep Research, формулюючи запит, який потребує глибокого аналізу;
агент у фоновому режимі протягом кількох хвилин збирає інформацію, структурує її й повертає результат у вигляді контент-блоків;
після завершення дослідження цей результат береться як вхід для наступної інтеракції — тепер уже з моделлю Nano Banana, яка спеціалізується на генерації зображень;
Nano Banana на основі текстового опису, сформованого Deep Research, створює зображення.
Важливий момент: увесь цей ланцюжок реалізовано через один і той самий Interactions API. Розробник не перемикається між різними SDK чи протоколами, а просто змінює ціль: спочатку agentId для Deep Research, потім modelId для Nano Banana. Контент між ними передається в тому самому форматі блоків.
Такий підхід відкриває шлях до ще складніших сценаріїв. Наприклад, можна уявити:
агент, який досліджує ринок, формує текстовий звіт;
модель, яка перетворює цей звіт на серію інфографік;
інший агент, який генерує аудіо- або відео-огляд на основі тих самих даних.
Усі ці кроки можуть бути реалізовані як послідовність інтеракцій у межах одного API, де кожен етап — це або модель, або агент, але з погляду коду різниця мінімальна.
Швидкість і економність як дизайн-принципи
Якщо подивитися на всі ці елементи разом — Gemini 1.5 Flash Free, Deep Research, мультимодальні блоки, асинхронні агенти — стає помітно, що Google DeepMind намагається зрушити фокус із «максимальної потужності моделі» на «ефективність у реальних воркфлоу».
Flash Free як базова модель для коду й планування — це ставка на швидкість і низьку вартість. Deep Research як вбудований агент — це спосіб винести найдорожчі й найдовші операції в окремий шар, який виконується рідше, але дає глибший результат. Мультимодальні контент-блоки й єдиний API для моделей і агентів — це спроба зменшити фрикцію для розробників, які хочуть комбінувати різні можливості без переписування інфраструктури.
У підсумку розробник отримує можливість:
будувати агентів, які швидко реагують на користувача, використовуючи Flash Free;
делегувати важкі дослідження Deep Research, не блокуючи інтерфейс;
перетворювати результати досліджень на зображення, аудіо чи інші формати через спеціалізовані моделі на кшталт Nano Banana;
керувати всім цим через один API, який підтримує як синхронні, так і асинхронні сценарії.
Це не просто набір окремих можливостей, а цілісна модель, у якій «агентність» — це властивість всієї системи, а не однієї моделі.
Висновок: від «однієї моделі» до оркестрації агентів і медіа
Поява Interactions API, використання Gemini 1.5 Flash Free як базового «двигуна» й інтеграція Deep Research як вбудованого агента показують, куди рухається екосистема Gemini. Замість того, щоб зосереджуватися на окремих моделях, Google DeepMind вибудовує платформу, де моделі, агенти й мультимодальні формати працюють разом у єдиному кодовому шляху.
Для розробників це означає перехід від парадигми «зробити один запит до LLM» до проєктування повноцінних воркфлоу: з плануванням, довгими дослідженнями, генерацією медіа й асинхронною обробкою. І хоча Gemini 1.5 Flash Free тренували ще до появи Interactions API, саме через навички, інструкції й уніфікований формат контенту вона стає центральним елементом цієї нової, більш агентної архітектури.