Agentic Marketing in 2026: de vier dingen die een systeem moet blootleggen

Kort antwoord: agentic marketing is marketingwerk dat wordt uitgevoerd door software die zelf de volgende stap kiest en die vervolgens zet. Ongeveer daar eindigt de overeenstemming. We hebben op 18 augustus 2026 de elf pagina's opgehaald die terugkwamen voor de term en zijn varianten, en acht daarvan noemen het protocol, tool calling of function calling helemaal niet — precies de laag waar een agent ophoudt een chatvenster te zijn en iets wordt dat je community, je campagne of je klantgegevens kan veranderen. Daarom definieert dit bericht agentic marketing aan de hand van de vier dingen die een systeem moet blootleggen voordat een agent überhaupt marketingwerk kan doen, citeert het het Model Context Protocol over waarom de labels die die systemen over zichzelf publiceren niet te vertrouwen zijn, en beoordeelt het Zealy's eigen agent-oppervlak tegen de definitie, inclusief het deel waarop we zakken.

Openbaarmaking: Zealy publiceert deze pagina en Zealy verkoopt het product waarover het gaat. Zealy is een community- en questplatform. Twee van de functies zijn agents in de zin die dit artikel definieert: een MCP-server die een externe AI kan aansturen, en een AI-reviewer in het product. Alle drie komen hieronder aan bod. Alles hier over Zealy's eigen agent-oppervlak is first-party: gelezen uit Zealy's repository, door ons uitgevoerd tegen Zealy's eigen server, door niemand anders geaudit. Je moet het lezen met het scepticisme dat je zou toepassen op elke leverancier die zijn eigen product beschrijft.

Laatst geverifieerd: 18 augustus 2026.

Wat is agentische marketing?

Agentische marketing is marketingwerk dat wordt uitgevoerd door software die zelf de volgende actie richting een doel kiest, in plaats van een workflow te volgen die een persoon heeft uitgetekend. Een systeem komt alleen in aanmerking wanneer het vier dingen blootlegt: benoemde tools in plaats van een chatvenster, een manier om ze te ontdekken voordat er wordt gehandeld, een bewuste goedkeuringsgrens en een vertrouwensgrens voor wat er terugkomt.

Die definitie is van ons en is bewust opgebouwd uit de machinerie in plaats van uit de ambitie. Elke gepubliceerde definitie die we lazen, beschrijft wat de software probeert te doen. Geen enkele beschrijft wat er waar moet zijn aan je stack voordat het dat kan doen. Hier zijn de vier onderdelen, in de volgorde waarin een systeem eraan moet voldoen.

1. Benoemde tools, geen tekstvak. Een agent heeft bewerkingen nodig met namen, argumenten en retourvormen, dingen zoals create_campaign, list_members en send_message, want een model dat alleen proza kan produceren, kan alleen proza produceren. Het Model Context Protocol is de huidige gangbare manier om zo'n lijst te publiceren, en de tools ervan zijn wat het modelgestuurd noemt: het taalmodel ontdekt en roept ze zelf aan, op basis van context en de prompt van de gebruiker. Zonder deze laag heb je een schrijfassistent. Dat is een nuttig product; dit is het niet.
2. Ontdekking vóór actie. De agent moet kunnen vragen wat er bestaat en wat elk ding doet, voordat hij zich ergens aan verbindt. Een hardgecodeerde integratie waarbij een mens al de drie aanroepen heeft gekozen, is automatisering met een model aan de tekst geplakt.
3. Een goedkeuringsgrens die iemand bewust heeft gekozen. Elke actie stopt wel of niet voor een persoon, en ergens is er een regel die bepaalt welke. De regel kan streng of los zijn. Wat hij niet kan zijn, is ononderzocht.
4. Een vertrouwensgrens voor wat er terugkomt. Toolresultaten zijn data die door andere mensen zijn geschreven: leden, klanten, formulieren, gescrapete pagina's. Als een teruggegeven string de agent kan overhalen tot zijn volgende toolaanroep, heb je een systeem gebouwd dat instructies aanneemt van wie je quest-inzendveld ook maar invult.

