My 7 EPPC2026 takeaways

I have attended this year’s European Power Platform conference in Copenhagen and I loved every moment of it. The sessions, the networking, the insights, the location. My favourite thing: seeing how other professionals in the Power Platform space are navigating the changing landscape and how they continue to find ways to create value with curiosity and enthusiasm.

I was one of only three people from my company who got to attend the event this year. That is a privilege, and it comes with a responsibility: bring the learning back.

So, after taking 3 days to let everything sink in and reviewing all the material I have gathered, I have summarized my take in 7 short takeaways to give you an idea of where I think the journey is headed.

And it’s headed somewhere exciting, so buckle up!

1. Governance is becoming enablement infrastructure

EPPC2026 made one thing clear to me: AI is not replacing Power Platform governance. It is exposing whether we had usable governance in the first place. The strongest governance message was not "lock it down." It was:

make the safe path easier to follow.

The old governance model is easy to describe: everything goes through the same queue, everyone waits, and the admin team becomes the bottleneck. That model was already strained with Power Platform. Agents make it worse.

The stronger pattern is risk-based enablement.

That means giving makers a safe place to start, clearer boundaries for what they can build, and a visible path from personal productivity to managed production. It also means treating governance as something we design into the platform: environment routing, managed environments, environment groups, sharing limits, solution checks, scoped admin roles, ownership, review cadence, and cost controls.

The practical question changes.

Not: "How do we stop people from building?"

But: "What conditions make it safe for more people to build?"

That is the difference between governance as a brake and governance as infrastructure.

For me, the useful move is to map the maker journey like a product journey. Where does a new maker start? Where do they get guidance? When does a solution outgrow personal productivity? What must change when it becomes business-critical? Who owns it after go-live?

A safe path is not just a policy. It is a route through the platform.

Do this: pick one maker journey and map the current friction. Find the places where a clear guardrail could replace a manual gate.

Public resources to keep learning:

2. Agents are becoming work architecture, not just chat

The most useful agent sessions were not about better chat. They were about where the agent sits in the process.

Sometimes the right answer is a deterministic workflow. Sometimes it is an agent. Sometimes it is both: a workflow for predictable steps, an agent for judgment-heavy steps, and a human approval where the consequence matters.

I kept hearing the same architectural question in different forms:

How much autonomy has this task earned?

A low-risk summarisation task can tolerate more flexibility. A process that writes to Dataverse, sends a customer message, touches finance data, or changes a business record needs more structure.

That structure can include scoped tools, explicit instructions, test cases, telemetry, approvals, cards, and rollback paths. The agent is one part of the design. The work system around it matters just as much.

A few patterns stood out:

Put AI inside the process, not beside it as a separate chat window.
Use workflows for steps you can draw on a whiteboard.
Use agents where the path genuinely changes based on context.
Design the handoff to humans before production, not after the first scary result.
Treat cards, approvals, and app surfaces as part of the agent experience, not UI polish.

This is a big shift for Power Platform people. We need to get sharper at choosing between app, flow, workflow, agent, multi-agent pattern, and human-in-the-loop process.

The future is not "everything becomes an agent." The future is more composable than that.

Do this: take one process you know well and mark each step as deterministic, judgment-based, or human-owned. That is the start of a better AI design.

Public resources to keep learning:

3. Agent governance is a trust-boundary problem

The more useful agents become, the more boundaries they cross.

They use connectors. They call APIs. They can use MCP servers. They may communicate with other agents. They may act through service accounts, delegated identity, or app registrations. They create transcripts and traces. They show up in inventories that are useful, but not always complete enough on their own.

That was one of the clearest security themes for me: an agent is not just an app. It is an actor.

So the governance questions change:

Who is the agent?
What can it access?
Who does it act as?
Which tools can it call?
Which conversations and actions are logged?
Where does the transcript live?
What happens when the agent calls another agent or an external MCP server?

Visibility is necessary, but visibility is not the same as control. An inventory tells us something exists. It does not automatically tell us whether the agent is safe, useful, owned, reviewed, or correctly scoped.

For anyone working with Power Platform, Copilot Studio, Microsoft 365, or AI governance, this is the area to watch closely. MCP, A2A, Agent 365, Entra Agent ID, Advanced Connector Policies, Dataverse RBAC, OAuth on-behalf-of, transcript retention, and registry views are starting to belong to the same conversation.

Before we celebrate an agent going live, we should be able to draw its trust boundaries.

Do this: pick one agent or planned agent and answer three questions: who owns it, what tools can it call, and whose identity does it use when it acts?

Public resources to keep learning:

4. AI readiness starts in the data model

A lot of EPPC content was about agents, Copilot, and new AI surfaces. Underneath that, another message kept repeating: AI is only as useful as the foundation it reads from.

That foundation is not only "the data."

It is table names, column descriptions, relationships, views, semantic models, Power BI measures, date tables, knowledge-source scope, security trimming, and the business meaning we encode into the platform.

One Dataverse pattern made this concrete for me: descriptions are no longer just maker documentation. They can become part of how AI understands the business. A vague status field is not just untidy metadata. It can become a reasoning problem.

