AI Happens Twice -- Copilot, Your Data Platform and the Bridge

This post is also available in German: KI entsteht zweimal -- Copilot, deine Datenplattform und die Brücke dazwischen

My motto on the speaker slide for this talk was “sometimes you have to tell the tiger that it’s orange”. It’s the kind of line that only makes sense once you’ve seen the problem it’s about, and the problem in this case was one that Jens Kröhnert and I had each been looking at from opposite sides for years. Jens is Principal Solution Architect at ORAYLIS in Düsseldorf, where they build data platforms, data warehouses and business intelligence. I come from Microsoft 365, SharePoint and now Copilot at Solvion. We only met this year, found out that we’ve both been with our companies for about twenty years and that we think in surprisingly similar patterns, and decided to put both perspectives on one stage at a Copilot day in Vorarlberg, under the title “From Copilot to agents: how companies scale AI productively”.

AI often happens twice

When we say AI initiatives fail, we don’t mean the dramatic kind. We mean the projects that start with a lot of enthusiasm, and then after two, three, four or five months somebody asks whether anyone is actually using it. The answers vary. Some say it’s a much better search, some use it as an answer machine, and then comes the question that decides everything, usually once the pilot is over. Do we license more people, fewer, and who’s next? That’s the point where we see things break.

And they break because AI usually starts on two separate islands. In the business, people try Copilot and their first agents. Some are all in and push to see what works, others need to be picked up. On the IT side, the reactions range from “we need this, it’ll bring us so much, but it has to be secure” all the way to “we don’t want this at all, where’s our data, will they train on it?” Every one of those concerns is legitimate. But if you asked both sides separately where they stand and where they want to be with AI next year, would you get the same answer?

Frontend AI, backend AI and the competence nobody owns

Jens gave the two sides names that I’ve been using ever since. Frontend AI is Copilot, the AI every employee has in front of them, good for everything from a cake recipe to a real business question. Backend AI is the consolidated data platform, the place where a company finally pulls its most important data out of the operational silos and creates one version of the truth. It used to be called business intelligence, today it’s a data lake or an analytics platform, and the names keep changing while the idea stays the same. In Jens’s experience, many companies still haven’t done that homework.

Each side has a typical blind spot. The data platform delivers insights, but the potential never reaches the daily work, and governance and lifecycle exist but never make it to the frontend. Copilot agents, on the other hand, use what’s easy to reach rather than what actually counts, and their use cases end exactly where company data begins. Our colleagues learn Copilot, use it, and then ask the obvious question. How do I get to my KPIs, my revenue numbers? Not everything lives in Microsoft 365, not even in our own company, and that next step of bringing your real work context into the context window is what this year has been about, with MCP servers and similar tools.

So successful AI needs three competences, not two. Backend AI, frontend AI, and the ability to connect them, which is the one that usually sits with nobody.

The shortcut that only gives you your own truth

With my background I could sit down and build a Copilot agent that goes from the very top of the stack straight down to the data, in sixty or seventy minutes if I have the permissions. Easy. And then a colleague comes along and says, nice, that’s your solution with your interpretation of the data. If five people build that shortcut, you get five definitions of the same KPI, and in a large company that starts with something as basic as how margin is defined. The old SharePoint rule still applies. Just because you can doesn’t mean you should.

Jens had the matching story from his side. ORAYLIS used to be asked for business intelligence, and then at some point everyone asked for self-service BI instead, and they had to explain every time that you need a stable BI core before you let people loose with self-service. It’s the same story again, only this time it’s about context.

What the connection looks like in practice

We showed it with two demos. In the first, purchasing data sits in Microsoft Fabric, the one version of the truth for purchasing. You used to need SQL to work with it. Now you switch on a Fabric data agent and ask questions in plain language, which is backend AI. Then we switched to the frontend. A colleague in purchasing is supposed to email the top three suppliers every week, so first they need to know who the top three are. They don’t have to work that out themselves or define any business logic. From Microsoft 365 Copilot they simply tap into the backend agent that delivers the quality-assured answer, and carry on with their own workflow from there.

