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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что изменил MCP

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

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

LLM стала мозгом, а 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. Пока это только гипотеза, и агент называет её именно так.

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

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

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

После «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 при этом ниже медианы.

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

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

Тема письма, вероятно, хорошо привлекла внимание, но повышенный интерес не перешёл в пропорциональный рост кликов. Стоит отдельно проверить контент и 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>, домен rusender.ru верифицирован
Template:     Обновления в Сентябре (169434)
Links:        2/2 проверено, 0 битых
UTM:          email / ru / september_update, совпадает с профилем
Variables:    0/0, переменных в письме нет
Unsubscribe:  есть, регистр верный
Tracking:     включён, своих меток в ссылках нет
Recent sends: за 7 дней по этому списку отправок не было
Warnings:     0 стоп, 1 предупреждение, 3 заметки

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

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

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

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

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

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

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

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

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

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

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

Теперь:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Навыки:

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

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

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

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

git clone https://github.com/Lunevv/email-agent.git
cd email-agent
./scripts/install.sh --copy

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

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

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

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

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