.jpg)
Table of contents
An AI context platform built for analysis may leave critical gaps when agents need to act. Learn how analytical and operational AI use cases shape your AI context architecture, and which capabilities each requires.
Key takeaways
- Match the architecture to the workload. Use a lakehouse with a semantic layer for analytical AI and an operational data fabric for precise entity context and governed actions. Integrate both patterns for workflows that combine analysis and operational execution.
-
Build a semantic foundation. Both patterns require semantic modeling, an ontology, and a knowledge graph. Their scope and implementation differ according to analytical or operational needs.
- Design for precise business context. Model the meaning and relationships the task requires, then deliver the relevant information within the user’s permissions. Unnecessary context can impair answer quality, increase data exposure, and add processing cost.
- Define how fresh each input must be and how quickly each workflow step must respond. These requirements determine what context can be prepared in advance, what must be assembled from operational sources, and what needs rechecking before execution.
- Set separate permissions for reading data and taking action. Enforce them through the interfaces agents use to retrieve context and invoke updates.
- Make evidence capture part of the architecture. Retain the context delivered, controls applied, actions taken, and confirmed results so outcomes can be evaluated against the context used.
Two AI context platform patterns
The analytical pattern organizes context around datasets, metrics, populations, and time periods. A common foundation is a warehouse or lakehouse, with shared business definitions, governed query execution, and traceability from an answer to its supporting data. Analytical architectures can include streaming and frequently refreshed data when the workload requires it.
The operational pattern organizes context around the business entitiesA business entity is something an organization tracks and manages, such as a customer, account, product, order, or claim. K2view unifies and manages the data for each individual entity, such as a specific customer, in its own Micro-Database™.Explore K2view Micro-Database technology involved in a workflow, their relevant state, and permitted operations. An operational data fabric can connect distributed sources and maintain reusable entity context. The surrounding context architecture must support precise context assembly, delivery within the required latency, runtime governance, and confirmed execution results.
For enterprises supporting both analytical and operational AI, the AI context platform should integrate complementary architecture patterns: a lakehouse for governed analysis and an operational data fabric for precise business context and authorized actions. Shared business definitions, entity identifiers, and policies should connect the two, allowing analytical findings to inform operational decisions.
AI context management is the discipline behind these choices. The examples below translate them into architectural recommendations.
A telco example connecting analysis and action
A marketing manager at a telecommunications provider asks an AI assistant: Which mobile plan offers performed best in last quarter’s campaign, and for which customer segments?
During a live customer interaction, a service representative asks an AI assistant: Which mobile plan best fits this customer’s usage?
The AI assistant recommends an option based on the customer’s context. If the customer accepts, it initiates the authorized plan change.
The marketing manager uses analytical AI to explore campaign performance across customer segments. The service representative uses an operational AI application to get a personalized plan recommendation and initiate an authorized change.
A workflow can also move between these modes. Analytical campaign insights can inform the offers recommended during customer interactions. The AI context architecture must support the handoff from population-level analysis to individual, personalized decisions and actions.
Analytical AI example with campaign analysis
The campaign question needs shared business definitions, governed queries, and appropriate historical data. Four architectural considerations shape how those capabilities work together.
1. A shared semantic foundation
A semantic layer defines the business meaning of data attributes, measures, and calculation rules. An ontology formalizes business concepts and relationships, such as customers holding subscriptions and campaigns presenting offers. A knowledge graph represents the business data as connected entities and facts, including subscriptions, campaign offers, and acceptance outcomes.
Together, these capabilities provide a semantic foundation over governed warehouse or lakehouse data. The knowledge graph’s physical implementation depends on the relationship queries required, from a logical view over existing data to dedicated graph storage.
For campaign analysis, the architecture must support querying those entities and relationships as they existed during the campaign period, including the applicable offer terms. Historical semantic definitions must also remain available so that measures retain their original meaning. This creates requirements for storing, versioning, and retrieving both data and definitions across time..
2. Analytical execution close to the data
Population-level analysis places computation in the warehouse or lakehouse. The analytical AI agent receives calculated results and the supporting evidence needed to interpret them.
The architectural choice is how much computation happens in advance. Reusable aggregates reduce repeated computation for predictable questions. Queries over detailed records support broader exploration but introduce more variable processing costs and response times.
The query interface therefore needs to support governed exploration while controlling the volume of data returned to the agent.
3. Ingestion and refresh patterns matched to the question
A quarterly comparison and an active-campaign dashboard place different demands on the ingestion architecture. The former needs a reliable historical reporting period, while the latter needs frequent updates to support ongoing decisions.
The ingestion layer needs appropriate combinations of batch and near-real-time processing, with asynchronous push or scheduled and on-demand pull. The choice depends on source capabilities, acceptable data delay, and processing cost.
Reporting periods and update timestamps belong in the query results, giving the agent evidence of which period the data covers and how current it is.
4. Query authorization and retained evidence
Analytical exploration moves between aggregate results and record details. Permissions must remain effective throughout that path, with dataset, row, and field controls enforced by the query architecture.
The evidence requirements extend beyond the final answer. Retaining the relevant definitions, queries, data versions, and results makes it possible to assess whether the answer follows from the context supplied to the agent. The architecture needs a way to associate that evidence with each interaction.
Operational AI example with personalized offers
1. Entity models and identity resolution
Operational context depends on reusable models for customers, accounts, subscriptions, contracts, and their relationships. Source mappings establish where the relevant facts reside, while runtime identity resolution determines which specific records belong to the customer involved.
A shared family allowance, for example, spans multiple subscriptions within an account. The architecture must preserve those relationships so that the recommendation reflects shared usage and allowance. Entity-based data products package the entity models, relationships, and logic for retrieving or updating the underlying multi-source data.
2. Task-specific assembly of precise business context
Precise business context includes the data, relationships, history, and applicable governance policies needed for the specific entity and task, within the user’s permissions.
For the mobile plan recommendation, the context includes historical usage patterns, current subscription status, and relevant contract and offer terms. The context architecture needs filtering, enrichment, and runtime governance before delivery, with further retrieval as the conversation develops.
Context scope is an architectural concern. Irrelevant or conflicting information can impair answer quality. Unnecessary sensitive data increases exposure, while additional content consumes tokens and processing time. The assembly layer must select the minimal sufficient context for the task while controlling what reaches the model.
3. Context delivery within conversational latency
The context architecture determines how much context is maintained in advance and how much is retrieved during the interaction.
An operational data fabric can maintain synchronized entity context through CDC, messaging, and streaming, supplemented by APIs and database queries. In-memory processing and smart caching reduce the work required during an interaction. Targeted source queries provide information whose freshness requirements demand a current check.
Source dependencies also require runtime handling of delays and failures. The delivery layer needs to distinguish between context that remains usable and missing information that prevents a dependable recommendation or action.
4. Maintain context freshness and consistency through execution
The architecture therefore needs synchronization and cache-refresh policies, with timestamps showing when retrieved data was last updated. It must also ensure that data assembled across systems describes a consistent business state. For example, usage and allowance figures must correspond to the same subscription plan and billing cycle.
A further boundary exists between recommendation and execution. The authorized update operation (of the selected plan) needs access to authoritative state to check conditions that could have changed. An already redeemed promotion or a changed subscription should trigger the application to reassess the recommendation.
5. Separate governance for retrieval and actions
Permission to retrieve customer context and permission to change a subscription are separate architectural concerns. Customer eligibility, the requester’s authority, and the agent’s permission to invoke the operation must each be established.
These controls belong in the data access and execution services, which enforce permissions for the target entity and requested operation. After the customer accepts the recommended plan, the AI assistant requests the change. The execution service (API/tool) checks authorization and applicable business rules before applying it.
6. Execution interfaces that report confirmed outcomes
Write-back requires defined business operations with explicit inputs, validation rules, and results. A plan-change operation must report whether the request was rejected, accepted for processing, or completed.
When completion is delayed or uncertain, retained execution status gives the application a way to establish the outcome of the write-back. These interface requirements determine what the AI assistant can reliably tell the customer. A submitted request and a completed plan change represent different business states.
Connecting analytical findings to operational execution
Analytical campaign insights can inform a next-best-offer policy or a customer attribute, such as a segment assignment. Shared entity identifiers and business definitions allow the operational path to interpret those outputs consistently. Policy versions and update timestamps establish which rules apply and when derived customer attributes were calculated.
During an individual customer interaction, the operational path combines these inputs with current customer context. Its data access and execution services enforce the permissions and business rules governing the recommendation and any subsequent change.
The two paths may rely on different stores and interfaces. AI evaluation and observability provide evidence spanning both: the analytical findings, applicable policy versions, context delivered during each customer interaction, and any requested actions and confirmed outcomes. Retaining these links allows teams to investigate what happened and evaluate recommendations and actions against the context actually used.
Choosing an architecture to deliver context
The requirements above lead to three context delivery patterns:
- Direct source access retrieves authoritative state during the interaction. It suits tasks involving a few responsive services, but makes source availability, latency, and request load part of the runtime dependency.
- Maintained entity context supports hige-volume interactions requiring data from many systems. An operational data fabric assembles context ahead of the request, reducing runtime integration work while introducing synchronization and refresh requirements.
- Maintained context with live retrieval combines prepared relationships and historical summaries with current operational facts. The architecture determines which data follows each path and how the combined state is validated.
Analytical delivery involves a related choice between prepared aggregates, cached results, and queries over detailed records, with different implications for flexibility, freshness, and compute cost.
Across these patterns, text-to-SQL limits API sprawl. Parameterized queries and defined business operations support varied requests without an endpoint for every question. Data agents interpret requests, plan the required operations, and invoke the relevant queries through data products.
SQL, APIs, MCP, and retrieval pipelines provide access mechanisms within this architecture. Entity and field permissions, query execution limits, and separate authorization for updates govern what those mechanisms can retrieve or change.
Comparing the architecture requirements
Use this matrix to identify requirements for your own use case. The examples illustrate the patterns; freshness and response times still depend on the task.
|
Architecture consideration |
Analytical AI |
Operational AI |
|
Example use case |
Campaign analysis |
Personalized offer recommendation |
|
Common foundation |
Warehouse or lakehouse with semantic and governed query layers |
Operational data fabric or entity services with governed retrieval and execution |
|
Context model |
Metrics, populations, time periods, historical relationships |
Specific entities, relevant state, relationships, rules, permitted operations |
|
Preparation |
Historical datasets, metric definitions, reusable aggregates |
Entity models, source mappings, integration logic, reusable context |
|
Freshness |
Reporting cutoffs or live updates, as the question requires |
Attribute-specific freshness, with source retrieval and checks where needed |
|
Consistency |
Comparable populations, time periods, metric definitions |
Compatible entity state, policy versions, and execution conditions |
|
Response time |
Fast enough for exploration or reporting (up to few minutes) |
Fast enough for the interaction, including context assembly and reasoning (milliseconds) |
|
Runtime governance |
Query permissions and controlled access to detailed records |
Entity and task scope, privacy, consent, and separate read/write permissions |
|
Data access |
Governed queries and metric interfaces |
Reusable scoped queries, tools, and business operations |
|
Write-back |
N/A |
Required when the agent is authorized to change business state |
|
Evidence |
Definitions, queries, data versions, supplied results, outputs |
Point-in-time context, controls, operations, outputs, execution results |
An operational architecture example from K2view
K2view’s AI Context Platform illustrates the operational pattern, built on an entity-centric data product foundation.
Each data product’s semantic model serves as an entity-scoped ontology, defining the business meaning and relationships for an entity type (customer, order, policy, employee, etc.). The complete data product definition also includes integration logic and governed read/write operations.
At runtime, each entity instance has its own Micro-Database™A Micro-Database™ is K2view’s dedicated data store for a single business entity instance, such as a specific customer, account, or order. It unifies that entity’s data and relationships across source systems, stays synchronized with those systems, and provides fast, independently governed access.Explore K2view Micro-Database technology holding isolated AI context: an entity-scoped logical knowledge graph of its facts and relationships. The data is synchronized with source systems according to the use case’s freshness requirements.
Data agents interpret intent, resolve the relevant business entity, instance, and authentication context, and plan the required operations. They invoke data products through the appropriate tools, APIs, RAG pipelines, and dynamic SQL queries.
Data products retrieve or update the underlying multi-source data. A business agent uses the delivered context to reason about the next offer. AI runtime governance controls access and operations through the managed path, while evaluation and observability capture interactions for assessment and replay.
Match your AI context architecture to the workload
Analytical and operational AI call for different AI context platform patterns.
A warehouse or lakehouse with a semantic foundation supports governed analysis across datasets, metrics, and historical populations. An operational data fabric provides precise entity context, delivery within workflow response times, and runtime controls for authorized actions with confirmed outcomes.
