AI Mesh: How RWE Turns Data Products Into AI Products

Summary

RWE's AI Mesh concept reframes AI as a catalog of business-owned AI products — each with defined goals, guardrails, access controls, evaluation criteria, and a product life cycle — rather than ad-hoc chatbot prompts that repeat the same work without shared trust or enterprise reuse.
AI products capture domain expert reasoning from structured business processes, are triggered by events rather than manual prompts, and run on Databricks alongside Unity Catalog, MLflow, Lakebase, Databricks Apps, Genie, and MCP tools for governed multi-agent orchestration.
A wind farm early layout planning example shows how event-driven AI products can evaluate turbine selection, noise compliance, and project value in hours instead of weeks, with traceable, explainable decisions and human oversight preserved throughout.

AI Mesh: How RWE Turns Data Products Into AI Products

AI Mesh at RWE Renewables turns trusted data products into governed, reusable AI products that expose domain expertise across the business. Instead of adding chatbots to existing workflows, RWE packages expert capabilities as business-owned agents with defined goals, guardrails, access controls, evaluation criteria and product life cycles.
See how RWE uses Databricks, Unity Catalog, MLflow, Lakebase, Databricks Apps, Genie and MCP tools to create an AI product catalog and orchestrate multiple agents toward shared system goals. A wind farm early layout planning example shows how event-driven AI products can evaluate turbine selection, noise compliance and project value in hours instead of weeks while preserving traceability and human oversight.
Learn more about MCP orchestration with Databricks Apps: https://community.databricks.com/t5/technical-blog/three-mcps-one-answer-building-a-data-quality-monitor-on/ba-p/156106

Chapters

FAQs

What is RWE's AI Mesh concept?

AI Mesh is RWE's approach to treating AI capabilities as governed, versioned products rather than ad-hoc prompts, so that domain expertise is captured once and reused across the business. Each AI product has defined goals, guardrails, access controls, evaluation criteria, and a product life cycle owned by the responsible business domain.

Why does RWE argue that adding chatbots to existing workflows is not enough?

Pascal from RWE argues that using AI purely for personal productivity — summarizing emails, working on tickets — repeats the same work multiple times without creating reusable enterprise value, generating hidden context and no shared trust. True transformation requires rethinking workflows so AI products replace manual coordination steps rather than merely assisting them.

How does the wind farm early layout planning AI product work at RWE?

The AI product is triggered by a layout planning event and automatically evaluates turbine selection options, noise compliance requirements, and project value using multi-agent orchestration. Work that previously required weeks of meetings and manual analysis can be completed in hours with traceable, explainable outputs that preserve human oversight.

What Databricks tools does RWE use to build and govern AI products?

RWE uses Databricks alongside Unity Catalog for governance and access control, MLflow for evaluation and versioning, Lakebase for transactional state, Databricks Apps for hosting AI product interfaces, Genie for natural language querying, and MCP tools for agent orchestration. This stack enables a full AI product catalog with discovery, auditability, and enterprise reuse.

Full transcript

