Where Context Lives

Key takeaways

• The AI era isn't changing whether marketers need context. It's changing what kind of context agents need to make good decisions.
• Decision context is what transforms customer data into next best actions, connecting customer signals, business rules, and real-time outcomes.
• The most effective AI architectures create continuous learning loops between customer interactions, decisioning, and execution.

‍

A few weeks ago I wrote about decision context in the wake of BlueConic’s acquisition of Blueshift. Since then, the conversation has moved quickly.

Databricks entered the CDP market with an agentic CDP of their own. Their leaders made an argument similar to the one I made in my post: agents need real-time customer and decision signals to operate, and the platforms marketers run on today were not built to provide them. We agree with that diagnosis. Where we differ is in the answer to the question I raised: where does context live? That difference is worth unpacking, because it determines the architecture each brand ultimately needs.

What Databricks got right

There's a lot in their framing I agree with. Agents are becoming the primary operators of marketing systems, not assistants to them. The campaign calendar is giving way to a continuous loop where the system analyzes, decides, and acts on behalf of every customer. And the distinction they draw between customer signals and decision signals aligns closely with the two kinds of context I described in my earlier post.

Where we differ

Databricks argues that context lives in the lakehouse, alongside the data, models, and agents. Our view is different. We don’t believe that context should be tied to any one particular location at all.

The strongest case for putting context in the lakehouse is speed, and Databricks has solved that problem very well. Their new real-time engine queries governed data at millisecond latency, at high concurrency, and they are right that agents need that. If the only question were how fast an agent can look something up, the lakehouse would be a complete answer.

But an agent's loop has four parts, and lookup is only one of them. Context gets created when a customer (or, increasingly, that customer’s AI agent) interacts with the brand. It gets read when an agent (acting on behalf of the marketer) decides what should happen next. It gets acted on when that decision reaches the customer. And it becomes richer when the outcome feeds the next decision. 

A lakehouse-native architecture owns the middle of that loop: storage and decisioning on governed data. At both ends, where customers actually interact with the brand, it relies on partner systems. Behavioral capture comes from event vendors. Execution runs through the marketing clouds and ESPs. Their own launch customers describe the pattern: build the audience in Databricks, activate through Adobe. 

The decision is fast. The action, however, happens in another system, and the outcome has to cross that boundary before it can inform the next decision. In other words, the read has been accelerated, but the loop itself has not.

BlueConic owns both ends of that loop. This is by design. A couple of years ago, we acquired Jebbit, which became our Experiences product. And with our recent acquisition of Blueshift, we completed the picture. 

On the front end, Experiences turn anonymous sessions into consented profiles with declared intent, in real time, in the session where it happens. Most ecommerce traffic is anonymous until checkout, which means the richest moments in a customer relationship rarely reach any warehouse in usable form. A quiz completion is not an insignificant behavioral data point. It’s a customer explicitly telling a brand what they want, and it becomes part of the customer profile as soon as the interaction ends. On the back end, Blueshift brings decisioning and execution into the same system, so an agent learns from what it just did while the moment still matters.

That architecture rests on two assumptions. Whether those assumptions hold is what determines which approach is right for a given brand.

The first assumption: the data problem is already solved

A lakehouse-native architecture starts after data is aggregated in one place. It assumes the governed foundation is stood up and there's a team operating it. For a Fortune 500 company operating a mature lakehouse, that’s a reasonable assumption and a compelling model.

Many of the companies I talk to, however, are not there, and it’s not for lack of trying. We recently spoke with a DTC brand sitting on tens of thousands of quiz completions full of declared intent, while their Meta campaigns continued paying to acquire the same shoppers the quizzes already identified. 

Another brand told us their non-converting visitors exist only as page views in their analytics tool. Every shopper who doesn’t convert today is invisible tomorrow, forcing the company to pay to re-acquire people they already met. 

A subscription food company described the window between deliveries as the weakest link in their retention program, because the signals that predict a cancellation live in three systems that never talk within that window.

None of these companies needs a multi-year data foundation project before an agent can do something useful for them. They need the loop closed on the data they already have, wherever that data happens to live. That’s what our Growth Plays are designed for: getting a first use case live in weeks, with a measured outcome inside a quarter, and expanding from one proven outcome to the next. They don’t wait for the perfect data foundation. They work with the data where it’s already available.

The second assumption: deciding and acting can live in different hands

When a brand wants to send a customer email using Databricks CustomerLake, it has to connect to a partner ESP. This is a deliberate choice on their part, and it makes sense as Databricks is positioning themselves as the neutral foundation other products activate from. Owning execution would mean competing with the partners their ecosystem depends on. 

But every architectural decision has consequences. Separating decisioning from execution introduces a handoff and that handoff is where learning slows down.

We made the opposite choice, and it’s a large part of why we acquired Blueshift. When  deciding and acting are interconnected, an agent learns from what it just did while the moment still matters. The next decision is shaped by the last outcome, and is not delayed until the connected system returns the outcome data.

Speed isn’t the only thing that matters to that handoff. Governance does too. Data governance answers questions about tables: who can query what, where it came from, how it flows. Decision governance answers questions about people: what this specific person consented to, for which purpose, what they are eligible for, how often they can be contacted, and when a human needs to review an automated decision. 

The first is the responsibility of the data platform, and Databricks does that well. 

The second is decision context, and it’s where agents most often fail in production. Sinch surveyed 2,527 senior decision makers this spring and found that 74% of enterprises have already rolled back an AI customer communications agent after deployment because of a governance failure. Those are failures at the decision level, not the data level: agents acting without the memory or guardrails decision context provides, and learning too slowly to correct course.

We’ve been building consent and eligibility directly into the customer profile since GDPR made it existential for our European customers. And with the EU AI Act now introducing additional oversight requirements for automated decisions about individuals, that discipline becomes even more important if agents are going to improve safely and responsibly.

What we are optimizing for

We’re optimizing for the company that has the data problem and cannot hire its way out of it, and for a loop fast enough that the agents learn. We’re deliberately not competing to be the enterprise data foundation. If a brand already runs its business on a mature lakehouse, that architecture may serve it well, and in our model the data can even stay there. The context layer above it is the part we are building, and it works whether the data lives in a lakehouse or not.

Ultimately, the debate about where context lives is actually a debate about what agents need in order to work. There are two answers that are now on the table. Databricks believes context belongs inside the data platform. We believe it belongs above the storage layer, close to where context is created and where decisions show up, in a loop tight enough to learn from.

‍

Frequently asked questions

What is decision context?

Decision context is the information an AI agent needs to determine the next best action for an individual customer. It includes customer behavior, consent, eligibility, business rules, communication history, and recent outcomes, not just profile data.

How is decision context different from customer context?

Customer context describes who a customer is and what they have done. Decision context adds the information required to determine what should happen next, including governance, business constraints, and previous decisions.

Why does decision context matter for agentic marketing?

As AI agents take on more marketing decisions, success depends on more than access to customer data. Agents also need the business context to decide what action is appropriate, execute that action, and learn from the outcome. Decision context provides the connective layer that enables continuous optimization rather than isolated automation.

Can AI decisioning work with a cloud data warehouse or lakehouse?

Yes. Modern AI decisioning platforms can work alongside cloud data warehouses and lakehouses. The key architectural question is whether decisioning and execution remain closely connected so customer outcomes can continuously improve future decisions.