Executive Summary
Enterprise IT operations are undergoing a fundamental transformation. For 40 years, data integration has been built around ETL (Extract-Transform-Load)—a pattern designed for human analysts who write SQL queries and read dashboards. But as AI agents become the primary consumers of operational data, a new integration paradigm is emerging: ECL (Ontology)—Entity-Context-Linking powered by a purpose-built operational ontology.
This whitepaper explores the evolution from ETL to ECL through the lens of agentic operations and data federation. It examines how Fabrix.ai's Agent Runtime Core with its embedded Ontology layer for agentic data federation, bridges the gap between siloed observability tools and autonomous enterprise operations, enabling AI agents to not only see data, but understand the context and causal relationships behind it.
Enterprise IT operations have evolved through three distinct phases, each defined by its failure mode and resolution model. The transition to agentic operations fundamentally changes who consumes data:
- Siloed Tools - Too much noise, human coordination, hours to days response times
- AIOps - too much signal, last mile problem, subject matter experts interpret dashboards and incidents
- Agentic Ops - Signal, Decide and act; humans notified and for oversight, not overloaded.
The Critical Gap in Agentic Operations
Today's agentic landscape suffers from two structural gaps:
Fabrix.ai's Siloed Observability to Unified Agentic Operations blog explains this gap.
Fabrix.ai addresses this gap with an AI-first, end-to-end agentic operations platform that spans the full enterprise stack—from cloud-native apps and cloud infrastructure to traditional enterprise apps, servers, network equipment, and security infrastructure. Unlike narrowly scoped alternatives, Fabrix.ai delivers observability ingestion, cross-domain reasoning, tool orchestration, workflow execution, closed-loop remediation, and governance guardrails from signal through decision to action.
The Three Generations of Data Federation
| Approach | Limitations | |
|---|---|---|
| Gen 1 Siloed Tools with Native Agents |
Each domain tool (APM, TOM, NPM, SIEM) operates independently with its own native agents, ingesting MELT data from its own scope. Cross-domain correlation requires domain-specific experts collaborating in a war room. | No cross-domain visibility. Resolution depends on human coordination across siloed teams. Slow MTTR, tribal knowledge bottlenecks, and inability to correlate a network event (NPM) with an application degradation (APM) without manual effort. |
| Gen 2 Static Data Federation |
A federation platform sits above siloed data sources, connecting them through SQL queries. Query mapping, schema mapping, result mapping, and selection criteria are configured statically by engineers to unify data across sources. | Brittle. Every new data source, schema change, or naming convention shift requires manual reconfiguration. Cannot adapt to dynamic environments. Federation mappings and rules are static - they break when the environment changes. |
| Gen 3 Agentic Data Federation |
Federation is performed by AI agents. The federation platform connects to enterprise data sources via APIs, legacy connectors, and direct-to-source access. Agents dynamically perform data discovery, schema mapping, and entity resolution—no static rules required. | This is Fabrix.ai pioneered approach. AI agents replace static mappings with intelligent, adaptive federation that self-discovers, self-maps, and self-resolves across the entire enterprise stack—zero copy, real-time, at scale. |
The fundamental difference is who performs the federation. In Gen 1, humans coordinate across siloed tools. In Gen 2, engineers configure static mappings that a platform executes. In Gen 3, AI agents perform the federation autonomously—discovering data sources, understanding schemas, resolving entities across naming conventions, and unifying insights without moving data.
Fabrix.ai's Agentic Data Federation in Practice
Enterprise data is fragmented, and centralizing it no longer scales. Fabrix.ai's agentic data federation is a zero-copy model where AI agents go to the data and unify insights without moving it. The platform connects to enterprise data sources through three access patterns - APIs for modern systems, legacy connectors for traditional infrastructure, and direct-to-source access for databases and logs - all mediated by the Universal Tooling & Connectivity Engine and its 1,900+ data integration bots.
Where static federation requires engineers to manually configure query mappings, schema mappings, result mappings, and selection criteria for every source, Fabrix.ai's agents handle all of this dynamically. When a new observability tool is added or an existing source changes its schema, the agents adapt - performing continuous dynamic data discovery and schema mapping without human intervention. The result is real-time access at the source, reduced integration overhead, faster insights, and lower platform cost.
Why AI Agents Need a New Data Architecture
ETL has served human analysts brilliantly since the 1980s. It extracts structured data from operational systems, transforms it into analytics-ready schemas, and loads it into operational databases, where humans write SQL queries and build dashboards. The entire pattern assumes a human end-consumer who can interpret metrics in context.
AI agents are fundamentally different consumers. They cannot look at a dashboard and intuit that a declining customer satisfaction score connects to slow support response times, a competitor mentioned in a sales call, and a pending contract price increase. They need those relationships made explicit. They need context—and more critically, they need an ontology that defines what entities exist, how they relate, and what those relationships mean operationally.
Introducing ECL: Entity-Context-Linking with Operational Knowledge
The term ECL—Entity-Context-Linking—was introduced by Sanjeev Mohan, former Gartner Research VP for Data & Analytics, at Data Day Texas, 2025. ECL extends this framework with a critical addition: a structured operational ontology that serves as the knowledge substrate for agentic data federation. It represents a fundamentally different integration pattern purpose-built for AI agent consumption.
ECL extracts entities from MELT data, tickets, API calls etc. to build context. The three steps of ECL—Extract Entities, Build Context via Ontology, Link Everything—produce a knowledge graph where AI agents can traverse from any entity (a service, incident, host, configuration change, metric anomaly) through ontologically defined relationships to understand the full operational picture and take autonomous action ("Why did it happen and what should we do?")
Why Ontology Is the Missing Piece
Most approaches to agentic AI skip the ontology layer entirely. They connect agents directly to data sources via MCP or APIs and rely on the LLM to figure out relationships on the fly. This creates three critical failure modes:
| Challenge | Without Ontology | With Fabrix.ai Ontology |
|---|---|---|
| Operational Data Scale & Hallucination | LLM receives raw MELT data without structure; hallucinates causal relationships | Ontology pre-structures entity relationships; Context Engine delivers grounded, relevant context to the LLM |
| Cross-Domain Reasoning | Agent sees isolated data per tool; cannot connect network events to application impact | Ontology defines cross-domain entity relationships; agents traverse from symptom through infrastructure to root cause |
| Entity Resolution | Same entity appears as different names across tools (e.g., hostname vs. IP vs. service name) | Ontology provides canonical entity resolution - agents dynamically map across schemas and naming conventions |
| Decision Provenance | Reasoning trace lost after each query; no institutional memory | Context Engine maintains persistent state, memory, and instruction management grounded in ontological structure |
This is why Fabrix.ai positions Ontology as the dedicated layer between raw connectivity and contextual reasoning. It is the knowledge substrate that transforms data federation from a plumbing exercise into an intelligence architecture.
This is precisely the kind of contextual intelligence that AI agents need to move from correlation to causation—from reporting what happened to understanding why and acting autonomously to resolve it.
Ontology: The Core Differentiator in Fabrix.ai's Agent Runtime
While ECL provides the data integration pattern, ontology is what makes it work at enterprise scale.
An ontology is not a schema—it is a formal, machine-readable representation of domain knowledge: what types of entities exist, what properties they have, how they relate to each other, and what rules govern those relationships. In the context of IT operations, an ontology defines the operational vocabulary that AI agents use to reason across domains.
Fabrix.ai's Agent Runtime Core Architecture
Fabrix.ai's Agent Runtime Core is a vertically integrated architecture designed with ontology as its foundational knowledge layer.
The platform is structured in three concentric layers, all wrapped in Security & Governance:
| Layer | Function |
|---|---|
| Universal Tooling & Connectivity Engine | The foundation layer. Dynamic tooling, connectivity, and metadata discovery across all enterprise tools, infrastructure, and data - including both MCP-enabled and non-MCP systems. This is where Fabrix.ai's 1,900+ data integration bots, dynamic tool generation, dynamic tool wrappers, and Universal MCP Server operate. |
| Ontology | The knowledge substrate. Agentic Data Federation and the operational ontology that defines entity types, relationships, and domain semantics across the entire enterprise stack. This layer transforms raw connectivity into structured operational knowledge—enabling agents to understand that a CPU spike on a host, a latency anomaly on a service, and a deployment event are causally connected, not independent signals. |
| Context Engine | The reasoning layer. State, memory, and instruction management with optimized compaction, intelligent caching, and context cache. The Context Engine uses the Ontology layer to assemble precisely the right operational context for each agent task—addressing hallucination risk by grounding agent reasoning in ontologically structured knowledge rather than raw, unstructured data. |
Surrounding the Agent Runtime Core, Fabrix.ai provides an Agent Ecosystem comprising the Agent Catalog (50+ pre-built agents for ITOps, NetOps, SecOps), Agent Studio (visual, flow-based agent builder), AgentOps (observability, security/guardrails, eval/improvement, cost controls), and Partner Agents—delivering a fully vertically integrated Agentic Platform as a Service.
Ontology Driven ECL - Entity, Context, Linking: What Fabrix.ai Does
Everything Connected
AI agents can traverse relationships to understand "why"
Observability systems generate MELT data—Metrics, Events, Logs, and Traces—the operational telemetry that forms the foundation of enterprise IT context. Fabrix.ai's agentic data federation applies ECL pipelines to MELT data at enterprise scale. The pipeline flows through the Agent Runtime Core's three layers:
Universal Tooling & Connectivity Engine
Extract Entities from MELT streams: Data Federation Agents and the 1,900+ data integration bots continuously ingest metrics, events, logs, and traces from multiple observability platforms (Dynatrace, Splunk + ITSI, SolarWinds, Cisco DNAC/ACI, CloudWatch, and more) via both MCP and native API connectors. Dynamic data discovery continuously maps schemas across these heterogeneous sources.
Ontology Layer
Build Context via operational knowledge: The Ontology layer resolves entities across source boundaries and defines their operational relationships. A CPU spike on a host (from SolarWinds), a latency anomaly on a service (from Dynatrace), and a deployment event (from a CI/CD log ingested via Splunk) are connected through the ontology into a causal context chain. The ontology understands that these are not three independent signals—they are one incident with a root cause, linked through defined infrastructure-to-application-to-business-impact relationships.
Context Engine
Link Everything into actionable intelligence: The Context Engine assembles the ontology-structured knowledge into optimized context for each agent task. When an RCA agent investigates a service degradation, the Context Engine delivers the precise subgraph of entities, relationships, and historical patterns - with intelligent caching and compaction to manage operational data scale and prevent hallucination. The agent doesn't query a table of alerts - it traverses from symptom through infrastructure dependencies, recent changes, and historical incidents to deliver a root cause with full provenance.
This is precisely the kind of contextual intelligence that AI agents need to move from correlation to causation—from reporting what happened to understanding why and acting autonomously to resolve it.
The ECL Technical Stack for Agentic Operations
Building ECL (Ontology) pipelines requires a purpose-built technical stack that differs significantly from traditional ETL tooling:
This is Fabrix.ai's pioneering approach.
- Federation is performed by AI agents.
- Agentic Data Federation agents replace static mappings with intelligent, adaptive federation that self-discovers, self-maps, and self-resolves across the entire enterprise stack—zero copy, real-time, at scale.
- The agents connect to enterprise data sources via APIs, legacy connectors, and direct-to-source access. Agents dynamically perform data discovery, schema mapping, and entity resolution—no static rules required.
Complementary, Not Competitive: ETL + ECL
ETL is not dead. ETL will still be used to generate normalized data from real-time MELT and structured data. However AI agents need traversable, ontology-structured context graphs with entity relationships, causal chains, and decision provenance—served by ECL pipelines through platforms like Fabrix.ai. The winning architecture integrates both patterns. Fabrix.ai's agentic data federation sits at this intersection: its Agent Runtime Core can access both normalized data and unstructured MELT telemetry, building ontology-driven context graphs that enable autonomous operations while preserving compatibility with existing analytics infrastructure.
Conclusion
Fabrix.ai is uniquely positioned at this inflection point. Its Agent Runtime Core—with the Ontology layer as its knowledge substrate, the Universal Tooling & Connectivity Engine as its foundation, and the Context Engine as its reasoning layer—already implements the core principles of ECL: extracting operational entities from heterogeneous MELT sources, structuring them through operational ontology, and delivering actionable intelligence to agents that autonomously resolve issues with human oversight.
The teams building this infrastructure now, connecting ontology-driven context graphs to observability data, deploying agentic federation across the enterprise stack, and integrating structured and unstructured data for AI consumption—are building the operational intelligence platform for the next decade.
About Fabrix.ai
Fabrix.ai delivers Digital Workers for Autonomous Enterprise Operations. The platform's Agent Runtime Core—featuring an embedded Ontology layer, Context Engine, and Universal Tooling & Connectivity Engine—powers agentic data federation across the full enterprise IT stack.
With 1,900+ specialized data integration bots, 20+ pre-built agents for ITOps, NetOps, and SecOps, and a fully vertically integrated Agentic Platform as a Service (Agent Catalog, Agent Studio, AgentOps), Fabrix.ai partners with Cisco, Splunk, IBM, and AWS to deliver operational intelligence that moves enterprises from reactive operations to autonomous resolution.
Recognized in multiple Gartner reports and named to the 2025 Top 50 Agentic AI platforms.