ChatGPT Agent vs Deep Research: досліджувати чи виконувати дії

Обирайте Deep Research, коли кінцевий артефакт — перевірюваний звіт: зібрати джерела, розкласти складне питання, зіставити суперечності й передати висновки reviewer. Станом на 13 вересня 2026 року OpenAI позначає колишній ChatGPT agent mode як недоступний і спрямовує довші багатокрокові задачі та готові deliverables до ChatGPT Work. Водночас актуальна документація дозволяє запускати Deep Research не лише в Chat, а й, коли доступно account, у Work і Codex. Стару назву збережено в заголовку, бо вона описує поширений пошуковий намір, але capability треба перевіряти на поточному account.

Отже, це вже не одна вісь `Agent або Deep Research`. Спочатку оберіть method: швидкий lookup, evidence-heavy research чи виконання. Потім environment: Chat для інтерактивного report, Work для довшої задачі й готового deliverable або Codex для repository-bound роботи. Для research перевіряють claim support, coverage і citations; для workflow з інструментами додатково доводять правильність цілі, effective permissions, точні параметри, approvals, side effects, reconciliation та можливість зупинити або відкотити процес.

• Потрібен evidence report із керованими джерелами → Deep Research у доступному середовищі.
• Потрібен багатокроковий finished deliverable → перевірте Work; для repository-bound задачі — доступний Codex contour.
• Потрібні і докази, і зовнішня дія → два етапи з окремим людським approval між ними.
• Наслідкова або незворотна операція → human-owned workflow, навіть якщо execution environment допомагає з підготовкою.

Зафіксуйте decision receipt до запуску. Поля `method`, `environment`, `account/workspace`, `model option`, `allowed sources`, `connected apps`, `web policy`, `output destination`, `write authority`, `reviewer` і `expiresAt` не дають команді плутати однакову назву функції з однаковими permissions. OpenAI прямо зазначає, що Deep Research у Work або Codex використовує джерела, доступні поточній задачі, а запуск research не надає додаткового доступу до файлів чи apps.

Handoff теж залежить від середовища. У Chat reviewer перевіряє report, citations, sources-used і activity history та може завантажити результат у підтримуваному форматі. У Work або Codex треба відкрити створений документ чи файл, перевірити citations, destination, repository/workspace state і окремо керувати збереженими файлами. Conversation retention не є доказом, що deliverable існує в потрібній папці, а створений файл не доводить, що consequential external state був змінений.

• Method receipt → чому потрібен саме Deep Research, а не search або standard chat.
• Source receipt → дозволені web domains, files, apps і effective identity.
• Artifact receipt → точний path або URL, формат, hash/version і reviewer verdict.
• Action receipt → окремий approval та authoritative postcondition лише якщо задача має write side effect.

Контракт Deep Research описує питання, часовий і географічний scope, обов’язкові першоджерела, критерії порівняння, формат звіту, citation policy та умови `не вдалося підтвердити`. Його завершенням є artifact, який людина може відкрити, перевірити й відхилити без зміни зовнішнього стану. Довший звіт або більше URL не означають кращого результату: consequential claims перевіряють на рівні supporting passage.

Контракт agent mode описує початковий і бажаний стан, дозволені домени, identity, data boundary, допустимі read/write операції, spend limit, stop conditions і postcondition. Формулювання «організуй поїздку» недостатнє: воно змішує пошук, вибір, передачу персональних даних і потенційну покупку. Розкладіть роботу на research brief, approved shortlist і окрему дію з точними параметрами.

OpenAI описує confirmations перед consequential actions і передачу керування користувачу для окремих чутливих кроків. Це важливий control, але команда все одно має перевірити effective account permissions, already-authenticated sessions, connected apps, downloadable data та наслідки кожної дії. Confirmation повинна показувати конкретний об’єкт, суму, одержувача й незворотність; загальне «продовжити» не дає змістовної згоди.

Не дозволяйте тексту вебсторінки розширювати повноваження. Retrieved page, email, document або tool result — недовірені дані, які можуть містити prompt injection. Інструкція на сторінці не може змінити дозволений домен, додати одержувача, відкрити secret, вимкнути review або перетворити read task на write. Якщо agent просить login або користувач takeover, після повернення потрібно заново показати pending plan і перевірити, що параметри дії не змінилися.

