Gemini Spark: як «агент» Google автоматизує рутину в Workspace

Google розгортає новий підхід до ШІ в Workspace — завжди активного агента Gemini Spark. У ролику на каналі Jeff Su показано, як цей інструмент виходить за межі простого чату й починає сам виконувати роботу в Gmail, Calendar та Drive.

Чат проти агента: що вміє Gemini Spark

Gemini Chat залишається звичним інтерфейсом: користувач ставить запитання — модель відповідає, підсумовує документи, готує тексти. Spark робить інше — запускає дії автономно, реагуючи на файли, події чи розклад.

Ключові відмінності:

• Файли в Google Drive
• Chat: уміє знайти та коротко викласти вміст файлів.

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

• Документи за розкладом

• Chat: згенерує звіт у Docs, але щоразу після запиту.

• Spark: створює той самий звіт на щоденній чи щотижневій основі без додаткових дій користувача.

• Обробка пошти

• Chat: може підсумувати листи та накидати відповіді, але не підтримує стабільний формат, не архівує і не навішує мітки.
• Spark: запускає власний сценарій обробки («triage»): форматує підбірки листів у заданому стилі, пропонує мітки й може автоматично архівувати зайве.

У підсумку Chat — це реактивний інструмент для відповідей, тоді як Spark — проактивний агент, що сам ініціює завдання.

Перші налаштування: пам’ять і «Spark OS»

Щоб Spark працював повноцінно, потрібні кілька кроків у Google-акаунті:

• Увімкнути пам’ять і доступ до сервісів
• У розділі налаштувань Gemini — пункт «Personal intelligence» — варто увімкнути Memory. Це дозволяє системі зберігати робочі звички та уподобання.

• У вкладці Connected apps переконатися, що активовані Google Workspace та Search Services. У корпоративних акаунтах доступна лише вкладка Connected apps, де достатньо ввімкнути Google Workspace.

• Створити базову структуру у Drive
  У корені My Drive створюється папка Spark OS — це буде опорна точка для правил, шаблонів і тимчасових результатів.

Ця структура згодом використовується в усіх прикладах — від звітів до складніших «playbookів».

Чотири ключові можливості Gemini Spark

1. Об’єднання контексту з різних сервісів

Spark працює як єдиний «омнібокс» для Gmail, Calendar, Drive та вебу — та ще й уміє діяти відразу після пошуку.

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

Важливий момент: користувачеві не потрібно відкривати окремо Gmail, Calendar чи Drive — агент сам шукає потрібні листи, події та файли, зшиваючи контекст в одну дію.

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

2. Робота за шаблонами: стабільні звіти без перепояснень

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

Рекомендована логіка:

1. Підготувати структуру
2. У папці Spark OS створити підпапку Spark templates.

3. Додати туди Google Doc із шаблоном, наприклад «Weekly Report Template» з типовими блоками: ключові результати, ризики, наступні кроки тощо.

4. Організувати «сирі» дані
   Команди (наприклад, продажів) ведуть один вхідний документ з хаотичними оновленнями.

5. Попросити Spark зібрати матеріал
   Агент отримує інструкцію: взяти нові оновлення з intake-документа й перетворити їх на лаконічний звіт у форматі шаблону.

Результат — стабільно оформлений лідершип-бріф без необхідності щоразу пояснювати структуру. Достатньо один раз закріпити логіку в шаблоні та спрямувати до нього Spark.

3. Skills: повторювані «плейбуки» замість одноразових промптів

Щоб не копіювати довгі інструкції, у Gemini Spark є Skills — повторювані «форми» обробки даних.

Процес побудови виглядає так:

1. Тимчасова папка для результатів
   У Spark OS створюється папка, наприклад 99_Temp, куди зберігатимуться вихідні файли.

2. Створення Skill із уже працюючого сценарію
   Після того, як Spark одного разу згенерував щотижневий звіт, користувач просить:

3. створити Skill «Weekly report»,

4. налаштувати його так, щоб він:

   • знаходив найновіший запис у intake-документі,
   • переформатовував його відповідно до шаблону,
   • зберігав результат у 99_Temp,
   • а перед збереженням показував план дій для затвердження.

