Агентный маркетинг в 2026 году: четыре вещи, которые система обязана предоставить

Короткий ответ: агентный маркетинг — это маркетинговая работа, которую выполняет программное обеспечение, само выбирающее следующий шаг и затем его совершающее. На этом согласие примерно заканчивается. Мы загрузили одиннадцать страниц, выданных по этому термину и его вариантам 18 августа 2026 года, и восемь из них вообще не упоминают протокол, вызов инструментов или вызов функций — а именно на этом уровне агент перестаёт быть окном чата и становится чем-то, что может изменить ваше сообщество, вашу кампанию или ваши записи о клиентах. Поэтому в этом посте агентный маркетинг определяется через четыре вещи, которые система обязана предоставить, прежде чем агент сможет выполнять хоть какую-то маркетинговую работу; приводятся слова Model Context Protocol о том, почему метки, которые такие системы публикуют о себе, не заслуживают доверия; и агентная поверхность самого Zealy оценивается по этому определению, включая ту часть, где мы ему не соответствуем.

Раскрытие информации: Zealy публикует эту страницу, и Zealy продаёт то, о чём она. Zealy — платформа сообществ и квестов. Две её функции являются агентами в том смысле, который определяет эта статья: MCP-сервер, которым может управлять внешний ИИ, и встроенный ИИ-ревьюер. Все три упоминаются ниже. Всё здесь о собственной агентной поверхности Zealy — из первых рук: прочитано в репозитории Zealy, запущено нами на собственном сервере Zealy, никем другим не проверено. Читайте это с тем же скепсисом, с каким отнеслись бы к любому вендору, описывающему собственный продукт.

Последняя проверка: 18 августа 2026 года.

Что такое агентный маркетинг?

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

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

1. Именованные инструменты, а не текстовое поле. Агенту нужны операции с именами, аргументами и формами возврата, такие как create_campaign, list_members и send_message, потому что модель, способная выдавать только текст, может выдавать только текст. Model Context Protocol — текущий распространённый способ публиковать такой список, а его инструменты — это то, что он называет управляемыми моделью: языковая модель сама обнаруживает и вызывает их, исходя из контекста и запроса пользователя. Без этого уровня у вас помощник для письма. Это полезный продукт; но не этот.
2. Обнаружение до действия. Агент должен иметь возможность спросить, что существует и что делает каждая вещь, прежде чем на что-либо решиться. Жёстко заданная интеграция, где человек уже выбрал три вызова, — это автоматизация с моделью, приделанной к тексту.
3. Граница одобрения, выбранная кем-то намеренно. Каждое действие либо останавливается ради человека, либо нет, и где-то есть правило, решающее, что именно. Правило может быть строгим или мягким. Чего оно не может быть — непроверенным.
4. Граница доверия к тому, что возвращается. Результаты инструментов — это данные, написанные другими людьми: участниками, клиентами, формами, спарсенными страницами. Если возвращённая строка может уговорить агента на следующий вызов инструмента, вы построили систему, которая принимает инструкции от любого, кто заполнит поле отправки квеста.

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

Существующие определения и то, где каждое проводит черту автономности

Опубликованные определения сходятся в том, что агент планирует и действует самостоятельно, и расходятся в том, сколько человеческого участия допустимо сохранить. Vlerick Business School допускает минимальное вмешательство. Braze описывает системы, которые воспринимают, решают и действуют. Young Urban Project и Netcore обе проводят черту на пошаговом человеческом одобрении. Forrester полностью разделяет агентов и агентный ИИ.

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

Каждая строка в правом столбце была сверена с исходным текстом связанной страницы, полученной 18 августа 2026 года, а не взята из результатов поиска. Шесть страниц, ранжирующихся по этому запросу, вообще не удалось прочитать. Salesforce, IBM, Gartner и BCG возвращали 403 на каждую попытку, а McKinsey и Adobe выдавали тайм-аут. Ни одна из них здесь не цитируется.

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

В отличие от автоматизации маркетинга. Treasure Data пишет, что "агентный маркетинг уже, чем ИИ-маркетинг, и отличается от автоматизации маркетинга", поскольку "автоматизация маркетинга выполняет фиксированные, заданные человеком рабочие процессы". Проверка не в том, действует ли ПО без вас. Ваш инструмент для email уже так делает. Проверка в том, была ли последовательность шагов выбрана заранее человеком.

