Агент, который меня заменил, или открытия одного интернет-маркетолога

У нас было 12 проектов и один человек, который отвечал за настройку всех email-рассылок.

Этим человеком был я. Директ-маркетолог с 7 годами опыта ^[1], но только с двумя руками и одной головой.

В какой-то день нужно было запустить одну рассылку. В другой — три или четыре. Для одного проекта использовался старый шаблон, для другого приходил новый. Где-то нужно было отправить письмо по всей активной базе, где-то — только определённому сегменту.

И каждую рассылку нужно было руками собрать и проверить. Тот ли шаблон? Правильная ли база? Есть ли в ней нужные поля для подстановок? Все ли ссылки работают? На месте ли отписка? Не забыли ли UTM? Не получала ли эта аудитория похожее письмо совсем недавно?
Информацию я сводил в заметки, таблицы, что-то хранилось даже в специально выделенных чатах телеги…

А после нажатия «Send» работа не заканчивалась.
Нужно было вернуться за статистикой, собрать метрики, перенести их в таблицу, посмотреть на конверсии, сравнить результаты с предыдущими рассылками. А через какое-то время — вернуться снова, потому что данные успели актуализироваться.

По отдельности ни одна из этих задач не выглядит сложной. Проблема начинается, когда проектов двенадцать, рассылки идут практически каждый день, а человек, который всё это настраивает, — один.

В какой-то момент я решил сделать себе AI-помощника. А в итоге сделал агента, которому смог перепоручить большую часть моей работы.

Я не собирался делать AI-маркетолога

Изначально идея была гораздо проще — мне хотелось автоматизировать самые скучные части работы.

LLM и до этого неплохо помогали с email-маркетингом. Можно было попросить придумать десять вариантов темы письма, переписать текст, предложить идеи для A/B-теста или принести результаты рассылки и попросить их проанализировать.

Но довольно быстро я заметил странную вещь — чтобы AI помог мне сделать работу, сначала мне самому приходилось сделать половину этой работы.

Допустим, я хочу понять, почему последняя рассылка сработала хуже предыдущих. Я открываю email-платформу. Нахожу нужную кампанию. Собираю показатели. Потом нахожу несколько предыдущих кампаний. Собираю их показатели. Копирую всё это в ChatGPT и только после этого спрашиваю:

Что здесь произошло?

Модель анализирует данные и выдаёт хороший ответ — но данные для неё собирал я.

То есть у меня появился очень умный аналитик, у которого была одна небольшая проблема: он не умел самостоятельно открыть аналитику. И его ассистентом оставался я. С настройкой рассылок было то же самое.
AI мог написать тему и прехедер, но поставить их в кампанию должен был я.
AI мог подсказать, какой сегмент выбрать, но настроить его, не косякнув в процессе, должен был я.
AI мог напомнить проверить ссылки, но открыть письмо и проверить их должен был кто? Опять — я.
Получалось, что AI умеет думать о работе, но саму работу всё равно выполняю я.

И вот это начало меняться, когда у системы рассылок появился MCP.

Что изменил MCP

Для меня ценность MCP оказалась довольно простой: AI получил возможность не только говорить о том, что нужно сделать, но и работать с реальными инструментами напрямую.

Если сильно упростить:

LLM стала мозгом ^[2], а MCP дал ей руки.

Вместо того чтобы каждый раз приносить модели данные, можно дать ей возможность самостоятельно их забрать.

И тогда запрос:

Вот результаты десяти рассылок, проанализируй их.

превращается в:

Вот аккаунт. Посмотри последние десять рассылок этого проекта и скажи, что у нас происходит с открываемостью.

Разница кажется небольшой. На практике — огромная.

Потому что во втором случае агент сначала сам находит нужные кампании, получает данные, сверяет показатели, сравнивает результаты — и только потом возвращается с выводом.

Позже в тот же чат приехал второй коннектор — к нашей системе аналитики BI на Metabase.

Это важная развилка, и о ней стоит сказать сразу: сервис рассылок знает про письмо всё, кроме денег. Доставили, открыли, кликнули — да. Купил ли человек после клика — нет.

Поэтому конверсии и выручка живут в BI. Дашборды по ним строятся там же, в чате: я прошу — Metabase собирает и отдаёт результат. А в истории проекта по каждой рассылке лежат две цифры, конверсии и выручка, сведённые по UTM-метке кампании. Дальше агент работает с ними наравне с открытиями и кликами: показывает, сравнивает с серией, замечает отклонения.

