We just named our first Forward Deployed Engineer at Aampe. I first heard the term 15 years ago - in 2010 - while working in the US Department of Defense deployed to Afghanistan. I didn’t know anything about private sector SaaS at the time, but as someone hired partly as an intelligence analyst and partly as an anthropologist, the concept seemed pretty obvious to me. A central method in my graduate training was participant observation - your research was expected to be immersed in the context and activities of the people you were studying and seeking to understand. The engineering I was doing was data engineering, but I knew data wasn’t much use unless you knew exactly how it was being collected and generated - you had to see where it came from up close - if you wanted to be able to use it effectively.

Now here we are in 2025 and software is on its way to thoroughly eating the world - except - software has been all rules-based. Every bit of it has required humans to tell it exactly what to do under very specific conditions. That just doesn’t scale. Our product managers sit in our offices and whiteboard “the user journey” and our marketers idealize their perfect campaign sequence in a canvas and none of it reflects any of the gritty and critical detail of our users’ actual experiences or interests or intentions.

Our hardware enables our applications to sit right in the pockets of our customers - accompanying them as they take a walk, or stand in line at the grocery store, informing the way they live their very rich lives in an incredibly textured world - but our software is entirely bound up in the cripplingly confined borders of our whiteboards and canvases.

We founded Aampe to set consumer applications free - no longer rule engines - but interfaces and messaging actively managed by agents that can forward deploy into the world with their designated user.

The implications of this are incredible. In fact I spend a good number of hours each week in a slight daze at how little we realize the power and extent of what our software can be capable of.

What does this mean? It means the actual Context we live in as human individuals is incredibly rich. There’s absolutely no reason that our applications shouldn’t be able to incorporate and narrate around that rich Context.

For example, we live in and through the Weather. Every application should be piping in rich weather feeds as user context:

• You’re a ride hailing app and your user completes a ride - you know it’s raining - send them a message thanking them for taking the ride and tell them you “hope they stay dry.”

• You’re a fashion commerce app and you know there’s a cold spell this coming weekend in a user’s area - let your user know about the warm jacket that just came on sale.

Sports are at the center of many people’s lives. Every application should be piping in fun sports feeds:

• You’re a food delivery app and you have the NFL schedule for the team in your user’s city - tell them the best pizza they can order for the upcoming game. Or learn that they actually follow a different NFL team.

• You’re a running app - give your a user a clip of a brilliant NBA athlete sharing why they train and what training means to them, so your user gets that extra motivation to get out and run.

Historical references, literary characters, lyrics from your favorite pop star - it’s all available in data and through feeds - pipe it to your agents and let them learn and weave wonderfully specific Context into your users’ lives.

We have to push for a major leap forward in how consumer technology operates. Aampe’s agentic infrastructure provisions agents that can learn over whatever context you give them. Conventional software could never take advantage of all that context because the human rules that governed it would have simply broken down under the weight of it all. But agents can handle that level of context. We just have to give it to them.

And that’s what Forward Deployed Engineers at Aampe will be doing for our customers and partners: leaning in and developing right along with them to ingest and enable massive amounts of context - to push the boundaries of what’s possible with agentic infrastructure.

I can’t think of a more exciting and rewarding kind of work. 15 years ago I would have completely leaped at this kind of work. I’m so lucky and happy to be a part of it now.

1. We can employ a weighting strategy to convert all instrumented app events - not just funnel events - into useful signal for agentic learners. I personally prefer the weight to be a combination of the average daily inverse count of events, and a pagerank personalized to prioritize end-of-funnel events.