Daaruit volgen twee consequenties, en dat is precies de reden dat we de moeite namen om überhaupt een definitie te schrijven. Alles zonder het eerste deel is een chatbot met betere marketing. En alles wat het derde deel mist, heeft geen beslissing over autonomie genomen — het is ermee geconfronteerd. Een goedkeuringsgrens die je niet zelf hebt gekozen is geen ontwerppositie, het is een ongeluk dat je nog niets heeft gekost.

De definities die bestaan, en waar elke definitie de autonomiegrens trekt

De gepubliceerde definities zijn het erover eens dat een agent zelfstandig plant en handelt, en verschillen van mening over hoeveel menselijke betrokkenheid mag blijven bestaan. Vlerick Business School staat minimale tussenkomst toe. Braze beschrijft systemen die waarnemen, beslissen en handelen. Young Urban Project en Netcore leggen de grens allebei bij menselijke goedkeuring per stap. Forrester scheidt agents volledig van agentic AI.

Lees de middelste kolom vóór de rechterkolom. Wie de categorie definieert, zegt veel over waar zij de grens leggen.

Elke string in de rechterkolom is vergeleken met de ruwe tekst van de gelinkte pagina zoals opgehaald op 18 augustus 2026, in plaats van gelezen uit een zoekresultaat. Zes pagina's die voor deze term ranken, konden helemaal niet worden gelezen. Salesforce, IBM, Gartner en BCG gaven bij elke poging een 403 terug, en McKinsey en Adobe gaven een time-out. Geen ervan wordt hier geciteerd.

Drie van de pagina's trekken ook een bruikbare grens tegen een naburige term, en dit zijn de enige drie die we het bewaren waard vonden.

Tegenover marketingautomatisering. Treasure Data schrijft dat "Agentic marketing narrower is dan AI-marketing en te onderscheiden van marketingautomatisering", omdat "marketingautomatisering vaste, door mensen gedefinieerde workflows uitvoert". De toets is niet of software zonder jou handelt. Je e-mailtool doet dat al. De toets is of de volgorde van stappen vooraf door een persoon is gekozen.

Tegenover generatieve AI. Optimove zet het als een contrast tussen twee triggers: "Generatieve AI creëert content op basis van menselijke prompts", terwijl "Agentic AI autonoom handelt zonder op prompts te wachten." Promptvormig versus doelvormig, wat een echt onderscheid is en zelden wordt gerespecteerd.

Tegenover een assistent. De scherpste zin die iemand in de set schreef is van Docket's Arjun Pillai: "Een assistent wacht op een gebruiker, helpt bij een taak en leeft binnen een menselijke workflow." Het agent-deel is "Een agent handelt naar een doel, neemt begrensde beslissingen, activeert workflows en draagt onder toezicht een deel van de uitvoering." Een aparte passage op dezelfde pagina levert het mechanisme dat die zin mist: mensen "definiëren doelstellingen, escalatieregels, onderwerpbeperkingen en goedkeuringsdrempels. De agent opereert binnen die grenzen. Wanneer iets daarbuiten valt, escaleert hij." Escalatie is de goedkeuringsgrens uit onze definitie, beschreven vanuit de kant van de agent.

Eén meningsverschil is het waard om te vermelden in plaats van glad te strijken. Forrester, op een pagina over use cases voor AI-agents met Craig Le Clair erop genoemd, scheidt de twee termen die elke leverancierspagina hierboven als uitwisselbaar behandelt: AI-agents draaien op "vooraf gedefinieerde regels", terwijl "agentic AI bredere autonomie en aanpasbaarheid introduceert". Een eerlijke waarschuwing over die bron: het is een landingspagina van een podcast, geen gepubliceerde onderzoeksnotitie, en we citeren het als de framing van één onderzoeksbureau, niet als bevindingen.

De laag die acht van de elf definities weglaten

