![\"The](\"https:\/\/chiefmartec.com\/wp-content\/uploads\/2025\/02\/systems-of-context-systems-of-truth-key.png\")
<\/a><\/figure>\nFor years, martech was divided into systems of record<\/strong> and systems of engagement<\/strong>.<\/p>\n Systems of record stored the \u201cmaster\u201d versions of data. CRMs and CDPs for customer data. PIM for product data. DAM for brand assets. ERP for inventory data. (I know, there\u2019s a ton of acronyms in this piece, almost to the point of parody. Click on the image above for a larger-scale version to read the Acronymn Decoder Ring on the right.)<\/p>\n Systems of engagement interacted with customers, either directly with tools such as MAP-delivered email or DXP-delivered web experiences or indirectly with tools such as SFA supporting sales teams who engaged with customers.<\/p>\n In reality though, this division wasn\u2019t quite as clean. For instance, CRMs and CDPs often blended data management and customer engagement functionality. But as a way of talking about different martech categories and their roles in a tech stack, it sufficed.<\/p>\n But I don\u2019t think it\u2019s the right mental model anymore.<\/p>\n With the AI revolution sweeping everything in marketing and technology, I believe a better framing is systems of context<\/strong> and systems of truth<\/strong>.<\/p>\n Now, squinting at my diagram you might ask, \u201cIsn\u2019t this just systems of engagement and systems of record with different labels?\u201d They\u2019re similar, yes. Both roughly delineate a layer of data and a layer of services. But here\u2019s why they\u2019re different.<\/p>\n First, at the data layer, systems of record historically combined responsibilities for both storage and arbitration of data. Each system of record had its own database that was tightly coupled with business logic to determine what could be written to or read from that database and in what format.<\/p>\n In the model I\u2019ve sketched here, the systems of truth<\/strong> section of the stack acknowledges that these concerns of storage and arbitration have now been separated, thanks to the rise of the cloud data warehouse\/lakehouse.<\/p>\n Cloud data warehouses\/lakehouses store and distribute data across the organization. But the very strength of this universal data layer \u2014 that it can house any and all data flowing across the organization \u2014 is also its weakness. Data flooding through it isn\u2019t necessarily standardized or rationalized across all its various sources and destinations. Conflict and contention can run rampant.<\/p>\n You still need software to arbitrate what is correct and canonical data, governing how it gets written or read, in what format, validated with standard definitions and relevant business logic. With something as important and complex as master customer records \u2014 what is traditionally stored in a CRM \u2014 such arbitration and governance is non-trivial and mission-critical.<\/p>\n This is why many \u201cclassic\u201d martech systems of record \u2014 CRM, MDM, PIM, DAM, etc. \u2014 still play an important role in the cloud data warehouse\/lakehouse era: they remain the arbiters of truth for data within their domain. Even if their data is increasingly stored in an independent layer further down.<\/p>\n Will there be a new generation of such data arbiter platforms? Or will the current leading platforms of today evolve to adapt to this new environment? Probably both. <\/p>\n These classic martech data platforms also provide useful contextualization<\/em> of data. For instance, combining a list of customers with a set of advertising audience segments creates a context<\/em> for that customer data within a specific marketing campaign. This is exemplified with composable CDPs. They work directly with the data stored in a cloud data warehouse, but they organize and manage that data for a wide variety of different contexts in which marketers want to use it.<\/p>\n In fact, a composable CDP is arguably more system of context<\/em> than system of truth.<\/p>\n (If the word \u201ctruth\u201d bothers you for philosophical reasons, and you\u2019d prefer we change it to something else, sorry, we Kant.)<\/p>\n We never achieved a true single<\/em> system of truth (SSOT). Turns out there are just too many domain-specific data truths. But with a universal data layer on bottom and domain-specific data governance platforms on top, we now have many systems \u2014\u00a0plural<\/em> \u2014 of truth.<\/p>\n So what makes systems of context<\/strong> different from systems of engagement?<\/p>\n Systems of engagement have been relatively \u201cfixed\u201d in the context they provided. For instance, with MAP and CEP platforms, you learned how to use them, often adapting the way you work to their structures and processes. When you built a website on a DXP, the experience customers received was the context you had mind for them when you designed it. It\u2019s not really their context. It\u2019s the context you think<\/em> they have.<\/p>\n With the rise of AI agents, both employee-facing and customer-facing, context is being created more dynamically. Many AI agents can be spun up, each tailored to a specific task or workflow for an employee or hyper-personalized for a specific customer\u2019s experience.<\/p>\n Systems of context differ from systems of engagement quantitatively<\/em> \u2014 increasingly, there are more AI agents proliferating across the stack than traditional SaaS platforms \u2014 and qualitatively<\/em> because they\u2019re purpose-fit for much more specialized contexts.<\/p>\n The extreme incarnation of this is individual AI agents that create software experiences on-the-fly for each employee or customer, for whatever job-to-be-done they want completed at that moment. This is what we described as the new \u201chypertail\u201d of martech software \u2014 in aggregrate, billions of software apps created on-demand by AI \u2014 in our Martech for 2025<\/strong><\/a> report a couple of months ago.<\/p>\n Dynamically-generated customer-facing AI agents, which we\u2019ll call concierge AI agents<\/em>, will deliver much more contextually relevant experiences to those users. They\u2019ll listen to exactly what the customer wants, and informed by all existing customer and company data in our systems of truth, deliver exactly the content and services the customer wants in that exchage.<\/p>\n Instead of a monologue, where a brand serves a contextual experience based on its own definition of the buyer\u2019s journey and what it thinks<\/em> the buyer wants, concierge AI agents will engage buyers in a true dialogue<\/em> to understand and serve their actual context.<\/p>\n A little farther out on the horizon \u2014 but maybe not that far \u2014 buyers will use their own AI agents to interact with our systems of context. These aren\u2019t customer-facing AI agents that sellers control. These are customer-owned<\/em> AI agents that they<\/em> control. They will inherently shape the experience to the context of the buyer.<\/p>\n Two more points:<\/p>\n First, in the stack schematic at the top of this post, I included a whole bunch of different martech product acronyms. I\u2019m not saying that every stack needs all of these. Unless you are at a large enterprise, you probably only have, need, or want a subset. I only included a bunch to show where I thought these different categories fit in this architecture. It is also by no means comprehensive.<\/p>\n Second, illustrating this as a stack \u2014 components neatly packed together, stacked on top of each other like perfectly fitting Lego blocks \u2014 isn\u2019t a really accurate representation of reality.<\/p>\n The stack view is easier to understand \u2014 at least I think so, given that\u2019s how we\u2019ve thought about martech stacks for so long.<\/p>\n But a more accurate representation would be a graph view. All of these different products and platforms, and all these different apps, agents, and automations, are all nodes in the cloud that connect with any of the others. I still think of systems of truth at the center of this cloud, surrounded by many systems of context.<\/p>\n In summary, yes, we still have records, and we still have engagement.<\/p>\n But the defining characteristic of the martech \u201cstack\u201d in an AI world is going to be context<\/em> and the truth<\/em> it\u2019s wrapped around.<\/p>\n P.S. Speaking of martech stacks, we hope you\u2019ll consider sending in a slide illustration of yours for our 2025 Stackie Awards<\/strong><\/a>. It\u2019s seriously one of the most fun awards programs in all of marketing \u2014 admittedly in my highly biased opinion. But there\u2019s no fee to enter, and in fact, we donate $100 to UNICEF for every legit entry, up to $10,000 total. Deadline to enter is April 4.<\/p>\n Subscribe to my newsletter to get the latest insights on martech as soon as they hit the wire. I usually publish an article every week or two \u2014 aiming for quality over quantity.<\/p>\n<\/div>\n<\/div><\/div>\n<\/p><\/div>\n\n","protected":false},"excerpt":{"rendered":" For years, martech was divided into systems of record and systems of engagement. Systems of record stored the \u201cmaster\u201d versions of data. CRMs and CDPs for customer data. PIM for product data. DAM for brand assets. ERP for inventory data. (I know, there\u2019s a ton of acronyms in this piece, almost to the point of […]<\/p>\n","protected":false},"author":1,"featured_media":106643,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[98],"tags":[3576,25217,8402,11355,23265,5477],"dealstore":[],"offerexpiration":[],"class_list":["post-106640","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-marketing","tag-chief","tag-context","tag-marketing","tag-systems","tag-technologist","tag-truth"],"yoast_head":"\n<\/a><\/figure>\n<\/a><\/figure>\n<\/a><\/figure>\n<\/a><\/figure>\n<\/a><\/figure>\n<\/a><\/figure>\nGet chiefmartec.com directly in your inbox!<\/h3>\n