The Case for Decision Context

In the months before we formulated BlueConic’s product vision, I talked to many of our customers to learn what’s top of mind for them. It’s no surprise that AI came up a lot in each conversation. However, what was interesting to me was that they all described wanting to be AI-pilled (my words, not theirs), but what held them back was not the availability of their data or their willingness to transform, but something very specific.

Here’s one example: a subscription business rich in first-party data, but running on a marketing stack they had outgrown. They had a perfectly good model flagging which subscribers were about to cancel. But what they couldn't do was act on those signals effectively. The cancellation signal lived in one system, the subscriber record in another, the email tool in a third, and the logic for what to actually offer them was missing. So the “rescue campaign” email went out a few days late with a standard discount. Even though the model worked, the systems underneath didn’t and as a result, the customer experience remained poor.

I heard a flavor of that in nearly every conversation. What I learned from those conversations is that intelligence isn’t the constraint. Anyone can call a capable model now, and these are improving rapidly. But if we’re going to build intelligent agents, they still need context: can you provide the models with the right information about a customer, the right information about the decision, and do it fast enough for it to act and learn?

That's one big reason why we acquired Blueshift. They had built the piece we were missing, and I'll come to what that is. But first, I want to share what we mean by context, because a lot has been said about it in our industry this year, and it’s not always clear what we mean by context.

What context actually means

In our view, there are two kinds of context when it comes to helping agents understand and act on marketing growth opportunities. 

The first is customer context. This is who the person is: their identity resolved across devices and channels, what they did in the last hour, what they've bought, what they've ignored, where they sit in their lifecycle. It's the profile, kept current and trustworthy enough that something can act on it. This is what BlueConic has been building for more than a dozen years: a place where a customer's data is unified, governed, and made dependable across the whole business, and not just one channel's narrow view of it.

The second is decision context. This is what to do about the person. What did we decide for them last time and why? What happened as a result? What are they eligible for now? What rules and guardrails should shape the next move? While customer context is the underlying substance, decision context is the judgment and memory that adds to what we know about someone. It’s what turns knowing about a person into doing the right thing for them.

Take that same churn prediction use case from earlier. Customer context tells the agent the subscriber's usage has dropped and renewal is three weeks out. The decision context says we already tried a discount in the spring, it didn't move her, she isn't price-sensitive, so don't send money, send the feature she's never turned on. If we ignore the decision context, the agent just keeps discounting, because the data says she's at risk and a discount is the obvious lever. The agent can only be as intelligent as the context it can see.

Most platforms, at least from the erstwhile CDP category, have some version of the first. The second, as something an agent can actually call on, is something we didn't see anyone building.

A different read on composable

Before I get to how we're filling that gap, a word on how we got here, because it’s different from where many players in the industry are heading.

The composable conversation in our industry is mostly about storage. Instead of storing your data in the CDP vendor’s database, keep it in your own cloud data warehouse and assemble the pieces yourself. There are good reasons for this shift, and we support it. But it's a technical definition of composable. It doesn't do much for the marketer who just wants an outcome.

Our version is composable by outcome. We took the old all-or-nothing CDP—the eighteen-month implementation, the ROI few could justify, the unification project that became another silo—and broke it into bite sized use case implementations that we call Growth Plays. Each growth play does a single job, proves its lift, and earns the next. You turn on a play, watch it achieve growth outcomes, and add the one after it. To us, that’s real composability, because it's measured in outcomes a marketer can name, and not components an engineer has to stitch together.

And of course, as we’ve built these Growth Plays, we’ve been making them agentic. But what it takes for those plays to be truly agentic is what forced the context question. An agent running a growth play is only as good as the context behind it. And that's where we ran into the gap.

Why Blueshift

That gap is what Blueshift had already built. What was missing was a system that decides for itself what to do for each person, measured against an outcome and willing to do nothing when nothing is the right call. That's what Blueshift brings: a production decisioning engine, along with owned channels including email, SMS, and push notifications to act on what it decides.

It also matters now because of where we believe the market is heading. Much of what the industry calls agentic marketing still leaves the marketer doing the real work. It scores a list, recommends a send time, drafts multiple subject lines for a human to pick from. That’s useful, but a person still designs the journey and the AI helps at the edges. We believe that, more and more, the primary constituent on the other end of our platform won't be a marketer clicking through a campaign builder. It will be an agent acting on the brand's behalf, deciding and executing without a human staging every step. An agent like that can't lean on a human to make the call. It needs decision context it can act on directly.

The other reason owning both halves matters is the closed loop. When deciding and the acting sit in separate systems you don't own, the loop runs too slowly and has too many gaps for an agent to learn from what it just did. By the time the outcome comes back, it’s too late. Owning enough of that loop is what lets the agent get better. That’s where Blueshift fits really well.

Where context lives

There’s another question that comes up a lot: in an agentic world, where does context actually live?

Most of the people I talked to or learned from answered with a location. It could live in the model's memory. It could live in the data warehouse. But we don’t think context should be pinned to any single location. The data itself can be stored wherever latency and governance call for it: in our real-time store when a decision has to happen in the moment, or in the customer's own cloud data warehouse when it doesn't. What matters is that the context layer sits above all of it and remains callable, by us or by any agent, regardless of where the underlying data rests. 

That subscription business failed for exactly the opposite reason: their context was trapped in separate systems, and no one could reach it when it counted. They had a model that knew exactly who was about to leave. They just couldn't do anything with it in time. 

I think we’re going to see more and more versions of that story over the next few years. The models will keep getting better, but they’ll still need the right context to make good decisions. That's the problem we want to solve, and it's why I’m so excited about what Blueshift lets us accelerate.