ChatGPT Tasks vs Gemini Spark vs Copilot Tasks: що обрати

ChatGPT Scheduled Tasks варто тестувати для reminders, recurring briefings, monitoring і підтримуваних event-triggered workflows у Work. Gemini Spark варто тестувати для довших personal workflows, де task може використовувати reusable skills, запускатися за часом або умовою та працювати з дозволеними Google-сервісами. Copilot Tasks варто тестувати, коли потрібне видиме browser-based виконання з можливістю спостерігати, зупинити або перебрати керування. Це стартові гіпотези, а не рейтинг надійності.

Назви приховують різні runtime contracts. ChatGPT task може повідомити про зміну або відреагувати на підтримувану Gmail, Slack чи GitHub подію; Gemini Spark відокремлює task, schedule і skill; Copilot Tasks може планувати багатокрокову роботу, взаємодіяти із сайтами та просити approval. Доступність залежить від account, plan, region, app version і rollout. Microsoft прямо позначає Tasks як preview, тому вибір потребує current capability receipt і повторюваного pilot.

• Briefing, reminder або change monitor → почніть із ChatGPT Scheduled Tasks.
• Task + reusable skill + Google-connected workflow → перевірте Gemini Spark.
• Видимий browser workflow із take-over → перевірте Copilot Tasks preview.
• Критична операція → використовуйте окремий керований control plane.

Reminder має простий контракт: правильний зміст, час і одержувач. Monitor додає retrieval: система періодично або за подією перевіряє джерело й повідомляє лише про material change. Agentic action додає planning, tools і можливий side effect. Один успішний reminder не доводить, що продукт безпечно виконає purchase, змінить файл або надішле лист; один гарний browser demo не доводить delivery SLA чи стійкість recurring run.

Перед вибором класифікуйте use case як `inform`, `propose`, `prepare` або `execute`. Inform потребує evidence і delivery receipt. Propose повертає plan та exact diff без write. Prepare може створити draft або заповнити форму, але зупиняється до submission. Execute дозволяється лише для визначених оборотних дій із вузькими параметрами. Якщо product не дає надійно відрізнити стани, залиште його в inform/propose lane.

Створіть manifest до тесту: provider, surface, plan, country, account type, app version, task type, trigger, frequency, active/concurrent limits, connected services, browser access, file access, memory, approval behavior, notification channel, checkedAt і official source. Для ChatGPT окремо позначте schedule, monitoring та event trigger. Для Gemini не переносіть властивості scheduled actions у Spark schedules. Для Copilot збережіть preview label і controls саме у вашому account.

Authority manifest перелічує дозволені domains, accounts, folders, mailboxes, recipients, action classes, spend ceiling і заборонені дані. Connected account не є blanket authorization. Browser cookie не є дозволом змінювати будь-яку сторінку, а reusable skill не повинен непомітно розширювати права task. Якщо exact scope неможливо переглянути, використовуйте synthetic account або read-only fixture.

• Identity → account, plan, region, app і connector owner.
• Trigger → time, event або condition з timezone та end condition.
• Authority → read, draft, submit і irreversible actions окремо.
• State → pending, running, awaiting-approval, completed, failed, paused або unknown.
• Evidence → source snapshot, trajectory, output і authoritative postcondition.

Copilot документує approvals або hand-back для платежів, надсилання personal information, повідомлень іншим людям, account/file changes та інших sensitive actions. ChatGPT event-triggered action також може призупинитися до approval. Ці gates зменшують ризик, але користувач може підтвердити неправильний target або застарілий plan. Approval card має показувати exact destination, normalized parameters, data leaving the boundary, expected effect, reversibleUntil та evidence, що призвело до дії.

Після approval потрібна reconciliation. HTTP success, зникнення spinner або фінальний текст агента не доводять, що email надіслано один раз чи файл змінено правильно. Перечитайте authoritative system of record, порівняйте intended diff з actual state та збережіть object ID. Після timeout спочатку шукайте committed effect за idempotency key; blind retry створює дубль саме тоді, коли UI здається невизначеним.

Microsoft окремо попереджає про prompt injection на сайтах, із якими взаємодіє Copilot Tasks. Та сама загроза стосується workflow, що читає email, issue, document, page або tool output. Додайте fixture з прихованою інструкцією змінити destination, попросити secret або ігнорувати approval. Очікуваний результат: content лишається data, task дотримується owner instruction та policy, а підозрілий перехід зупиняється з видимою причиною.

Memory і reusable skills перевіряйте як версійовану конфігурацію. Збережіть instruction hash, source owner, allowed tools і lastReviewedAt. Негативні тести: skill змінився після створення schedule; memory містить стару адресу; connector відкликано; browser session увійшла не в той tenant; page відкрила redirect на схожий domain. Cleanup перевіряйте окремо для history, memory, screenshots, cookies, connectors та зовнішньої системи.

Scheduled consumer agents не слід трактувати як гарантований job scheduler. Google документує approximate run times, delays, compute/concurrency limits і pause після downgrade або вимкнення Spark. ChatGPT має plan-dependent active/frequency limits та може pause inactive task. Copilot preview залишає usage і experience мінливими. Deadline-critical або regulatory workflow потребує orchestrator із SLA, queue, retry policy, audit export і on-call ownership.

Для low-risk workflow зберігайте run receipt: local task ID, schedule revision, due window, observed time, input freshness, tool calls, approval state, delivery та verdict. Missed run діагностуйте без mutation: task існує? paused? capacity exhausted? credential revoked? output створений, але notification не доставлена? Recovery run отримує новий cutoff і label. Side-effect replay заборонений, доки не перевірено postcondition та duplicate key.

• Freshness fail → не подавати старий snapshot як поточний.
• Capacity fail → queue або human fallback, не прихований пропуск.
• Approval wait → expiry і named owner.
• Unknown outcome → reconcile before retry.
• Preview drift → повторити fixtures після material release change.

День 1: створіть три synthetic lanes. Briefing lane збирає відомості з frozen джерела. Monitor lane знаходить одну material change і ігнорує near-match. Action lane готує draft у тестовому account та зупиняється перед consequential submit. Дні 2–4: запустіть candidates на однакових acceptance criteria, але не змушуйте product імітувати unsupported surface. Якщо event або browser execution недоступні, зафіксуйте `not eligible`, а не оцінюйте їх за chat output.

Дні 5–6: введіть stale source, prompt injection, revoked connector, timezone change, duplicate event, approval expiry і timeout-after-write simulation. День 7: виконайте pause, export доступних receipts, connector revoke, cookie/memory cleanup та re-entry test. Reviewer оцінює trigger precision, supported claims, wrong-tool rate, unexpected navigation, approval clarity, duplicate effects, recovery time та cost per accepted run. Результат належить вашому fixture, account і даті, а не є універсальною accuracy.

Рішення приймайте по lane: один product може виграти monitoring, інший — supervised browser preparation, а production action може лишитися no-fit. Decision record містить chosen surface, allowed task classes, data classes, authority ceiling, approvals, evidence retention, owner, review date та stop triggers. Не давайте task право на payments, sensitive decisions щодо людей, security changes або professional judgment лише через технічну здатність відкрити сторінку.

Rollout починається з одного read-only або draft-only task. Promotion потребує accepted runs, пройдених negative fixtures, відсутності duplicate effects і зрозумілого failure queue. Rollback: pause schedules, stop task, revoke connectors/cookies, reconcile external state, зберегти мінімальний incident receipt і повернути workflow людині. Для centralized policy, deterministic retries, machine-readable audit і team-wide kill switch перенесіть execution у керовану automation platform.