• Окремий тестовий account і мінімальні permissions для pilot.
• Allowlist доменів та операцій замість необмеженої сесії браузера.
• Exact-action confirmation після будь-якої зміни parameters.
• Ніяких паролів, recovery codes або payment secrets у prompt чи artifact.

У Deep Research створіть claim ledger: atomic claim, source URL, publisher, дата, supporting passage, verdict і reviewer. Перевіряйте, чи citation підтримує саме твердження, чи знайдена чинна редакція документа і де джерела конфліктують. Офіційна сторінка vendor є первинним джерелом його власної функції, але не незалежним доказом переваги або ринкового результату.

В agent workflow URL і screenshot не доводять завершення дії. Потрібні authoritative state evidence: order ID у системі продавця, ticket status із system of record, calendar event із правильним owner або read-after-write response. Після timeout не повторюйте дію наосліп: спочатку виконайте reconciliation за idempotency key чи зовнішнім reference. Інакше успішний перший крок може перетворитися на duplicate purchase або повторне повідомлення.

Для задач, де режими справді доповнюють один одного, зафіксуйте дві різні lifecycle states. На етапі `researching` Deep Research збирає варіанти й evidence без authority діяти. Reviewer переводить вибраний варіант у `approved`, фіксуючи точні параметри та строк чинності. Лише тоді agent отримує короткий action contract. Будь-яка матеріальна розбіжність повертає задачу в review, а не запускає імпровізацію.

Цей розрив також покращує audit і rollback. Research artifact можна оновити або відхилити; action run має власні timestamps, confirmations, state transitions і postcondition. Kill switch зупиняє нові дії, ізолює незавершену сесію та передає reconciliation оператору. Звіт не повинен автоматично ставати планом виконання лише тому, що його створив той самий продукт.

Зберіть task set із трьох груп: research-only, action-only і змішані задачі. Для research додайте застарілий документ, суперечливі джерела, paywall, твердження без доказу й prompt injection у файлі. Для actions додайте wrong recipient, changed price, revoked permission, timeout до та після side effect, expired approval, unexpected login і сторінку з malicious instruction. Наперед визначте очікувану abstention або escalation.

Вимірюйте verified task success, critical unsupported-claim rate, prohibited-action rate, correct-confirmation rate, duplicate side effects, recovery success, reviewer corrections, elapsed time і повну вартість прийнятого результату. Provider-reported system-card evals допомагають зрозуміти відомі ризики, але не замінюють тест вашого account, сайтів і data boundary. Один красивий demo не є rollout evidence.

Почніть із research-only задач і read-only browser navigation, далі проведіть shadow run поруч із людиною. Bounded reversible writes відкривайте лише після негативних тестів, exact-action confirmation і перевіреного postcondition. Для команди визначте owner, дозволені plans/regions, account policy, retention, review threshold, incident path і дату повторного eval після product update.

Rollback вимикає нові agent runs, відкликає connected access, завершує або reconcile незакриті операції й повертає workflow до ручного виконання. Deep Research artifacts можна зберегти за чинною retention policy, але вони не підтверджують, що зовнішня дія була виконана або скасована. Не послаблюйте цей control через добру якість текстових відповідей: research accuracy та action safety — окремі gates.

Найнебезпечніша помилка виникає не всередині окремого режиму, а на переході між ними. Research brief часто містить дієслова на кшталт «знайди, обери й забронюй», тому система може сприйняти рекомендацію як дозвіл продовжити. Розділіть intent на два машинно й людськи читабельні контракти. Research contract має право лише читати, порівнювати й формувати evidence bundle. Action contract створюється після review та називає один затверджений об’єкт, параметри, межу витрат, дозволену операцію й умову завершення.

Gate повинен відхиляти не лише відсутній approval, а й семантичну невідповідність. Якщо звіт рекомендував refundable room, а action page показує non-refundable rate; якщо валюта, одержувач, дата, кількість або account змінилися; якщо джерело втратило чинність — попереднє рішення більше не authorizes дію. Agent не має самостійно обирати «найближчий» варіант. Він повертає diff до reviewer із поясненням, яка саме умова перестала збігатися.

