The Holy Trinity: What AI Actually Needs to Get to Work

A manufacturing company wants to know which of its 14,000 SKUs actually turn a profit. The answer sits in three systems that have never exchanged a single data point. Until recently, getting it required three departments, two weeks and a good deal of goodwill. Since early 2026, an AI can answer that question in minutes: search the data, draw connections, produce a recommendation. Provided, that is, it has access.

The models are ready. They act, execute tasks across multiple steps and system boundaries, prepare decisions, trigger workflows. Many companies have already had their first taste of this through Copilot, but Copilot knows the M365 universe: emails, documents, calendars. To point AI at the data that actually runs the business, at ERP, CRM, IoT and production systems, you need a different foundation.

That foundation has three parts. We built each of them as a managed service, each goes live in three to four weeks, and together they form the platform on which AI can do real work.

First: Data worth querying

Back to the 14,000 SKUs. Production data lives in the ERP, sales figures in the CRM, and somewhere in between a single person maintains a spreadsheet that happens to be the only source for a business-critical KPI. This is not an edge case. It is the norm. And as long as these data sit in separate systems, AI has no coherent view of the business.

A lakehouse architecture resolves this in three layers: raw data from source systems (Bronze), curated and validated datasets (Silver), business-level aggregates that feed directly into analytics or AI pipelines (Gold). Whether this runs on Databricks or Fabric depends on the requirement. Both work. So does a hybrid of the two.

The Azure Data Foundation is our managed service for this. It integrates data from ERP, CRM, IoT and other source systems into a single platform, defined entirely as Infrastructure as Code, with automated drift detection, end-to-end data governance via Unity Catalog or Purview, and role-based access for business users, analysts and data engineers alike. The practical effect: a company with this foundation in place can, for the first time, ask questions that were previously unanswerable, not for lack of will, but because the data, though present, was never connected.

Second: A place where workloads actually run

Having data is one thing. Doing something with it that goes beyond a one-off query is another. AI applications, automated business logic, long-running jobs: anything that autonomously and repeatedly accesses enterprise data needs a runtime environment you can control. That environment, whether you planned it this way or not, consists of containers.

The Azure Container Foundation provides this framework: a standardised container platform built on Azure Container Apps or Azure Kubernetes Service, depending on the workload. Unified network access, centralised authentication via Entra ID with Managed Identities, consistent monitoring throughout. All governed through Terraform and GitHub, all reproducible.

What this makes possible: rather than every team spinning up its own cluster and defining its own rules, there is a shared framework in which workloads do not merely run but remain governable. That is the precondition for granting them autonomy.

Third: Where models become agents

A model is not an agent. Between a language model and something that reliably captures orders, checks invoices or escalates service cases lies a lot of unglamorous work: which model, which tools, which data sources, which guardrails, and what happens when the agent gets it wrong. That work has to happen somewhere traceable and repeatable, not in a notebook on one person's laptop.

The Azure AI Foundation is our managed service for this layer, built on Microsoft Foundry (formerly Azure AI Foundry): model catalogue, agent orchestration, connections to tools and data sources, evaluation and observability in one place. An agent built here reaches data and workloads through the same Entra identities as the rest of the landscape, runs against the guardrails you have defined, and leaves a trail you can audit.

We deliver it defined as code, with role-based access, content filters and network boundaries that are not up for negotiation, and a deployment path that moves an agent from development into production without anyone turning screws by hand. Only then does an agent stop being a prototype and become something an enterprise can actually run.

The Holy Trinity

Three building blocks, each in production within three to four weeks, each deployable on its own, together the platform on which AI reaches the parts of the enterprise where value is actually created.

The Azure Data Foundation gives AI access to the data that describes the business. The Azure Container Foundation gives its workloads a place to run, durably and under control. And the AI Foundation is where those data and those workloads become an agent you can build, evaluate and operate.

Put all three together and you have the ground on which AI stops summarising and starts working.