People moved on from DOS to Windows because of how the graphical UI made the powers of their computer more approachable and accessible. Most people, that is. The software developers and IT admins who need to go beyond the GUI-supported methods stick with the command-line interface (CLI).

Today, LLMs are taking over everything that’s accessible via the CLI. A big reason for this is how closely the chat experience and next word prediction capabilities these language models excel in resembles giving commands to a computer via the command-line. It’s also what the model training data is full of: easy-to-consume code, as opposed to the messy world of visual interfaces that us humans consume with our eyes. Evolution made us quick to spot the lurking predator in the woods. Code is something we’ve had to learn with little help from natural selection.

The majority of use cases where AI agents already provide value in the year 2025 are about code. As for interactions that require navigating UIs built for regular human beings, they fumble around and present massive security risks. An AI agent with a virtual computer + browser can literally be “hacked” by appending instructions to a URL by using a hashtag. Oops!

It may well take a decade for AI agents to evolve into what the tech vendors advertise as their use cases. The security gaps are a feature, not a bug of how LLMs work today. Something more than merely scaling the GPT-style frontier models probably needs to happen before we can let AI agents browse the internet while holding our credit card and credentials in their virtual hand. What are we gonna do in the meantime?

In this week’s newsletter issue I’ll reflect on potential use cases I see for the skills LLMs have today in the domain of business applications. Somewhat surprisingly, it’s about how they could help us with the UI.

“Chat is all you need.” Well, no. It’s not. We’re reaching a point where the relentlessly chatty AI assistants are producing so much on-demand text that most of us will just zone out when encountering it. A wall of text used to require effort and expertise to produce — now it’s often just proof of an LLM being let loose to do its thing without supervision.

It’s true that classic Windows apps often presented the user with too damn many buttons on the toolbar. Enterprise software became a pain to use when people didn’t understand where the tools they needed were hidden among an ever-growing list of features. Today, Microsoft is promoting Copilot + Windows 11 as the computer you can talk to. The practical results aren’t very convincing yet:

Reducing everything to a chat window would require deep trust in the computer being able to figure out exactly what we need, as well as sticking to results that contain zero hallucinations. Since it’s unlikely to happen in the near future, I don’t believe the age of the graphical app UI is coming to an end anytime soon.

Microsoft, like all other app development tool vendors, is investing in AI-driven tools that put together a GUI based on what the user prompts. I’ve already written about the App Builder (Frontier) agent in Microsoft 365 Copilot. At Ignite 2025, MS launched the “vibe experience” for creating apps on top of Dataverse tables (rather than SharePoint lists used by App Builder). As expected, it’s fairly good at generating apps that would have been pre-packaged Power Apps templates ten years ago. With modern React app styling, of course.

Since the capability for generating UIs is there, why not take it up a notch? Instead of an app maker creating one experience for many users, why couldn’t every user get their own tailored experience, on-demand? Meaning that instead of the AI responding with a wall of text, it would produce an appropriate app-style UI for the user to view and interact with.

A recent publication Google released alongside Gemini 3 gives a glimpse of the future where the UI is defined based on the context and data. Check out the Generative UI site for a few live examples that demonstrate what LLMs can do when given the task to figure out what’s the effective way to present the information and features requested in a user prompt:

When you try things like Gemini dynamic view and ask it to create a comparison of The Magnificent Seven, for example, the end result is pretty slick. Yet it takes a longer time for AI to render it than I’d prefer to wait for my Power Apps UI to open, for example (not that it’s fast either). As the models and hardware become more efficient, though, the response times could surely decrease drastically. At some point, the generated UI might open as fast as your CRM app does today.

In the visual domain, creativity can be a bonus. Whereas you’re not going to want AI to be creative when it’s telling you numbers from financial documents. Could there be some middle ground where we could get best of both worlds into use?

The foundation of what Dataverse and model-driven Power Apps are built on, essentially XRM from ~20 years ago, is a structured business system with a relational database and rules for business process operations. The Power Platform is very capable in supporting the creation and management of the artifacts that tightly link to the models followed by the business. It’s less capable in making it look all funky ’n fluid for users to access in whatever context they need.

Perhaps it’s time to separate things and make the business applications headless. The concept of headless CMS became popular around ten years ago as web developers were trying to serve the same content to a growing number of channels and use cases. Instead of a classic WordPress site where the content management and presentation are handled by the same monolithic system, the decoupling of the CMS from the frontend tech allowed using modern JS frameworks, improving site performance, scaling, deployment options, and so on.

Today, developers are trying to make traditional business app data and features available to AI agents. Both as a delivery mechanism (users chat with a bot instead of browsing a web app) as well as more atomic tools to achieve a bigger goal (retrieve the customer’s pricing details from ERP as part of a response).

One method for achieving this is similar to what RPA was all about. Don’t rebuild everything to have a clean REST API, instead give a software robot a computer and make it click the legacy app UI. While LLMs may offer more ability for computer-using agents to figure things out on their own, they come with the risk of AI agents figuring out the wrong way to do things. The web and the (majority of) business apps are built and designed for human users. Trying to get the computer to use them is always going to be messy.

What if we could offer just the relevant parts of our business app functionality to the agents? Instead of just offering raw database access and hoping for the best, it would be pretty sweet if the business app developer could define that “when you need to do X, always call this tool”. This would reduce the need to have every single detail described inside agent instructions. Just like a headless CMS lets the content authoring and lifecycle management happen without letting the JavaScript frameworks of the frontend get involved in any way.

Now, I don’t know whether this is exactly what the Power Apps MCP Server shown at Ignite 2025 is going to be about. But the demo and slides sure make it look like it could offer a world where you don’t have to choose between the app and the agent. Rather the backend Power Platform functionality and business processes could serve both types of consumers.

The “S” in MCP stands for security, as they say. Meaning: giving your AI agent access to MCP servers outside your control is in general a bad idea, due to many examples popping up in tech news all the time. Even Microsoft has warned about the risks of MCP. Just because someone somewhere has implemented an MCP server, it doesn’t mean you should trust it as the toolkit for your AI agent handling processes related to money or customer data, for instance.

As a technology used within the closed doors of Microsoft’s own cloud, though, it sounds a lot more interesting for real-world usage. Especially if the Power Apps MCP server turns out to be something that provides configurable actions specific to the context of existing business apps. We don’t have official details about how it works, yet I see this as potentially unlocking the “headless business apps” approach for mainstream business process scenarios.

No matter how quickly AI can spin up a graphical experience around a process, it’s not necessarily beneficial for the business to have ultimate flexibility in their tools. After all, organizations usually train their human workers to follow common processes and rules. The repeatability of doing one thing and getting the exact same output every time is most often a virtue.

Today’s AI tools try to actively get the users to “explore what’s possible”. It can be very tempting to throw data at LLMs and ask them to analyze, summarize and visualize it. Today, when Copilot Chat has gained the ability to design and execute Python code, Microsoft has jumped into promoting this as the way to visualize business data from Power Apps and Dataverse. Because the bubble charts look really cool in demos!