2. We can perform a version of Interrupted Timeseries Analysis (ITS), using each message as the "interruption" and using a sufficiently large and exponentially weighted lookback/lookahead window (I've found 12 hours seems to be a good default window size).

3. We can aggregate judgments over time using another exponential decay to define long-term and short-term memory. Long-term memory is how much history of interventions you decide to aggregate, and the short-term memory defines the half-life of the decay function.

Using these three principles, we can estimate user-level preferences for anything that can be defined as an intervention attribute. The day of week, time of day, hours since triggering event, channel, value proposition, offering category, call to action, and recommendation type instantiated in an individual message - or the interaction of any of those things - are all examples of intervention attributes.

Have 5 different value propositions and want to know which to use on which user? Randomly assign those value props to different users by sending them messages. Use your weighting strategy and ITS to aggregate the signal before and after the intervention, which summarizes the evidence for and against the idea that the message had an impact. Then aggregate that before and after signal over time using the long- and short-term memory parameterization of the attention function. Then convert that aggregated signal into a confidence estimate, the same way you would for an individual message.

So learning preferences is a matter of loading up interventions with tags that represent attributes that could be used to select future interventions, and then aggregating signal over time.

Of course, this doesn't help for users who yield little-to-no signal with which to characterize their interventions. We need a way to infer that from other users. But that's a topic for another post.

What is AI segmentation? Ask your favorite search engine or LLM and I bet the answer is a mishmash of the words “algorithms”, “machine learning”, “artificial intelligence”, “automatic”, and “dynamic”. More importantly, you’re unlikely to find a simple explanation of how AI segmentation works and how it differs from traditional segmentation. 

This article will do just that—offer that missing explanation—while also covering Aampe’s approach to segmentation. 

What is AI segmentation? How does it work?

Unlike traditional segmentation, where folks like you and I would spend hours combining events and attributes to build segments based on our understanding of our respective users, AI segmentation simply  groups users with similar behavioral characteristics or traits (attributes); some examples below: 

• Users who are in a similar stage of their journey

• Users who spend more or less time in the app than the average user does

• Users who have bought similar products or tried specific features

• Users who spend more or less money than the average user does

• Users who buy more or less frequently than the average user

You get the idea. 

In essence, these are segments that we can create manually by specifying rules—the AI is simply making the process faster by automatically creating the most obvious segments and letting us further refine them. At the end of the day, even these AI-generated segments are rule-based. 

Is there value in this approach? Most definitely. 

Is this a game-changer? Not really. 

How is Aampe’s approach to segmentation different? Why?

Aampe has flipped the rule-based segmentation approach we all know—one we have a love-hate relationship with—on its head. What that means is that at Aampe, we believe that it is time for us humans to move past the drudgery of building, documenting, and maintaining a bajillion segments by hand.

Instead, Aampe leverages a method called Reinforcement Learning where it assigns an agent for every user that decides what to deliver, when to deliver, and most importantly, whether or not to deliver in the first place. 

How does it work?

Each agent learns the behaviors and preferences of its client—your user—and adjusts message delivery based on the feedback it receives from the user. You can think of an Aampe agent as an additional headcount for every user of yours. This process takes place continuously and at the same time, the agent tests its biases constantly so that wins are not continued in perpetuity. 

Aampe’s agents begin by generating a large set of features or characteristics that describe everything they know about a user, which enables the agents to group users based on those features. 

Imagine a spreadsheet with a row for each of your team members. Next, imagine a column for every possible way to describe each team member’s outfit; the columns might look like these:

• Wears Spectacles? (Yes or No)

• Spectacle Rims Shade (Dark, Light, Clear)

• Shirt Has Collar? (Yes or No)

• Shirt Pattern (Solid, Striped, Checked)

• Shoe Type (Formal, Sneakers, Sandals)

• Shoe Color (Dark or Light)

• And so on

Now, imagine the different ways you can group the rows based on the above columns; here’s a random selection of some of the groups:

• Wears Spectacles = Yes AND Shirt Has Collar = Yes

• Wears Spectacles = No AND Shirt Has Collar = Yes AND Shoe Type = Sandals

• Shirt Pattern = Solid AND Spectacle Rims Shade = Clear

• Shoe Color = Dark AND Show Type = Formal AND Shirt Pattern = Striped

You get the picture, don’t you? The number of permutations and combinations is in the thousands—maybe even hundreds of thousands considering that we haven’t considered all variables (pants, belt, etc).   

The process of creating all these groupings by hand is, well, exhausting and rather impractical.  Fortunately for us, AI agents don’t get exhausted and don’t care about the practicality of a given task—they just do it.

So when do you—Aampe’s user—build segments? 

Well, only when you need to send one or more messages to a predefined audience—agents can take care of the rest. 

Why does Aampe suggest this approach to segmentation?

Because it is humanly impossible to keep track of the changing habits and preferences of every user and a sheer waste of one’s capacity for creativity to decide who receives what message when. Instead, Aampe lets people like you and me focus on crafting lots and lots of message variants and tagging them accurately for Aampe’s agents to use them in the right context. 

This approach frees us from everyday grunt work and provides much-needed space to focus on higher-impact, meaningful tasks—tasks like creating a catalog of compelling messages for our diverse audiences. 

But that’s not it.

Aampe also helps us better understand what our users are interested in by surfacing hard-to-gain insights about the needs and preferences of every user, enabling us to improve the overall customer experience. 

The future is 1:1 personalization

This is an unbiased take based on my experience both as a personalization evangelist and a consumer: It’s no longer enough to anticipate a user’s needs and put them into a box based on one’s limited understanding of who the user is and what it is that they’re looking for. 

We’re all unique and as our circumstances change, our tastes, needs, and wants are prone to change. Therefore, it only makes sense to let an intelligent piece of technology take over the messy work of keeping up with our changing preferences while we do what we’re best at—unleashing our creativity to build better relationships with our customers.

Originally posted on the Aampe blog

Hugo Cheyne at Trailblaze wrote a really interesting piece of the use of learning maps to empower personalized AI tutors. Someone tagged me in a comment, pointing to some work we've done at Aampe on knowledge graphs. Hugo was kind enough to respond to that comment by asking for my take.

I was half-way done writing that take before I realized it was already far too long to give in a comment. So, with apologies to Hugo, I'll post my answer here. I think the issue he raises an important issue about agentic learning in general - a mindset shift that, at least initially, proves to be a challenge for many of our customers. Scroll to the end of this post to see that more general takeaway.

First, here's my reply to Hugo:

It's been a while since I worked in the education sector, so my thinking on this issue might be a little rusty. Also, I'm not deeply familiar with your particular application. Also, at Aampe, we solve for this kind of content-dependency issue in a particular way, so I might just be biased from being steeped in that particular mindset. All that being said:

Do you need to build those learning dependencies into the learning map itself? Wherever a student is in their learning there are a number of learning options available to them. The dependency path isn't singular or linear: learning competency 1 unlocks the ability to learn competency 2a, 2b, 2c, 2d, etc., even if a, b, c, and d represent very different subjects.

Curricula are often set out linearly because textbooks are linear by nature. One of the strength of AI-facilitated learning, to my mind, is the ability to break free from that arbitrary constraint.

So you could do the following:

1. Set out the initial learning map as just different pieces of content - different stuff someone could learn. The organization doesn't matter at first, because a new student doesn't have permission to access most of that content up front anyway (because there are dependencies and a new student hasn't satisfied any of them).

2. Place eligibility restrictions on the content. This is your dependency information. So if content C really shouldn't be tackled until competency has been demonstrated for content A and B, set that restriction. Likewise, track which competencies a student has already obtained.

3. Recommend content. For a particular user, first filter down content to only those modules a student is eligible for (based on dependencies fulfilled). You could then add in additional ranking mechanisms to select from what's left. Or you could just present students with options and let them choose.

4. Over a short period of time, you could then allow the structure of your learning map to emerge based on actual student navigation of the map. So modules D, E, and F might all be eligible after a student has demonstrated competency for module C, but you could find that students who do E next perform better than students who do D or F next. That means E should go after C - or even better, hedge your bets to get a Sankey type of path where E would have the thickest road and D and F would have relatively smaller roads.

This would allow the map to change over time as student behavior changes. Teachers could see dominant patterns, and see students who diverge from those patterns - perhaps indicating the need for differentiated learning. Students would also have a de-facto recommender system for learning objectives - they'd be able to see what paths other students had taken, allowing them to progress through their learning with more confidence.

I'm guessing you could probably find at least half a dozen beneficial second- and third-order effects from having a self-organizing learning map, but that requires you to separate the issue of dependencies out of the map itself. A dependency is nothing more than a tag you can attach to a piece of content. Users (students) can collect tags. That manages your dependencies.

Here's the more general takeaway for agentic learning:

A huge amount of the "structure" we think is necessary for good learning, good marketing, or good user engagement, actually does very little to facilitate learning, marketing, or engagement. The structure is a relic of an AI-less past where humans had to make more choices than they could realistically make, and therefore needed to impose semi-arbitrary structure in order to keep their heads above water. One of the most empowering aspects of using agents is that you can do away with most of that structure. Don't arbitrarily limit the audience eligible for any piece of content. Keep those constraints as wide-open as you possibly can, let the agents learn how to operate within that space (because that's what agents do), and then visualize what those agents are doing to learn more about the space yourself.

Some structure is necessary. But, having build agentic infrastructure for a while now, I've literally *never* seen a case where all the structure the human operators thought they needed was actually necessary. In most cases, they imposed anywhere from 2x to 10x too much structure.

Agents dynamically create structure. Don't tie their hands unless you absolutely need to.

𝐒𝐢𝐦𝐩𝐬𝐨𝐧’𝐬 𝐩𝐚𝐫𝐚𝐝𝐨𝐱 is not a school of media criticism about why the earlier seasons of the Simpsons are so superior to the later ones. 𝐈𝐭’𝐬 𝐭𝐡𝐞 𝐧𝐚𝐦𝐞 𝐨𝐟 𝐚 𝐩𝐡𝐞𝐧𝐨𝐦𝐞𝐧𝐨𝐧 𝐰𝐡𝐞𝐫𝐞 𝐭𝐡𝐞 𝐬𝐭𝐚𝐭𝐢𝐬𝐭𝐢𝐜𝐚𝐥 𝐭𝐞𝐧𝐝𝐞𝐧𝐜𝐢𝐞𝐬 𝐨𝐟 𝐭𝐡𝐞 𝐰𝐡𝐨𝐥𝐞 𝐝𝐨𝐧’𝐭 𝐥𝐨𝐨𝐤 𝐥𝐢𝐤𝐞 𝐭𝐡𝐞 𝐬𝐭𝐚𝐭𝐢𝐬𝐭𝐢𝐜𝐚𝐥 𝐭𝐞𝐧𝐝𝐞𝐧𝐜𝐢𝐞𝐬 𝐨𝐟 𝐭𝐡𝐞 𝐩𝐚𝐫𝐭𝐬. And sometimes it’s hard to spot.

I ran into it today when trying to gauge the performance of different message groups across two larger categories of messages. For the sake of anonymity, let’s say we launched messaging in two towns at the same time: Springfield and Shelbyville. The business (our customer) was interested in message-group-wise performance as well as the Springfield vs. Shelbyville comparison.

In the aggregate, Shelbyville has an advantage - you can see that in the bar chart on the left. But the story is different when you look at the performance of each individual message group (the figure on the right). For most messages, performance was better in Springfield than in Shelbyville. Why?

In discussions of Simpson’s paradox, reference is made to the “lurking variable,” which is just a menacing way to refer to a confounding variable that tells a different story than the aggregate.  Here, the “lurking variable” is which message group you’re talking about.

Take a look at the scatter plot on the right.  Each point represents an individual message group; the horizontal axis represents the message group’s performance in Springfield, and the vertical axis represents the message group’s performance in Shelbyville.  The diagonal represents what it would look like for a message group to have the exact same performance in both towns.

The first insight that pops out from this plot is that most of the points are to the lower-right of the diagonal.  In other words, 𝐦𝐨𝐬𝐭 𝐦𝐞𝐬𝐬𝐚𝐠𝐞 𝐠𝐫𝐨𝐮𝐩𝐬 𝐡𝐚𝐯𝐞 𝐚 𝐡𝐢𝐠𝐡𝐞𝐫 𝐩𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞 𝐢𝐧 𝐒𝐩𝐫𝐢𝐧𝐠𝐟𝐢𝐞𝐥𝐝 𝐭𝐡𝐚𝐧 𝐭𝐡𝐞𝐲 𝐝𝐨 𝐢𝐧 𝐒𝐡𝐞𝐥𝐛𝐲𝐯𝐢𝐥𝐥𝐞.

But there’s another thing represented in the scatter plot - the relative volume messages that went out for each message group, which is encoded in color.  A blue point represents a message group with low volume; a red point represents high volume.

And you can see pretty immediately there’s one bright red spot amid a sea of purple-ish blue ones.  𝐓𝐡𝐚𝐭’𝐬 𝐭𝐡𝐞 𝐡𝐢𝐠𝐡𝐞𝐬𝐭-𝐯𝐨𝐥𝐮𝐦𝐞 𝐦𝐞𝐬𝐬𝐚𝐠𝐞 𝐠𝐫𝐨𝐮𝐩, 𝐚𝐧𝐝 𝐢𝐭 𝐣𝐮𝐬𝐭 𝐡𝐚𝐩𝐩𝐞𝐧𝐬 𝐭𝐨 𝐛𝐞 𝐨𝐧 𝐭𝐡𝐞 𝐒𝐡𝐞𝐥𝐛𝐲𝐯𝐢𝐥𝐥𝐞 > 𝐒𝐩𝐫𝐢𝐧𝐠𝐟𝐢𝐞𝐥𝐝 𝐬𝐢𝐝𝐞 𝐨𝐟 𝐭𝐡𝐞 𝐠𝐫𝐚𝐩𝐡.

In other words, we’ve got one group that performs better in Shelbyville than it does in Springfield, and just because that group is way higher-volume than all the others, it shifts the whole average.  If you just look in aggregate, you might assume there’s something special about Shelbyville that makes it receptive to your offering.  But when you break it down by message group, that interpretation starts looking a little less compelling - maybe it’s really just something unique about that one group.  

𝐈𝐬 𝐢𝐭 𝐫𝐞𝐚𝐥𝐥𝐲 𝐬𝐚𝐟𝐞 𝐭𝐨 𝐬𝐚𝐲 𝐭𝐡𝐚𝐭 𝐭𝐡𝐞𝐲 𝐥𝐨𝐯𝐞 𝐲𝐨𝐮 𝐦𝐨𝐫𝐞 𝐢𝐧 𝐒𝐡𝐞𝐥𝐛𝐲𝐯𝐢𝐥𝐥𝐞 𝐭𝐡𝐚𝐧 𝐢𝐧 𝐒𝐩𝐫𝐢𝐧𝐠𝐟𝐢𝐞𝐥𝐝, 𝐣𝐮𝐬𝐭 𝐛𝐞𝐜𝐚𝐮𝐬𝐞 𝐚 𝐬𝐢𝐧𝐠𝐥𝐞 𝐡𝐢𝐠𝐡-𝐟𝐫𝐞𝐪𝐮𝐞𝐧𝐜𝐲 𝐦𝐞𝐬𝐬𝐚𝐠𝐞 𝐠𝐫𝐨𝐮𝐩 𝐡𝐚𝐩𝐩𝐞𝐧𝐬 𝐭𝐨 𝐚𝐩𝐩𝐞𝐚𝐥 𝐭𝐨 𝐒𝐡𝐞𝐥𝐛𝐲𝐯𝐢𝐥𝐥𝐢𝐚𝐧𝐬 𝐦𝐨𝐫𝐞?

Why does this matter? Well, we think about this kind of thing at Aampe a lot.  If you judge performance based on broad overall measures and miss a “lurking variable” that changes the story, you can end up making suboptimal decisions.

At the same time, it’s hard to figure out which variables matter. If you tried to be really comprehensive about figuring out what influences performance, the complexity could spiral out of control.

That’s exactly why you need an agentic platform like Aampe. Aampe’s core offering is a way to look at each of your unique users, figure out what they prefer, and design a user experience just for them - instead of what it looks like most users prefer (which could be misleading in aggregate). 𝐖𝐞 𝐝𝐨𝐧’𝐭 𝐦𝐚𝐤𝐞 𝐝𝐞𝐜𝐢𝐬𝐢𝐨𝐧𝐬 𝐛𝐚𝐬𝐞𝐝 𝐨𝐧 𝐭𝐡𝐞 𝐟𝐨𝐫𝐞𝐬𝐭 - 𝐰𝐞 𝐡𝐚𝐯𝐞 𝐚𝐧 𝐚𝐠𝐞𝐧𝐭 𝐟𝐨𝐫 𝐞𝐚𝐜𝐡 𝐭𝐫𝐞𝐞.

KEY POINTS

1. CMSs are often seen as repositories of content to present on webpages but they can be structured to use data for purposes beyond webpage display such as personalization, communication, and discovery. LLMs can significantly improve CMS data management.

2. There are opportunities in what you bring in and what you take out of the CMS. Information provided by vendors can be better used by turning it into structured data.

3. Generative AI can be leveraged to dynamically change the way content is displayed to users each time.

4. Cleaning your CMS can allow you to extract additional value from it. LLMs enable on-the-fly data cleaning and enhancement without the massive manual effort previously required. They can also analyze content tone, create detailed sub-categories, and generate descriptive tags. This data can power features like sophisticated filters and AI-driven personalization through agentic learning.

5. The alignment problem in AI is when there is a gap between user expectations and AI recommendations. The hardest part of aligning input to output in an LLM is getting the context right. 

6. In a CMS, an input is anything that resides in the CMS, such as item IDs, item names, and item descriptions. An output is information that is presented to the user.

7. LLMs work when choosing between a limited number of options. When there are hundreds of thousands of items, LLMs aren't able to sort through all of the information consistently and coherently.

8. LLMs can be used to clean your CMS data and to further personalize the presentation of information. They can extract tone, feel, and other metadata that enhance both recommendations and browsing experiences.

9. Lots of information can be pulled in from various sources to address the discovery problem, but it must be presented selectively. Companies that help users find relevant information quickly will retain users better than those who don't.

10. A/B testing tells you what works for the largest minority of users, so giving everyone that experience is a bad idea. We can use AI agents to learn recommender preferences and cater to the changing needs of each user, as they are scalable and can give each user the required attention.

CHAPTERS:

• 00:00 Introduction

• 01:22 Developments in CMS technology

• 03:45 Clean your CMS

• 07:34 Leveraging tags for recommendation

• 09:42 The alignment problem

• 14:53 Applications of LLMs

• 19:14 Data extraction capabilities of LLMs

• 25:29 Value propositions in food delivery

• 28:36 The potential of CMS

• 31:34 Integrating external data

• 33:45 Agentic applications in CMS

• 40:13 Inputs and outputs

  ---

Unlike what the name suggests, a self-driving car doesn’t drive itself but is driven by an agentic system that performs a series of interconnected and complex tasks based on real-time data. 

The terms “AI Agent” and “Agentic”, on the other hand, have only become popular in the last 12–18 months due to the general availability of Generative AI and the commodification of LLMs.

One reason agents and large language models (LLMs) have become inextricably linked is that prominent figures like Andrew Ng have only referenced the notion of agentic systems in the context of LLMs. LangChain’s Harrison Chase even defines an agent as “a system that uses an LLM to decide the control flow of an application”.

However, as “AI Agent” enters the mainstream, it’s important to highlight that not all agentic systems need to interact with an LLM—agents can also be powered by other AI technologies and methodologies such as computer vision and reinforcement learning. 

This is the first post in this series for semi-technical folks (like me) to gain foundational knowledge about this emergent tech that’s already changing how software and hardware are built and used. 

The goal of this post is to offer clear definitions and examples of various types of agents based on the inputs they work with and the outputs they produce.

Agent and Agentic Definitions

Let’s begin with the definitions.

To be an agent is to intentionally make things happen by one’s own actions.

Agentic is derived from the concept of agency in social sciences; it refers to a quality or state of being characterized by agency—the capacity to act independently, make choices, and exert influence on one's environment or circumstances.

I’d like to quote Schaun who offered much-needed clarity: “Every agent takes an input and produces an output. The input defines the context in which the agent is supposed to respond, and the output is the response itself. The agent is taught to recognize which responses are appropriate given which context.”

Keeping that in mind here’s how I’d define an agent: 

An agent is a software component that can learn to process an input and produce an output—autonomously, within specified boundaries. 

What does it mean to act autonomously? Well, given a certain input, an agent can inject variation or randomness in the output rather than produce the same output every time. 

In Schaun’s words, “For agents, inconsistent output or randomness is a feature whereas with traditional software it's a bug.”

Talking about the input, it can be text (as in the case of LLM-based or more broadly, language-based agents) but doesn’t have to be. 

To reiterate Schaun’s statement, “The input defines the context in which the agent is supposed to respond.” 

Therefore, if the input is, say, behavioral data (event data), the agent processing and acting upon the input doesn’t need to interact with an LLM to produce a personalized recommendation.

Instead, the agent can reference an inventory of pre-approved items that are properly tagged with information that enables the agent to pick an item—a product or a piece of content—that is likely to be relevant based on the input data.

Agent Inputs and Outputs

To work with a data set of any type, we must first know where the data originates. And we must know what types of data to expect to plan the next step.

Knowing the data type is particularly important when exploring an agentic system—because?

Because “the input defines the context in which the agent is supposed to respond.” 

Now let’s look at the various input types and outputs agents can create. 

Text as Input

Given a set of instructions along with specified parameters in natural language, a language-based agent can perform various tasks; here are some examples: 

• An agent can create and execute a workflow or send a series of predefined emails to users who meet certain criteria.

• An agent can perform some analysis on a given set of data and generate reports on a predefined schedule. 

The level of autonomy is subjective. In cases where the output is strictly based on a set of predefined rules, there’s no agent at work—the autonomy is stripped away when the system has to adhere to strictly defined rules. 

Audio as Input

My understanding is that there are two distinct types of agents that can work with audio inputs: 

1. Agents that simply execute the instructions, similar to how agents execute workflows based on natural language inputs. In essence, these agents are similar to those that work with text as input. 

2. Agents that perform workflows based on the metadata of the audio input. For example, an agent that’s supposed to first recognize a voice and then execute a workflow based on the result of the previous step. Or an agent that sends out alerts based on keywords or tone. Or one that analyzes audio to detect diseases.

Image and Video as Input

I’d like to list down some identifiable agentic workflows that process images and videos: 

• Perform an image search, find matching products, and offer recommendations by factoring in the user’s preferences

• Identify an object in a video feed, run it through algorithms to detect its authenticity, and create an authenticity score. 

• Recognize gestures and perform a workflow if the agent detects some form of threat. 

It’s worth mentioning that agents can also generate a visual or text output, but doing so is merely a step in an agentic workflow. 

Sensor Data as Input

Some examples of sensor data are location, temperature, and humidity (environmental) and heart rate, retinal scans, and glucose levels (biometric). Below are some agentic workflows based on sensor data as input:  

• Autonomous vehicles decide optimal routes using location and weather data

• A system sending alerts or shutting down the power grid based on seismographic data

• A smart health monitor notifies emergency services and shares the user’s real-time location based on a sudden spike in heart rate 

Behavioral Data as Input

The most common type of behavioral data is clickstream data from apps that’s stored as events. There are so many great use cases for agentic workflows that produce outputs based on behavioral data; here are some that come to mind: 

• Identifying at-risk customers based on their product usage and offering times to talk to their customer success manager 

• Detecting a fraudulent actor, interrupting a transaction, and sending out alerts in real-time

• Delivering a personalized message to a user via the channel with the highest propensity for engagement (email, push, in-app, etc) and at the time the user is likely to take action (based on past engagement behavior)

Evaluative vs. Generative Agency

As we were figuring out the best way to communicate the difference between LLM-based and behavior-based agents, Schaun came up with the idea of grouping agents based on the mode they operate in. 

An agentic system can operate in two different modes: Evaluative and Generative.

In the evaluative mode, an agent evaluates the input based on pre-learned patterns and representations—or everything the system already "knows". LLM-based agents like ChatGPT and Midjourney operate in the evaluative mode where context and queries reference that learned-in-the-past distillation of what the agent was trained on.

In the generative mode, an agent acts on an input and then revises what it already “knows” in light of the new information it receives based on the action. Aampe’s agents operate in this mode where the context and queries output new actions that change the learned representation itself.

Further, LLM-based agents are evaluative in general but are generative in individual sessions. That's why we can tell ChatGPT that it got something wrong based on which it tried to generate a new output. 

On the other hand, Aampe’s agents are generative in general but evaluative in individual sessions. The agents continue to revise their understanding but when it’s time to make a decision, they optimize the output by referencing what they already know.

To summarize, agentic systems can:  

1. Evaluate inputs given pre-learned representations (LLM-based)

2. Actively revise their learned representations given the success of outputs (Behavior-based)

It makes perfect sense to me now but when I first heard this delineation, I asked Schaun, “Isn’t it confusing for people to read that LLM-based agents are Evaluative rather than Generative?” 

Here’s what he said: 

"The irony is that Generative AI is generative only within-session. It grows and adapts as long as you're feeding in additional prompts, but as soon as you start a new session, it loses all of that growth. Generative AI can adapt in the short term but has no long-term memory unless you invest in constant fine-tuning, which nobody does."

Did you find my definition helpful? Have thoughts on how to improve it?

Share your thoughts on my definiton

KEY POINTS:

1. Decisions can be broken down into three components:

• The decision set (options of the decision)

• The outcome set (what happens based on decisions)

• The information set (data relevant to making decisions)

2. Decisions can be described to see how they can be handed to machines. This can be done based on criteria such as whether the decision is answer set constrained and the repeatability and frequency of the decision.

3. Recognizing which problems are constrained and repeatable can help leverage past experience to tackle them systematically and save a lot of time.

4. Identifying the information relevant to making a decision helps constrain the decision set.

5. Recommender Systems are well suited for large decision sets with thousands of options. They should share relevant information to learn about users while not overwhelming them. The way information is presented affects both user decisions and system learning.

6. In decision automation, humans are needed to provide context and business constraints, and design interfaces that capture meaningful signals from users. We can show AI agents how to make decisions like we do.

7. Challenges in Decision Automation:

• There's often a mismatch between available data and user preferences.

• Business problems often involve opinions rather than facts, making outcome evaluation difficult.

• Most software are built so that the burden of making something repeatable and learning from that repetition falls on humans. 

• When relevant information is not shared with users, it can make it difficult for agents to understand the information influencing users’ preferences and limit effectiveness.

  ---

CHAPTERS:

• 00:00 Machines and decisions

• 04:30 What is a decision?

• 06:32 Constrained, repeatable problems

• 08:00 Components of a decision

• 09:03 The answer set

• 12:00 Constrained resources

• 12:58 Repeatability and frequency

• 15:21 Delivering recommendations

• 16:55 Evaluating outcomes

• 19:44 LLMs making decisions

• 22:03 Facts and inference

• 24:13 Not just for users

• 27:14 The information set

• 28:33 How recommender systems evaluate answers

• 31:12 Relevant information and why we automate decisions

By the way, this video mentions a previous video on parameterizing beta distributions. You can find that here:

KEY POINTS: 

1. Identify the Problem: Recommender systems address the "discovery problem" by helping users sift through vast amounts of options to find relevant content quickly. Recognizing this problem is crucial before diving into solutions.

2. System Components: Recommender systems are complex and involve multiple components such as:

   • Item Inventory: Detailed metadata about items (e.g., descriptions, categories).

   • User Interaction History: Data on user interactions with items (e.g., views, purchases).

   • Recommendation Model: The core model that filters and ranks items based on user preferences.

   • The Learner: An important component, which trains the model and separates it from the model's deployment phase.

3. Build vs. Buy: Should one build a recommender system from scratch or use existing solutions? For many startups, buying an off-the-shelf system can be more practical due to advances in data infrastructure and the complexity of developing a bespoke system. Buying a system can also free up resources for other critical areas.

4. Practical Recommendations for Startups: Instead of getting bogged down by complex models initially, startups are encouraged to start with simpler models and leverage existing infrastructure to implement a functional recommender system.

5. Innovations in Recommender Systems: Schaun is interested in combining traditional methods with reinforcement learning to enhance system performance. DJ is excited about research addressing causal questions and handling sequential recommendations.

REFERENCES:

• "Are we really making progress?" This paper is a replication study on recommender algorithms and shows that many DL approaches couldn't be reproduced or could be beaten with linear methods.

• "Deep Exploration for Recommender Systems" This paper talks about sequential decisioning for RSs (where you consider more than just one item recommendation).

• "Two Decades of Recommender Systems at Amazon" This paper is a retrospective on what's work well at Amazon.

Over the weekend, I had some neighbors over for a barbecue. One of them works in computational fluid dynamics, and as we chatted about his work, something clicked with some refactoring we’ve conducted recently at Aampe.

He explained that in his field, the cost (both in computational complexity and actual dollars) of observing real-world fluid dynamics is so high that it's often more accurate to work with computational models rather than conduct physical tests. At first glance, this seems counterintuitive. Surely real-world experiments would yield more accurate data, right? Well, not exactly. The massive scale of fluid dynamics experiments makes gathering accurate data prohibitively expensive. Imagine the number of sensors you'd need to measure fluid impact on even a moderately sized surface. Now, think about the precision required in each of those sensors and the computational power needed to crunch all that data. You’d need a budget that even NASA might flinch at.

When we have a solid understanding of how a system works on a small scale, we can often extrapolate that understanding to larger scales or different scenarios—no expensive, full-scale experiment required.

This reminded me of a recent refactor we conducted on a portion of the Aampe codebase.

The Refactor: Aampe’s Personalization Map

In Aampe, users write messages that include placeholder sections we call Variants. Within each Variant, users can specify a number of Alternates. For instance, a user might create a "greeting" Variant with Alternates like "Welcome to the team!", "Welcome aboard," and "Welcome to the family." When Aampe’s Agents generate a message to send to a specific user, they select one Alternate per Variant to customize the message. Each Alternate is tagged with labels that describe its qualities. For example, the Alternates above might be labeled "Exciting," "Casual," and "Cozy."

Variants also have types indicating their purpose in the message. For example, the message above contains a Greeting Variant, but we also support other types like Call To Action, Value Proposition, Tone, and Offering (among others). Offerings are particularly core to Aampe messages, as they help drive user engagement. We combine Offerings with other variants to fully personalize each message.

Our Personalization Map feature allows users to see how much coverage different variant labels have relative to each Offering label. If Offering A performs well for a larger subset of users than Offering B, and Value Proposition A only ever appears alongside Offering B, then it will look like the value proposition performs poorly only because it was never given the chance to feature alongside the more popular offering. The Personalization Map lets you ensure that you have even coverage of labels across all offerings.

The Original Personalization Map

The software development adage “make it work, make it right, make it fast” applies especially in startups, where our goal is often to get a feature in front of customers quickly, so we can determine how much value it provides, before we start to optimize it. Such was the case with the Personalization Map, where our first pass at the calculation leaned more towards speed of development and developer comprehension than pure performance.

The original Personalization Map worked by taking all Variants and Alternates for a message, generating every possible combination, looking at the labels attached to each combination, and incrementing a count for relevant combinations. For example, if we were creating a map of Offering > Tone labels, and the full set of generated message combinations contained 3 instances where a message contained both a Tone Alternate labeled "Exciting" and an Offering Alternate labeled "Exclusivity," the resulting map would look like this:

This approach worked fine for messages with a relatively small number of possible combinations, but when customers started creating messages with millions or even tens of millions of combinations, the approach simply didn’t scale. The cost of producing and then observing the entire message set became too computationally expensive to be useful. Fortunately, we didn’t need to go to those lengths.

We already know the rules for how message sets are generated: select one Alternate per Variant and populate them within the message body. So, instead of generating and observing every possible message, we could predict the properties of those messages perfectly—without breaking the bank.

The New Personalization Map

Let’s look at a scenario to see how this plays out. Suppose we have the following message:

"Welcome to the team! We’re happy you joined. Check out the latest blog posts here."

In this message, the phrases correspond to the following types:

1. "Welcome to the team!" (Greeting)

2. "We’re happy to have you." (Tone)

3. "Check out the latest blog posts here." (Offering)

Each Variant has the following Alternates, with labels specified in parentheses:

1. "Welcome to the team!" (Familiarity), "Thanks for joining!" (Appreciation), "Welcome aboard!" (Casual)

2. "We’re happy to have you." (Happy), "It’s nice to meet you." (Polite), "Let’s get started." (Active)

3. "Check out the latest blog posts here." (Novelty), "Find your teammates here." (Connection), "Fill out your profile now." (Personal)

To calculate the Personalization Map for Offering and Greeting, we gather all the labels attached to the Greeting Variant within the message and their counts: Familiarity (1), Appreciation (1), Casual (1).

Next, we calculate how often each label will appear in the overall message set, expressed as a value from 0 to 1. We’ll call this value Coverage. It’s calculated by taking the count for each label and dividing it by the number of Alternates in the Variant: Familiarity (0.3333), Appreciation (0.3333), Casual (0.3333).

We do the same for each Offering label, which gives us these Coverage values: Novelty (0.3333), Connection (0.3333), Personal (0.3333).

For each combination of Offering and Greeting labels, the number of messages containing that combination is equal to the overall message count multiplied by Coverage for the Offering and Coverage for the Greeting. In other words: message_count * offering_coverage * greeting_coverage.

Since the overall message count for this message is 27 (3 Greetings x 3 Tones x 3 Offerings), the personalization map looks like this:

Not exactly edge-of-your-seat thrilling: everything is the same. Let’s spice things up by adding another Familiarity Alternate to the Greeting Variant:

"Welcome to the team!" (Familiarity), "Hello there!" (Familiarity), "Thanks for joining!" (Appreciation), "Welcome aboard!" (Casual)

Now, the values change to:

• message_count: 36

• familiarity_coverage: 0.5

• appreciation_coverage: 0.25

• casual_coverage: 0.25

The Coverage for Offering labels remains the same, so the map now looks like:

That makes sense. We’ve doubled the number of messages with the Familiarity label, while the counts for the other labels stay the same—even though their Coverage value has changed. This is because the total number of possible messages increased with the new Alternate.

Handling the Same Label Across Variants

Now, let’s complicate things a bit by adding another Greeting Variant:

1. "Welcome to the team!" (Greeting)

2. "Your account is set up." (Greeting)

3. "We’re happy to have you." (Tone)

4. "Check out the latest blog posts here." (Offering)

The alternates and labels for the new Greeting Variant are: "Your account is set up." (Efficiency), "Your teammates are waiting." (Urgency), and "Everything is ready for you." (Familiarity).

Now we’ll have messages where the same label is duplicated across two Variants. This is interesting because when we calculate Coverage for each Variant, we have to account for messages where the same label appears in both. For example, Familiarity has 0.5 Coverage in Variant 1 and 0.333 Coverage in Variant 2. We can’t just sum these values for the total Coverage because that would result in double-counting.

To avoid this, when calculating Coverage in Variant 2, we eliminate the Familiarity instances from Variant 1. We do this by multiplying the Coverage value for Variant 2 by the inverse of the Coverage for Variant 1. In this case, that gives us 0.333 * 0.5 = 0.166. When we add the Coverage for both variants together (0.5 + 0.166 = 0.666) and multiply that by the total number of messages, we get the correct value of 81 * 0.666 * 0.333 = 18.

The resulting personalization map looks like this:

Message-Level Labels

Let’s complicate things further by considering something we haven’t touched on yet: labels applied to an entire Message. When a label is applied at the Message level, every possible message combination uses that label. For example, if we applied a message-level "Casual" label to the scenario above, where the total message count is 81 (or 27 per Offering label), the resulting personalization map would look like this:

Performance Gains

So how much more efficient is the new approach? When the original implementation started succumbing to the scale of our customers’ data, our response time distribution looked like this:

Yes, the P90-99 values are in hours.

With the new implementation, the distribution looks like this:

Still not blazingly fast at the higher ranges. There are likely additional optimizations we can make for customers with large numbers of messages, since we run a calculation per message, but it’s now back in a decidedly usable range. The performance improvement works out to:

Wrapping It Up

So, what did my neighbor’s fluid dynamics lesson teach us? Just like in computational fluid dynamics, where observing every variable in a real-world experiment is impractical, we realized that we didn’t need to produce every possible message. Instead, we leveraged the underlying rules of message generation to predict the outcome. The result? A personalization map that’s more efficient, scalable, and ready to handle the growing complexity of our users' needs.

Next time you find yourself bogged down by the sheer volume of possibilities, remember: sometimes, it's not about observing every outcome but understanding the rules that generate them. And who knows, maybe a backyard barbecue can spark your next big breakthrough, too.

Originally posted on the Aampe blog.

It’s a frequent and regular opinion. A helpful way to evaluate a claim like this is to look at the alternatives, the competitors. What else might “change everything”?

Matthew Herper has a powerful view at STAT: "Why we’re not prepared for the next wave of biotech innovation":

🧫🧬😷🧪💉🧠

"It's biology's century...In the same way the 20th century belonged to physics, the 21st is biological. But while physics in the 20th century brought airplanes, personal computers, and posters of Albert Einstein, it also meant the atom bomb and a complete transformation of the social order."

What do you think? 🤔

Whatever your perspective on these 2 areas of innovation - genAI and biotech - they share a problem:

⚠️ 🚧

" ...the biggest looming problem is that we will simply become lost and confused as to what works and what doesn’t, scuttling our own progress, wasting money, and missing opportunities to save lives. That’s what happens when new technologies in biology outpace our ability to assess them."

The same goes for GenerativeAI. It's great that you can generate 1000s of unique images & text. But how do you know which person likes which image? The big datasets behind the Large Language Models have NOTHING to say about the specific customers your business serves.

Remember 'starving artists'?  👩‍🎨🤤

You used genAI to make an image YOU think is cool. There's no guarantee anyone else will like it. 

Getty Images already has >477 million assets. As a marketer, is it just the price that stops you from using those assets? Or is it that you simply have no way to operationalise which asset to use for which instance and marketing surface?

What's the answer to this looming problem? Matthew puts it simply:

"The core technology is not the drug molecule but randomization, randomly assigning patients to get one thing or another. This is the only way researchers can be sure that people who get the drug live longer, and the outcome is not due to chance."

"At some point, collecting data to determine whether or not treatments work...should not simply be the results of studies. It should be a property of a ... system. An ideal system would collect data — and perhaps even conduct randomized controlled trials of different treatments — almost automatically."

💯💯💯

"So why don’t we have such a system? Part of the answer is that it’s harder than it looks."

Matthew is entirely right: it IS harder than it looks. The standard CRM and CEM and CDP platforms just haven’t cracked what it takes.

That’s why we set out to build Aampe. Aampe’s agents do the hard work FOR your overworked tech teams. Aampe lets you generate 1000s of messages and unbounded content in any format, and then rapidly and efficiently randomizes their assignment to your individual customers to learn what works and what doesn't ... for every single customer.

With Aampe you get automated, statistical experiment design, at scale, with automated follow-through optimisation - ready to deploy in your app or website.

In both consumer tech and biotech, the innovation is just getting started. To achieve the kind of ambition we see so broadly today, we have to learn the limitations of our tools as quickly as possible, so that we can use them the right way, and extend and further develop them efficiently and effectively.

Citation

https://www.statnews.com/2022/11/03/why-were-not-prepared-for-next-wave-of-biotech-innovation/

🏛️⚖️📜

Here are some assumptions that everyone seems to share - one might even call them facts:

➡️ Businesses have to generate More Value for and from their customers (higher activation, higher engagement).

➡️ Businesses have to Spend Less to generate that value (lower CAC, less retargeting).

➡️ Competition for customer attention is fiercer than ever (discounts are a race to the bottom).

💡 The 3 points above make the 4th point obvious:

➡️ Businesses have to use their owned media/channels more effectively (effectiveness = revenue output, efficiency = effort input)

In other words: 

Razor Thin Margins that Only Work at Scale and which Assume Extremely Low Customer Acquisition Costs 

- is not a viable business model in 2024.

So far so good.

But Businesses are composed of parts, and those parts have to operate somewhat independently. 🗳️

A large business has multiple business and product verticals. For example, a commerce app has different category/product-line verticals.

The leadership of each part recognises the first 3 bullets above, and arrives at the 4th point: They need to use channels more.

This is where Governance becomes the problem.

🤔 😵

Your super app has a 🚗 ride-hailing team sending messages, and a 🥡 food delivery team sending messages, and a 💳 payments team sending messages.

They're all sending to the same users at the same time. 🚫🛑

Even if your app *only* does Food Delivery, you still have:

• a general marketing team sending notifications about vouchers & offers,

• a product team sending lifecycle messages about the customer's wishlist,

• a merchant partner team sending notifications on behalf of their restaurant partner,

• and on and on.

It's a mess. Every leader I speak with knows it's a mess. That's why Governance is at the top of everyone's Priority List.

🏁Coordination and Orchestration🏁

Here's the good news: You don't have to wade into a political war that will burn up a entire quarter of your financial year while you resolve it and arrive at some set of Rules that satisfy none of the teams and isn't followed anyway. 🗑️🔥👎

Instead, shift most of your tactical decisions to agents - agents like Aampe provides - and get Governance as a feature. 🤑📈🙌

Your app is like an economy with different Agents (teams) using Resources (your channels and offerings) to maximise their Value to the business.

You can decide whether you want your app to work more like a:

• Command Economy - enforce centralised rules about what message is sent when,

• Market Economy - revenue optimisation decides what message is sent when, or

• Mixed Economy - set guidance targets and then let the system manage traffic within those guide rails.

If Governance is on your mind, make it your mission to learn how Agents make Governance far more feasible than ever before. Better Governance can help you hit your business and marketing goals today.

Learn more about Aampe now

2 parts are especially good:

1) Dave:

 "Usually how it works …is people doing a lot of work. And so what often happens is, folks will come to us and say, “Look, I’m doing this activity over and over. I would really love some help to automate this process.” And so, in that case, they’re thrilled."