The same theme appeared in Power BI and Fabric material. If the semantic model is weak, Copilot has less useful context. If reports live as opaque files with no source control, review and collaboration stay harder than they need to be. If a model has no proper date table, time intelligence becomes fragile.

For agents, grounding is also an architecture decision. SharePoint, Dataverse, Fabric, Azure AI Search, Graph connectors, uploaded files, and MCP servers all create different trade-offs around freshness, permissions, citations, auditability, and risk.

AI readiness is not a toggle. It is a data-foundation habit.

Do this: choose one table, report, or knowledge source that AI is likely to touch. Review its descriptions, ownership, security model, and business meaning. Ask: would a new colleague understand what this field really means? If not, an agent may not either.

Public resources to keep learning:

5. AI-assisted app development still needs contracts, tests, and ownership

AI can get us to a prototype fast. It does not remove the need for architecture.

The Power Apps track had a lot of energy around Code Apps, Vibe Apps, Generative Pages, and AI-assisted development. The interesting part was not "AI can build UI." We already know it can produce something quickly.

The more useful question is: what happens after the impressive first demo?

AI-generated apps still need security review, role design, ALM, testing, ownership, accessibility, performance thinking, and a clear responsibility boundary between what the platform gives us and what the team still owns.

The line that stuck with me:

Treat AI-generated code like a junior developer's first pull request.

Helpful? Yes.

Fast? Often.

Production-ready without review? No.

The most practical pattern I saw was the design contract. Do not just ask AI to "make it look good." Give it tokens, components, rules, behaviours, constraints, examples, and a clear spec. The better the contract, the less randomness the model gets to invent.

This matters because Power Platform now has more app surfaces than before: model-driven apps, canvas apps, custom pages, generative pages, code apps, vibe-style generation, and Power Pages. The surface choice is not just a UX preference. It changes what the platform owns and what the delivery team owns.

Do this: before using AI to generate an app surface, write the review checklist first: data access, roles, write paths, ALM, tests, owner, and support model. Then prompt.

Public resources to keep learning:

6. Automation craft still matters in the agent era

With all the focus on agents, it would be easy to treat classic Power Automate skills as yesterday's topic. That would be a mistake.

Production automation still needs the boring disciplines: naming, structure, error handling, retry logic, monitoring, connection ownership, performance, child flows, solution design, documentation, and supportability.

Agents may decide what should happen next. But very often, a flow still performs the action.

That makes flow quality more important, not less. If a flow is slow, brittle, impossible to read, or owned by the wrong person, adding an agent in front of it does not make the architecture better. It just makes the weak point harder to see.

This is good news for Power Automate people. Existing automation craft is not obsolete. It becomes part of the agent-era foundation.

The future is not agents instead of flows. It is agents plus reliable automation, with the right boundary between judgment and execution.

Do this: pick one business-critical flow and review it as if an agent might call it tomorrow. Is the owner right? Is the error path clear? Are inputs validated? Can someone else understand it in six months?

Public resources to keep learning:

7. The human layer is part of the architecture

The Inspire sessions were a useful counterweight to all the product news.

Yes, the technology is moving quickly. But the repeated message was human: people need context, confidence, ownership, safe practice, champions, language they understand, and a reason to change how they work.

AI adoption is not a licence assignment.

It is a change in how people learn, decide, and take responsibility together.

Copilot adoption is a real change journey, not a training calendar. Public enterprise stories showed the same pattern from another angle: AI only scales when governance, adoption, and operations grow together.

The strongest human-governance point for me was ownership.

AI can draft, summarise, suggest, and act within boundaries. But AI does not carry accountability. A human still owns the outcome, especially where decisions affect customers, colleagues, compliance, or trust.

That means enablement has to be practical. Not: "Here is a cool tool, good luck."

More like: here is where AI is safe, where it needs review, where a human must decide, how to record the decision, and who to ask when something feels wrong.

This is also where co-elevation matters. The people who attend conferences, test new features, or work close to the platform have a responsibility to bring others with them.

Do this: for one team you work with, define the first three AI habits they should practise together - and the one human decision they should never outsource.

Public resources to keep learning:

The pattern underneath all seven

When I put the seven themes next to each other, the pattern is clear:

AI is pushing Power Platform work from "build the thing" to "design the operating system around the thing."

That operating system includes:

where makers build,
how solutions move from experiment to production,
how agents get identities,
what tools they can call,
where their actions are logged,
what data they are grounded on,
how AI-generated code is reviewed,
how flows behave when an agent calls them,
and which human owns the outcome.

That sounds like governance. But it is also architecture. And adoption. And change management.

That is why this space is so interesting.

The next wave of Power Platform work is not only about making AI more capable. It is about making capability safe enough, understandable enough, and useful enough that organisations can actually say yes.

My 7 EPPC2026 takeaways

1. Governance is becoming enablement infrastructure

2. Agents are becoming work architecture, not just chat

3. Agent governance is a trust-boundary problem

4. AI readiness starts in the data model

5. AI-assisted app development still needs contracts, tests, and ownership

6. Automation craft still matters in the agent era

7. The human layer is part of the architecture

The pattern underneath all seven

0 comments

You might also love