И довольно быстро возник следующий вопрос.

Если агент уже умеет получать данные из email-платформы, почему бы не дать ему возможность не только анализировать кампании, но и создавать их?

Так постепенно я начал отдавать ему всё больше своей работы.

Сначала статистику.
Потом аналитику.
Потом проверки.
Потом настройку кампаний.

В какой-то момент это перестало быть AI-помощником.
Получился практически ещё один email-маркетолог.

Теперь я просто присылаю ему задачу

Сегодня начало работы над рассылкой может выглядеть примерно так:

Нужно подготовить рассылку для проекта X.

Вот текст.

Возьми наш стандартный шаблон. Отправляем активной аудитории. Перед запуском покажи мне итоговый вариант.

Например вот реальный запрос на создание рассылки:

Дальше начинается самое интересное. Мне не нужно в каждом сообщении объяснять агенту всю историю проекта. Он уже знает, с каким продуктом работает.

У нас 12 проектов, поэтому для каждого хранится свой контекст: описание продукта, аудитория, tone of voice, используемые базы, доступные поля, шаблоны, ограничения и история предыдущих кампаний.

Получив задачу, агент сначала понимает, к какому проекту она относится, и подтягивает нужный контекст.

Затем идёт в email-платформу.
Находит шаблон.
Создаёт кампанию.
Подставляет контент.
Выбирает нужную базу и сегмент.
Настраивает sender, subject и preheader.
Проверяет tracking.
Но на этом его работа не заканчивается.

Потому что я хотел автоматизировать не только настройку рассылки, но и ту часть процесса, где я обычно пытался понять, не накосячил ли где-нибудь при настройке.

Агент, который проверяет сам себя

Это оказалось одной из самых полезных частей всей системы. Перед запуском агент проходит собственный чек-лист:

• проверяет ссылки;

• проверяет UTM;

• проверяет наличие отписки;

• проверяет используемые переменные;

• сверяет их с полями выбранной базы;

• смотрит аудиторию и исключения;

• проверяет пересечения между базами.

Там же считается охват — и это отдельная мелочь, которая когда-то стоила мне пересчёта отчётов. В списке 19 133 контакта — это число видно в интерфейсе, и его хочется взять как охват. Активных из них 14 703: остальные отписались, отвалились по ошибкам или пожаловались.

Разница в 23%. Если брать размер списка, поедут все проценты в отчёте, а ждать результата будешь от базы, которой нет. Теперь агент берёт только активных и называет оба числа.

Например, если в новом шаблоне используется:

{{first_name}}

агент может самостоятельно проверить, существует ли такое поле в выбранной базе.

Если нет — сообщить об этом до отправки. Или заметить, что в рассылку случайно попадает аудитория, которая не должна её получить.

Но самый полезный случай оказался тем, которого я в чек-листе не предусмотрел.

Агент проверял черновик, собранный две с половиной недели назад, и остановил отправку. Письмо обещало скидку «до конца дня 3 сентября». Шло 21-е.

Черновик просто пролежал. Текст поправили, аудиторию выбрали, а дату в теле никто не перечитал — ровно тот случай, когда берёшь прошлое письмо и меняешь в нём пару абзацев.

После этого в чек-лист добавилась девятая проверка: прошедшие даты и дедлайны в тексте, несоответствие сезону и возраст черновика. Она не требует ни сети, ни доступа к аналитике — просто сверка того, что написано в письме, с сегодняшним числом.

Вот так выглядело предупреждение от агента:

И вот здесь автоматизация начинает давать не только экономию времени, она снижает количество вещей, которые приходится держать в голове.

Когда ты настраиваешь первую рассылку за день, довольно легко пройти весь чек-лист. Когда настраиваешь четвёртую для третьего проекта подряд, гораздо проще что-нибудь пропустить.

Агенту всё равно, первая это рассылка или двадцатая. У него есть набор проверок — он их выполняет.

Но самое интересное — он помнит, что происходило раньше

Автоматически создать кампанию — полезно, но это всё ещё просто автоматизация. Гораздо интереснее стало тогда, когда агент начал использовать историю предыдущих рассылок.

Потому что у каждого из 12 проектов постепенно накапливаются собственные данные.

• какие темы мы использовали;

• какая была открываемость;

• какой CTR;

• какие сегменты получали письмо;

• какой шаблон использовали;

• когда была отправка;