The second demo goes the other way round, and it’s the one people ask about. Once you can read and interpret data, you quickly want to change it, right there from your agent. There’s no built-in function for that yet, but you can write an MCP server, a tool that gets loaded into the context of your harness and that understands you’d like this or that record changed in the other system. It’s the same story as Teams ten years ago, no more context switching, you stay in one window. The non-negotiable part is identity. The write has to happen under my identity and be traceable, exactly as if I had made the change in that system myself. Because Copilot runs under my identity, that’s solvable, and it’s what makes the full round trip safe.

My recommendation is still to build the reading part first and add writing when somebody actually asks for it. Making an agent write is technically very simple. Staying in control as a human while it does is much harder, and Jens put it better than I can. For us, human control has become a more important phrase than human in the loop. You need to trust that the agent performs exactly the one atomic operation you wanted, not something that comes back as “A1, A2, A3, A4” and has quietly changed more along the way.

To get away from pharma or automotive examples, we also showed my Pizza Factory, a complete .NET application that simulates a pizzeria as a stand-in for any third-party system, because the business doesn’t only run in Microsoft 365. With the SharePoint Copilot apps and MCP apps, Copilot doesn’t just return text anymore but real interactive UI, still in preview at the time of the talk. The whole thing took me an afternoon, and the repository is public.

Microsoft is lining up the backend side under the IQ label. Fabric IQ stands for data, Work IQ is the evolution of Microsoft Graph with natural-language access to everything in Microsoft 365, and Foundry IQ covers the institutional knowledge that sits in thousands of documents somewhere else and still needs preparing before an AI can use it well. Fabric IQ is where Jens is at home, Work IQ is where we are.

IT builds the pitch, the business plays

I used to coach youth football, and one thing they taught us is to let kids play. When seven-, eight- and nine-year-olds play and you walk in, the instinct is to correct everything. Don’t. Let them play until they’re done, and then the training starts. Translated to AI, I’d like IT to see its job as building the pitch. The grass is cut, the water drains when it rains, the floodlights work, the changing rooms are there, and the lines are clear, which means security and governance. Inside the lines, the business plays. IT can’t take every department by the hand and lead it to happiness, that won’t scale. What it can do is provide central services and a frame within which a maker community can move freely without anything breaking.

Where to start

We closed with four questions, and they’re the same ones we’d ask in any first workshop. First, context and position: where do your data and their use stand, and what do the two sides know about each other? Second, target picture and impact: what should AI really change, and how would you recognise success? Even “we’re introducing Copilot” and “we’re introducing Copilot well” are two different targets, and a number in the annual report rarely depends on Copilot alone. Third, feasibility and a lighthouse: what works today, what needs a foundation first, and which case convinces both sides? Fourth, focus and a roadmap: what happens in the next six months, and who decides what?

On the roadmap I keep coming back to Eisenhower’s line that plans are worthless but planning is everything. With a new announcement every few weeks, a plan is old after four weeks, so plan in shorter cycles, three months, maybe six, and accept that the fog gets thicker the further out you look.

And put the right roles at one table: IT leadership or the CIO or CDO, the head of data, BI or analytics, the Microsoft 365 and modern work lead, a business lead with AI ambitions, and at least one person who can make decisions. It reminds me of the move from on-premises to the cloud, when the Exchange, SharePoint and directory people suddenly had to talk to each other although they’d been in the same building for years. Jens said the same thing from his side. At some large customers in the region, both of our companies have been long-time providers for years and had never spoken to each other, and neither had the departments. ORAYLIS builds the reliable numbers, we train the people who need them, and the people often don’t even know those numbers exist.

AI may happen twice. It shouldn’t end up with two versions of the truth.

The slides

The English version of our deck. The illustrations on two slides still carry their original German labels.