The enterprise does not own the customer context.
Customer technology has spent years promising a complete customer view. The promise is attractive because it suggests that more integration will eventually produce certainty. In practice, the enterprise holds fragments: records, events, permissions, interactions and inferences created for different purposes at different times.
The customer retains experiences, intentions and circumstances the organisation may never observe. Even within the enterprise, context changes with the encounter. What is useful for service may be inappropriate for marketing. What is current today may be misleading tomorrow. A context architecture must begin with those limits rather than pretending they can be engineered away.
Useful context is bounded by purpose, time, permission and accountability.
Context architecture principle
Customer context and agent context are different design problems.
Customer-operational context describes the governed information required to understand and act within a customer encounter. Agent context describes the information, instructions, tools and memory an automated actor needs to perform a task. They overlap, but they are not interchangeable.
An agent can be technically well supplied with prompts and retrieved knowledge while still acting on incomplete customer state, weak identity, ambiguous consent or a false inference. Improving the agent context window does not complete the customer architecture beneath it.
Five disciplines make context usable without pretending it is complete
- 01
Purpose
State which decision or encounter the context is intended to support.
- 02
Provenance
Distinguish observed facts, customer statements, system events and inferred attributes.
- 03
Time
Record when context was true, when it changed and when it should expire.
- 04
Permission
Enforce which uses are allowed rather than treating consent as descriptive metadata.
- 05
Accountability
Name who is responsible for interpretation, correction and harm when context is wrong.
Design for sufficient context, not omniscience
- What is the minimum context required for this decision?
- Which elements are observed, declared or inferred?
- How quickly can each element become stale?
- Can a customer or operator correct the record?
- Which context must not cross into another purpose or encounter?
Govern customer context
Build a context architecture that knows its limits.
A customer context review can clarify the identity, provenance, permission and lifecycle controls required before AI or decisioning depends on them.