"They don’t want to be looking at some screen of data over and over and over again. They want to be doing something insightful and creative. And so that’s where we really partner with them and take off that component of what they do."

Great AI products are most reliably about relieving drudge work.

2) Dave:

“Some folks talk about AI in the pharma space being like, “I just want an algorithm that can predict, from the structure of a small molecule, the efficacy in humans,” like that’s the entire drug discovery process. That’s just not going to happen; that’s completely unrealistic."

"So we just think about the fact that there are countless processes, it’s a very complicated process to bring something to market, and there are just numerous opportunities along the way. Even within a specific use case, you’re rarely using one AI algorithm. It’s often, “For this part of the problem, I need to use this algorithm, and for this, I need to use another.”

Effective AI is not a model in a jupyter notebook. But it's also not even a model that's been "deployed to production".

Effective AI is Software, with all the necessary pains and joys of designing, implementing, maintaining, and regularly updating or even overhauling it.

Such a great episode!

Credible Communication

Communication is a huge part of how you build (or lose) credibility with your customers. If you talk to them about what they like, when they like, and in a way that they like, then you’ll build credibility. If you talk to them like you’re a marketing department and they’re just a source of revenue, then you’ll lose credibility.

Aampe uses a large message inventory as the starting point for what we call the Guess-Listen-Adapt Design (GLAD) of customer communication. Our infrastructure generates agents which bear the responsibility of managing all those messages and finding which users they’re best suited for. 

