Agentic Marketing in 2026: чотири речі, які система має надавати

Коротка відповідь: agentic marketing — це маркетингова робота, яку виконує програмне забезпечення, що саме обирає свій наступний крок і потім його робить. Приблизно тут згода й закінчується. Ми отримали одинадцять сторінок, що повернулися за запитом на цей термін та його варіанти 18 серпня 2026 року, і вісім із них жодного разу не згадують протокол, tool calling чи function calling — а це саме той рівень, де агент перестає бути вікном чату й стає чимось, що може змінити вашу спільноту, вашу кампанію чи ваші записи про клієнтів. Тож цей пост визначає agentic marketing через чотири речі, які система має надавати, перш ніж агент зможе виконати будь-яку маркетингову роботу взагалі, цитує Model Context Protocol щодо того, чому позначки, які ці системи публікують про себе, не є довіреними, і оцінює власну агентну поверхню Zealy за цим визначенням, включно з тією частиною, де ми її не проходимо.

Розкриття інформації: Zealy публікує цю сторінку, і Zealy продає те, про що вона. Zealy — це платформа для спільнот і квестів. Дві її функції є агентами в тому сенсі, який визначає ця стаття: MCP-сервер, яким може керувати зовнішній AI, і вбудований AI-рев'юер. Усі три згадуються нижче. Усе тут про власну агентну поверхню 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 повністю розділяє агентів і агентний AI.

Спершу прочитайте середню колонку, а потім праву. Те, хто визначає категорію, багато говорить про те, де вони проводять межу.

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

Три сторінки також проводять корисну межу з суміжним терміном, і це єдині три, які ми вважали вартими збереження.

Проти автоматизації маркетингу. Treasure Data пише, що "Агентний маркетинг вужчий за маркетинг зі штучним інтелектом і відрізняється від автоматизації маркетингу", оскільки "автоматизація маркетингу виконує фіксовані, визначені людиною робочі процеси". Перевірка полягає не в тому, чи програмне забезпечення діє без вас. Ваш інструмент для електронної пошти вже це робить. Перевірка полягає в тому, чи послідовність кроків була обрана заздалегідь людиною.

Проти генеративного штучного інтелекту. Optimove подає це як контраст між двома тригерами: "Генеративний штучний інтелект створює контент на основі людських запитів", тоді як "Агентний штучний інтелект вживає автономних дій, не чекаючи запитів". Форма запиту проти форми мети — це справжня відмінність, яку рідко дотримуються.

Проти асистента. Найгостріше речення, написане кимось із цього набору, належить Docket's Арджуну Піллаю: "Асистент чекає на користувача, допомагає із завданням і живе всередині людського робочого процесу." Його агентна половина — це "Агент діє заради мети, ухвалює обмежені рішення, запускає робочі процеси та володіє частиною виконання під наглядом." Окремий уривок на тій самій сторінці надає механізм, якого бракує цій фразі: люди "визначають цілі, правила ескалації, обмеження тем і пороги затвердження. Агент діє в межах цих кордонів. Коли щось виходить за них, він ескалює." Ескалація — це межа затвердження з нашого визначення, описана з боку агента.

Одна розбіжність варта того, щоб її надрукувати, а не згладити. Forrester на сторінці про випадки використання агентів штучного інтелекту із зазначенням Крейга Ле Клера розділяє два терміни, які кожна сторінка постачальника вище вважає взаємозамінними: агенти штучного інтелекту працюють на "заздалегідь визначених правилах", тоді як "агентний штучний інтелект запроваджує ширшу автономію та адаптивність". Справедливе попередження щодо цього цитування — це цільова сторінка подкасту, а не опублікована дослідницька записка, і ми цитуємо її як формулювання однієї аналітичної фірми, а не як висновки.

Шар, який вісім із одинадцяти визначень залишають поза увагою

З одинадцяти сторінок, які ми отримали для цього терміна 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, чиє власне пояснення агентного маркетингу ніколи не доходить до того, що він випускає. Це твердження про одинадцять сторінок за один день, а не про всю категорію — але воно справджувалося для кожної перевіреної нами сторінки.

Дві сторінки в наборі називають відсутній шар, і обидві роблять це добре.

Дункан Леннокс із HubSpot пише: "Але агенти не клікають по дашбордах і не навігують інтерфейсами; вони викликають API, читають структуровані виводи та вживають дій." Та сама сторінка визначає обсяг як "те, що агенти можуть читати, записувати та на що можуть діяти", і це правильна одиниця. Не "чи може він займатися маркетингом", а які іменники та які дієслова.

Real Story Group, дослідницька фірма з маркетингових технологій, що продає оцінки постачальників, надає речення, яке завершує суперечку. У статті про MCP від 11 червня 2025 року головний аналітик Скотт Сіммонс називає його "універсальним шаром абстракції 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 чи внутрішній каркас, який тримає модель. Тож за прямого прочитання протоколу безпека вашого агентного маркетингу — це робота вашого клієнта, а сервер, до якого ви підключилися, не винен вам нічого, крім чесного переліку інструментів.

Галузь це знає і не цілком розуміє, що з цим робити. Посібники постачальників регулярно визначають агента через відсутність людини, а потім далі на тій самій сторінці кажуть, куди повернути людину; ми розбираємо одну з таких сторінок у чи може AI-агент насправді керувати вашою спільнотою. Обидві половини щирі. Визначення написане для ринку, а інструкція — для розгортання, і саме в проміжку між ними ухвалюється кожне реальне рішення про автономність.

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

