Як Stampli перетворив ChatGPT Work і Codex на GTM-систему: від продуктового контексту до сотень матеріалів

У product marketing вузьке місце часто не «написати текст», а відновити, що саме змінилося в продукті, чому команда це змінила, які обмеження діють і що вже пообіцяно ринку. Коли джерела розкидані між Jira, GitHub, meeting notes, Google Workspace та усними домовленостями, кожний launch починається з археології. Накласти на це генератор тексту — банальний спосіб прискорити створення красиво оформлених помилок.

Stampli використав ChatGPT Work і Codex як шар, що зводить product context, рішення та messaging guidance в один робочий контур. Під час запуску Deep Finance цей контур допомагав перетворювати evolving decisions на review-ready blog series, email, webinar deck, social/paid creative, PR, web page та sales enablement. Важливіше, що той самий підхід залишився щоденною системою підтримки product materials, а не одноразовим «AI launch stunt».

Trigger — product release, зміна feature/status, нове рішення після meeting, запит на launch asset або потреба оновити downstream materials. Input — versioned product context: Jira items, GitHub changes, meeting notes, approved messaging, prior assets, owners, release state і channel-specific constraints. У production-відтворенні доступ до цих джерел має бути read-scoped за ролями; model context не повинен автоматично бачити весь corporate drive лише тому, що «так зручніше».

AI stage складається з retrieval/context assembly, change detection, task decomposition, draft generation і validation prompts. Integrations — issue tracker, repository, workspace/documents, content repository та approval surface. Output — candidate updates або assets із provenance: які source records використані, що змінилося, які claims потребують перевірки і хто має затвердити результат.

• Trigger → release event, product decision, changed ticket/code або explicit content request.
• Input → approved product sources + messaging rules + channel/template contract + ownership metadata.
• AI → retrieve, compare, summarize delta, build candidate asset, flag unsupported claims.
• Integrations → Jira/Atlassian, GitHub, workspace/docs, content systems; write access відокремлений від read access.
• Output → review-ready artifact + evidence pack + exact publish/update proposal.

Репродукований workflow: `release/change event → source sync → permission filter → context snapshot → delta extraction → asset plan → draft/update → deterministic checks → factual/brand review → publish approval → authoritative publication check`. Snapshot повинен мати repository SHA, ticket/release IDs, source timestamps, prompt/policy version і target channel. Інакше через два тижні неможливо пояснити, чому AI написав саме це.

Для ongoing content корисний change ledger: кожна downstream сторінка знає, від яких product facts вона залежить. Коли змінюється pricing, availability, supported integration або release date, система не переписує весь сайт; вона створює candidate impact set. Це різко знижує blast radius і робить review реальним, а не символічним.

A3 доречний: агент може сам зібрати context, визначити affected assets, сформувати drafts і запустити checks, але не має самопризначеної authority на зовнішню публікацію. Перед publish reviewer бачить exact diff, supporting sources, unresolved claims і channel target. Для legal, security, pricing або partner statements потрібен окремий owner.

Особливо небезпечні непрямі інструкції у retrieved text. Issue comment або зовнішній документ може містити prompt-like content; його треба трактувати як data, не як instruction. System policy, tool permissions і publish authority живуть поза retrieved corpus. Це простіше, ніж після релізу сперечатися, хто саме дозволив боту придумати новий SLA.

Failure modes: source sync пропустив change; Jira і GitHub суперечать одне одному; release відкладений після draft; draft посилається на deprecated feature; tool timeout стався після CMS write; дві паралельні задачі оновили одну сторінку; retrieved source містить malicious instruction. Для conflict система abstain-ить і піднімає owner task, для stale source — блокує publish, для timeout — читає authoritative CMS state до retry.

Write-action отримує idempotency key на `asset + source snapshot + intended version`. Після publish система перевіряє canonical URL/version, а не вірить HTTP success. Якщо customer-facing asset уже змінився людиною, автоматичний retry не повинен затерти новішу версію; потрібен merge/review path.

На малому обсязі AI економить drafting time; на великому bottleneck стає source freshness, review capacity, permissions і context cost. Масштабування потребує incremental indexing, cache для stable context, task queues за severity, per-channel templates і policy-based model routing. Heavy reasoning не варто витрачати на mechanical diff, а дешевий route не варто пускати на ambiguous claims.

Повний cost model: `model inference + retrieval/indexing + connector/API cost + tool runtime + storage/versioning + observability + human review + correction/rework + incident reserve`. Показник 3.16× у Stampli походить із modeled hours конкретного launch workflow. Для власного rollout рахувати треба `cost per verified published asset`, `time from source change to approved update`, rework rate і escaped factual errors.

Eval set має містити historical releases, conflicting sources, deprecated features, delayed launch, pricing change, missing permissions, adversarial ticket text і duplicate event delivery. Deterministic graders перевіряють URLs, required fields, source timestamps, forbidden claims і link integrity; model/human graders — factual support, message consistency та omission severity. Найважливіша негативна перевірка: система повинна відмовитися від publish-ready claim, якщо evidence недостатньо.

Rollout: `offline replay → read-only context assistant → draft-only for one content type → automated impact detection → bounded multi-asset generation → approved CMS writes → broader channels`. Promotion лише після стабільної source coverage, нульових critical unsupported claims у acceptance window, прийнятного review time і відпрацьованого rollback. Production incident стає permanent regression case.

Патерн підходить B2B SaaS, fintech, platform products і компаніям із частими releases, де product truth живе у кількох engineering/business systems. Не починайте з «підключимо все». Виберіть один release stream, 20–50 ключових assets і 3–5 authoritative source types; зафіксуйте ownership, access і freshness SLA.

За 2–4 тижні можна зібрати pilot: побудувати source adapters, створити versioned context snapshot, replay-нути 50 historical changes, виміряти recall affected assets і factual precision drafts, підключити exact-diff review і лише потім дозволити bounded write. Мета — не більше тексту. Мета — швидше переносити підтверджену product truth у канали без втрати контролю.