Context layer: giving an agentic CDP the business context it needs

Your AI agent can read your orders, CRM records and campaign history. Ask it to identify high-value customers and it adds up their purchases. The calculation includes cancelled orders and overlooks refunds. It is consistent with the tables it queried, but it does not match the way your business measures customer value...

👉 That is where a context layer comes in.

A context layer makes those business definitions available to agents, alongside the information needed to apply them. Within an agentic CDP, it helps connect customer data, marketing objectives and the conditions governing the use of operational tools.

Key takeaways

The term describes an architectural function whose scope varies between implementations. It does not require a particular database or necessarily mean buying another product. Some of the required context may already exist in your data models, catalogue or CDP.

A context layer should bring together semantic definitions, lineage, ownership and access policies. For a marketing team, the practical test is whether an agent can find the agreed definition, apply it to the appropriate data and use it for the intended operation.

A context layer is different from a model’s context window. The window holds the information actually passed to the LLM during processing. The layer organises resources from which that information can be selected.

An order record tells an agent that a transaction took place. It may not establish whether marketing should count that order towards customer value. Status changes, later returns and account relationships can all affect the interpretation.

Three gaps commonly separate accessible data from an actionable decision.

A detailed prompt can help during an initial trial. However, if every team copies its rules into separate conversations, those rules can drift apart. A context layer makes knowledge reusable, with an identifiable owner and authoritative source.

Document the concepts that materially change a selection: eligible purchase, net revenue, loyal customer, churn risk or customer value. Connect each definition to the fields, filters and time periods needed to calculate it.

For instance, a twelve-month value measure needs a policy for returns, currency and eligible orders. A prediction of future value should be distinguishable from historical spending, with its calculation date and prediction horizon available for review.

An agent needs to understand the entities it is working with: individuals, accounts, households, orders, subscriptions and products. A B2B contact may belong to an account with several users. An account-level decision does not automatically apply to every person within it.

Include the signals relevant to the use case, such as the latest purchase, subscription status, recent interactions, preferences and unresolved service issues. Identity matching rules need to be explicit rather than leaving the model to guess whether two profiles describe the same person.

Specify the intended outcome, available actions and constraints. A reactivation initiative might prioritise margin, restrict discounts or reserve certain customers for an adviser’s attention.

Separate a preference, which can inform a recommendation, from a prohibition, which must be enforced by the execution system. Writing a rule in a document does not create an access control.

Retain the source, owner, update time and limitations of information that affects the decision. A weekly score and a recent order event have different useful lifetimes.

Define which source takes precedence when definitions conflict. If the authoritative information is unavailable or too old for the intended action, the agent should expose that limitation rather than fill the gap with an assumption.

These concepts address complementary needs. They do not necessarily require separate products or deployment projects.

Semantic layers can already serve AI agents, for example by making shared metrics available to AI tools. A semantic layer can therefore contribute to a context layer; the distinction depends on the capabilities each implementation covers.

RAG can retrieve text and other relevant information. Retrieval alone does not establish that a rule remains valid or that an action is permitted. An MCP connection provides access to tools: the protocol does not create business definitions or replace their governance.

A graph may make relationships easier to explore, but it is not essential to every first implementation. The initial priority is to make useful knowledge accessible and reviewable, wherever it is stored.

A knowledge graph represents entities and their relationships. For our retailer, a knowledge graph could connect a customer to orders, each order to purchased products and each product to a category. An ontology defines the entity types and permitted relationships: an order belongs to a customer; a product belongs to a category.

The graph can also connect a metric to its definition and owner. That makes it possible to follow a relationship from a marketing selection to the data and knowledge supporting it. This is useful when a user asks why a customer qualified rather than simply requesting an audience total.

A context graph may use this representation to make relevant relationships available to an agent. Some implementations also record decision history. Neither the graph label nor the presence of an ontology establishes that the knowledge is correct. Teams still need to check which relationships exist, where they came from and whether the graph reflects current systems.

For a CDP, the design should follow the decision being supported. There is little value in building an enterprise knowledge graph of every available entity when the immediate task only needs customer, order and suppression relationships.

Vector search retrieves information according to semantic similarity. It can help an agent find documentation when a user’s question uses different wording. Graph traversal follows explicit relationships.

For campaign preparation, a retrieved rule still needs a validity check. An old policy may be semantically close to the query while applying to a different market or product. A useful retrieval result therefore carries source metadata, version and scope, rather than an isolated passage.