But for the sake of illustration, let’s assume a world where Aampe’s agents don’t exist: let’s assume you have no way of aligning your communication with customer’s individual preferences at scale. All you can do is send a message, and it’s a coin toss whether that message will build or lose credibility with each of your users. 

Random Walks

This results in what statisticians call a random walk. With each message, you either deposit one coin into your user’s credibility bank, or you withdraw a coin. As time goes on, your credibility “balance” for each user depends on how your latest message affected your credibility, and on how your credibility stood before that message.

We promised you pictures, so here you go:

This is the random walk: each blue line is a user, and every user starts at zero. With each new interaction, you gain or lose credibility. Notice what things look like by the end of all those interactions:

• You’ve built lots of credibility with a few users

• You’ve lost lots of credibility with some users

• A whole lot of users are still hovering right around zero, which means they’re still deciding how they feel about you. 

If your credibility with a user is below zero, you haven’t convinced them to do anything on your app that would provide value to you - they haven’t bought anything. The more credibility you have, the more they buy. (And remember, we’re pretending right now, just for the sake of illustration, that there’s no way to tilt the randomness in your favor…although that’s exactly what Aampe’s do).

The Absorbing Barrier: Your Credibility Ends with your Customers’ Patience

The problem with this random walk is that your users don’t let you run a deficit forever. Lose enough credibility, and they’ll take their attention and money elsewhere. 

