Introduction 

AI agents are rapidly becoming a core component of enterprise transformation strategies. Organizations are deploying agents to assist employees, automate business processes, improve customer experiences, accelerate decision-making, and scale operations. Yet many organizations still face a fundamental challenge.

How do we prove the business value of AI agents? 

While innovation and experimentation are important, long-term success requires a disciplined approach to measuring outcomes, managing costs, and continuously optimizing investments. Organizations that fail to establish clear ROI measurements often struggle to justify continued funding, prioritize future investments, or scale successful solutions. 

An effective AI Agent ROI Framework helps leaders connect technology investments directly to business outcomes. It enables organizations to identify the right use cases, understand cost drivers, quantify value, establish governance, and create a culture of continuous optimization. 

This article presents a practical framework that can be used across industries and business functions to define, measure, and maximize AI agent return on investment. 

Start with the Right Use Cases 

One of the biggest mistakes organizations make is evaluating AI projects solely through a technology lens. Successful organizations begin with business outcomes. 

Before building an AI agent, leaders should evaluate opportunities across six dimensions: 

• Reduction of operational overhead 
• Resource optimization 
• Scalability improvements 
• Workforce productivity gains 
• Customer experience enhancement 
• Revenue growth potential 

The highest-performing AI initiatives typically address repetitive, high-volume, and measurable business processes where automation can quickly generate value. 

Examples include: 

• Employee support assistants 
• Knowledge retrieval agents 
• Customer service agents 
• Sales enablement assistants 
• Compliance review agents 
• IT operations agents 

Organizations should prioritize quick wins that provide: 

• Low implementation complexity 
• High business impact 
• Short time-to-value 
• Strong executive sponsorship 
• Clear success metrics 

Establishing early wins creates momentum, increases adoption, and generates measurable evidence that supports broader AI investments. 

Understanding the Cost Structure of AI Agents 

Accurate ROI calculations require a complete understanding of costs. Many organizations underestimate the true investment needed to deploy and operate AI agents successfully. 

AI agent costs generally fall into five categories.

1. Infrastructure and Platform Costs

These costs include: 

• AI model consumption 
• Compute resources 
• Storage 
• Networking 
• Hosting platforms 
• Development environments 

Organizations should select the simplest architecture that satisfies business requirements. Overengineering often becomes one of the largest sources of unnecessary spending.

2. Development and Integration Costs

Building an agent often requires: 

• Solution design 
• Business analysis 
• Prompt engineering 
• System integration 
• API development 
• Security implementation 
• Testing and evaluation 

These investments form the "cost to achieve" portion of ROI calculations.

3. Data Preparation Costs

Data remains one of the most significant contributors to AI project success. 

Poor data quality increases costs through: 

• Additional token usage 
• Lower response quality 
• Greater compliance risk 
• Increased maintenance effort 

Organizations should invest early in data cleansing, deduplication, classification, and governance.

4. People and Skills Costs

Successful AI implementations require cross-functional collaboration among: 

• Business stakeholders 
• AI engineers 
• Data engineers 
• Developers 
• Security professionals 
• Governance teams 
• User experience specialists 

Many organizations underestimate the ongoing talent investment required to operate AI solutions at scale.

5. Ongoing Operational Costs

Agent deployment is not the end of the journey. 

Ongoing expenses include: 

• Monitoring 
• Evaluation 
• Model updates 
• Prompt optimization 
• Governance reviews 
• Support operations 

Many enterprises find that annual operational expenses represent a meaningful percentage of the original implementation investment and should be included in ROI planning.

Defining Business Value 

A common challenge when measuring AI ROI is focusing only on labor savings. 

The most successful organizations evaluate value across multiple dimensions. 

Productivity Impact 

Productivity improvements include: 

• Faster task completion 
• Reduced manual work 
• Improved employee efficiency 
• Reduced process latency 

Typical measurements: 

• Hours saved 
• Tasks automated 
• Cycle-time reduction 
• Increased throughput 

Financial Impact 

Financial value may include: 

• Revenue growth 
• Cost reduction 
• Resource optimization 
• Reduced outsourcing spend 

Examples include higher conversion rates, increased deal velocity, or lower support costs. 

Risk Reduction 

AI agents can provide value through: 

• Compliance improvements 
• Better policy adherence 
• Reduced operational errors 
• Faster issue detection 