В отличие от генеративного ИИ. Optimove формулирует это как контраст между двумя триггерами: "Генеративный ИИ создаёт контент на основе человеческих промптов", тогда как "агентный ИИ предпринимает автономные действия, не дожидаясь промптов". Форма промпта против формы цели — это реальное различие, которое редко соблюдают.

В отличие от ассистента. Самая точная фраза во всём наборе принадлежит Docket's Арджуну Пиллаи: "Ассистент ждёт пользователя, помогает с задачей и живёт внутри человеческого рабочего процесса". Его агентная половина: "Агент действует в направлении цели, принимает ограниченные решения, запускает рабочие процессы и под надзором отвечает за часть исполнения". Отдельный фрагмент на той же странице даёт механизм, которого не хватает этой фразе: люди "определяют цели, правила эскалации, тематические ограничения и пороги утверждения. Агент действует в этих границах. Когда что-то выходит за них, он эскалирует". Эскалация — это граница утверждения из нашего определения, описанная со стороны агента.

Одно разногласие стоит напечатать, а не сгладить. Forrester на странице о сценариях использования ИИ-агентов с указанием Craig Le Clair разделяет два термина, которые каждая страница вендора выше считает взаимозаменяемыми: ИИ-агенты работают на "предопределённых правилах", тогда как "агентный ИИ вводит более широкую автономию и адаптивность". Честное предупреждение об этой ссылке — это лендинг подкаста, а не опубликованная исследовательская записка, и мы цитируем её как формулировку одной аналитической фирмы, а не как выводы.

Слой, который опускают восемь из одиннадцати определений

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

Восемь без упоминания каких-либо из этих строк: braze.com, cdp.com, docket.io, forrester.com, netcore.ai, tofuhq.com, vlerick.com и youngurbanproject.com. Из оставшихся трёх hubspot.com упоминает Model Context Protocol, но не является страницей с определением. Optimove — та, что запомнилась нам больше всего: строка MCP встречается на её странице только в навигационном меню как "The Optimove MCP" и ни разу в теле статьи, объясняющей категорию. Вендор, который выпускает MCP-сервер, а его собственное объяснение агентного маркетинга так и не доходит до того, что он выпускает. Это утверждение об одиннадцати страницах за один день, а не обо всей категории — но оно подтвердилось для каждой проверенной нами страницы.

Две страницы из набора всё же называют недостающий слой, и обе делают это хорошо.

Duncan Lennox из HubSpot пишет: "Но агенты не кликают по дашбордам и не перемещаются по интерфейсам; они вызывают API, читают структурированные выходные данные и предпринимают действия". Та же страница определяет охват как "что агенты могут читать, записывать и на что действовать" — это правильная единица. Не "может ли он заниматься маркетингом", а какие существительные и какие глаголы.

Real Story Group, исследовательская фирма в области martech, продающая оценки вендоров, даёт фразу, завершающую спор. В материале об MCP от 11 июня 2025 года ведущий аналитик Scott Simmons называет его "универсальным слоем абстракции API, созданным для ИИ-агентов", и делает вывод, что агент "настолько мощён, насколько вендор решит открыть".

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

Почему список инструментов — это доказательство, а метка инструмента — лишь подсказка

Model Context Protocol отвечает на вопрос, что агент может сделать с вами, предлагая прочитать список инструментов сервера, а затем велит клиентам не доверять тому, что этот список говорит о себе. Примечание об этом находится в схеме, а не в тексте, и отчасти поэтому его прочитали так немногие.

Вот этот фрагмент из ToolAnnotations интерфейса в схеме спецификации в редакции 2026-07-28:

ПРИМЕЧАНИЕ: все свойства в ToolAnnotations являются подсказками. Они не гарантируют достоверного описания поведения инструмента (включая такие описательные свойства, как title).

И по той же теме, со страницы инструментов:

В целях доверия, безопасности и защиты клиенты ДОЛЖНЫ считать аннотации инструментов недоверенными, если они не получены от доверенных серверов.

Задержитесь на этом на секунду. Ответ протокола на вопрос «откуда мне знать, что эта штука может со мной сделать» таков: прочитайте список. А следующая же инструкция гласит: этот список — заявление стороны, которую вы оцениваете. Имена и схемы инструментов несут ключевую нагрузку, потому что модель вызывает их, а сервер обязан их соблюдать. Метки риска, прикреплённые к ним, — это собственное описание сервером своего же поведения.