Van de elf pagina's die we op 18 augustus 2026 voor deze term ophaalden, noemen er acht nooit het Model Context Protocol, tool calling of function calling. Die laag is het verschil tussen een model dat een campagnepitch voor je schrijft en een model dat een quest kan aanmaken, een lid kan bannen of je eventstream ergens anders naartoe kan wijzen.

De acht zonder vermelding van een van die strings: braze.com, cdp.com, docket.io, forrester.com, netcore.ai, tofuhq.com, vlerick.com en youngurbanproject.com. Van de overige drie noemt hubspot.com het Model Context Protocol, maar het is geen definitiepagina. Optimove is degene die ons bijbleef: de string MCP verschijnt op de pagina alleen in het navigatiemenu, als "The Optimove MCP", en nooit in de body van het artikel dat de categorie uitlegt. Een leverancier die een MCP-server levert, wiens eigen uitleg over agentic marketing nooit bij datgene komt wat hij levert. Dat is een uitspraak over elf pagina's op één dag, niet over de hele categorie — maar het gold voor elke pagina die we controleerden.

Twee pagina's in de set benoemen de ontbrekende laag wel, en beide doen dat goed.

HubSpot's Duncan Lennox schrijft: "Maar agents klikken niet door dashboards of navigeren niet door interfaces; ze roepen API's aan, lezen gestructureerde outputs en ondernemen actie." Dezelfde pagina kadert scope als "wat agents kunnen lezen, schrijven en waarop ze kunnen handelen", en dat is de juiste eenheid. Niet "kan het marketing doen", maar welke zelfstandige naamwoorden en welke werkwoorden.

Real Story Group, een martech-onderzoeksbureau dat leveranciersevaluaties verkoopt, levert de zin die het argument afsluit. In een artikel over MCP van 11 juni 2025 noemt Principal Analyst Scott Simmons het "een universele API-abstractielaag gebouwd voor AI-agenten", en trekt de conclusie dat een agent "slechts zo krachtig is als wat de leverancier ervoor kiest om beschikbaar te stellen".

Die laatste zin is alles. Agentische marketing is geen eigenschap van het model dat je hebt gekozen. Het is een eigenschap van het oppervlak dat je leveranciers publiceren. Als de tools alleen-lezen zijn, rapporteert je agent. Als er geen tools zijn, schrijft je agent copy. De capaciteitsvraag en de inkoopvraag zijn dezelfde vraag, en daarom zijn de definities die deze laag overslaan zo prettig om te lezen en zo moeilijk om naar te handelen. Als je het bredere beeld wilt van de kanalen waarbinnen een agent zou opereren, onze web3-marketingpijler behandelt ze en wat ze kosten.

Waarom een lijst met tools bewijs is en een toollabel slechts een hint

Het Model Context Protocol beantwoordt de vraag wat een agent jou kan aandoen door je te vertellen de lijst met tools van de server te lezen, en vertelt clients vervolgens dat ze niet moeten vertrouwen op wat die lijst over zichzelf zegt. De opmerking die dat zegt staat in het schema in plaats van in de tekst, wat deels de reden is dat zo weinig mensen het hebben gelezen.

Hier is de passage, uit de ToolAnnotations interface in de specificatie's schema bij revisie 2026-07-28:

LET OP: alle eigenschappen in ToolAnnotations zijn hints. Ze zijn niet gegarandeerd een getrouwe beschrijving van het gedrag van de tool te geven (inclusief beschrijvende eigenschappen zoals title).

En over hetzelfde onderwerp, uit de toolpagina:

Voor vertrouwen, veiligheid en beveiliging moeten clients MOETEN toolannotaties als onbetrouwbaar beschouwen, tenzij ze van vertrouwde servers afkomstig zijn.

Laat de vorm daarvan even bezinken. Het antwoord van het protocol op "hoe weet ik wat dit ding met mij kan doen" is: lees de lijst. De eerstvolgende instructie is: de lijst is een bewering van de partij die je beoordeelt. De tool namen en schema's zijn essentieel, omdat het model ze aanroept en de server ze moet honoreren. De risicolabels die eraan hangen, zijn de eigen beschrijving van de server van zijn eigen gedrag.