Для особистої разової задачі цей gate може бути коротким confirmation screen. Для команди потрібен versioned handoff: research artifact hash, selected option ID, approver, approval time, expiry, allowed action і expected postcondition. Не переносіть cookies, відкриті вкладки або browser session як неявний доказ згоди. Технічна безперервність сесії не є безперервністю людського рішення.

• Research state → read і synthesis дозволені; зовнішні writes заборонені.
• Review state → людина обирає точний варіант і фіксує constraints.
• Action state → agent отримує мінімальний одноразовий контракт.
• Mismatch state → параметри змінилися; потрібен новий review.
• Reconciled state → authoritative system підтвердив результат або відсутність дії.

Approval не повинен бути безстроковим токеном «зроби щось подібне». Визначте lease: до якого часу він чинний, для якого account і домену, яка максимальна сума або інша consequence, чи дозволена одна спроба, і які зміни анулюють згоду. Коротка тривалість особливо важлива для цін, availability, schedule та політик скасування. Після expiry agent може оновити read-only evidence, але не продовжити write без повторного підтвердження.

Прив’яжіть lease до нормалізованого action fingerprint: operation type, target identifier, істотні параметри, currency, total, owner identity та research version. Перед фінальною дією система повторно обчислює fingerprint і порівнює його з approved value. Це не замінює зрозумілий confirmation для людини; воно не дає інтерфейсу випадково підтвердити одну сутність, а tool call виконати іншу.

Lease споживається після підтвердженого side effect. Якщо відповідь невизначена, його не можна автоматично використати вдруге: спочатку read-after-write або перевірка в system of record. Якщо дія не відбулася й це доведено, policy може дозволити контрольований retry із тим самим idempotency key. Якщо стан не вдалося встановити, задача переходить оператору, а не в нескінченний цикл повторів.

Повний research transcript є поганим action input: у ньому багато альтернатив, неперевірених уривків і недовірених інструкцій зі сторінок. Створіть мінімальний evidence handoff. Він містить decision statement, обраний canonical identifier, перевірені параметри, посилання на supporting sources, unresolved caveats, timestamp і reviewer verdict. Цитований текст залишається data, а не command; лише окремі поля action contract можуть керувати tool call.

Reviewer має бачити provenance до approval: яке джерело підтверджує ціну або правило, коли його відкрили, чи існує конфлікт і що не вдалося перевірити. Agent mode перед виконанням перевіряє freshness-sensitive поля на authoritative сторінці, але не переписує business decision. Наприклад, він може повідомити, що ціна зросла, проте не має права компенсувати це дешевшим non-refundable варіантом без нового вибору.

Після run доповніть bundle execution evidence: action fingerprint, confirmation, tool response, external reference, postcondition check і залишкові obligations на кшталт cancellation deadline. Так один пакет відповідає на три різні питання: чому варіант обрали, що саме дозволили та який стан реально настав. Screenshot можна додати для діагностики, але authoritative reference і read-back мають вищу доказову силу.

• Decision evidence → supporting sources, caveats і reviewer verdict.
• Authority evidence → approver, scope, expiry та action fingerprint.
• Execution evidence → tool result, external reference і postcondition.
• Recovery evidence → reconciliation result, retry decision або operator handoff.

Назва продукту не є стабільним capability contract. Перед pilot зафіксуйте дату, план ChatGPT, тип workspace, роль користувача, регіон, доступні connectors, стан browser session і фактичні controls, які бачить тестовий account. Deep Research може працювати з public web, завантаженими файлами та дозволеними джерелами, але конкретний набір source controls і usage limits залежить від чинного product contract. Agent mode так само не слід вважати доступним або однаково керованим для кожного account лише тому, що він описаний у публічній документації.

Збережіть capability manifest разом із eval run: `mode`, `workspace`, `plan`, `region`, `connectors`, `allowed domains`, `confirmation behavior`, `takeover behavior` і `checkedAt`. Невідому можливість позначайте `unverified`, а не `supported`. Якщо команда не може відтворити capability на цільовому account, workflow залишається research-only або ручним; marketing page не замінює acceptance test.