• какие были конверсии и сколько денег принесла рассылка — по данным из BI;

• какие письма оказались особенно успешными или, наоборот, провалились.

Человек при работе с большим количеством проектов довольно быстро перестает помнить всё это в деталях.

А агент может перед новой кампанией обратиться к истории. И тогда вместо универсального совета:

«Попробуйте сделать тему письма короче»

он может сказать:

В последних 14 рассылках этого проекта короткие темы с конкретной выгодой показывали более высокий OR. Можно проверить эту гипотезу ещё раз на следующей кампании.

Или:

В реактивационных рассылках мемные изображения раньше показывали более высокий CTR, а в письмах активной аудитории лучше работали продуктовые креативы.

Это уже совсем другой уровень рекомендаций.

Потому что они основаны не на абстрактном представлении LLM о маркетинге, а на истории конкретного продукта.

При этом здесь есть важное ограничение.

Агент умеет довольно хорошо получать цифры. Они приходят из первичного источника, и при необходимости он может повторно запросить и сверить их. Отдельная история — проценты, которые отдаёт сама платформа.

У нас Click Rate считается от открытий, а не от доставленных. То есть это CTOR, а не CTR. На одной из кампаний это 5,18% против настоящего CTR 0,81% — разница в шесть раз.

Если взять готовый процент и подписать его привычным названием, отчёт получится в шесть раз оптимистичнее реальности. Поэтому агент считает метрики сам, из абсолютных чисел, а готовые проценты использует только чтобы сверить свой расчёт.
Но и правильно посчитанные цифры — это ещё не ответ. Интерпретация — другая история.

Если CTR стал ниже, агент может предположить, что проблема была в CTA. Но это ещё не означает, что именно CTA стал причиной падения.

Поэтому внутри системы я стараюсь разделять три вещи:

Факт: CTR снизился.

Наблюдение: в нескольких кампаниях с определённым типом контента CTR был выше.

Гипотеза: возможно, этот формат контента лучше работает с конкретной аудиторией.

Хороший пример, на котором это разделение видно.

В A/B-тесте тем победил вариант, который открывали реже: 12,2% против 13,2%. Но кликов на открытие у него было вдвое больше — 3,5% против 2,4%, и именно по ним сервис выбрал победителя.

Факт: победила тема с меньшей открываемостью. Наблюдение: короткая конкретная тема собрала меньше открытий, но более качественный трафик. Гипотеза: длинная тема с перечислением привлекает любопытных, короткая — тех, кому это действительно нужно.

Гипотеза записана и ждёт следующего A/B. Пока это только гипотеза, и агент называет её именно так.

Получается довольно простой цикл:

рассылка → метрики → анализ → гипотеза → следующая рассылка.

И вот этот цикл агент может повторять ^[3] практически постоянно.

После «Send» он тоже продолжает работать

Раньше после запуска рассылки начиналась ещё одна рутинная часть моей работы — сбор отчётности.

Нужно было дождаться результатов, открыть кампанию, собрать показатели и перенести их в таблицу. Потом через какое-то время актуализировать. А потом ещё сравнить с предыдущими рассылками.

При 12 проектах это довольно быстро превращается в бесконечное обслуживание таблиц.

Теперь агент забирает данные самостоятельно.
После отправки он возвращается к кампании и получает актуальные показатели: delivery, open rate, clicks, CTR, CTOR, unsubscribes — всё, что знает сам сервис рассылок. Конверсии и выручка приходят со стороны BI и ложатся в ту же запись по UTM-метке.
При необходимости позже снова обновляет их.

Сам по себе агент не просыпается — это стоит сказать честно. У него есть задача в планировщике: каждый будний день в 10:00 он проходит по проектам, находит кампании за последние две недели, у которых снимок старше суток, и обновляет метрики. Всё, что старше, уже дозрело, и трогать это смысла нет.

В расписание не поставлено ничего, что отправляет письма. Планировщик работает, когда человека нет за клавиатурой, и необратимые действия там недопустимы по определению.

Но просто собрать цифры мало. Поэтому следующий шаг — сравнение. Допустим, рассылка получила OR 34%. Хорошо это или плохо? Само по себе число почти ничего не говорит. Причём сравнивать надо не с прошлыми рассылками, а с сопоставимыми.

Когда я первый раз отобрал серию просто по типу аудитории, получилось 37 кампаний с разбросом открываемости от 4,2% до 70,7%. Медиана по такому набору ничего не значит.