Er zijn vier zulke labels — readOnlyHint, destructiveHint, idempotentHint en openWorldHint — en twee ervan, destructiveHint en openWorldHint, staan standaard op true. Een tool zonder label wordt daarom als destructief beschouwd en er wordt aangenomen dat deze de buitenwereld raakt, wat de juiste keuze is en het tegenovergestelde van wat de meeste mensen verwachten.

Degene die ertoe doet voor een definitie van agentische marketing is destructiveHint, vanwege wat het niet vraagt. Het scheidt overschrijven van toevoegen. Schade is een andere as en het schema heeft er geen kolom voor, dus een puur additieve aanroep kan het meest ingrijpende zijn dat een agent met je stack doet en toch als de veilige manier worden gelabeld door een server die volledig te goeder trouw handelt. Wat elke flag in de praktijk betekent, en hoe een echte listing eruitziet zodra je de standaardwaarden toepast, staat in de walkthrough hiernaast.

Dit is ook de eerlijke versie van wat marketeers blijven aanduiden als agent washing. Young Urban Project benoemt het precies: "De meest voorkomende fout is agent washing, een bestaand automatiserings- of chatbotproduct nemen en het rebranden als agentisch zonder de plannings- of beslissingslaag eronder toe te voegen", en voegt toe dat "de demo is gescript om precies de kloof te verbergen die ertoe doet". Een lijst met tools is veel moeilijker te scripten dan een demo. Het is ook het enige artefact in deze hele categorie dat een koper kan controleren zonder medewerking van de leverancier, en daarom schreven we een aparte walkthrough van hoe je de tools van elke MCP-server opsomt voordat je verbinding maakt.

Waar de goedkeuringsgrens ligt, en wie die daar hoort te plaatsen

Het Model Context Protocol stelt dat er altijd een mens in de loop moet zijn met de mogelijkheid om tool-aanroepen te weigeren, en dat zegt het tegen de clientapplicatie, als SHOULD in plaats van MUST. Niets in het protocol verplicht de server waarmee je verbinding maakt. Waar jouw goedkeuringsgrens ligt, is een keuze die iemand heeft gemaakt, en vaak niet jij.

De exacte zin:

Voor vertrouwen, veiligheid en beveiliging SHOULD moet er altijd een mens in de loop zijn met de mogelijkheid om tool-aanroepen te weigeren.

Dezelfde beveiligingssectie vraagt clients om "tool-invoer aan de gebruiker te tonen voordat de server wordt aangeroepen, om kwaadwillige of per ongeluk datalekken te voorkomen" en om "tool-resultaten te valideren voordat ze aan het LLM worden doorgegeven". Beide zijn gericht aan de client: het ding dat aan jouw kant draait, de Claude of ChatGPT of interne harness die het model bevat. Dus bij een gewone lezing van het protocol is de veiligheid van je agentic marketing de taak van je client, en de server waarmee je verbinding hebt gemaakt, is je niets verschuldigd buiten een eerlijke tool-lijst.

De categorie weet dit en is er niet helemaal zeker van wat ze ermee moet. Leveranciershandleidingen definiëren een agent routinematig door de afwezigheid van een persoon en vertellen je vervolgens verderop op dezelfde pagina waar je de persoon weer moet plaatsen; we halen een van die pagina's uit elkaar in kan een AI-agent je community echt runnen. Beide helften zijn oprecht. De definitie is geschreven voor de markt en de instructie is geschreven voor de deployment, en de kloof daartussen is waar elke echte beslissing over autonomie daadwerkelijk wordt genomen.