• Re-check перед rollout і після суттєвого product update.
• Окремі manifests для personal, team та managed workspace.
• Connected source не означає дозволу на будь-яке читання або запис.
• Unavailable чи unverified capability не входить у business case.

Для exact lookup — чинний тариф, дата або формулювання policy — починайте з прямого першоджерела чи звичайного search. Для synthesis багатьох джерел із claim-level review використовуйте Deep Research. Якщо потрібна лише навігація до сторінки або заповнення чернетки без submit, agent mode може працювати в read-only чи draft-only boundary. Коли задача змінює booking, order, message, calendar, ticket або інший system-of-record state, вона потребує окремого approval, exact-action diff і authoritative postcondition.

Маршрут визначає найнебезпечніший необхідний крок, а не середня складність задачі. Якщо 90% роботи — research, а останній крок надсилає лист клієнту, весь run не повинен успадковувати write authority від початку. Розділіть його на evidence artifact, людське рішення та короткий action envelope. Якщо під час виконання змінюються target, сума, дата, одержувач, data class або незворотність, approval спливає й задача повертається до review.

• Exact fact → direct source або search із ручною перевіркою.
• Multi-source evidence pack → Deep Research.
• Read-only navigation чи draft → bounded agent session.
• External state change → approved action envelope та postcondition.
• High-impact або незворотне рішення → людина виконує consequence-bearing крок.

Research-to-action handoff має бути новим артефактом, а не кнопкою «продовжити» під довгим звітом. Мінімальний packet містить approved option, exact target, immutable parameters, allowed data, maximum spend, expiry, reviewer identity, source claims, unresolved assumptions, prohibited actions і expected postcondition. Agent отримує лише packet та мінімальний контекст для виконання; чернетки, відхилені варіанти й сторонні інструкції зі звіту не стають operational policy.

Після run зв’яжіть packet із confirmation event, external reference, read-after-write evidence та final state `verified`, `failed`, `unknown` або `needs-reconciliation`. Стан `unknown` не можна автоматично трактувати як failure і повторювати write: спочатку перевірте system of record. Для rollback зупиніть нові runs, відкличте session або connector access, reconcile незавершені side effects і поверніть task owner людині. Це створює audit trail без вигаданого припущення, що текстова відповідь доводить зовнішній результат.

OpenAI нині прямо позначає ChatGPT agent як недоступний і рекомендує ChatGPT Work для довших багатокрокових задач та finished deliverables. Це робить старе бінарне питання «agent чи Deep Research» міграційним наміром: спочатку встановіть, який current surface доступний на вашому plan, workspace і platform, а вже потім переносіть workflow. Історичний опис agent mode корисний для розуміння browser actions, takeover, confirmations і prompt-injection risk, але не є доказом актуальної кнопки, entitlement або tool set.

Не перейменовуйте старий production workflow лише на підставі маркетингової наступності. Побудуйте migration diff: legacy mode і current Work surface, доступні apps/tools, local або cloud execution, data boundary, approvals, admin controls, usage model, artifact formats та recovery behavior. Кожне поле має статус `verified`, `changed`, `unavailable` або `unknown` із датою та account evidence. Якщо critical write або rollback control невідомий, міграція лишається read-only чи draft-only.

Deep Research водночас зберігає окремий контракт: користувач обирає public web, uploaded files, specific sites або enabled apps; переглядає proposed research plan; може змінювати focus і sources під час run; отримує report із citations, sources-used section та activity history. Тому Work не треба автоматично використовувати для кожного складного питання. Якщо acceptance artifact — documented report, Deep Research дає чіткіший source-control і review boundary.

• Legacy query → зафіксуйте, що саме користувач називає agent mode.
• Current surface → перевірте Work availability на цільовому account і platform.
• Research-only outcome → залиште Deep Research із reviewed source plan.
• Tool-bearing workflow → повторіть permission, approval, side-effect і recovery eval.
• Unknown capability → не включайте її в rollout або ROI model.