Оказалось, что в одну кучу попали три разные вещи: основные отправки, досылы по неоткрывшим и дожим по тем, кто открыл и кликнул. У досыла аудитория по определению та, что не открыла — там 4% это норма. У дожима аудитория по определению вовлечённая — там 70% это тоже норма.

После разделения по роли отправки серии стали осмысленными: досылы 4–7%, основные 10–31%. Сравнивать очередное письмо теперь есть с чем.

Агент может посмотреть предыдущие кампании этого же проекта и сообщить:

OR текущей кампании — 34,2%. Медиана по последним десяти сопоставимым — 29,8%, разброс от 27,1% до 33,8%. CTR при этом ниже медианы.

Медиана, а не среднее — намеренно. Одна аномальная рассылка сдвигает среднее и не сдвигает медиану. И рядом с медианой всегда идёт разброс: число без разброса создаёт иллюзию точности. Если крайние значения серии отличаются в разы, агент отказывается считать медиану и говорит, что сравнивать не с чем.

И уже после этого сформировать гипотезу:

Тема письма, вероятно, хорошо привлекла внимание ^[4], но повышенный интерес ^[5] не перешёл в пропорциональный рост кликов. Стоит отдельно проверить контент и CTA.

Мне остаётся посмотреть на данные и решить, согласен ли я с такой интерпретацией.

Следующий шаг — смотреть не на рассылки, а на людей

Когда агент получил доступ к истории рассылок и аудиториям, появилась ещё одна интересная возможность.

А что, если анализировать не только кампании?
У нас много проектов, и аудитории могут пересекаться. Один и тот же человек может получать несколько разных коммуникаций. Поэтому агент может искать пользователей, которым мы пишем слишком часто.

Например:

Этой аудитории за последние семь дней уже уходило два письма. Это будет третье, при лимите два. Исключить тех, кто получил предыдущие два?

Или искать обратную ситуацию:

Найди активных пользователей, которые хорошо взаимодействуют с письмами, но которым мы почти ничего не отправляем.

Или:

Найди людей, которые регулярно открывают письма, но за последние 60 дней ни разу не кликнули.

Это уже задачи, которые технически можно было делать и раньше. Просто вручную я вряд ли стал бы запускать такой анализ перед каждой рассылкой. Агенту всё равно.

И здесь он постепенно перестаёт быть системой, которая просто делает мою работу быстрее. Он начинает делать то, на что у меня раньше вообще не хватало времени.

Почему я всё ещё оставил себе кнопку Send

Несмотря на всё это, есть одна вещь, которую агент пока не делает самостоятельно. Он не принимает финальное решение о массовой отправке.

После настройки он присылает мне итоговую конфигурацию:

Project:      RuSender
Audience:     Все DOI RuSender 09.09.2026 (список 43444)
Recipients:   14 703 активных (в списке 19 133)
Excluded:     —, сегмента нет
Subject:      🤖 Сентябрь: теперь нас двое
Preheader:    Главное обновление месяца — MCP-сервер
Sender:       RuSender <team@rusender.ru ^[6]>, домен rusender.ru ^[7] верифицирован
Template:     Обновления в Сентябре (169434)
Links:        2/2 проверено, 0 битых
UTM:          email / ru / september_update, совпадает с профилем
Variables:    0/0, переменных в письме нет
Unsubscribe:  есть, регистр верный
Tracking:     включён, своих меток в ссылках нет
Recent sends: за 7 дней по этому списку отправок не было
Warnings:     0 стоп, 1 предупреждение, 3 заметки

И ждёт подтверждения.

Причина простая: у автоматизации должна быть цена ошибки ^[8].

Если агент неправильно сформулировал гипотезу в аналитическом отчёте — неприятно.
Если агент самостоятельно отправил неправильное письмо 50 тысячам человек — совсем другой уровень проблемы.

Поэтому чтение данных, анализ, проверки, создание draft и отчётность могут работать практически автономно. А там, где действие сложно отменить, остаётся human approval. И пока такой баланс мне нравится больше всего.

Так он всё-таки меня заменил?

Не полностью.

Агент всё ещё ошибается. Иногда выдаёт спорные рекомендации. Иногда делает слишком уверенный вывод из небольшого количества данных. Иногда не учитывает какую-нибудь специфическую особенность продукта. Поэтому его приходится тюнить, добавлять правила и накапливать контекст по каждому проекту.

