Three days at the Power Platform Community Conference in Las Vegas mostly leave you with a long list of announcements. Copilot Studio got a new harness, Power Pages now builds a site from a prompt, and Microsoft showed Autopilot, an agent that keeps working after you close your laptop. Back home we put the slides from our sessions side by side and asked the question our clients will soon be asking us: what does all of this mean for an organization that builds on Power Platform?

In short, almost everything we saw makes building faster. The hard part of a project just sits there less and less.

Building is cheap now. Ownership isn't.

The Power Pages team opened with a picture many organizations will recognize: six digital front doors to the same business data. A partner portal in .NET, an application form on PHP, a supplier portal in Java, each with its own way of signing in. Six security models to align, six stacks to patch and not a single place to govern them. They call it the maintenance tax. Authoring is easy. Maintenance is forever.

Duke DeVan of RSM reached the same point by a different route in his session Is Low-Code still Low-Code? Code is faster to produce than ever, for makers and developers alike. But someone still has to support, secure and upgrade it. His advice to leaders was remarkably businesslike: fund ownership for year two, not only the build.

We recognize that. A project has a budget for the build and a go-live date. What comes after is often nobody's budget. As long as building was expensive, that was easy to overlook. Now that AI produces a first version much faster, the balance flips. Microsoft is even adding a dedicated feature to Power Pages to transfer site ownership, so a portal isn't orphaned when someone leaves. Apparently that goes wrong often enough.

The platform decides what counts as low-code

The question in the title of DeVan's session is a fair one. If a developer builds a React app with Claude Code or GitHub Copilot, is that still low-code? DeVan showed the menu: canvas apps, model-driven apps, code apps, Copilot Studio agents and Azure services. None of those options says anything about how much code is involved.

According to him, the platform is what makes it low-code. He checks four things.

Hosting: does it run in an environment an admin already manages? Governance: do data policies, security roles and audit apply? Data: does the data live in Dataverse or behind connectors, rather than in a side database? Lifecycle: do solutions and pipelines carry it to production?

Four yes answers and he calls it low-code, however much code is in it. That includes a React code app, as long as someone can maintain that code. In his live demo he built the same app twice, as a canvas app and as a code app, on the same Dataverse table. Same app, just more code of your own to maintain.

To choose between the options he uses a ladder. Start with a model-driven or canvas app on Dataverse. Add a PCF control or code app where the platform stops. Bring in an agent where a person would otherwise rely on experience. Reach out to Azure only when the work genuinely has to leave the platform. And only climb a step when the one below no longer holds.

That ladder matches how we work. We are taking on more pro-code ourselves. Low-code stays the foundation. We use code where the platform falls short, and to properly review what AI writes for us. That turns the choice between a canvas app and a code app into a question of ownership: can a maker still change it next month, or does maintenance sit with a developer and a repo?

AI only where judgment is needed

Microsoft's Copilot Acceleration Team showed how automation in Copilot Studio is shifting: from cloud flows in Power Automate, through agent flows, to workflows where an agent or AI step is just another building block, next to a condition or an approval.

The demo featured Zava, a fictional insurer after a wildfire. After a disaster like that, claims arrive all at once and every inventory list looks different. The team split the process into steps and labeled each one: follows rules, needs judgment, or the adjuster decides. Checking coverage and applying depreciation follow fixed rules. Reading a messy list with lines like "TV LG 47" and finding a comparable replacement need judgment, so agents handled those. Items with low confidence, specialty items or a value of $2,500 or more went to the adjuster, who approved, rejected or put them on hold. Everything landed in Dataverse with an audit trail.

Their summary: accelerate the evidence, preserve the judgment. In their view, agents and workflows aren't an either-or choice. The question is which part of the process should be fixed and which part can adapt.

That's a useful way of working, in Copilot Studio and beyond. Walk through the process step by step and ask one question per step: does this have to happen exactly the same way every time? If so, it belongs in a fixed flow, testable and predictable. Only where the answer is no do you need a model. And every step that involves money, liability or a customer needs a person who makes the call.

Trust and cost decide whether AI sticks

The session on Autopilot, the new personal agent in Copilot, showed a Gartner forecast: more than 40% of agentic AI projects will be cancelled by the end of 2027. Gartner points to escalating costs, unclear business value and inadequate risk controls. The Autopilot team's conclusion: trust decides who succeeds.

You onboard Autopilot like a colleague, with its own mailbox, calendar and memory, and it keeps working while you're away. That's exactly why so much of the session was about governance. Every Autopilot is its own Entra Agent User, owned by one person in one tenant. Actions carry a risk tier, an approval applies only to the exact request, and every action is audited. Admins use spending policies to govern how many Copilot Credits can be consumed.

In Copilot Studio the meter keeps running too. Agents on the new GitHub Copilot harness consume Copilot Credits while you build and while they run. The Autopilot team even held a separate roundtable on how to weigh the value of an always-on agent against cost and governance, when time saved is only part of the story. That's not a question you want to answer after go-live.

The Power Pages team looked at it from a security angle. In October, PHP2Shell made the rounds: a flaw that had sat in PHP for more than a decade until researchers used AI to find it and turn it into a working exploit. Public sites in the Netherlands went offline temporarily too. "AI doesn't get tired. Every stack you run is in the queue," their slide read. If AI makes old vulnerabilities cheaper to exploit, every standalone web stack you maintain yourself becomes a bigger risk. One managed platform with one security model, where every fix protects every site, has become a business argument as well.

What we're changing in our projects

Much of this isn't new. Governance, ALM and support have always made the difference between an app that lasts and one that slowly decays. What's changing is the balance. When the build costs next to nothing, everything else suddenly becomes the largest part of the business case.

For our own projects, we're taking a few rules of thumb from this:

At the start, we ask who will support the solution in year two, and we put that in the budget. We start on the platform and only add code where the platform stops. Before anyone builds an agent, we decide per process step whether it should be fixed or needs judgment. We make Copilot Credits consumption visible up front, including runtime.

Microsoft makes building faster every year. Who keeps it running afterwards is a decision no tool makes for you.