Agents Aren't the Point. The Learning Loop Is.

In Kana's recent Agentic Divide Research Report, 82 percent of the marketing, data and AI leaders we surveyed said they expect agents to run a third or more of their routine marketing decisions within two years.

At Ai4 2026, Kana co-founder Vivek Vaidya made the case for what that shift truly requires: not another point solution, but an operating layer, a nervous system for a marketing technology stack that has only ever had organs. That's the frame we build from. The question worth answering next is what actually earns a system the right to call itself that, once it's the thing running a third of your team's decisions, and we’d like to propose that one critical point of evaluation for any agentic technology solution is whether is getting better at making decisions, or just faster at making the same ones.

That distinction is the sharpest definition we have of what agentic marketing has to do to earn the name, and frankly it's also the one we are holding ourselves to.

The trap of "just add agents"

Picture the version of AI agents for marketing that ships fastest: a handful of specialized agents, each wired into your stack through MCP, each doing its one job. One drafts audience segments. One flags spend anomalies. One drafts ad copy. Useful on its own. Importantly, each is on its own, an organ without a nervous system.

Every one of those agents starts each task from zero context. Nothing one of them learns is available to the next. The output stops at a recommendation, or, if it's wired to act, it takes the action and forgets why it did. Run it for a year and you have faster point solutions. You do not have a system that knows more about your customers, runs better campaigns, or makes better calls, than it did on day one.

That's the same tax on your best people that Vivek discussed during his presentation at Ai4: marketers spending 60 to 80 percent of their time on operational execution instead of strategy or creative judgment. A set of agents with no shared memory doesn't remove that tax. It just moves the manual work one layer up, from copying data by hand to chasing down why an agent forgot the exception someone approved for this account six weeks ago. What generally hasn’t been built is a way for one decision to make the next one easier, cheaper, and/or smarter, for the people running the program or for the system itself.

This is why agent count is a bad proxy for progress, since a team can ship a dozen well built agents and still be exactly as far from a marketing operating layer as a team with zero, if none of those agents share what they've learned.

‍Everything new looks old again

This isn't a hypothetical failure mode. The last decade sold marketing teams two different promises that both landed short of this bar. One wave promised smarter journeys and next best action, and mostly delivered fast execution wired to rules that never got smarter about which rules were right. Another wave promised a single source of truth in the data warehouse, and delivered a very complete memory with nothing attached to it that could decide what to do with what it remembered. A pile of point agents and MCP connections risks repeating that same pattern in a more responsive package: quicker, more conversational, but still not learning anything between decisions.

What actually compounds, and who it's for

Here's the test we propose everyone use: when this exact type of decision comes up again next week, does the system know anything it didn't know last time? That means building in a step most implementations skip: after the system acts, someone, or something, has to ask what happened, and feed the answer back in.

This is where the marketer's judgment matters most, not least. When an experienced marketer overrides a recommendation, that override is a signal worth more than the recommendation itself. Capture why the override happened and it becomes the new default. Skip it, and that same judgment call gets made from scratch by the next person, or ignored by the next agent, forever. Done well, a compounding decision loop is how one marketer's hard won read on an account, a channel, or a customer segment becomes the whole team's baseline instead of staying locked in their head. That's the opposite of replacing marketers with automation. It's building a system that finally learns from and retains what your best people know.

Why this has to be built around you

If the thing that matters is whether a decision gets cheaper and smarter the second time, the nervous system has to be built around your decisions specifically: your eligibility rules, your margin logic, your override history, the exception that currently lives in one person's head. A generic point solution can't give you that, because it was built to be identical for every customer who buys it. A pile of individually wired agents can't give you that either, because nothing about MCP or agent orchestration on its own creates a shared place for that history to live and be reused.

What should be yours to own is the learning loop itself: a running record of the decisions you’ve made, the reasoning behind them, how they played out, and how the system used that to act differently the next time around. That's worth building on purpose rather than hoping it emerges from enough point agents wired together.

Again, that figure of 82 percent of leaders expecting agents to run a third of routine decisions within two years signals that the journey to agentic marketing is demonstrably well underway. However, we all should be posing the question of what your agentic system is built to remember once it gets there. 

A nervous system that senses, decides and acts but never learns is still just a faster version of the same trap marketing has bought before, dressed up in better technology. The version worth building treats every decision as something to keep and compound, not something to redo, and it's built around the judgment your best marketers already have instead of around any single agent or vendor's roadmap.

If you're trying to figure out where that first decision loop should live in your own stack, let's talk.