DataFab / Why DataFab
The competitive landscape, honestly
Five archetypes, and the one already installed.
Five archetypes circle the agentic enterprise — and a sixth is already installed: the vanilla software you licensed years ago and have been configuring toward ever since. Most hold agents or data, rarely both, and rarely across the whole estate. The position that matters pairs a governed, in-boundary, cross-estate data foundation with a workforce of agencies the business itself builds — and leaves the firm owning what it built.
The unit of analysis
Not a data platform. Not an agent tool. An operating model.
In 2026 the market stopped talking about chatbots and started talking about agents as operational software — systems that retrieve data, plan, call tools, trigger workflows, coordinate with each other and produce auditable outputs. Every serious buyer now asks the same question first: can I govern what these agencies do, on data I trust, inside my boundary?
The operational AI programme
Governed operational agents on an ontology, deployable in sensitive settings. Real capability — bought by ingesting into their world and adopting their model.
The bundled cloud platform
Broad, bundled agent builders with native governance and distribution — and a gravity that pulls everything toward one cloud.
The app-suite agent
Strong, trusted agents where the source of truth already lives in their application. Excellent inside that application.
The data-platform agent layer
Governed agents on the lakehouse or warehouse, with lineage and federation — centred on data the platform manages.
The developer framework
Flexible toolkits to build and orchestrate agents quickly. Fast to prototype, and silent on the hard enterprise half.
DataFab is the one shape that pairs a governed, in-boundary, cross-estate data foundation with a workforce of business-built agencies. Others lead on one axis — strong agents, or strong data — usually inside a single estate.
Versus the operational AI programme
They proved the category. We change its operating model.
This is the closest conceptual reference and the opposite operating model. It is genuinely brilliant, and genuinely heavy. You buy the brilliance by moving into their world: their ontology, their model, their forward-deployed engineers, a deployment measured in quarters and a dependency measured in years. The enterprise reorganises around the platform.
The programme model
Powerful — and expensive and slow to adopt.
- Asks the enterprise to ingest into the platform and adopt its ontology
- High-touch deployment; expansion happens through a programme
- The intelligence becomes the vendor’s asset, built on your data
- A standing bench of their engineers inside your building
- Time to value measured in a transformation cycle
- Software that arrives as a consulting engagement wearing a product’s name
DataFab
The same outcome, without the rebuild.
- Govern in place across the estate — no migration into our environment
- Agencies built by the business, not by forward-deployed engineers
- Every schema, agency and resolved entity is your intellectual property
- Nobody moves in. Software that deploys itself
- Usable, regulated capability in weeks
- The ontology is derived from your estate, not authored by a priesthood
The programme model wins where the buyer accepts a high-touch ontology programme. DataFab wins where the buyer wants the outcome without the rebuild, the dependency or the time-to-value burden.
Versus the bundled cloud platform
They bundle agents into their cloud. We stay neutral to it.
The bundled model
Powerful inside their own estate.
- Gravity pulls data, governance and agents toward one cloud
- Governance is per-platform; cross-cloud and on-premises are an afterthought
- Headline capacity is sized for dashboards, not continuous agentic execution
- Strongest where the enterprise has already standardised on that cloud
DataFab
Cloud-neutral by design.
- One governed layer across every cloud, on-premises and air-gapped
- Operate where the data lives; no pull toward a single provider
- Governance and audit at the source, spanning the whole estate
- Independence from any one vendor’s renewal leverage
Versus the app-suite agent
Excellent inside their app. We act across the whole estate.
The app-suite model
Real governance — over one application’s view.
- Strongest inside their own ecosystem and data model
- Broad workflows must still reach systems the app does not own
- Agents are bound to one application’s view of the enterprise
- The application’s data model is imposed on the business
DataFab
One governed graph spanning every system.
- Entity resolution across core systems, CRM, warehouses, files and applications, in place
- Cross-system decisioning rather than single-app automation
- No application’s data model imposed on the enterprise
- The conclusion that exists only between two systems becomes reachable
Versus the data-platform agent layer
They add agents to the platform. We bring agencies to the data.
The data-platform model
Governed agents — on data the platform holds.
- Agents work best on data already inside the lakehouse or warehouse
- The platform stays the centre of gravity for data and for spend
- Built for data engineers, not for the business
- The pattern remains source to replicated store to transformed model to consumption
DataFab
No platform to land data in.
- One governed graph across the estate, not one platform’s storage
- Agencies authored by the business, no code required
- Regulated determinism and audit, in-boundary and air-gapped
- We do not replace the warehouse — we activate it, along with everything it could never hold
Versus the developer framework
Frameworks help you build agents. They leave the hard half to you.
The framework model
Fast to prototype, expensive to industrialise.
- No governed, in-boundary data foundation underneath
- No entity resolution, residency, audit or regulated deployment
- You assemble — and then own — the governance and the plumbing
- The demo is easy; the second year is not
DataFab
Both layers, governed and ready.
- A governed graph across the estate, in place, with full audit
- Agencies built by the business on top of it
- Enterprise-grade from day one, not a build-it-yourself stack
- Foundation and workforce as one operating model, not a project
Nine comparisons, drawn
There are two ways to buy intelligence. You have only been sold one.
Versus the vanilla you already licensed
Don’t buy vanilla. Compose it. Cascade it.
The sixth competitor is not a vendor. It is the software already installed — bought as a product, configured toward someone else’s average, and renewed every year without ever becoming yours.
Rented process
A licence per workflow, renewed forever. An integration project per system, per vendor. A vendor engagement for every new use case. And the same capability bought again for the next entity.
An accumulating asset
The resolved estate, built once and reused by everything after. The encoded workflow as an owned asset rather than a renewed engagement. Every next agency cheaper and faster than the last. And the schema, the graph and the agencies remain exportable — you can leave with them.
A vendor stands beside the estate, so each deployment reaches one system and the next starts again. An agency composed in the Studio stands on the resolved estate, so it applies everywhere the moment it is published. Not one integration at a time.
Capability matrix
Across the capabilities that define the agentic enterprise.
A directional view of publicly disclosed capability, for orientation. Archetypes are described by their operating model rather than named.
| Capability | DataFab | Operational AI programme | Bundled cloud | App-suite agent | Data-platform agent | Developer framework |
|---|---|---|---|---|---|---|
| Governed data foundation, in place | Strong | Partial | Limited | Limited | Partial | — |
| Cross-estate, not one app or cloud | Strong | Partial | Limited | — | Limited | Partial |
| Entity resolution into one graph | Strong | Strong | Limited | Limited | Partial | — |
| Business-built agencies, no code | Strong | — | Partial | Partial | Limited | — |
| Governance and audit over agent and data | Strong | Strong | Partial | Partial | Partial | — |
| In-boundary and air-gapped | Strong | Strong | — | — | Limited | Partial |
| The encoded workflow becomes yours, not renewed | Strong | Partial | — | — | — | Partial |
| One agency applies across the estate on publish | Strong | Partial | Limited | — | Limited | — |
| You can leave with the schema, graph and agencies | Strong | — | — | — | — | Partial |
| No ontology rebuild required | Strong | — | Partial | Partial | Limited | Partial |
| Time to value in weeks | Strong | — | Partial | Partial | Limited | Partial |
The difference at a glance
Governed agencies on governed data — without the rebuild.
| DataFab | Operational AI programme | Bundled / app-suite agents | Developer frameworks | |
|---|---|---|---|---|
| Who owns the intelligence | You | Increasingly, them | Split across their tenancy | You, once you have built it |
| Data foundation | Governed, in place, cross-estate | Ingested into the platform | Within one cloud or app | None — you provide it |
| Scope | The whole estate | Whatever is modelled in the ontology | The vendor’s estate | Whatever you wire up |
| Who builds agencies | The business, no code | Deployment engineers | Admins and developers | Developers |
| Governance and audit | At the source, over agent and data | In the ontology | Per platform | Build it yourself |
| Deployment | Any cloud, on-premises, air-gapped | In-boundary, programme-led | Mostly SaaS or a single cloud | Self-hosted |
| Time to value | Weeks | A transformation cycle | Fast inside their estate | Depends on your build |
Counted properly — licence, cloud compute, implementation, the separate agentic layer the data platforms do not include, the internal engineering bench, and migration and egress — the modelled three-year all-in cost of reaching the same governed-agentic outcome lands substantially below the migrate-and-build alternatives, and reaches it in months rather than years. Those are model outputs from a scenario analysis, not quotes; the figures for your estate are built from your own case mix, volumes and source list.
Why it holds
The two layers together are the whole product.
It is honest to say that no single piece is defensible on its own. A connector, a catalogue, a knowledge graph, a private deployment or a protocol, taken alone, is not a moat. The defensibility is in the combination and in where it lives.
The whole-product gap
Agents-only and data-only rivals each have half. Assembling the other half is the hard, governed, regulated part — and it runs against the grain of their architecture and their economics.
Estate gravity
Once the foundation governs the estate in place, every new source and every new agency raises the switching cost — because leaving means re-integrating an estate that never had to move.
A compounding library
Each agency the business authors is reusable supply the next team inherits. The workforce compounds, and so does the knowledge state beneath it.
“No raw data leaves” is not a catalogue feature. It is an architectural posture.
A platform built around centralising data cannot simply bolt it onNext step
Test the claim against your own estate.
Bring the workflow that spans the most systems and the source list nobody wants to migrate. That is the fairest test of the difference.