Таких меток четыре — readOnlyHint, destructiveHint, idempotentHint и openWorldHint — и две из них, destructiveHint и openWorldHint, по умолчанию равны true. Поэтому инструмент без меток считается разрушительным и считается взаимодействующим с внешним миром — это верное решение и противоположность тому, чего ждут большинство людей.

Для определения агентного маркетинга важна destructiveHint, потому что она не задаёт вопрос. Она отделяет перезапись от добавления. Вред — это другая ось, и в схеме для неё нет столбца, поэтому чисто аддитивный вызов может быть самым значимым действием агента в вашем стеке и при этом помечен как безопасный сервером, действующим совершенно добросовестно. Что каждый флаг означает на практике и как выглядит реальный листинг после применения значений по умолчанию — в разборе по соседству.

Это также честная версия того, что маркетологи называют agent washing. Young Urban Project формулирует точно: «Самая распространённая ошибка — agent washing: взять существующий продукт автоматизации или чат-бота и перебрендировать его как агентный, не добавив снизу слой планирования или принятия решений», и добавляет, что «демо написано так, чтобы скрыть именно тот пробел, который важен». Список инструментов гораздо труднее подделать, чем демо. Это также единственный артефакт во всей этой категории, который покупатель может проверить без содействия поставщика, поэтому мы написали отдельный разбор о том, как перечислить инструменты любого MCP-сервера до подключения к нему.

Где проходит граница одобрения и кто должен её установить

Model Context Protocol говорит, что человек всегда должен быть в цикле с возможностью отклонить вызовы инструментов, и говорит это клиентскому приложению как SHOULD, а не MUST. Ничто в протоколе не обязывает сервер, к которому вы подключаетесь. Где находится ваша граница одобрения — это чей-то выбор, и часто не ваш.

Точная формулировка:

В целях доверия, безопасности и защиты всегда СЛЕДУЕТ держать человека в цикле с возможностью отклонить вызовы инструментов.

Тот же раздел безопасности просит клиентов «показывать пользователю входные данные инструмента перед вызовом сервера, чтобы избежать злонамеренной или случайной утечки данных» и «проверять результаты инструмента перед передачей в LLM». Оба требования адресованы клиенту: тому, что работает на вашей стороне, — Claude, ChatGPT или внутренней обвязке, которая держит модель. Поэтому при буквальном прочтении протокола безопасность вашего агентного маркетинга — задача вашего клиента, а сервер, к которому вы подключились, не должен вам ничего, кроме честного списка инструментов.

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

Версия, за которую стоит спорить, — ни «полная автономия», ни «одобрять всё». Она в том, что граница — это настройка для каждого решения с ценой на обеих сторонах, а механизм, который её обеспечивает, сам является программным обеспечением, которое может отказать, — что и показал сбой модерации в Discord в начале этого года, когда шаг проверки человеком был в опубликованном дизайне, а баг убрал его из процесса. О том, что это значит для передачи агенту управления сообществом , мы написали отдельно, потому что это заслуживает большего, чем одна оговорка.

Теперь есть и измеренный ответ на вопрос, какие вызовы заслуживают шлюза, и он не совпадает с интуицией. SABER: Small Actions, Big Errors — Safeguarding Mutating Steps in LLM Agents, авторы Alejandro Cuadron, Pengfei Yu, Yang Liu и Arpit Gupta, представлена 26 ноября 2025 года, исследует, где именно сбой траектории агента, использующего инструменты, реально вам дорого стоит. В ней сообщается, что «напротив, отклонения в немодифицирующих действиях почти не оказывают эффекта». Предыдущее предложение даёт другую сторону: каждое дополнительное отклонение в модифицирующем действии снижает вероятность успеха до 92% в одной из двух её областей и до 96% в другой для моделей уровня state-of-the-art. Сбои концентрируются в вызовах, которые меняют состояние.

Вывод по дизайну неброский и дешёвый: ограничьте записи, не трогайте чтение и перестаньте считать «человека в контуре» единой ручкой с единственной настройкой. Сервер Zealy работает именно так, и стоит прямо сказать, что мы не вывели это из статьи — статья появилась после дизайна и соглашается с ним, а это слабее, чем инженерия на основе доказательств, и сильнее, чем ничего. С цитированием связана одна оговорка: SABER документирует ошибки разметки в бенчмарке, на котором строится, и публикует исправленную версию — хороший повод не цитировать старые оценки бенчмарков инструментальных агентов так, будто они по-прежнему описывают текущие модели. Другая причина осторожно относиться к одному числу здесь — то, что отказы агентов во многом проблема дисперсии — многоходовое исследование разделяет деградацию на небольшое снижение способностей и сильный рост ненадёжности, а это другая управленческая проблема, нежели модель, которой просто не хватает качества.