This is what probabilists call an “absorbing barrier” (Google “gambler’s ruin problem” if you want to dive down that rabbit hole). Essentially, if a user hits the absorbing barrier, their walk stops - there’s no set of next steps in which you can gain back credibility…they’re just done with you.

This is what happens if you have an absorbing barrier:

The red lines show the random walks that got cutoff, because users simply stopped listening. The gray lines show how those random walks would have changed if they’d been allowed to continue. Notice that some of those gray lines rebounded quite a bit: there was value to be had there, but we lost it, because we hit the limit of our user’s patience.

When exploring a new app, the credibility balance each user holds for us has some degree of overdraft protection. You don’t need every message to be perfect. That being said, you can’t get it wrong too many times without getting it right just as often. If you lose enough credibility, you lose your user. 

The more you lose credibility, the more you lose value

The longer you can keep a user, the more credibility you can build with them, and the more opportunity they have to provide value to your business. If you have really patient users, then your random walk might look something like this:

You’ll recognize the random walk in the top image, but we’ve added a second picture on the bottom to summarize the total amount of “positive credibility balances” you have at any given moment in time. The blue line is what you would have seen if there had been no absorbing barrier - if every user had been infinitely patient. The gray line is what you actually get, given that some users drop you. There’s not much difference between the two lines. That’s because we set a ridiculously low absorbing boundary (in other words, we imagined that our users were ridiculously patient). Users, in general, are not patient. This is a more realistic scenario:

That’s a big gap. The less patient your users are, the less forgiving they are when you repeatedly lose credibility with them.

Message diversity protects you against credibility loss

Ok, so pictures are very pretty, but what do random walks and absorbing barriers have to do with having a large content library?

Nothing loses credibility with a user like messaging the same thing over and over and over again. It doesn’t take many messages that all say some thinly-disguised variation of “Act NOW to get 20% off!” before a user decides that you won’t ever have anything new to say to them. They’ll tune you out. And if they tune you out, you have no way to remind them of what you offer them. And if you can’t keep anywhere close to top of mind, then you’ve lost those users. 

There’s a lot of uncertainty in customer communication - you might message a user about the exact thing they want (gaining credibility), but at a terrible time for them to act on it (losing credibility). Figuring out the right message and right topic and right time for each user is hard (which is why we built Aampe to make it easy). Limiting yourself to just a handful of messages and recycling those messages over and over again is a sure-fire way to lose credibility. The greater the number of messages you can send at any given time, and the greater diversity of messages that quantity represents, the more likely you are to send each user a message that is different *enough* from what you sent them last time that it won’t automatically lose credibility.

Combine true personalization with message diversity to grow credibility (and value)

So now, let’s stop pretending that every message is a coin toss. Aampe’s agents match messages with user preferences to get users what they want when they want it. All of the random walks above assumed that each message had a 50% chance of adding credibility, and a 50% chance of subtracting credibility. Let’s keep the realistic absorbing barrier that we used in the last example, but let’s chance those probabilities just slightly: 55% chance of a message succeeding vs. 45% chance of it failing:

