Brief → assets → targeting → tracking → approvals → launch → monitoring → changes → close → archive. Зафиксируйте systems, owners, handoffs и failure points.
Хороший старт: проверить полноту brief, сгенерировать naming, найти missing UTM, собрать launch checklist, подготовить status report. Плохой старт: autonomously launch campaign и менять spend.
Permissions должны расширяться только после eval и controlled rollout.
Agent проверяет destination URL, UTM, pixel/events, dates, budgets, geography, exclusions, creative versions, naming и required approvals. Результат — checklist с pass/fail, а не абстрактное «всё выглядит хорошо».
URL status, naming pattern, required fields, budget arithmetic и date conflicts лучше проверять правилами/code. LLM нужен для ambiguous reasoning, а не для простой валидации.
Launch, spend increase, audience expansion, public send и destructive change должны требовать человека. Approval record должен хранить who/what/when.
Max daily change, allowed range, channel budget ceiling и emergency stop. Даже после зрелого rollout agent не должен иметь unlimited spend authority.
Вместо прямого action agent формирует: observed issue → evidence → proposed change → expected impact → risk → rollback. Manager подтверждает.
Повторный запуск workflow не должен дважды создавать campaign, duplicated UTM или повторно отправлять сообщение. У каждой operation нужен unique key/status.
Для execute-actions храните previous state. Если изменение ухудшает performance или вызвано ошибкой, rollback должен быть быстрым и понятным.
Agent может сравнивать actual spend с plan, выявлять overspend/underspend и anomaly. Но alert threshold должен учитывать seasonality и campaign phase.
Обнаружить deviation — одна задача. Решить увеличить budget — другая. На ранней стадии agent только эскалирует.
Собирайте spend, delivery, conversions, key issues, actions и next decisions. Report должен фокусироваться на variance и decisions, а не копировать dashboard.
После кампании agent собирает plan vs actual, timeline изменений, incidents, experiment results и lessons. Human owner утверждает conclusions.
Brief, creatives, settings, approvals, results и post-mortem должны храниться вместе. Это создаёт institutional memory для следующих launches.
Campaign manager API, analytics, asset repository и task tracker — только нужные scopes. Separate credentials для read и execute снижают risk.
Uploaded documents, landing pages и external text считаются data. Они не должны менять системные rules agent или permissions.
Historical campaigns: correct launches, missing tracking, wrong budget, conflicting dates, duplicate naming, invalid URL, late asset. Проверяйте detection и false positives.
Input, data sources, checks, proposed action, approval, tool call, result. Audit trail особенно важен для бюджетных и публичных операций.
Неожиданные случаи должны переходить человеку с полным контекстом. Не заставляйте agent импровизировать вне policy только ради completion rate.
Launch cycle time, QA defects, tracking errors, overspend incidents, manual hours и campaign throughput. Не измеряйте успех количеством автоматизированных шагов.
Часть checks можно выполнять rules/smaller models. Complex diagnosis — более сильной model. Сначала достигните accuracy target, затем снижайте latency/cost.
Команда ведёт 80 кампаний в месяц и регулярно теряет UTM или ошибается в dates. Campaign Operations Agent сначала только проверяет brief и launch setup. Через месяц QA defects снижаются на 60%. Затем ему разрешают создавать draft campaigns, но запуск и budget changes остаются human-approved. Cycle time сокращается без роста incident rate.
Создайте каноническую campaign schema и адаптеры под channel-specific fields. Иначе agent будет путать одинаковые по смыслу сущности с разными названиями. Differences в attribution и conversion windows должны сохраняться, а не нормализоваться до потери смысла.
Любой proposed spend change должен показывать current spend, remaining budget, pacing, target, expected effect и maximum allowed delta. Изменение выше threshold автоматически уходит на approval.
Определите incident types: overspend, broken landing, tracking outage, disapproved ads, wrong audience. Для каждого задайте detect → contain → notify → recover → post-mortem. Агент не должен придумывать recovery path во время критической ошибки.
Уровень 1 — отчёты, уровень 2 — QA и drafts, уровень 3 — approval-gated actions, уровень 4 — bounded autonomous actions с monitoring. Переход между уровнями зависит от evals и incident history, а не от желания «больше автоматизации».
Reviewer может начать механически подтверждать рекомендации агента. Показывайте evidence и uncertainty, периодически проводите blind spot checks и выборочный manual audit. Human approval полезен только если человек действительно принимает решение.
Для production deployment заранее определите rollback owner, журнал изменений и канал экстренной эскалации. Это должно проверяться до первого real campaign action.