Тот же паттерн «оставлено на усмотрение реализатора» проявляется на уровень ниже, в четвёртой части нашего определения. 18 августа 2026 года мы скачали семь страниц спецификаций и безопасности и просмотрели их: модель угроз спецификации — это модель угроз авторизации и транспорта, охватывающая confused deputy, передачу токенов, подделку запросов на стороне сервера и скомпрометированный локальный сервер среди прочего, а атака на уровне модели оставлена реализаторам. На скачанных страницах фраза «prompt injection» не встречается; четыре совпадения по «injection» в документе о лучших практиках безопасности — это межсайтовый скриптинг, инъекция команд оболочки и удалённое выполнение кода. Это не претензия к транспортной спецификации, которая вправе ограничивать свою область. Это утверждение о том, какую половину проблемы вы наследуете в момент подключения чего-либо, и о том, почему граница доверия для возвращаемых данных должна быть чьей-то явной задачей, а не предполагаемым свойством протокола.

Zealy не проходит собственное определение, и вот здесь

По самым строгим определениям в этом посте — «без одобрения человеком каждого отдельного шага» от Young Urban Project и «без требования одобрения человеком на каждом шаге» от Netcore — Zealy не занимается агентным маркетингом. Каждая запись через агентную поверхность Zealy останавливается для человека, а записи отключены, пока оператор их не включит.

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

Все четыре присутствуют, и это лёгкая часть. Третья настроена не в ту сторону для этого ярлыка. Сервер Zealy ставит шлюз одобрения на стороне сервера, что больше, чем протокол требует от сервера, и больше, чем допускает строгое определение агентного маркетинга. Сама поверхность инструментов достаточно велика, чтобы её стоило аудировать — 72 именованных инструмента на момент подсчёта — но число не главное. Главное — настройка.

Мы также не можем заявлять о согласованности по всему продукту. Zealy также выпускает AI-ревьюера, который сам закрывает заявку на квест, без человека на этом пути: та же компания, противоположная настройка, в решении, от которого зависит, получит ли участник оплату. Оба выбора защитимы; чего мы честно не можем сказать, так это что существует единый общеcompany ответ на вопрос, какой уровень автономии уместен.

Так что снимите ярлык. Zealy на самом деле предлагает агентно-читаемую поверхность с шагом фиксации человеком — скучное название для того, что большинству команд стоит хотеть в первую очередь. Если вам нужна механика подключения, документация по интеграции MCP канонична, и этот пост намеренно её не пересказывает; если вам нужна более старая, широкая поверхность под ней, документация по API её покрывает. А если вы никогда не пользовались продуктом, что такое Zealy — более короткий путь.

Что спросить, прежде чем покупать что-то под названием «агентный маркетинг»

Попросите список инструментов. Продавец агентного маркетинга либо может показать вам именованные операции, которые получает агент, с приложенными разрешениями, либо нет. Всё остальное — язык планирования, язык целеустремлённости и демо — совместимо с чат-ботом, подключённым к форме, и у Young Urban Project есть для этого название.

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

1. «Какие операции получает агент, по названиям?» Если ответ — фраза о возможностях, а не список, вы получили ответ. Если это список, читайте его на глаголы. Читать, писать, удалять, отправлять, публиковать, платить.
2. «Какие из них могут действовать без меня?» Не «есть ли человек в контуре»: на этот вопрос все ответят «да». Спросите, какие конкретные вызовы пропускают человека и кто выбрал это разделение.
3. «Что происходит с текстом, который написал клиент, когда агент его читает?» Вы спрашиваете, рассматриваются ли результаты инструментов как данные или как потенциальные инструкции. Поставщик, который об этом задумывался, ответит сразу, потому что это тот самый режим отказа, который не даёт их инженерам спать.
4. "Что означают ваши метки риска?" Затем сверьте ответ со спецификацией, а не с рекламной презентацией, и спросите, каковы значения по умолчанию — большинство людей угадывают их наоборот.
5. "Чего он не может?" Список границ — самый дешёвый возможный сигнал доверия, и почти никто его не публикует. Его отсутствие ничего не доказывает. Его наличие стоит многого.

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