De versie die het verdedigen waard is, is noch "volledige autonomie" noch "alles goedkeuren". Het is dat de grens een instelling per beslissing is met een prijs aan beide kanten, en dat het mechanisme dat die afdwingt zelf software is die kan falen — wat de Discord-moderatiefout eerder dit jaar aantoonde, waarbij de stap voor menselijke beoordeling in het gepubliceerde ontwerp bestond en een bug die uit het pad haalde. We schreven over wat dat betekent voor het een agent een community laten runnen apart, omdat het meer verdient dan een bijzin.

Er is nu ook een gemeten antwoord op welke oproepen de poort verdienen, en het is niet degene die je intuïtie je geeft. SABER: Small Actions, Big Errors — Safeguarding Mutating Steps in LLM Agents, door Alejandro Cuadron, Pengfei Yu, Yang Liu en Arpit Gupta en ingediend op 26 november 2025, onderzoekt waar een traject van een tool-gebruikende agent die misgaat je daadwerkelijk geld kost. Er wordt gemeld dat "Daarentegen hebben afwijkingen in niet-muterende acties weinig tot geen effect." De zin direct daarvoor geeft de andere kant: elke extra afwijking in een muterende actie verlaagt de kans op succes met tot 92% op een van de twee domeinen en tot 96% op het andere, voor state-of-the-art modellen. Falen concentreert zich in de aanroepen die de status wijzigen.

De ontwerpconclusie is onglamoureus en goedkoop: poort de schrijfacties, laat de leesacties met rust, en stop met "human in the loop" te behandelen als één knop met één stand. De server van Zealy werkt toevallig zo, en we moeten duidelijk zijn dat we dat niet uit dit paper hebben afgeleid — het paper kwam na het ontwerp en is het ermee eens, wat zwakker is dan evidence-led engineering en sterker dan niets. Bij de verwijzing hoort één voorbehoud: SABER documenteert annotatiefouten in de benchmark waarop het voortbouwt en publiceert een gecorrigeerde versie, wat een goede reden is om oudere tool-agent benchmarkscores niet te citeren alsof ze nog steeds de huidige modellen beschrijven. De andere reden om hier voorzichtig te zijn met één getal is dat agentfalen grotendeels een variantieprobleem is — de onderzoek naar meerdere beurten splitst de verslechtering in een klein verlies van bekwaamheid en een grote stijging van onbetrouwbaarheid, wat een ander managementprobleem is dan een model dat simpelweg niet goed genoeg is.

Hetzelfde patroon van "overgelaten aan de implementator" speelt zich een laag dieper af, bij het vierde deel van onze definitie. We hebben op 18 augustus 2026 zeven specificatie- en beveiligingspagina's gedownload en doorzocht: het dreigingsmodel van de specificatie is een autorisatie- en transportdreigingsmodel, dat onder meer confused deputy, token passthrough, server-side request forgery en een gecompromitteerde lokale server dekt, terwijl de aanval op modelniveau aan implementatoren wordt overgelaten. Op de pagina's die we hebben gedownload komt de term "prompt injection" niet voor; de vier treffers voor "injection" in het document met beveiligingsbest practices zijn cross-site scripting, shell command injection en remote code execution. Dat is geen klacht over een transportspecificatie, die zichzelf mag afbakenen. Het is een uitspraak over welke helft van het probleem je erft zodra je iets verbindt, en over waarom een trust boundary op geretourneerde data iemands expliciete taak moet zijn in plaats van een veronderstelde eigenschap van het protocol.

Zealy voldoet niet aan zijn eigen definitie, en dat is waar

Volgens de strengste definities in dit bericht — "zonder dat een mens elke afzonderlijke stap goedkeurt" van Young Urban Project en "zonder menselijke goedkeuring bij elke stap" van Netcore — doet Zealy niet aan agentic marketing. Elke schrijfactie via het agent-oppervlak van Zealy stopt voor een persoon, en de schrijfacties staan uit tot een operator ze aanzet.

Dat zeggen we liever dan de discussie later te verliezen. Hier is de volledige scorecard tegen onze eigen vier delen, first-party en ongeauditeerd.

