Analytics engineering is evolving into context engineering. Here's what that shift means for CEP strategy, agentic AI, and real-time engagement in Southeast Asia.
Most customer engagement platforms are sitting on a structural lie. The data is there. The channels are connected. The automation is live. And yet the messages going out still feel like they were written by someone who met the customer once, three months ago, and is working from notes.
The problem isn’t the platform. It’s what we’re feeding it.
The Shift from Data Modeling to Context Modeling
Getdbt’s Britton Stamper recently made a quiet but significant argument: the analytics engineer role is evolving into something new — the context engineer. The distinction matters. Analytics engineering has historically meant modeling data for dashboards — clean tables, reliable metrics, a source of truth that humans query. Context engineering means modeling data for agents — structuring information so that an AI system can act on it, right now, in the middle of a customer interaction.
This reframe has direct implications for how CEP teams should think about their data layer. A CRM enriched for reporting looks very different from a CRM enriched for real-time decision-making. The former needs historical accuracy. The latter needs recency, relevance, and retrievability. If your data team is still primarily optimizing for the dashboard, your engagement platform is flying partially blind — even if the dashboards look great.
For Southeast Asian markets specifically, where a customer might browse on a Shopee app, ask a LINE chatbot a question, and convert via a Grab Pay promotion in the same afternoon, that context modeling challenge is compounded by cross-platform fragmentation. The signals exist. Stitching them into a coherent, actionable customer context is the actual hard work.
RAG vs Agentic AI: Knowing Which Tool You’re Actually Deploying
Monte Carlo’s breakdown of RAG versus agentic AI is one of those pieces that cuts through a lot of vendor noise. The short version: RAG (retrieval-augmented generation) makes a model smarter about a single question by pulling in relevant external data before it responds. Agentic AI gives a model the ability to plan, execute multiple steps, use tools, and loop until a task is done.
In CEP terms: RAG is what powers a chatbot that can answer a nuanced product question by retrieving the right knowledge base entry. Agentic AI is what powers a system that can notice a cart abandonment, check inventory, assess the customer’s price sensitivity based on historical behaviour, trigger a personalised offer, wait for a response, and escalate to a human agent if the window closes — without anyone pressing a button.
The mistake most brands make is assuming they’re deploying agentic capability when they’ve actually wired together a few RAG calls and some if/then logic. These aren’t equivalent. Agentic systems require a fundamentally different data architecture — one where context is continuously updated, retrievable at millisecond speed, and structured in ways that an orchestrator can reason about. Most data warehouses aren’t built for this. Most marketing clouds aren’t either, yet.
What ‘Real-Time’ Actually Requires at the Data Layer
Here’s the uncomfortable truth about real-time engagement: it’s less a technology problem than a data preparation problem. The platforms can move fast. The question is whether the context they’re acting on is stale.
A practical way to stress-test this: pick your most important customer segment and trace exactly what data points your CEP uses to decide the next best action. Then ask when each of those data points was last updated. In most setups, the answer involves some combination of nightly batch jobs, weekly syncs, and event streams that are technically real-time but practically inconsistent.
Context engineering addresses this by treating customer context as a living object — something that’s continuously written to as signals come in, not periodically reconciled. In practice, this means investing in event streaming infrastructure (Kafka or equivalent), maintaining feature stores that blend historical attributes with real-time signals, and — critically — deciding which context attributes actually need to be real-time versus which ones are stable enough to batch. Not everything needs to move at the speed of a click event. But some things absolutely do, and right now most teams haven’t made that distinction deliberately.
For teams managing multilingual audiences across Malaysia, Thailand, Indonesia, and the Philippines, context modeling also needs to account for language preference as a live signal, not a static field. A customer who switches between English and Bahasa across touchpoints is telling you something. Whether your system is listening is a data architecture question.
The Stakeholder Conversation Nobody Wants to Have
Shifting from analytics engineering to context engineering isn’t just a technical retooling — it’s a resourcing and mandate conversation. Data teams have historically been accountable to reporting accuracy and dashboard uptime. Context engineering makes them accountable to engagement performance: did the right customer get the right message at the right moment? That’s a different kind of ownership, and it requires alignment with marketing and product in ways that most data teams haven’t been asked to sustain.
The practical path forward isn’t a wholesale transformation. It’s starting with one high-value journey — say, post-purchase re-engagement or churn prevention — and rebuilding the data layer beneath it to support genuine context modeling. Instrument the right events. Build the feature store for that journey. Connect it to the CEP with sub-second latency. Measure engagement lift. Then expand.
The brands that get this right won’t just have faster automation. They’ll have engagement that actually feels like it understands the customer — which, in markets as competitive as Southeast Asia’s, is increasingly the only kind that earns a response.
Key Takeaways
- Redefine your data team’s mandate: modeling context for agents is a different skill set from modeling data for dashboards, and the gap matters for CEP performance.
- Before investing in agentic AI capabilities, audit your data architecture for recency and retrievability — most platforms can move fast, but stale context makes speed irrelevant.
- Start the context engineering shift on one high-value customer journey, prove lift, then scale — don’t try to rebuild the entire data layer at once.
The real question for growth and data leads heading into 2027 isn’t which engagement platform to pick — most of the mature options are good enough. It’s whether the data layer beneath the platform is being actively engineered to serve agents, not just analysts. The teams that answer yes will run circles around those still optimizing for the dashboard. Which layer are you actually investing in right now?
At grzzly, we work with marketing and data teams across Southeast Asia to design CEP frameworks where the data architecture and the engagement logic are built together — not bolted together after the fact. If your real-time engagement isn’t performing the way the platform vendor promised, the answer is usually upstream. Let’s talk
Sources
Written by
Brooding GrizzlyDesigning CEP frameworks that move beyond batch-and-blast into real-time, context-aware engagement — across channels, devices, and the messiness of actual human behaviour.