И ответственность за результат всё равно остаётся на мне. Если что-то уйдёт не той аудитории, фраза «это агент сделал» вряд ли будет хорошим объяснением.

Но однажды я заметил другое. Я стал гораздо реже открывать сам email-сервис.

Раньше мой обычный процесс выглядел примерно так:

зайти → найти кампанию → выбрать шаблон → вставить текст → настроить → проверить → отправить → вернуться → собрать статистику → записать → сравнить.

Теперь:

поставить задачу → проверить → подтвердить → принять решение.

И именно в этот момент я понял, что агент действительно меня заменил. Только не совсем так, как обычно представляют замену человека AI. Он не занял моё место. Он забрал мою старую работу.

• Настройка кампаний — агент.

• Проверка переменных и ссылок — агент.

• Работа с базами и сегментами — частично агент.

• Сбор статистики — агент.

• Актуализация отчётности — агент.

• Первичный анализ — агент.

• Подготовка гипотез — агент.

• Отчёты для разных проектов — агент.

А моя работа постепенно сместилась в другую сторону.

Теперь больше времени можно тратить на эксперименты, сегментацию, автоматизацию, развитие самого агента и, в конечном счёте, на идеи, которые должны приносить компании больше денег.

И поэтому фраза «агент, который меня заменил» одновременно и правдивая, и немного обманчивая.

Агент не заменил меня как сотрудника. Он заменил большую часть работы, для выполнения которой раньше был нужен я.

Наверное, именно это изменение кажется мне самым интересным. Потому что в нашей небольшой компании фактически появился ещё один работник.

Он знает контекст 12 проектов. Не забывает ^[9] собрать статистику. Не устает на четвёртой рассылке за день. Может перепроверить данные столько раз, сколько потребуется, и постепенно накапливает знания о том, что происходило с каждой кампанией раньше.

А я вместо того, чтобы каждый день нажимать одни и те же кнопки, теперь в основном занимаюсь тем, чтобы этот сотрудник становился лучше.

Единственное, чего я ему пока не отдал, — кнопку «Send».

Посмотрим, надолго ли.

Как устроен этот агент

Агент — это не программа, которую я написал. Это набор инструкций на обычном markdown плюс подключённые сервисы. Отсюда и скорость: чтобы что-то поменять, не нужен релиз.

Мозг. Claude Opus 5 в Claude Code. Навыки — просто текстовые файлы, поэтому в других ассистентах они тоже читаются: привязки к конкретной модели нет.

Руки. MCP-коннектор RuSender — 79 инструментов, авторизация по OAuth, подключение бесплатное. Рядом — второй коннектор, к BI на Metabase: там строятся дашборды по конверсиям и выручке. Агент в него не ходит, он работает с уже сведёнными цифрами в истории проекта.

Память ^[10]. Обычные файлы в папке проекта. Двенадцать папок — по одной на продукт. В каждой: профиль с тоном и запретами, метаданные списков, история кампаний, тексты писем, HTML-шаблоны, гипотезы и лог действий. Всё читается глазами и правится руками.

Навыки:

Первые три я написал сам, остальные десять — готовые, из репозитория RuSender.

Что нужно, чтобы это работало: Claude Code, Node 18 и выше для проверки ссылок, доступ в сеть и подключённый MCP. Всё.

Агента можно забрать себе

Он лежит в открытом доступе — со всеми тринадцатью навыками, двенадцатью демо-проектами и готовыми шаблонами писем.

git clone https://github.com/Lunevv/email-agent.git ^[11]
cd email-agent
./scripts/install.sh ^[12] --copy

Дальше подключаете MCP RuSender (регистрация, один адрес сервера в настройках клиента, вход через OAuth — ключи копировать не нужно) и говорите агенту:

Заведи проекты по моему аккаунту.

Он посмотрит отправителей, домены, списки и кампании, предложит разбивку на проекты и доспросит то, чего нет в API: тон, запреты, частоту. После этого можно работать словами.

Если своего аккаунта пока нет — в комплекте двенадцать демо-проектов с историями, письмами и шаблонами. На них работает всё, кроме реальной отправки.

Если у вас другой сервис рассылок. Отчётные навыки написаны под RuSender и не переносятся. А вот память проектов, проверки перед отправкой и разбор результатов — переносятся, если у вашего сервиса есть MCP. Список из пятнадцати возможностей, которые агенту нужны, лежит в репозитории отдельным файлом: пройдётесь по нему и увидите, что закроется, а что нет.