Risk mitigation often generates significant value even when direct cost savings are difficult to observe. 

Strategic Value 

Not all benefits can be measured immediately in dollars. 

Strategic outcomes may include: 

• Improved customer experiences 
• Better decision-making 
• Increased innovation 
• Brand differentiation 
• Workforce empowerment 

Organizations should measure both financial and strategic outcomes to capture a complete picture of value.

Example ROI Statement (for a Business Requirement Document) 

• Manual process: 15 minutes per task 
• Expected agent time saved: 10 minutes per run 
• Expected runs per month per user: 10 runs/month per user 
• Number of Users: 20 users ( whole team) 
• User Adoption: 15 users for Phase 1 (first month after Agent Onboarding,75% adoption rate). Planned to expand to 100% adoption rate at Phase 2, with 20 users.  
• Monthly time saved: 
  • At Phase 1: 18,000 min per year (300 hours)  

• • At Phase 2: estimated to 24,000 min saved per year (400 hours) 

•  Additional benefits: Reduced SLA breaches, improved data accuracy, automated documentation. 

This becomes your measurable target for post-launch monitoring.  

Building an AI Agent ROI Model 

A practical ROI calculation includes three primary components: 

Cost to Achieve 

The investment required to build and deploy the solution. 

Examples: 

• Development 
• Licensing 
• Integration 
• Infrastructure 
• Training 

Cost to Maintain 

The ongoing investment required to operate the solution. 

Examples: 

• Model consumption 
• Monitoring 
• Governance 
• Enhancements 
• Support 

Benefits Generated 

The measurable value created by the AI agent. 

Examples: 

• Labor savings 
• Revenue improvements 
• Risk avoidance 
• Productivity gains 

A simplified ROI formula can be expressed as: 

 However, mature organizations move beyond simple ROI and evaluate investments across multiple years. 

 Example: Zava's Customer Service Agent - 3-Year Projection 

• Cost to Achieve = $80,000 
• Cost to Maintain = 20,000/year*3years = 60,000 
• Total Benefits over 3 years = $200,000 

When used with the formula to calculate ROI this achieves a result of 42.86% 

ROI = (60,000 ÷ 140,000) × 100 = 42.86% 

Interpret the result 

• ROI > 0% → Profitable investment 
• ROI < 0% → Loss-making investment 

A 42.86% ROI means the agent returns nearly 43 cents for every dollar spent over 3 years. 

Looking Beyond ROI with NPV 

Many AI investments generate value over several years. 

Net Present Value (NPV) provides a more comprehensive evaluation by accounting for the time value of money. 

 

Where: 

• CFt = cash flow in year t 
• r = discount rate 
• n = number of years 
• I = initial investment 

Let's say: Zava's Return Fraud Detection Agent - 5-Year NPV 

• Initial Investment = $100,000 
• Annual Cash Flow Impact (positive) = $30,000 
• Time Horizon = 5 years 
• Discount Rate = 8% 

Then: 

The 5-year discounted cash flow impact (NPV) is $19,781 dollars. Without applying the discount rate, the cash flow impact would be 50,000 dollars. 

Interpret the Result 

• NPV of the cash flow impact > 0 → Investment could be approved (subject to budget constraints) 
• NPV of the cash flow impact < 0 → Investment should be rejected 

This approach is especially useful for enterprise-wide AI platforms, multi-agent ecosystems, and large-scale digital transformation initiatives. 

When finance teams evaluate strategic AI investments, NPV often becomes a more meaningful indicator than ROI alone. 

Understanding sensitivity analysis for AI investments – Managing Uncertainty 

AI investments involve uncertainty.  

Identify key variables 

Start by listing the assumptions that significantly influence ROI. For AI agents, these might include: 