5. Автоматичне узгодження
   Spark спочатку формулює своє розуміння завдання та пропонує кроки. Після підтвердження користувача Skill стає доступним у відповідній вкладці.

Використання надалі просте: у новому чаті достатньо ввести / і вибрати потрібний Skill — агент виконає зафіксований сценарій щодо нового вмісту.

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

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

Окрема перевага — можливість:
– імпортувати чужий Skill (наприклад, для обробки пошти до «inbox zero»),
– експортувати свій для колеги — через завантаження/вивантаження файлу skill.md.

4. Scheduled tasks: коли Skill запускається сам

Якщо Skill — це інструкція, то Scheduled task — це тригер, який її запускає. Тут доступні два типи запуску:

• За часом (time-based)
  Наприклад, перетворити щотижневий Skill зі звітом на повністю автоматичний:
• створити задачу, що запускає Skill щопонеділка о 9:30,
• перевірити її у вкладці Schedules,

• за потреби вручну протестувати натисканням «Run».

• За подією (event-based)
  У Workspace є типовий сценарій: після кожної зустрічі користувач отримує на пошту автозгенерований транскрипт від службової адреси Gemini Notes. На це можна повісити тригер:

• «коли приходить лист від певної адреси з транскриптом,
  — проаналізуй зустріч,
  — підготуй лаконічний бриф у форматі “bottom line first”,
  — за потреби накинь чернетку рекеп-листа для учасників».

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

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

Spark, Claude, Codeex: де межа можливостей

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

Переваги Spark

• Мінімум налаштувань
  Spark уже вбудований у Gmail, Calendar та Drive. Не потрібно підключати додаткові інструменти чи писати сценарії.

• Хмарне виконання
  Усі задачі виконуються на стороні Google. Розкладені та подієві задачі продовжують працювати, навіть коли ноутбук вимкнений. У конкурентів на кшталт Claude Cowork чи Codeex часто потрібен активний локальний клієнт або сервер.

Обмеження Spark

• Невеликий список інтеграцій
  У розділі Connected apps поки що небагато зовнішніх сервісів, з якими Spark може працювати напряму. Для агента, чия роль — «ходити» по інструментах користувача, це помітний мінус, особливо на тлі ширших каталогів інтеграцій в Anthropic Claude.

• Закрита модель і непрозора пам’ять
  Користувач не може обрати конкретну модель Gemini — іноді результати виявляються нестабільними.
  Крім того, Spark не надає прозорого списку того, що «знає» про користувача: запит «покажи все, що ти про мене пам’ятаєш» дає розмиту відповідь. Для порівняння, у Claude Cowork використовують файл memory.md, де користувач чітко формулює, що має бути в «довгостроковій пам’яті» агента.

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

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

Як побудувати власну «систему Spark»

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

Базовий підхід:

1. Файл правил для Spark
   У папці Spark OS створюється документ Spark.md, де фіксуються «правила робочого простору». Для початку — кілька простих:
2. комунікаційне правило: завжди починати відповіді з короткого висновку (bottom line up front), а вже потім додавати деталі;
3. файлове правило: за замовчуванням зберігати всі нові файли до папки 99 (умовний «інбокс» для артефактів Spark).

Такий документ можна створити прямо через команду до агента: він сам додасть файл до Spark OS з потрібними правилами.

1. Явне підключення правил у запиті
   Надалі, формулюючи робочі завдання (наприклад, порівняти стратегії ШІ Google і Microsoft), користувач додає інструкцію «прочитай Spark.md перед відповіддю». У відповідях Spark уже дотримується закріплених там принципів — наприклад, починає з короткого підсумку.

Цей підхід наслідує логіку Claude Cowork та подібних систем, де агент завжди відштовхується від одного чи кількох керівних документів. Автоматичне врахування Spark.md поки що недоступне, але розробники Gemini натякають, що розширене налаштування для «просунутих користувачів» з часом стане частиною платформи — як на рівні markdown-документів, так і на рівні Skills.

Джерело

YouTube: Learn 90% of Google’s Gemini Spark in 15 Minutes!