[00:09] Thank you for joining this session. I want to start with a quote that I recently read on LinkedIn and then looked up on the internet because I don't trust LinkedIn directly. It was from Ali, who said that with AI we are at the same point as when steam engines were replaced by electrical engines, because at the beginning they just replaced the steam engine and everything else stayed the same.
[00:42] For around 40 years companies didn't see the value because electrical power was maybe a bit easier to get into factories, but apart from that it was exactly the same. I think with AI we are now at exactly the same point. The winners of the AI race will not be the ones that just use the same workflows we have today and give people some
[01:14] chatbots to do exactly the same thing but with a cool chatbot on the side. That's not the revolution we are heading to; it needs to be completely changed. We need to change how we think. With that, I welcome you to my session, AI mesh, the age of AI products. How do we go from data products to AI products?
[01:46] I'm Pascal, working for RWE, a power company. I want to guide you through what we are doing to rethink AI not just as a tool but as products, and how they reshape our way of working. RWE is an energy company active worldwide, a combination of gas and renewable energy, mainly in Europe, Australia and the Americas, and we are growing because with AI everyone needs more energy.
[02:51] We see a lot of companies doing AI pilots and everyone playing around with AI. Recently some companies even build rankings of who is using how many tokens to see AI adoption. I think that's really bad because that's not what I want; I want to create value, not see who uses the most tokens.
[03:25] We use AI to speed up personal tasks, summarizing emails, working on tickets faster, using MCP servers, but it's doing the same thing we currently do: someone writes a prompt and the agent spawns out. If you make a spelling mistake it behaves completely differently. None of this is versionized, everyone does it for themselves, so you have hidden context everywhere and no shared trust.
[04:31] The same thing gets repeated over and over, and we lose a lot of money summarizing the same email five times. Enterprise reuse breaks because it just adds extra cost. What I want is to think of AI as products: build things once so we can reuse them, with proper governance and a proper life cycle, so no one has to write a chat again and again.
[05:17] Coming back to RWE: we're not an IT company. We don't create value by closing a ticket faster or writing emails. What we actually do is find land where we can build a wind farm, see if the land is feasible, create a layout of how turbines would act, negotiate a price with the land owner, lease it, talk to the government, and find the right turbines.
[06:25] We use applications as a tool to help humans make better decisions, but all the teams come together in a lot of meetings, each bringing their own capability. Engineering, project management, origination, legal all have meetings, go back to their teams, and come back again. It takes a long time, but each team brings capabilities because they're experts.
[07:13] What I want is to bring this capability to the company as AI. I don't want AI that closes a ticket or reads a Confluence page; I want AI that finds the best turbine for a piece of land, or tells me a good price for the land, because that's the capability that creates value. Data products expose trusted data; AI products expose trusted domain capabilities so we can reuse them without talking to the expert, though the expert owns the capability.
[08:16] What is an AI product for us? It's an agent that works as a product with proper ownership, owned by a business domain where the experts train it. I don't want someone in IT looking at MLflow to optimize tool usage; it needs to be owned by business, who define the guardrails around the capability and how domain owners use it, with a life cycle, an interface, and governed access.
[09:38] Each capability can expose strictly confidential data, so a capability like reading contracts might only be available to a subset of people. The trust contract means we still want to see how it uses tools and improve its behavior. For an AI product to be a real product it needs to be discoverable and reusable, so we don't build it again and again slightly differently.
[10:25] The data product thinking helps: it's the same strategy we used for our data strategy. I build AI products not for a use case but within a use case so they're reusable and create value directly. They need discoverability through a proper catalog, and they need to be owned by the business, which a lot of companies miss because data and AI departments build these things and then get blamed when it fails.
[12:04] I was in a workshop where someone said, I have an Excel sheet with data, I choose from a drop-down menu and something comes out. I asked, why are you waking up to work on this? They said their manager told them. I dug deeper: there's a clear process, the project moves from one state to another. I'm not interested in the data itself, but in your thinking behind choosing one of the five menu items.
[13:25] That thinking is part of the capability. It's not only data in and data out, it's why you open the drop-down and choose this. This is a capability more people need, part of our critical value chain, that we need 24/7 whenever the environment changes, but it must be defined by the business. That's the agent's goal: what outcome do we want to achieve, so the agent might find a better way.
[14:42] We talk about the guardrails, then access, then the data the capability needs. Then we start publishing it via chatbot: give it a prompt, see how it behaves, evaluate, improve, give it more guidance. We do the MLflow stuff but also think about why the human thinks it's a better way, and we improve the guardrails, then operate it as a product across different places.
[16:19] How does the AI product work? I don't want people writing prompts all the time; if you do a typo it behaves differently. We start with why the manager is prioritizing it now, and that becomes the trigger so our AI products react to the outside world, not to a human starting it. Out of this we create a structured request with all the information it needs.
[17:23] It goes into the AI product boundary where it creates its own goal: with this information, this is what I need to deliver, these are my achievables, this is the evidence I'm done. After each turn we evaluate against those achievables; we don't let the AI just say I'm done and hope for the best. If it can't get closer to the goal, it notifies a different agent, part of defining what happens if it cannot deliver.
[18:42] It gives a structured output that can be the input for a different agent. I don't believe in luck; I want evidence, so I let the AI create a proper scope. On the tech stack, we utilize a lot of Databricks. We started our data journey with all our data products in Unity Catalog, which enabled AI functionality; Genie chat works more or less automatically because our data is in Unity Catalog.
[19:48] Databricks doesn't deliver everything, so we built an AI hub, a Databricks app, to orchestrate agents and have the AI product catalog. Every agent is registered in MLflow. We use Lakebase everywhere, including for agent states, plus serving endpoints and Genie spaces (now Genie agents) so the agent talks in natural language with Genie, which helps define the semantic layer.
[20:52] All the MCP notebooks and skills are registered in Databricks, so a tool used in my AI product is automatically also available in Genie chat. I'm not building a chatbot, that's built by Databricks already, and I try to be as Databricks-native as possible because I'm scared that if I go out of their product scope I'd need to reinvent my AI hub, which is more a visual representation for our business.
[22:02] A proper example: early layout planning is a prime capability we're building. A project moves to a stage where it's ready for a layout, which means putting turbines on a map within a scoped area. It's not that easy; the first question is which is the right turbine for this area, which is the Excel sheet, a combination of teams needing the weather team to tell us the conditions.
[23:21] Currently someone goes to a website to find the average wind speed and direction, with a lot of assumptions that are good enough given value and time. But if this capability were available 24/7 from the experts directly, you don't need to compromise. Then on the map, Europe has a lot of regulations, so you think about noise: how much noise the turbine generates and how close to a house you can build.
[24:24] You input this in a tool and do calculations until you find this turbine might need a quieter mode that generates less power, so maybe a different turbine generates more power, but that means talking to another team again. You have meeting after meeting to hand it over between teams, with assumptions because experts aren't always available, taking weeks to months, and maybe not even the optimal setup.
[25:27] We stop at good enough to get our permit, but we don't know if the project is the most valuable one or whether other projects should be prioritized. That's why early layout planning is so important. Now the project moves to a stage ready for early layout planning, and moments later you get system-ready outputs with all the details of why the turbine is placed there, no system opened, no meeting needed.
[26:18] We bring in not one AI product but a set of AI products working towards a system goal. Each AI product has its own goal, but together they work toward a system goal. I think of the system as an orchestrator: it has a system goal and thinks about which AI product is the best next one to bring it closer, so no meetings, no handovers, decisions in hours not weeks.
[26:50] We have the AI product catalog where all our capabilities are registered so everyone knows what's available and can search for them without reinventing. Each AI product gets a card with the MLflow experiment, the owner and their role, what it does, the capability description, how it should behave, and the behavior rules, which is where the thinking comes in, plus materiality and access.
[27:53] We give every agent memory, so after each task it thinks about how it did and how to improve, what was good and not, incorporating human feedback but also learning if a tool wasn't good so we avoid wrong tools. Permissions are completely synced with Unity Catalog so I don't reinvent them, and we configure which MCP servers each AI product can access.
[28:58] I don't want one AI product with millions of MCP servers trying to solve everything because it waters down which tool to use, so we separate AI products by capability, not too small and not too big. We created a system using Miro as a way of thinking: drag and drop AI products onto a canvas, starting with a trigger, for example a queue that starts the system.
[30:03] The system is an orchestrator that gets the message from the queue with a wrapper so it knows it's part of this system, then thinks about the goal, like a traceable early layout recommendation, and which AI product is best to bring it closer. We have two modes: a normal workflow mode that just hands over from one product to the next, and the orchestrator that chooses the best next product.
[30:51] It runs until finished or until it says it cannot do more, so you define the behavior if it's blocked, the same question I ask a human: what are you doing then? Describe exactly that, so we have the same problem solution; if you're blocked you may call someone or write something, so let's notify this person that we need more information.
[31:40] An AI system is composed of multiple AI products working together toward a system goal with a defined output. It starts with an automated trigger, and a few moments later you get a report saying we are noise compliant if you use this mode, this is the turbine you should use, this is the maximum power and the value of the project, so you can rate it against all other projects. It's hours instead of weeks.
[32:43] As a summary, we start with meetings and can only look at a few options; models help optimize but handovers still take weeks, with a lot of assumptions because you don't have access to all the experts. You optimize with chatbots, but is it the best way? That's why we want experts owning the capability.
[33:31] It's misleading for humans who say they don't trust the AI. I say it's much more traceable done the correct way than someone opening an Excel sheet and choosing randomly from a drop-down. There's an accountable expert, but why is he choosing that? That's why I ask in the workshop, and we make that thinking visible and traceable, seeing what went in and out.
[34:03] It's not perfect and will make mistakes, but it's much better to optimize if you know why it made a mistake than a human saying sorry, next time better. Weak projects continue too long because we take assumptions; the new way is much faster with more options because AI products can use different models to optimize, no meetings in between, with a decision pack showing what went into it.
[34:51] The business outcome: we can stop projects earlier, re-prioritize, lose less money, and invest in the right projects, in hours instead of weeks. It's important to think about the different levels of the AI product: when you start, you might not want it to take decisions, so it observes and gives recommendations, then collaborates asking for permission, and at some point operates and acts.
[35:40] Not each AI product needs to go to level three; some stop at level two because collaboration is enough. Each AI product can be at a different stage, and when you design your system you think about the right product at the right time so it doesn't always have write access. What does it all mean? We will operate our company differently at some point.
[36:31] We want the foundation we already have with feedback loops and trusted data for all our data products. Then we think about the capabilities already in the company, not each and every AI tool. I never use the word AI application because AI application is a support system a human needs; AI products operate certain areas of our value chain.
[37:17] We use these AI products in a lot of different AI systems that are part of our value chain, orchestrating them again and again, and these AI product systems interact with people because in renewables a lot still needs humans; the AI won't take the screwdriver and replace a part, so it still works with field service and stakeholder interaction.
[38:04] When you go to a community to say you want to build wind farms, you might not want the AI to do all the talking, and experts sometimes improve the AI product, so it goes hand in hand. But I believe they operate all the routine and analytical work, so our expertise is available on demand 24/7, and they interact when the environment changes, not when a human writes a prompt, which is why it's so important to plug into your data and event queue.
[38:52] In the end we have the physical reality it needs to interact with, which is why humans are in there. Make the reusable part the easiest part: think about the capabilities in your company where people rely on you, and make that accessible for everyone 24/7 instead of writing the prompt every time. Then automate it, publish it as an AI product, and compose it as systems so they interact. Build once, and reuse it everywhere. That's what we build at RWE Renewables. Thank you.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.