Тепер є й виміряна відповідь на те, які виклики заслуговують на шлюз, і вона не та, що підказує інтуїція. SABER: Small Actions, Big Errors — Safeguarding Mutating Steps in LLM Agents, авторства Алехандро Куадрона, Пенфея Ю, Ян Лю та Арпіта Гупти, подана 26 листопада 2025 року, досліджує, де відхилення траєкторії агента, що використовує інструменти, насправді коштує вам. У ній зазначено, що «На противагу цьому, відхилення в незмінювальних діях майже не мають ефекту». Речення безпосередньо перед цим дає інший бік: кожне додаткове відхилення в змінювальній дії знижує ймовірність успіху до 92% в одній із двох її предметних областей і до 96% в іншій для найсучасніших моделей. Збої концентруються у викликах, що змінюють стан.

Дизайнерський висновок негламурний і дешевий: обмежте записи, залиште читання без змін і перестаньте ставитися до «людини в циклі» як до єдиного перемикача з єдиним налаштуванням. Сервер Zealy працює саме так, і ми маємо чітко сказати, що не вивели це з цієї статті — стаття з'явилася після дизайну і погоджується з ним, що є слабшим за інженерію на основі доказів і сильнішим за ніщо. З цитуванням іде одне застереження: SABER документує помилки анотації в бенчмарку, на якому будується, і публікує виправлену версію, що є хорошою причиною не цитувати старі оцінки бенчмарків інструментів-агентів так, ніби вони досі описують поточні моделі. Інша причина бути обережними з одним числом тут — це те, що збій агента значною мірою є проблемою дисперсії — багатоходове дослідження розділяє деградацію на незначну втрату здібностей і велике зростання ненадійності, що є іншою управлінською проблемою, ніж просто недостатня якість моделі.

Той самий патерн «залишено реалізатору» проходить на рівень нижче, до четвертої частини нашого визначення. Ми завантажили сім сторінок специфікацій і безпеки 18 серпня 2026 року та переглянули їх: модель загроз специфікації — це модель загроз авторизації та транспорту, що охоплює confused deputy, передачу токенів, підробку запитів на стороні сервера та скомпрометований локальний сервер серед інших, тоді як атака на рівні моделі залишена реалізаторам. На завантажених нами сторінках фраза «prompt injection» не з'являється; чотири збіги для «injection» у документі з найкращих практик безпеки — це міжсайтовий скриптинг, ін'єкція команд оболонки та віддалене виконання коду. Це не скарга на транспортну специфікацію, яка має право обмежувати свою сферу. Це твердження про те, яку половину проблеми ви успадковуєте в момент підключення чогось, і про те, чому межа довіри для повернутих даних має бути чиєюсь явною роботою, а не передбачуваною властивістю протоколу.

Zealy не відповідає власному визначенню, і ось тут

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

Ми краще скажемо це, ніж програємо суперечку пізніше. Ось повна таблиця оцінок за нашими власними чотирма частинами, від першої особи й без аудиту.

Усі чотири присутні, і це легка частина. Третю налаштовано у зворотному напрямку для цього ярлика. Сервер Zealy ставить шлюз затвердження на стороні сервера, що більше, ніж протокол вимагає від сервера, і більше, ніж дозволяє суворе визначення агентного маркетингу. Сама поверхня інструментів достатньо велика, щоб її варто було аудитувати — 72 іменованих інструменти на момент підрахунку — але число не є суттю. Суть — налаштування.

Ми також не можемо заявляти про послідовність у всьому продукті. Zealy також випускає AI-рев'ювера, який самостійно закриває заявку на квест, без людини на цьому шляху: та сама компанія, протилежне налаштування, на рішенні, що стосується того, чи отримає учасник оплату. Обидва вибори можна захистити; чого ми не можемо чесно сказати, то це що існує єдина загальнокомпанійна відповідь на те, скільки автономії доречно.

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

Що запитати, перш ніж купувати щось під назвою агентний маркетинг

Запитайте список інструментів. Постачальник, який продає агентний маркетинг, може або показати вам іменовані операції, які отримує агент, з прикріпленими дозволами, або не може. Усе інше — мова планування, мова досягнення цілей і демо — сумісне з чат-ботом, підключеним до форми, і в Young Urban Project є для цього назва.

П'ять запитань у порядку, що дає найбільше інформації за найменший час зустрічі:

1. «Які операції отримує агент, за назвою?» Якщо відповідь — речення про можливості, а не список, ви маєте свою відповідь. Якщо це список, читайте його заради дієслів. Читати, писати, видаляти, надсилати, публікувати, платити.
2. «Які з них можуть діяти без мене?» Не «чи є людина в циклі»: на це запитання всі відповідять «так». Запитайте, які саме виклики пропускають людину і хто обрав цей поділ.
3. «Що відбувається з текстом, який написав клієнт, коли агент його читає?» Ви запитуєте, чи результати інструментів трактуються як дані, чи як потенційні інструкції. Постачальник, який подумав про це, відповість одразу, бо це той режим відмови, який не дає спати його інженерам.
4. "Що означають ваші позначки ризику?" Потім перевірте відповідь за специфікацією, а не за презентацією для продажів, і запитайте, які налаштування за замовчуванням — більшість людей вгадують їх навпаки.
5. "Чого він не може?" Перелік обмежень — це найдешевший можливий сигнал довіри, і майже ніхто його не публікує. Його відсутність нічого не доводить. Його наявність варта багато.

Останнє, що варто сказати, — про послідовність, бо рішення про купівлю тут зазвичай ухвалюють невчасно. Більшість команд, які оцінюють агентний маркетинг, ще не записали, які з їхніх повторюваних завдань безпечно передати, а які ні — і це те саме рішення, незалежно від того, чи руки належать підряднику, модератору чи моделі. Як делегувати завдання спільноти опрацьовує це з людьми, і аналіз переноситься майже без змін. Зробіть це спершу. Агент усе одно буде там, і ви знатимете, які інструменти ви насправді хочете йому дати.