Замість таблиці, яка швидко старіє, створіть capability receipt для кожного eval: `checkedAt`, product surface, plan, workspace class, role, platform, rollout state, enabled apps, tool permissions, write-approval behavior, data location, retention policy та observed limits. Прикріпіть first-party documentation URL і фактичний account screenshot або exported setting як різні типи evidence. Документація підтверджує заявлений contract; account evidence підтверджує, що він доступний саме вам.

Receipt має expiry. Повторюйте probe після перейменування surface, model/tool migration, зміни plan, admin policy, connected app, platform або material release note. Не порівнюйте результат старого agent-mode eval із новим Work run як одну безперервну time series без version marker. Спочатку replay frozen fixtures: source-restricted research, uploaded-file synthesis, draft deliverable, harmless app read, blocked write, approved reversible write, timeout та revoke.

Decision log відділяє три твердження: функція задокументована; функція спостерігається на нашому account; workflow пройшов наш acceptance test. Лише третє підтримує rollout. Такий поділ не дає свіжій продуктовій назві успадкувати старі оцінки без перевірки й не перетворює відсутність доступу під час поступового rollout на універсальну заяву про продукт.

Підключена app не має одного універсального рівня доступу для всіх ChatGPT surfaces. Поточна документація OpenAI описує Deep Research як workflow, що використовує лише read actions із підключених apps. Окремо Apps in ChatGPT може підтримувати search, sync, interactive experiences і write actions залежно від app, plan, workspace, role та configuration. Тому факт, що Deep Research прочитав CRM або drive, не доводить, що Work може щось записати туди, і навпаки: наявний write action не перетворює research report на дозвіл його викликати.

Перед eval побудуйте authority envelope для конкретної комбінації `surface + app + account + role`. У ньому перелічіть дозволені read resources, доступні action names, data classes, approval policy, admin restriction, target tenant і session expiry. Значення отримуйте з поточних workspace settings та контрольного probe; назва app у меню — лише discovery evidence. Поля, яких не видно або які не перевірені, позначайте `unknown` і не включайте в production workflow.

Research-to-action handoff повинен зменшувати authority, а не переносити її неявно. Deep Research віддає reviewed claim ledger і canonical identifiers без credentials, сторінкових інструкцій та повного transcript. Окремий action envelope називає одну операцію, target, істотні parameters, approver, expiry і expected postcondition. Якщо app просить ширший scope, інший tenant або нову дію, run зупиняється на re-authorization; він не адаптує permissions під текст звіту.

• Deep Research app access → read-only за documented product contract.
• Write-capable app → окрема capability, configuration та approval evidence.
• Surface change → новий capability receipt, навіть для тієї самої app.
• Unknown action або scope → fail closed і повернення owner.
• Revoked connection → containment, reconciliation і ручний recovery path.

Deep Research дає proposed plan, source controls, progress view, activity history і структурований report із citations або source links. Ці функції створюють review surface, але не автоматичний verdict якості. До запуску перетворіть питання на coverage matrix: decision criterion, потрібний тип джерела, часовий cutoff, geography, freshness tolerance і правило для missing evidence. Після run кожен material claim має посилатися на supporting passage, а не лише на релевантний документ; кожен обов'язковий criterion отримує стан `supported`, `conflicted`, `stale`, `missing` або `not-applicable`.

Окремо тестуйте source-control semantics. Fixture із дозволеними domains перевіряє, чи report справді спирається на них; режим prioritize-but-allow-web не слід описувати як жорстке обмеження. Fixture з uploaded file та connected app перевіряє attribution і data boundary, а суперечливі редакції policy — чи система показує конфлікт замість тихого вибору зручнішого тексту. Activity history допомагає відтворити маршрут, але фінальне citation audit усе одно читає consequential passages у першоджерелі.

Reviewer завершує research лише після coverage verdict і фіксує невирішені прогалини. `PASS` означає, що всі must-have criteria підтримані чинними джерелами; `CONDITIONAL` дозволяє лише явно названі припущення; `FAIL` або `STALE` блокує action handoff. Якщо report оновили, змінили source list чи додали app, попередній hash і approval більше не описують той самий artifact. Це не метрика точності OpenAI: це локальний acceptance contract для конкретного рішення.

