AI Engineering Systems are proliferating. Each one builds its own integrations, its own context silos, its own understanding of your business. This is the new heterogeneity problem—and the opportunity is in solving it via a Three-Tier Context Layer.
[!NOTE] Enterprise Context = Structural Unity
Humans understand that a problem isn't isolated; it's a ripple effect across the system.
- Behavioral: A doctor doesn't just look at a symptom; they look at the patient's entire history and chart.
- Engineering: Enterprise Context Layer stitches fragmented data across SCADA, CRM, and ERP into a single, queryable "History" for the organization.
[!NOTE] Engineering Playbook
This playbook covers platform architecture for context delivery. For bridging connectivity and structured knowledge, see Semantic Continuity. For capturing human judgment and decision traces, see Precedent Engineering.
Phase 0: The Heterogeneity Problem
The Problem
An AI agent (e.g., an industrial maintenance persona) proposes a "Critical Preventive Action" for a high-value CNC Machine. Where does the context for that decision come from?
Not one system. Six systems:
| System | Context Provided (Industrial) | Enterprise Parallel (SaaS) |
|---|---|---|
| Core CRM/ERP | Service history, work orders | Deal records, account history |
| Operational Ops | Slack/Ops shift lead approval | Slack/Email VP discount approval |
| Telemetry | SCADA/IoT vibration data | Usage analytics, product adoption |
| Technical Docs | BIM/CAD specs, manuals | Support tickets, Project/Product (Jira) |
| Semantic Layer | Definition of a "Healthy Asset" | Definition of a "Healthy Customer" |
And here's the killer: every enterprise has a different combination. One runs Salesforce + Zendesk + Snowflake. Another runs HubSpot + Intercom + Databricks. A third has a homegrown CRM + ServiceNow + BigQuery.
graph LR
IOT[SCADA / IoT] --> Decision{Decision}
ERP[ERP / Maint] --> Decision
Parts[Spare Parts] --> Decision
Ops[Slack / Ops] --> Decision
BIM[BIM / CAD] --> Decision
Semantic[Semantic Layer] --> Decision
classDef v-large font-size:24px,font-weight:bold;
class IOT,Decision,ERP,Parts,Ops,BIM,Semantic v-large;
| The Old Heterogeneity | The New Heterogeneity |
|---|---|
| 5 data warehouses, fragmented storage | Hundreds of AI Systems, each with partial context |
| "Where does the data live?" | "Whose semantics are right?" |
| Lock-in at the storage layer | Lock-in at the context layer |
[!TIP] Universal Architecture
Whether you are managing turbines or subscriptions, the "New Heterogeneity" is the same: your AI Engineering Systems are locked into the partial semantics of the systems they connect to.
Instead of every system building integrations to multiple high-value sources, we need a platform-level abstraction—a universal context layer that any system can query.
graph LR
IOT2[SCADA / IoT] --> UCL[Universal Context Layer]
ERP2[ERP] --> UCL
Inventory[Inventory] --> UCL
Specs[BIM / CAD] --> UCL
UCL --> A1[Maintenance Agent]
UCL --> A2[Supply Chain Agent]
UCL --> A3[Safety Agent]
classDef v-large font-size:24px,font-weight:bold;
class IOT2,UCL,ERP2,Inventory,Specs,A1,A2,A3 v-large;
[!TIP] Proof of Engineering: Cross-system context stitching reduces context-engineering overhead by 60-80%, as shared definitions propagate across all systems automatically.
The Decision-First Architecture: The Three-Tier Context Layer
To balance the stability of the system with the flexibility of human intent, we move from "Context-First" (storing everything in a static graph) to "Decision-First" (assembling the graph at runtime).
Tier 1: The Immutable Log (The Foundation)
- Role: Store raw, immutable events (clicks, tool calls, reasoning traces).
- Concept: The Engineer's layer. It ensures structural reliability and auditability without forcing early interpretation.
Tier 2: The Derived Topology (The Map)
- Role: Automatically infer relationships, clusters, and "process shapes."
- Concept: The Map. Using GNNs or heuristics, this identifies what is connected, providing a searchable index for the next layer.
Tier 3: The Runtime Reconstruction (The Perspective Engine)
- Role: Filter and re-interpret Tiers 1 and 2 based on the current decision intent.
- Concept: The Perspective Engine. Instead of a static "Context Graph," this builds a unique "Perspective Graph" on the fly for every query.
- Industrial Example: "Is this CNC machine healthy?" (Pulls SCADA + Maint History).
- Enterprise Example: "Should we discount this account renewal?" (Pulls Jira activity + Slack approvals + Contract value).
Phase 1: The Two Halves of Context
The Problem
We talk about "context" as if it's one thing. It's not. There are two fundamentally different types, and conflating them creates architectural failures.
The Solution: Operational + Analytical Context
| Context Type | What It Contains | Where It Lives | Examples (Industrial / Enterprise) |
|---|---|---|---|
| Operational | SOPs, safety protocols, tribal knowledge | Tickets, Slack, Runbooks | "Isolate turbine on red alert" / "Escalate overrides to VP" |
| Analytical | Asset/Customer health, metrics, calculations | Semantic Layer, dbt, BI tools | "Asset MTBF" / "Customer Churn Risk" |
graph LR
Ops[Operational] --> D{Decision}
Ana[Analytical] --> D
D --> Action[Action]
classDef v-large font-size:24px,font-weight:bold;
class Ops,D,Ana,Action v-large;
A maintenance decision doesn't just pull from operational context ("here's our isolation protocol"). It also pulls from analytical context ("here's how we calculate asset health score, here's what 'critical vibration' means").
The Extended Context Taxonomy
Building on the Four Planes of Awareness:
| Plane | Layer | Operational Side | Analytical Side |
|---|---|---|---|
| Temporal | Memories | Recent interactions, approvals | Rolling metrics, trend windows |
| Source | Documents | Runbooks, policy docs | Metric documentation, data dictionaries |
| Atomic | Entities | People, tickets, exceptions | Customers, products, accounts |
| Relational | Relationships | Escalation chains, approval flows | Entity hierarchies, attribution models |
[!IMPORTANT] The Context Gap: The specialized AI agent (e.g., Jira or SCADA) sees the workflow, not the analytical context that feeds it. The data warehouse sees the metrics, not the operational decisions that use them. The context layer must bridge both.
Phase 2: Platform Architecture
The Problem
AI agents can run context flywheels within their domain—but they can only improve context for their workflow. They can't improve the shared building blocks that all workflows need.
The Solution: Platform-Level Integration
| Architecture | Context Scope | Flywheel Scope | Integration Burden |
|---|---|---|---|
| Isolated AI System | Single workflow | Local | Each system builds multiple high-value integrations |
| Context Platform | All workflows | Global | Platform builds integrations once |
graph LR
S[Sources] --> C[Connectors]
C --> Stitch[Stitcher]
Stitch --> Store[(Store)]
Store --> API[API]
API --> A[Agents]
classDef v-large font-size:24px,font-weight:bold;
class S,C,Stitch,Store,API,A v-large;
What the Platform Provides
| Capability | Description | Core Match (Industrial / Enterprise) |
|---|---|---|
| Entity Resolution | Match fragmented IDs across sources | Turbine-4 (SCADA) ↔ ASSET-99 (ERP) / John Smith (CRM) ↔ jsmith (Slack) |
| Semantic Definitions | Single source of truth for metrics | "Critical Vibration" / "Healthy OKR Progress" |
| Cross-System Joins | Unified query across any source | SCADA + Spare Parts + ERP / Jira + Slack + Email |
| Precedent Storage | Decision traces for auditability | Why was downtime approved? / Why was the OKR deadline moved? |
| Governance | Centralized access control | Access to sensor thresholds / Access to discount policies |
Phase 3: The Compounding Flywheel
The Problem
Context engineering today is manual. Armies of engineers gather context from stakeholders, update system prompts, and tune evals. Every agent vendor does this redundantly, for every implementation.
The Solution: Platform-Level Feedback Loops
The system that wins isn't the one that captures the most context on day one. It's the one where context compounds over time.
graph LR
A[Accuracy] --> B[Trust]
B --> C[Adoption]
C --> D[Feedback]
D --> A
classDef v-large font-size:24px,font-weight:bold;
class A,B,C,D v-large;
| Stage | What Happens | Platform Effect |
|---|---|---|
| Accuracy | Context is correct, agents make good decisions | All agents benefit from shared definitions |
| Trust | Teams rely on the architecture | More workflows migrate to AI-assisted |
| Adoption | Usage increases across domains | Cross-domain patterns emerge |
| Feedback | Corrections and refinements flow back | Context quality improves globally |
Enterprise Context Ownership
The strategic lesson: enterprises learned that ceding control of data to a single vendor created lock-in. The same applies to context.
| Principle | Description |
|---|---|
| Context is Portable | Export your context layer to a new vendor |
| Governance is Centralized | Single source of truth for definitions |
| Agents are Pluggable | Any agent can read from the shared layer |
| Feedback is Aggregated | Improvements benefit the entire organization |
[!TIP] The Platform Play: The companies that have already built cross-system connectivity (metadata platforms, data catalogs, semantic layers) have a structural advantage. They've solved heterogeneity once—now they extend it to AI context.
Production Checklist
- Cross-System Stitching: Can you query context across CRM + support + warehouse in one call?
- Operational/Analytical Split: Are SOPs stored separately from metric definitions?
- Entity Resolution: Can you match identities across systems?
- Semantic Governance: Is there a single source of truth for key definitions?
- Feedback Loops: Do corrections propagate to shared definitions?
- Context Portability: Can you export your context layer?
The Bottom Line
[!IMPORTANT] Context is the strategic asset. Agents are the interface.
In a world of heterogeneity, the integrator wins—not the application. The platform that lets customers own their context will beat platforms that try to own it for them.
References & Further Reading
- Semantic Layer Concepts — How analytical context is defined and governed.
- Apache Iceberg — The open table format that inspired context portability thinking.
- Microsoft: GraphRAG — Graph-based retrieval for complex reasoning.
Related Playbooks
- The Engineering Manifesto — AlphaPebble's core philosophy for building high-stakes autonomous AI systems.
- Semantic Continuity — The strategic bridge between connectivity and meaning.
- Context Engineering — The prompt-level foundations this playbook extends.
- Precedent Engineering — Capturing decision traces and human judgment.
- Knowledge Graph Engineering — Entity and relationship extraction.
- Activity-Stream Engineering — Capturing the "How" of processes.
- Data Engineering Fundamentals — The infrastructure feeding context platforms.
This playbook is maintained by the AlphaPebble team. For implementation support, get in touch.