In the previous scenario (50% chance of message success), we ended up missing out on over 70% of our users’ credibility over time because we hit the absorbing boundary and users just stopped listening. In this very slightly improved scenario (55% chance of message success), we miss out on only 30% of our user’s credibility over time, and the amount of credibility we do succeed in stockpiling is 15 times higher than what it was under the 50-50 scenario. 

Having a large number of diverse messages hedges you against credibility bankruptcy. Combining that message inventory with even minimally-effective personalization puts you on track to not just keep your users, but actively engage them.

Product managers say stuff like: "Let's make our product so good that using it becomes a Habit for our users. Then we won't have to worry about retention."

Marketers say stuff like: "We have to keep running these discounts and vouchers or our CTR rates will drop and our growth will stall."

The paper "A Neuro-Autopilot Theory of Habit: Evidence from Canned Tuna" (with the neat dataset and use-case of the canned tuna market) illustrates the value of bringing the two perspectives together:

"Two modes of decision-making are proposed: a “habitual” mode in which the previous choice is automatically repeated, and a “model-based” mode in which utility is maximized using all available information. To arbitrate between these systems, the consumer learns utility predictions and tracks their reliability. The consumer enters a habit when outcomes are reliable (i.e. when choice outcomes match predictions) and exits habit mode when there is sufficient doubt about their utility predictions."

"Overall, we estimate that 12% of consumers are in a habit before the can size change, dropping to 10% during the can introduction, with roughly 17% of habitual consumers exiting a habit during the new can introduction."

Agentic AI - where agents are trained to model and evaluate precisely these kinds of factors in customer responses and decisions - offers teams the ability to evolve past dogmatic arguments between Habits and Incentives. Habits and Incentives can be integrated more fluidly and continuously through their interactions with your customers.

Citation

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4130496