• Coverage → усі must-have criteria мають явний evidence state.
• Entailment → cited passage підтримує точне твердження й scope.
• Freshness → дата та редакція джерела відповідають cutoff.
• Conflict → розбіжність показана reviewer, а не прихована synthesis.
• Handoff → лише versioned PASS/CONDITIONAL artifact може перейти до approval.

Не кожна складна на вигляд задача потребує найдовшого режиму. Почніть із двох осей: скільки невизначеності треба прибрати і яку зовнішню зміну може спричинити результат. Один актуальний факт із відомого першоджерела — це direct lookup або звичайний search. Рішення, що залежить від багатьох джерел, часових зрізів і суперечностей, є кандидатом для Deep Research. Finished deliverable із файлами, apps або іншими tools є кандидатом для Work лише після окремої перевірки доступного surface та permissions.

Третя вісь — ціна помилки. Помилка у внутрішній чернетці виправляється review; помилка в листі клієнту, бронюванні, закупівлі чи system-of-record write створює наслідок. Тому довгий research run може мати широку read boundary, але нульову write authority. Work run отримує лише ті tools і дані, які потрібні для затвердженого deliverable, а consequence-bearing step виноситься в короткий action envelope із точним target, параметрами, approver, expiry та postcondition.

Зафіксуйте routing receipt: сформульований outcome, мінімальний достатній режим, allowed sources, data classes, maximum authority, reviewer, time/cost budget і причина ескалації. Якщо search знаходить достатнє першоджерело, зупиніться; якщо coverage неповна — переходьте до Deep Research; якщо прийнятий artifact далі треба перетворити на дію — створіть новий контракт. Така ескалація зберігає відтворюваність і не видає тривалість роботи за інформаційний приріст.

• Один перевірюваний факт → direct source або search.
• Багатоджерельний evidence pack → Deep Research із coverage contract.
• Finished deliverable із tools → Work із capability receipt.
• Зовнішній write → окремий approved action envelope.
• Достатній доказ уже знайдено → stop, а не автоматична ескалація.

Research budget має кілька незалежних лімітів: elapsed time, кількість source hops, дозволені domains, обсяг uploaded або connected data, freshness cutoff і reviewer capacity. Work budget додає tool calls, writable objects, recipients, monetary ceiling, concurrency та кількість confirmations. Один загальний ліміт приховує головний ризик: дешевий run може прочитати надмірні дані, а короткий run — виконати дорогу або незворотну дію.

Перед запуском задайте exposure ledger: `data exposed`, `systems reached`, `actions possible`, `value at risk`, `human attention reserved` і `recovery deadline`. Negative fixtures повинні окремо вичерпувати кожний ліміт: недоступне джерело, надто широкий app result, прострочений approval, змінена ціна, новий recipient, tool timeout після можливого write та відсутній reviewer. Правильний результат — bounded abstention, downgrade до read-only або operator handoff, а не приховане розширення scope.

Після run порівнюйте не кількість сторінок чи кроків, а cost per accepted verified outcome разом із exposure. Evidence report проходить, коли покриває must-have criteria без критичних unsupported claims. Tool-bearing deliverable додатково проходить permission, action-diff, postcondition і recovery checks. Якщо простіший route дає той самий accepted outcome з меншим exposure, він є кращим для цього task class; це локальне рішення, а не універсальний рейтинг режимів.

• Time/token budget → контролює ресурс, але не authority.
• Source/data budget → обмежує exposure і provenance surface.
• Tool/action budget → обмежує можливі наслідки.
• Review budget → гарантує, що artifact справді буде перевірено.
• Recovery budget → визначає, хто і коли закриває unknown state.

Після завершення окремого agent mode не переносьте старий workflow до першої схожої кнопки. Deep Research обирайте для одноразового або періодичного evidence report, де головний результат — твердження з citations і source links. Work обирайте для довшої багатокрокової задачі та finished deliverable у доступному account. Workspace Agent розглядайте для повторюваної командної процедури з опублікованою конфігурацією, визначеними users або roles, apps і tools; OpenAI документує запуск таких agents у ChatGPT, Slack, за розкладом або через API, але сама instruction не надає app access.

