Wat leveranciers bedoelen met een AI-growthteam
Leveranciers gebruiken de term voor AI-agents die het werk van een growthteam overnemen: events en resultaten lezen, segmenten bouwen, journeys en de berichten daarin opstellen, rapporteren wat er is gebeurd. De pitch komt vaak als organigram, met één agent per functietitel (een strateeg, een Lifecycle Marketer, een analist, een copywriter) en soms een coördinerende agent die taken tussen hen verdeelt. Er is geen standaarddefinitie, en de producten achter het label lopen uiteen van een chatassistent met een prompt per rol tot agents die dingen kunnen wijzigen in een marketingplatform. De term slaat ook op de growthteams van AI-bedrijven; deze pagina gaat over de andere betekenis.
De vorm is geleend van menselijke growthteams. De gids van Andrew Chen over het opzetten van een growthteam noemt een Growth PM, een Growth Engineer, een Growth Marketer, een analist en een designer, en merkt op dat de samenstelling kan veranderen met het probleem dat het team oplost. Die menselijke functies staan in wie wat doet in een growthteam, onderdeel van het thema Groeiwerk & AI.
Een voorbeeld: één agent, één welkomstjourney
Neem één agent die je al gebruikt, zoals Claude, Cursor of Codex, via MCP verbonden met het platform waarmee je verstuurt, zodat hij daar de data kan lezen en segmenten, templates en journeys kan maken. Het voorbeeld hieronder is illustratief: een welkomstjourney voor nieuwe aanmeldingen, in vijf stappen. Elke stap begint als een gewone vraag, en de agent antwoordt door tools aan te roepen in plaats van instructies te schrijven die jij moet uitvoeren. Dat is de grens tussen een agent en een chatbot.
In het voorbeeld doet een mens drie dingen: elk doel bepalen, het concept lezen voordat het live gaat en kiezen wat er beter moet; de agent leest, bouwt, rapporteert en herschrijft. Het is één agent van begin tot eind, met één set tools. Op een organigram zouden die vijf stappen over meerdere functies lopen; hier is er geen overdracht. Let ook op wat de laatste stap niet deed: hij liet de live e-mail met rust, omdat het bewerken van een e-mail die een live journey gebruikt, verzendingen kan veranderen die al onderweg zijn.
Eén agent of een team van agents?
De AI opsplitsen in agents die naar een rol zijn genoemd, is één manier om prompts en overdrachten te organiseren: elke agent krijgt een functietitel en een smalle opdracht, en een coördinerende laag, meestal agent-orkestratie genoemd, verdeelt de taken en geeft context door van de ene agent aan de volgende. Agents met een rolnaam zijn een legitiem ontwerp; ze zijn niet de reden dat het voorbeeld werkte.
Dat het werkte, komt door drie dingen: tools om templates en een concept van een journey te maken, leestoegang tot events, profielen en resultaten, en een stop voordat er iets bij klanten terechtkwam. Een functietitel voegt geen tool en geen data toe; één agent opsplitsen in meerdere voegt overdrachten toe die je moet beheren. In zijn gids over het bouwen van effectieve agents beschrijft Anthropic agents als doorgaans gewoon LLM’s die in een lus tools gebruiken, gestuurd door feedback uit hun omgeving, en concludeert het dat de tools en hun documentatie een duidelijk, zorgvuldig ontwerp nodig hebben.
Dezelfde gids raadt aan de eenvoudigst mogelijke oplossing te zoeken en alleen complexiteit toe te voegen als dat nodig is, en meldt dat bij de tientallen teams waarmee Anthropic werkte, de meest succesvolle implementaties eenvoudige, combineerbare patronen gebruikten in plaats van complexe frameworks. Werk opsplitsen kan nog steeds zinvol zijn om technische redenen, zoals taken die parallel lopen of context die te groot is voor één gesprek. Onze kijk, voor growthwerk: begin met één capabele agent en de juiste tools, en voeg agents toe als een taak erom vraagt, niet om een organigram na te bootsen.
Wat bepaalt of het werkt
Haal de functietitels weg en er blijven drie vragen over. Ze gelden voor één agent of meerdere, op elk platform, en ze wegen zwaarder naarmate het team kleiner is, omdat minder mensen in de gaten houden wat er de deur uitgaat.
| Criterium | Wat je vraagt | Hoe een goed antwoord eruitziet |
|---|---|---|
| Wat hij kan wijzigen | Welke acties kan de agent uitvoeren in het platform? | Benoemde objecten die hij maakt of bewerkt, zoals een segment, een template of een concept van een journey, geen tekst die iemand nog moet omzetten in een segment of een journey. |
| Wat hij kan lezen | Wat ziet hij voordat hij iets opstelt? | Events, profielen, segmenten en resultaten uit het platform waarin hij bouwt, geen lege prompt. |
| Waar iemand controleert | Wat stopt voordat klanten het zien, en wat geldt meteen? | Een duidelijke grens: journeys blijven concepten tot ze worden gepubliceerd, publiceren vraagt een expliciete stap, en de leverancier zegt welke wijzigingen gelden zodra ze zijn opgeslagen. |
Let op wat er niet op de lijst staat: de functietitel van de agent. Een agent die strateeg heet maar je resultaten niet kan zien, schrijft op basis van giswerk; een naamloze agent met de juiste tools en data schrijft op basis van wat mensen echt deden. Een uitgebreidere toets van wat leveranciers beweren, vind je in wat agentic marketing betekent.
Waar iemand controleert
Van de drie vragen weegt de laatste het zwaarst. Het gangbare patroon voor marketingagents is human-in-the-loop: de agent doet een voorstel en een mens bepaalt wat live gaat. In de praktijk is dat controlepunt niet één schakelaar maar drie plekken, en een leverancier moet je precies kunnen vertellen wat er op elk ervan gebeurt.
Agents doen het best bij afgebakend, herhaalbaar werk met de data op één plek, zoals journeys voor onboarding en het terugwinnen van klanten, segmenten bouwen en wekelijkse rapportages. Sommige beslissingen blijven bij een mens, hoe je het ook inricht: welke metric dit kwartaal telt, hoe het merk klinkt, welke gok het budget waard is. Een agent kan de opties uitwerken. Onze gids over of AI je marketingteam kan vervangen trekt dezelfde grens.
Waar fromHello past
fromHello is open source marketing automation: berichten die worden getriggerd door wat mensen doen. Je eigen AI werkt erin via de MCP-server van fromHello, die Claude, Claude Code, Cursor, Codex, Windsurf, VS Code of elke MCP-client 59 tools geeft om analyses en profielen te lezen en segmenten, journeys, templates, eigen velden en eventkoppelingen te maken. De vijf stappen uit het voorbeeld (bedenken, bouwen, meten, analyseren en verbeteren) draaien allemaal op die tools, en MCP-aanroepen tellen nooit mee. De ingebouwde assistent deelt dezelfde tools: beschrijf een segment, een journey of een template in één zin en hij bouwt het, en een journey komt binnen als concept.
Loop de drie controles hierboven één voor één langs. Concepten: geen enkele AI-tool in fromHello verstuurt een bericht, en een journey die je AI bouwt, blijft een concept tot hij wordt gepubliceerd; publiceren, pauzeren of verwijderen via een agent vereist een bevestigingsstap in je AI-client, volgens de eigen toestemmingsinstellingen van die client. Opgeslagen wijzigingen: andere wijzigingen, zoals aan een segment of een template, gelden zodra ze zijn opgeslagen, dus ze kunnen een journey raken die al live is. Verzendmoment: personalisatie is per e-mailstap aan te zetten (Light, Medium of Deep) en herschrijft elke e-mail voor de ontvanger, op basis van het profiel, notities en eerdere e-mails, zonder controle per bericht; als de AI faalt, wacht de verzending standaard. Aanroepen van MCP-tools worden vastgelegd in de auditlog.
Twee van die antwoorden, over opgeslagen wijzigingen en het verzendmoment, zijn minder netjes dan een pitch je zou doen geloven. Wij hebben de controles opgesteld, dus weeg onze antwoorden met dat in gedachten. Wil je fromHello vergelijken met een tool die je kent? Bekijk fromHello vs. Customer.io of fromHello vs. HubSpot.