Choose the retrieval mechanism around the question. Calculating net revenue calls for structured data and governed metric definitions. Finding the current campaign policy may require document search. Combining these forms of retrieval can give an agent useful knowledge without placing the entire data estate in its context window.

Session memory retains the task’s working state: clarified objectives, selected filters and intermediate answers. Persistent memory can make information available across later conversations.

A correction made during a session should not automatically redefine a metric for the whole enterprise. The context layer needs a distinction between a local exception and approved shared knowledge. A marketer may temporarily exclude one product from an investigation without changing the organisation’s revenue definition.

Governed memory needs ownership, review and an effective date when it changes shared rules. Teams should also establish when remembered information expires. Otherwise an agent may reuse an old answer after its underlying data, definitions or policies have changed.

These mechanisms can contribute to a context layer, but memory is not the whole layer. A useful enterprise context layer brings the agent’s current task together with authoritative knowledge and the operational state relevant to that task.

Consider a fictional retailer preparing a reactivation campaign for high-value customers without automatically offering a discount. The following thresholds illustrate its own business rules.

This becomes agentic analytics when an agent organises several checks to investigate the business question.

Context supplies the basis for the decision; tools perform the calculations and authorised operations. Keeping those responsibilities explicit makes it possible to distinguish a proposal from a completed action.

Start with a bounded use case. Making one reactivation audience reliable is more useful than trying to document the entire organisation before running a first trial.

Anthropic’s explanation of context engineering focuses on selecting and managing information useful to a model. Access to more data is not, by itself, the objective.

A practical enterprise workflow begins with the user’s question and the data that user is allowed to access. The agent identifies which metric and entity definitions apply. A semantic layer can supply governed calculations; the wider context layer can provide relevant policy, source metadata and current operational information.

Next comes retrieval. For a structured query, the agent needs the approved data model and relationships required to select the appropriate tables. For a policy question, retrieval may search governed documents. In either case, the context layer should preserve provenance: which source supplied the knowledge, which version applied and what time the data represented.

Lineage helps explain how an answer was produced. If a metric changes because a source system stopped supplying returns, reviewers need to distinguish a data problem from a change in customer behaviour. Metadata linking the metric to its inputs makes that investigation more practical.

Before a tool runs, the execution system checks the user’s permissions. AI agents should not gain broader access simply because a document mentions an operation. A governed context layer can describe policy, but production systems must enforce it. The distinction applies to both reading sensitive fields and changing an audience.

Finally, the agent returns an answer with its definitions, data period, sources and unresolved limits. The user should be able to inspect the evidence without receiving every document or every customer record. This turns enterprise context into a reviewable operational output rather than an unstructured collection of knowledge.

For a B2B renewal, agents need account and contact relationships, the subscription definition and the current contract state. A recent support escalation may change the proposed action. The context layer connects that knowledge; the authorised workflow determines who may approve a follow-up.

For a cross-selling audience, agents need product relationships, customer purchase history and current eligibility rules. Governed definitions prevent returned products from being treated as retained purchases. The context layer can make those rules available across analytics and activation, while tools check the latest data before execution.

Prepare cases with known expected outcomes: a refunded order, a duplicate profile, conflicting rules, stale source data and a customer who becomes ineligible after audience preparation.

Check whether the system applies the agreed definition, identifies its source and makes uncertainty visible. If a required constraint is missing, stopping or asking for clarification may be the correct outcome.

Track relevant measures: agreement with a reference audience, missed suppressions, human corrections, review time and the age of the information used. Any reported error rate should identify its calculation method and the cases tested.

Richer context may improve the relevance of an agent’s work.

⚠️ It does not guarantee error-free output or better marketing performance. Access controls, execution checks and evaluation remain necessary.

An “active customer”, a “VIP audience”, a campaign rule: your team gives each term a specific meaning. Dan, DinMo’s AI data analyst, uses that business knowledge to prepare analyses and audiences around your request.

The Context Manager brings shared definitions and business guidance into one place. A definition can link to a reference segment, while pinned notes and other guidance relevant to the request give Dan access to the context your team maintains.

Ask Dan to “Prepare an email audience of active customers.” Dan can look up the agreed definition and consult relevant notes. When an accessible segment reference exists, Dan can use that rule and query tools to calculate results from current data. You can inspect the applied definitions and notes read in the conversation, making the basis of the proposal easier to review.

When you explain or correct a business term, Dan can propose turning it into a shared definition for your approval. Your team develops a reusable business vocabulary while keeping control of its meaning and audience review.

A context layer makes data interpretable within a business framework. Its value depends on finding an authoritative definition, applying it to the current situation and preserving a record of what informed the decision.