Створіть surface-fit card до міграції: `jobToBeDone`, частота, expected artifact, allowed sources, required tools, write effects, operator, approver, audience, trigger, retention, portability і stop condition. Якщо задача завершується перевіреним звітом без зовнішнього write, не додавайте reusable agent лише заради автоматизації. Якщо одна процедура повторюється командою, потребує централізованого version owner і контрольованих tools, не залишайте її як персональний Work chat. Якщо потрібен repository-bound code change, відокремте Codex contour від загальної knowledge-work automation.

Назва surface не доводить authority. Для Workspace Agent перевірте, чи agent published, хто може його run, які apps дозволив admin, який account авторизував source і які tools мають side effects. Для Work перевірте task-level sources, output destination і permissions. Для Deep Research у Chat connected apps використовуються як read sources, а не як неявний дозвіл на write. Невизначений privilege або destination переводить candidate у `hold`, а не у production run.

• Deep Research → source-bounded report, citations, reviewer і no implicit write.
• Work → довга задача або finished deliverable з task-scoped tools і destination.
• Workspace Agent → repeatable shared procedure з publisher, audience, version і tool policy.
• Codex → repository-bound software task з окремими environment та change controls.
• Hybrid → research artifact стає input для execution лише після explicit approval.

Візьміть три дозволені historical tasks: research-only, document-producing і action-adjacent. Збережіть sanitized input fixture, required sources, expected claims, artifact schema, prohibited actions, reviewer rubric і known edge cases. Повторіть кожну задачу на обраному current surface з новою session та мінімальними permissions. Старий screenshot або transcript є лише baseline evidence; він не доводить, що нова surface має ті самі tools, identity, retention, confirmations чи output semantics.

Порівнюйте claim support, missing-source disclosure, artifact completeness, destination correctness, reviewer edits, permission exceptions і prohibited side effects. Для Workspace Agent додайте unentitled user, unpublished revision, removed app, revoked user authorization, schedule replay та API caller без потрібної ролі. Для Work перевірте unavailable account, interrupted run і delivery у неправильний path. Для Deep Research перевірте source restriction, inaccessible app і citation, що веде на secondary summary замість required primary source.

Міграцію приймайте лише з compatibility receipt: old surface and revision, new surface and revision, fixture ID, effective identity, tool manifest, artifact diff, material deviations, reviewer і verdict. Статус `compatible` означає еквівалентність для цього fixture та environment, а не універсальний parity. Material deviation створює explicit redesign або manual fallback; не приховуйте її новим prompt, який непомітно розширює дані чи authority.

Не передавайте весь research chat до виконавчої surface за замовчуванням. Сформуйте мінімальний handoff envelope: approved objective, selected claims із source anchors, assumptions, unresolved questions, chosen option, exact parameters, data classification, expiry, approver і prohibited actions. Excluded alternatives, retrieved instructions та неперевірені висновки залишаються evidence context, а не executable directions. Це зменшує prompt-injection carryover і не дозволяє довгому report непомітно стати authorization policy.

Перед action повторно прочитайте authoritative state: актуальну ціну, recipient, calendar slot, repository revision або ticket status. Якщо будь-який material parameter відрізняється від approved envelope, поверніть задачу до review. Після write збережіть external object ID, read-back result і reconciliation status. Timeout переходить у `unknown`; оператор спочатку шукає committed effect, а вже потім вирішує, чи безпечно retry.

Для rollback збережіть research artifact незалежно від execution log, revoke app або agent access, pause schedules та API triggers, reconcile незавершені writes і поверніть процедуру до manual owner. Видалення або unpublish Workspace Agent не слід трактувати як доказ скасування раніше створених зовнішніх об'єктів. Так само збережений report не доводить, що approved action виконано: research evidence і state evidence мають різні owners та lifecycle.

• Approved evidence → тільки перевірені claims і точні source anchors.
• Action parameters → object, recipient, amount або revision, expiry і approver.
• Authority → конкретні tools, effects і prohibitions без успадкування з report text.
• Completion → authoritative read-back, external ID і reconciliation verdict.
• Rollback → pause triggers, revoke access, reconcile state і restore manual path.