• Adoption rate is the #1 variable (for example, % of users actively using the AI agent) 
• Development cost (for example, agents' building and change management) 
• Operational cost (for example, maintenance, updates, cloud usage) 
• Performance outcomes (for example, time saved, errors reduced, revenue generated 

Establish a baseline scenario 

Define the expected values for each variable based on current data or forecasts. For example: 

• Adoption rate: 70% 
• Development cost: $90,000 
• Operational cost: $12,000/year 
• Annual savings: $48,000/year 

Model different scenarios: 

Governance Frameworks That Support ROI 

Organizations attempting to scale AI should establish governance structures that balance innovation with operational discipline.

AI Center of Excellence (AI CoE) 

A strategic hub for AI strategy, governance, and standardization 

Building the CoE — 5 Steps 

1. Secure executive sponsorship — budget, authority, credibility 
2. Appoint a CoE leader — single point of contact for AI strategy 
3. Assemble cross-functional team — data scientists, engineers, ethicists, business leaders 
4. Determine organizational placement — central vs. embedded 
5. Define operating model — centralized early, advisory as maturity grows 

FinOps for AI 

Traditional cloud cost management principles are increasingly being extended to AI workloads. 

AI FinOps focuses on: 

• Cost transparency 
• Consumption accountability 
• Usage optimization 
• Budget forecasting 
• Resource right-sizing 

Organizations should establish visibility into costs at the level of agents, business units, products, and environments. 

GenAI Operations (GenAIOps) 

Continuous evaluation and operational excellence have become critical capabilities. 

Core practices include: 

• Prompt lifecycle management 
• Evaluation frameworks 
• Observability 
• Performance monitoring 
• Quality tracking 
• Automated improvement loops 

Together, AI CoE, FinOps, and GenAIOps provide the governance foundation necessary to maximize long-term ROI. 

Continuous Measurement and Optimization 

Many organizations calculate ROI once and never revisit it. 

High-performing organizations treat AI ROI as an ongoing process. 

Recommended metrics include: 

Business Metrics 

• Revenue impact 
• Cost savings 
• Productivity gains 
• Risk reduction 

Adoption Metrics 

• Active users 
• Utilization rates 
• User satisfaction 
• Repeat usage 

Operational Metrics 

• Response quality 
• Success rate 
• Resolution rate 
• Escalation rate 

Financial Metrics 

• Cost per interaction 
• Cost per task 
• Cost per outcome 
• Budget variance 

Continuous visibility helps organizations identify underperforming agents, optimize successful ones, and prioritize future investments. 

Recommended AI Agent ROI Dashboard 

A centralized dashboard turns this framework into an operating habit rather than a quarterly exercise. Track four groups of KPIs in one place: 

• Financial — ROI %, cost per interaction, cost per task completed, revenue influenced 
• Productivity — hours saved, tasks automated, throughput increase 
• User experience — adoption %, satisfaction score, retention rate 
• Governance — accuracy rate, escalation rate, compliance score, responsible AI metrics 

A Practical AI Agent ROI Maturity Model 

Organizations typically progress through four stages: 

Level 1: Experimentation 

• Individual pilots 
• Limited measurement 
• Basic cost tracking 

Level 2: Managed 

• Defined KPIs 
• ROI modeling 
• Governance processes 

Level 3: Optimized 

• Organization-wide standards 
• Continuous monitoring 
• FinOps practices 

Level 4: Value-Driven AI 

• Real-time ROI tracking 
• Portfolio management 
• Strategic investment optimization 
• AI treated as a business asset 

The most successful organizations operate at Levels 3 and 4, where AI investments are continuously evaluated and optimized based on measurable outcomes. 

Conclusion 

The future of enterprise AI will not be determined solely by model performance or technological innovation. It will be determined by an organization's ability to create measurable and sustainable business value. 

A successful AI Agent ROI Framework begins with selecting the right use cases, understanding the true cost structure, defining business outcomes, establishing governance, driving user adoption, and continuously optimizing performance. 

Organizations that embrace ROI-driven AI strategies will be better positioned to justify investments, scale successful initiatives, and maximize the long-term value of their AI agent ecosystem. 

The question is not whether AI agents can create value. The question is whether organizations have the discipline and framework required to measure, manage, and maximize that value at scale. 

References

• Maximize ROI from AI
• FinOps for AI Overview
• Forecast the return on investment (ROI) of AI agents
• The Economics of Agent Optimization
• How are AI agents spending your tokens? - Stanford Digital Economy Lab
• Agentic AI adoption maturity model

The five-answer problem

Ask a simple question inside a large operator: “How is this asset producing against plan, and what’s the constraint?”

Now watch five systems answer five different things. The production historian knows a “well” as a set of surface sensor tags. The reservoir team reasons about the wellbore and its completions in a subsurface model. Finance knows a cost object rolled up to a lease, licence, or block. The maintenance system knows the facility it sits on. The commercial team knows the contract. Every one of them is correct — and none agree on where a “well” ends and a “wellbore,” a “facility,” or a “licence” begins. OSDU itself separates Well from Wellbore for exactly this reason; the trouble is that our systems don’t honor that distinction consistently.

That is not a data-volume problem. Energy has spent a decade solving volume. It is a meaning problem. And until we solve it, every AI agent we point at that estate inherits the same confusion — five answers, no truth, no confidence to act.

This post is about where that problem finally gets solved: the semantic layer. I’ll connect three things that are usually discussed in separate rooms — Microsoft’s latest AI-readiness research, the open-data standard the energy industry already rallied around (OSDU), and the newly-previewed ontology capability in Fabric IQ — and make the case that they’re the same story. In Part 2, I build it.

Readiness, not ambition, separates the leaders

Microsoft’s recent research, From AI ambition to Frontier Transformation: Readiness defines the leaders, studied 1,000 organizations across 15 countries and eight industries. Two numbers should stop every energy executive:

• Only 17.7% of organizations qualify as AI leaders — the “Frontier Firms” that clear the bar on both technology and organizational readiness. They realize 56% higher AI value than everyone else.
• Organizations with high AI readiness report 47–64% stronger performance across operational efficiency, innovation speed, workforce productivity, customer experience, and revenue growth.

The research is blunt about why most organizations stall. The constraints are “fragmented foundations, unclear governance, and limited organizational alignment” — the exact conditions that keep companies trapped in perpetual pilots. Readiness has to be balanced: plenty of organizations reach strong technology or organizational readiness, but only those that clear both convert AI into outcomes.

If you work in oil and gas, none of those villains are unfamiliar. We arguably wrote the book on fragmented foundations.

In energy, the readiness gap is a meaning gap

Every industry has data silos. Energy’s are structural, and they are older than the cloud:

• Subsurface data is locked to applications. Seismic, well logs, and interpretation outputs have historically lived inside the specialist tools that created them — portable in theory, trapped in practice.
• Mergers and acquisitions fragment the estate by design. Every acquisition bolts on another set of systems, another naming convention, another definition of “well.” Post-merger, “one company” often means a dozen incompatible truths.
• Operational technology (OT) and information technology (IT) grew up apart. Real-time operational data and enterprise data have different owners, different security models, and different vocabularies — a divide that predates anyone’s AI strategy.

Map that onto the research’s four readiness profiles and the picture is uncomfortable. Many energy organizations are Operators — strong at execution and governance, but missing the modern platform — or Innovators funding pilots that never scale because the foundation can’t carry them. Very few are Frontier Firms.

Here’s the strategic point: in energy, what blocks scale is rarely the model. It’s that our data, even when we can move it, still doesn’t carry shared meaning a machine can reason over safely. Fix the meaning layer and you address “fragmented foundations,” “unclear governance,” and “alignment” at once. That is why frontier readiness in energy is won at the semantic layer.

Open standards did the hard part-and stopped one layer short

Give the industry credit: it already took the hardest first step. Faced with vendor lock-in and format sprawl, energy did something rare — it agreed on an open standard. The OSDU® Data Platform unifies subsurface and well data behind common schemas — building on decades of prior standards work, from PPDM’s petroleum data model to Energistics’ WITSML and PRODML — so data is no longer a hostage of the application that produced it.

This is the clearest example I know of how open standards support AI development, and it works on three levels:

1. Portability. Data liberated from proprietary formats can finally be assembled into a foundation. No shared foundation, no AI at enterprise scale.
2. Shared meaning within the domain. OSDU’s Domain Data Management Services (DDMS) don’t just move data — they standardize governed entity types and the relationships between them (seismic, wellbore/well logs, well delivery, reservoir, and rock-and-fluid samples). That’s real, machine-usable meaning: a Wellbore means the same thing across applications. Consistency like this is the precondition for trust — and trust is the precondition for letting software act on your behalf.
3. Ecosystem leverage. Because the standard is open — and deliberately cloud-neutral, running on AWS and Google Cloud as well as Azure — an ecosystem forms around it. On Azure, the managed path is Azure Data Manager for Energy, a fully managed OSDU platform aligned to the OSDU technical standard, with partners like SLB, RoQC, and Interica building on the same base.

So OSDU already gives you two things people often assume are missing: portable data and shared meaning — for the subsurface. Here’s the part the celebration skips: that meaning stops at the edge of the petrotechnical estate. What no upstream standard is chartered to do is stitch the subsurface to the systems that will never live in OSDU — the lease in finance, the work order in maintenance/EAM, the contract in commercial, the sensor stream from OT — and turn the whole into a live, queryable graph a human-supervised agent can reason over in business language. OSDU standardized the vocabulary; making it enterprise-wide and agent-operational is the further step — and that layer stays open no matter how far OSDU grows.

Why adoption is still inconsistent — and what leaders do differently

“We agreed on the standard years ago — so why is my data estate still a patchwork?” It’s the fair question I get from energy executives more than any other — and the honest answer isn’t “the vendors are slow.” It’s that committing to a standard is a readiness discipline, not a one-time data migration — and it plays out in an industry where oil & gas M&A “abounds”, so every acquisition resets the estate with new systems and another definition of “well.”

The published experience is consistent about where it snags. A 2023 review by an SLB enterprise architect names four recurring challenges — lack of standardization, resistance to change, integration with existing systems, and data quality and security (IJFMR, 2023). In practice:

• Sunk cost and resistance to change. Operators have “invested heavily in their existing data management systems and may be reluctant to switch” (IJFMR). The data is portable in theory; the workflows, budgets, and habits around it are not.
• Integration is a multi-year slog. A team deploying OSDU since 2018 puts it bluntly: migrating every application “isn’t feasible overnight… legacy applications might take years to be fully ‘OSDU-ready’ — and may never be” (INT, 2024). You can’t pause a producing asset to re-home decades of data.
• The standard itself is still maturing. “Not all data types are currently supported” (INT); on Azure, the Reservoir domain service only reached preview in early 2025 while seismic and wells are mature. The payoff genuinely varies with where you start.
• Trust gates everything. Teams won’t let agents act on data they don’t trust — and as EY warns, “garbage in, garbage out” has never been more accurate (EY). Quality and security are the precondition for adoption, not the final polish.

Notice the pattern: only the first is purely technical. The rest are organizational — investment, effort, trust, governance — the same readiness imbalance the research names. Organizations earlier in the journey treat OSDU as a project with an end date; leaders treat it as a sustained capability, funded and governed, sequenced so the highest-trust domains go first.

Open standards solved the first half of the readiness problem: data you can move. The second half — data that can reason — lives one layer up.

The missing layer: from data you can move to data that can reason

This is where Fabric IQ enters. Fabric IQ is the business-and-data context member of the broader Microsoft IQ family (alongside Work IQ, Foundry IQ, and Web IQ). It brings three layers of context together over a single foundation:

1. Unified data — OneLake. OneLake unifies data across clouds and on-premises into one governed source of truth using shortcuts, mirroring, and a catalog — explicitly to eliminate fragmentation. An OSDU/ADME estate becomes one addressable foundation instead of a dozen islands.
2. Business intelligence — Power BI semantic models. The curated analytics layer: measures, hierarchies, dimensions — the KPIs the business already trusts.
3. Operational intelligence — ontology (preview). The layer that defines core business entities, their relationships, properties, rules, and the actions agents are allowed to invoke.

Clearing up the confusion: semantic model vs. ontology

I get this question constantly, so let me be precise, because the “is the semantic model replacing the ontology?” framing is backwards. They are complementary layers of Fabric IQ, not competitors.

• A semantic model is a curated analytics layer — measures and KPIs for reports and dashboards.
• An ontology is an operational intelligence layer — a shared, machine-understandable vocabulary of entity types, relationships, rules, and available actions that both people and AI agents reason over.

Critically, per the documentation, ontologies can be generated directly from Power BI semantic models already in production — so your business language stays consistent across reports, agents, and apps. You don’t throw the semantic model away; you elevate it. Define the concept once — Well, Wellbore, Facility — and every downstream report, agent, and app reuses it. The ontology overview says an entity type “elevates the concept above any single table” — exactly the cure for the five-answer problem.

The same principle applies to your OSDU estate: its Data Definitions already describe entity types, relationships, and attributes, so a Fabric ontology can be built from your OSDU-grounded data in OneLake — reusing those definitions rather than reinventing them — then extended to the systems OSDU will never cover (finance, maintenance/EAM, commercial, OT). You elevate OSDU; you don’t replace it.

Two features make this real for energy:

• A governed graph. Relationships become first-class citizens — Well → Wellbore → (logs, markers, completions), plus your enterprise extensions like Facility and lease/licence — queryable without hand-written joins, with lineage and time-travel (historical) queries built in. That’s the observability agents need: you can trace which entities and relationships an answer traversed, not just the output it produced.
• Natural language to ontology (NL2Ontology). An engineer can ask in business terms and the ontology layer routes the query to the right engine (graph or real-time store) under the covers — no need to know which of the five systems holds the answer.

Now re-run the opening scene. With a bound ontology over an OSDU-grounded OneLake, “how is this asset producing against plan, and what’s the constraint?” resolves against one definition of the asset, traverses governed relationships, and returns one answer — that a person, or a human-supervised agent, can act on. That is the difference between data you can move and data that can reason.

Does Fabric ontology actually help oil & gas? An honest ledger

A practitioner’s job is to separate the capability from the hype — especially for a preview. Here’s my balanced read.

Where it genuinely helps:

• Cross-domain reasoning over your OSDU foundation without bespoke join logic — the single biggest unlock for a fragmented estate.
• Agent grounding for governed, human-approved actions. Agents don’t just read; they can surface which actions exist and recommend one, so “detect anomaly → recommend a governed action for a human to approve” becomes a controlled pattern rather than a science project.
• Business-language access via NL2Ontology, which widens the user base from data engineers to reservoir, production, and commercial teams.
• Low-friction start. Because ontologies can be generated from existing semantic models, you bootstrap from logic you already trust.

Where you must set expectations (preview reality):

• It is preview. Treat it as a design partnership, not a production guarantee.
• Not yet real-time truth. Per the docs, upstream changes require a manual graph refresh before they’re visible — plan around that for operational use cases.
• Setup and governance are net-new. The graph relies on a tenant Graph setting, and the security and Responsible AI posture around agent actions is still your accountability, not the product’s.
• It is not a physics/engineering digital twin. Fabric ontology is an enterprise-vocabulary semantic layer. It is a different tool from Azure Digital Twins / DTDL, which models the physical behavior of assets — a distinction worth stating plainly before someone in your org conflates them.
• It won’t rescue an unready foundation. If your OSDU adoption is thin and your governance is unclear, an ontology on top won’t hide those gaps — it will amplify them, because every agent now reasons and acts on them at scale. Which brings us back to readiness.

A leader’s playbook: readiness as a discipline

The research offers a sequencing lesson: leaders invest platform-first — strong cloud, data, and model foundations before scaling applications — and treat the cloud as a control plane where data, models, security, and governance operate together, on whichever cloud your OSDU estate runs. Frontier Firms don’t chase pilots; they standardize, reuse, and manage AI as a portfolio tied to KPIs. That portfolio view is also the cost story: reuse the foundation once and each new agent gets cheaper — you scale without re-paying the integration tax a fragmented estate quietly charges.

Translated for an oil & gas estate, that’s a concrete order of operations:

1. Foundation: Commit to the open standard. Land your subsurface and operational data on OSDU via Azure Data Manager for Energy, and unify the broader estate in OneLake — within your data-residency and sovereignty boundaries, which in energy are rarely optional. Portability first.
2. Meaning: Define your core entities once, then govern them forever — Well, Wellbore, Facility, lease/licence, Sensor — as an ontology, reusing OSDU’s definitions and the semantic models you already trust. In a major, simply agreeing what Well means is a multi-year effort — which is the point. This is where five answers collapse into one.
3. Action: Ground agents in that ontology so they reason and recommend actions in governed, auditable, human-in-the-loop ways.
4. Balance: Advance organizational readiness in lockstep — strategy, skills, culture, and Responsible AI governance. The research is unambiguous that technology readiness alone stalls, and that governance is an accelerant, not a brake. Trust is what unlocks adoption.

That fourth point is the one most technology teams underweight and the one that most separates Frontier Firms. Governance done right is how you earn the right to put an agent’s recommendation in front of the person who acts — because in upstream, taking action on a live asset belongs to safety-instrumented systems and management-of-change, never to an autonomous agent.

The bottom line

Oil and gas doesn’t have an AI ambition problem. It has a meaning problem — and meaning is an architecture decision, not a model choice. Open standards like OSDU gave us portable, governed data; Fabric IQ’s semantic model and ontology layers give that data shared meaning and a safe surface for agents to reason over and recommend action. I’ve framed this around upstream, but the same discipline carries into the energy transition — CCUS, hydrogen, and grid estates inherit the identical silo problem. Preview caveats and all, that’s where the next decade of energy AI will be won or lost.

If you want to know where your own organization sits, start with the mirror: read the AI Readiness Assessment whitepaper and run the AI Readiness Advisor. Then ask the honest question: when we point an agent at our estate, will it get one answer — or five?

In Part 2, I’ll go hands-on: standing up an ontology over an OSDU-grounded OneLake and grounding a production-monitoring agent on it — what works today in preview, and what to wait for.

I’ll also be carrying this conversation to the Women’s Energy Network Houston panel on AI, data, and the next energy opportunity this August. If you’re building the semantic layer for your energy estate — or just wrestling with the five-answer problem — I’d love to compare notes.

Sources

1. Microsoft, From AI ambition to Frontier Transformation: Readiness defines the leaders (2026).
2. Microsoft Learn, Ontology overview (Fabric IQ) and Fabric IQ overview.
3. Microsoft Learn, Azure Data Manager for Energy and Domain data management services (DDMS).
4. S. K. Patidar (SLB), Challenges and Solutions while adopting OSDU in Oil & Gas Industries, IJFMR, Vol. 5, Issue 4 (2023).
5. INT, Navigating the Deployment Challenges You May Run into with the OSDU Data Platform (2024).
6. EY, Driving oil & gas operations value through data foundation strategy.
7. McKinsey & Company, Amid volatility, oil and gas M&A abounds — here’s how to capture full value.
8. The Open Group OSDU® Forum, Data Definitions and Modeling (entity types, relationships, and attributes; schema repository).

From AI Foundations to a Shared Operating Model

In my previous article, AI Azure Landing Zone: Shared Capabilities and Models to Enable AI as a Platform, I explored how organizations establish secure, governed environments for AI workloads. Building on that foundation requires aligning three complementary responsibilities.

1. Establish the deployment foundation

Azure landing zones establish the subscription, identity, networking, and governance foundations. AI landing-zone implementations extend these foundations with architectures for Foundry-based applications, agents, and shared AI gateways.

2.Use native AI platform capabilities

Microsoft Foundry provides model and agent services alongside capabilities for evaluation, observability, security, and governance. These are native platform capabilities—not capabilities introduced by Citadel.

3.Standardise how teams deploy and operate AI

As multiple teams adopt these services, enterprise-wide design decisions become essential:

• Which resources are shared or isolated?
• Where are access policies enforced?
• How is consumption attributed?
• Who owns onboarding, monitoring, and incident response?

Citadel brings an opinionated architectural approach to these decisions, connecting native capabilities with cross-team governance and operational practices.

These responsibilities coexist. A customer with an existing landing zone and Foundry deployment can assess Citadel’s patterns against its operational gaps rather than treating adoption as a replacement of the existing platform.

This is the role of Citadel AI Foundry:

What Is the Citadel Architecture?

Citadel is an opinionated reference architecture, documented in the Foundry Citadel Platform repository, for composing Microsoft Foundry and complementary Azure services into an enterprise AI operating model.

Its contribution is the architectural guidance connecting those services: where shared controls operate, how teams consume capabilities, and how responsibilities are divided between platform owners and application teams.

What Does a Customer Adopt?

Customers adopt selected patterns from the Citadel architecture guidance and implement them using native Azure services and the relevant implementation guidance. Adoption does not require replacing existing landing-zone or Foundry investments.

A practical starting sequence is:

1. Assess the existing environment. Review current Foundry resources, identity, networking, and monitoring. Identify which foundations can be reused and where gaps remain. The AI Landing Zones repository provides reference implementations for these foundations.
2. Choose one workload and one operational gap. For an HR assistant, the initial goal might be consistent model access or workload-level usage attribution. Record its data-access, isolation, and operational requirements before selecting additional components.
3. Apply the relevant pattern and agree ownership. The platform team configures selected shared controls; the application team configures its assistant, tools, data permissions, and evaluations. Where a gateway is selected, use the AI gateway guidance and confirm which requests actually pass through it.
4. Demonstrate the outcome before expanding. Confirm that unauthorized access is blocked, usage can be attributed to the workload, failures reach the responsible team, and response quality meets the agreed criteria. Document the onboarding steps before applying the pattern to another team.

Assess prerequisites, feature availability, preview status, and operating costs for each selected service. Citadel provides the architectural approach; the customer remains responsible for configuring and operating the resulting environment.

An organization can retain its existing landing-zone and Foundry investments while adopting selected Citadel patterns to address specific operational gaps. 

The architectural decision is not “landing zone or Citadel?”, but “which additional patterns does our operating model require?”

Citadel Reference Architecture: Shared Governance and Workload Environments

Citadel separates shared platform responsibilities from application-team responsibilities. A shared governance hub provides selected gateway and discovery capabilities, while workload environments contain applications, agents, and their data dependencies.

The architecture brings together four governance concerns: the governance hub, AI control plane, agent identity, and security fabric. These are complementary responsibilities—not four sequential stages through which every request passes. The diagram below shows how they relate to the workload components.

For the HR assistant example, the platform team establishes shared controls: approved model deployments, gateway policies for requests routed through the gateway, identity requirements, and telemetry destinations. The application team configures its assistant, approved tools, and workload-specific data permissions. During requests, these configured Azure services enforce the agreed controls—there is no separate Citadel runtime. The same onboarding and operating patterns can then be reused by other teams without granting them access to HR data.

Workload Component 1: Foundry Resource and Project Management

Microsoft Foundry provides a native resource hierarchy for organizing AI workloads. The Foundry resource is the management scope for settings such as networking, security, model deployments, and connections. Projects provide development and access boundaries for teams working with agents, files, evaluations, and related assets.

Citadel’s architectural contribution is to establish how these native scopes are used consistently across the organization.

For example, HR and Finance may use separate projects within a shared Foundry resource when their requirements permit shared networking and security settings. The platform team manages the shared setup, while each business team develops its own AI assistant.

Projects should not be treated as independent network-isolation boundaries. Workloads requiring different resource-level networking or security configurations may need separate Foundry resources. Connected services—including Azure AI Search, Azure Storage, and Azure Key Vault—retain their own access controls and governance boundaries.

Workload Component 2: Data, Retrieval, and Grounding

Enterprise AI applications often need information beyond a model’s pretrained knowledge. Retrieval-augmented generation (RAG) addresses this by retrieving relevant enterprise content and supplying it to the model as context when generating a response.

Azure provides native capabilities for storing source data, preparing content, generating embeddings, and retrieving information. The combination depends on the workload’s data sources, access requirements, freshness needs, and retrieval approach.

Citadel’s architectural contribution is to standardize how these capabilities are selected, connected, secured, and operated across teams.

For example, an HR assistant can retrieve relevant policy passages from an approved search index and supply them to the model alongside the employee’s question. The retrieval path must ensure that only content the employee is authorized to access is returned.

Source systems remain the systems of record; a search index provides a retrieval-ready representation of selected content. Copying or indexing data must not be assumed to preserve its original permissions automatically.

Conversation history and agent memory are separate concerns from grounding data. They are not mandatory components of every RAG implementation and require their own access and retention decisions.

For example, an HR assistant can call an approved model deployment with the employee’s question and retrieved policy passages. Before changing the model or version, the team evaluates representative questions to compare answer quality, safety, response time, and cost.

Not every model supports the same fine-tuning, networking, filtering, or capacity features. Deployment choices must also satisfy data-processing requirements: the location of a Foundry resource alone does not establish where inference requests are processed.

Workload Component 4: Agents and Orchestration

Microsoft Foundry Agent Service provides native capabilities for building and operating agents that coordinate models, retrieval, and tools. Supported capabilities depend on the agent type and hosting approach.

Citadel standardizes the operating rules around these capabilities: which tools agents may use, what permissions they receive, and how execution, state, and failures are managed.

Multi-agent orchestration and persistent memory are optional design choices—not requirements for every assistant. The example below is read-only; submitting or changing a leave request would require a separately defined authorization and approval path.

Private-networking options depend on the selected services and deployment modes. Azure Activity Log records management operations; application and tool-call tracing require separate configuration. Content filters do not guarantee factual correctness, and deploying security services alone does not demonstrate compliance.

Citadel in Practice: A Day-in-the-Life Request Flow

An employee asks, “Explain my leave options.” This read-only example brings the preceding components together: access checks, permitted data retrieval, agent orchestration, an approved model, response safeguards, and operational observation.

Access must also be enforced at each data source, tool, and model endpoint; passing the initial access check does not grant unrestricted downstream permissions.

Citadel AI Foundry Repo Link:  https://github.com/Azure-Samples/foundry-citadel-platform