Alle vier zijn aanwezig, wat het makkelijke deel is. De derde staat verkeerd om ingesteld voor het label. Zealy's server plaatst de goedkeuringspoort aan de serverzijde, wat meer is dan het protocol van een server vraagt en meer dan een strikte definitie van agentic marketing toestaat. Het tooloppervlak zelf is groot genoeg om te auditen — 72 benoemde tools op het moment dat we ze telden — maar het aantal is niet het punt. De instelling is dat wel.

We kunnen ook niet claimen dat het hele product consistent is. Zealy levert ook een AI-reviewer die een quest-claim zelf afsluit, zonder dat er een persoon aan te pas komt: hetzelfde bedrijf, de tegenovergestelde instelling, bij een beslissing die bepaalt of een lid wordt uitbetaald. Beide keuzes zijn verdedigbaar; wat we niet eerlijk kunnen zeggen, is dat er één bedrijfsbreed antwoord is op de vraag hoeveel autonomie gepast is.

Dus laat dat label vallen. Wat Zealy feitelijk biedt, is een voor agents leesbaar oppervlak met een menselijke bevestigingsstap, wat een saaie naam is voor iets wat de meeste teams als eerste zouden moeten willen. Als je wilt weten hoe je het aansluit, de MCP-integratiedocumentatie is leidend en dit bericht herhaalt die bewust niet; als je het oudere, bredere oppervlak eronder wilt, de API-documentatie behandelt dat. En als je het product nog nooit hebt gebruikt, wat Zealy is is de kortere route in.

Wat je moet vragen voordat je iets koopt dat agentic marketing heet

Vraag om de tool-lijst. Een leverancier die agentic marketing verkoopt, kan je ofwel de benoemde operaties laten zien die een agent krijgt, met de bijbehorende permissies, of niet. Al het andere, de plannings taal en de doelzoekende taal en de demo, is verenigbaar met een chatbot die aan een formulier is gekoppeld, en Young Urban Project heeft daar een naam voor.

Vijf vragen, in de volgorde die je de meeste informatie oplevert voor de minste vergadertijd:

1. "Welke operaties krijgt de agent, bij naam?" Als het antwoord een capaciteitszin is in plaats van een lijst, heb je je antwoord. Als het een lijst is, lees die dan op werkwoorden. Lezen, schrijven, verwijderen, verzenden, publiceren, betalen.
2. "Welke daarvan kunnen zonder mij handelen?" Niet "is er een mens in de loop": die vraag krijgt van iedereen een ja. Vraag welke specifieke calls de persoon overslaan, en wie die splitsing heeft gekozen.
3. "Wat gebeurt er met tekst die een klant heeft geschreven wanneer de agent deze leest?" Je vraagt of toolresultaten als data of als mogelijke instructies worden behandeld. Een leverancier die hierover heeft nagedacht, antwoordt meteen, want dit is de faalmodus die hun engineers wakker houdt.
4. "Wat betekenen jullie risicolabels?" Controleer het antwoord vervolgens aan de hand van de specificatie in plaats van de verkooppresentatie, en vraag wat de standaardinstellingen zijn — de meeste mensen gokken ze verkeerd.
5. "Wat kan het niet?" Een lijst met grenzen is het goedkoopste geloofwaardigheidssignaal dat er is, en bijna niemand publiceert er een. De afwezigheid ervan bewijst niets. De aanwezigheid ervan is veel waard.

Het laatste punt gaat over volgorde, want de aankoopbeslissing hier is meestal verkeerd getimed. De meeste teams die agentic marketing evalueren, hebben nog niet opgeschreven welke van hun terugkerende taken veilig kunnen worden overgedragen en welke niet — en die beslissing is dezelfde, of de handen nu toebehoren aan een contractor, een moderator of een model. Hoe je communitytaken delegeert werkt het met mensen door, en de analyse blijft vrijwel ongewijzigd van toepassing. Doe dat eerst. De agent zal er nog steeds zijn, en je zult weten welke tools je hem echt wilt geven.