⚜️ Morphic Apps ... the future is Intent, not Apps !
Currently, everything revolves around apps: when we need to accomplish something, the initial step is to determine where to actually do it: Teams,SharePoint, PowerApps , is it on ServiceNow or an internal tool ? Should we use that old app someone built years ago that apparently is working in a sepcific version of a browser… Nuts right?
After finding the right app, we need to undersand how the app works, the screens and input the information in the right format, and for doing that we need to follow a process that was set up when the app was build and quite frankly its frustrating, literraly a King’s Arthur knighmare : we’re clicking, and switching tab, hoping that everything works out okay( kind a SharePoint 2007 configuration tasks on the old days ).
This should be simpler no? We are doing this for so long that currenlty , kinda feels normal …
It isn’t.
We got a clear idea on what are the goals, but its the computer that forces us to sweat out hte details and how and where to do it … which is lamme : its the machine that is in charge and we are just trying to figuring out its way of doing things
That’s what I think is about to change.
The future is not Applications is Intent
Picture this , instead of launching an application, we start with actually what we want
“I need to understand why these requests have been sitting here for more than a week, and deal with the ones we can close.”
That’s it.
I dont cherry pick the application to use, don’t request a screen or chart with details and buttons, I dont need to mention where the data is because hopefully, the system already understands what I need. It seems like we’re missing some context here: for ages when we working with technology, it’s crucial that the system that we work with, understands what we want, with no need to spelled out every little detail. Meaning it is easier for making easier for us to get things done
But until now, we’re starting from scratch and we need to explain it everything,.
The system looks at who we are, what we are doing, what we are allowed to change and what capabilities exist, building whatever experience fits the request.
Maybe we highlighted problem case list.
We ask why one group is taking so long, and the experience shifts completly because now it needs information from somewhere else.
We spot requests that we can probably close and say “check these and let me approve before anything happens," and the interface morphs again into something closer to an approval screen.
We didn’t create any of it, it was already taken care of.
No one can or could predict the exact path things would take six months prior, back when the application was still in the planning phase.
It seemed everything worked out exactly as we had hoped, making the entire experience smooth and effortless.
Morphic Apps
The concept is indeed really interesting : the app has no longer fixed boundaries, it becomes a shape-shifter changing accordily the need. It builds around the context , adapts as context changes and vanishes when we are done it.
Keep in mind, the core behind the scenes doesnt go away: data, logic, business rules, audit trails and permissions remains intact ! What is temporary is the experience that brings all together in that specific moment, focus on underlying capabilities and data into a coesive granular experience that is destroyed leaving the core intact.
Context-dependent experience deliver through dynamic apps is the key and will change the way we build and interact with software.
… and its prety much the opposite of how we being developing software currently
We tend to put everything into boxes
That’s right …
We create a solution with a bunch of capabilities inside of it , give the box a name+icon+owner and a URL.
When we want those operations, that’s the box we go.
So a team creates an app that does one thing, then another team creates something else: before we know it we have a lot of tools, and we need to keep track of all of them, so we create another system with links to all of those new apps like a app hub.
If you look close, things like MCP and Agents quietly break that pattern , they dont care which box owns a capability: it cares if the capability exists, whether it can use, and makes sense using it right now.
That’s a very different relationship with software.
We can just say something is not ok, with this request, understand whats going on and show us options instead of navigating to a ServiceNow screen to find a specific record, to change it and then open another app to validate somthing else. It’s a lot easier to have things done when we ask for what we need and get the required information… like the human we are 😁
We dont care if the system uses ServiceNow, SharePoint, an internal api or whatever …
We simply, dont care.
From an architecture point of view, those systems still matter a lot , I’m not suggesting we throw everything into one magical AI bucket and pray: its the opposite.
From the user’s point of view: why should my experience needs to match with what we happened to build around our backend systems?
AI inside Apps might just be the awkward phase
Currently we are sistematicly integrating Copilots into existing apps, which is in fact a logical step However it looks like we are subverting truly innovative technology to force it into our old traditional software model. Instead of exploring new ways to use this technology, we are limiting the full potential of Copilots.
Think a bit : when we create an app we first figure out the entire process ( from start to finish) , how the app looks like, screen include, navigation and actions. With all that done , we bring the AI compo to be available on the right-hand side of the screen…
Now we have the app and i can use it, but…
Im still inside the App…
and its boundaries,
Now… what if we reverse that?
Imagine a tool that is created by a smart layer when it’s needed: it can be a screen, a dashboard and hey, sometimes there won’t even be a ui, since its nothing for us to click on. It is a little system that knows exacly what we need and creates the right tool for the job .
This smart layer is always working behind the scenes, figuring out what we need and when we need it, its not just about having a lot of features, it’s about having a something that will adapt to what we’re doing, giving us the right tools to get the job done.
We’ve spent decades assuming that if software does something, there has to be an application for a us to interact with it. Maybe there doesn’t. Maybe the human expresses intent, and will only get an interface when there’s actually a decision to make…
Kind of cool, hum ?
This is where MCP starts getting really interesting
MCP it’s a great way to connect Agents to tools in a standard way, really useful indeed, but i find even more interesting is when an Agent can figure out what’s available in its environment on its own, instead of being limited to just one specific application.
This opens up a lot of interesting possibilities :the Agent is no longer stuck with whatever we decided to give it when we built the app, it can adapt to what is happening, discover what capabilities are available and figure out which ones actually make sense for what we’re trying to do.
And that’s the bit I find particularly interesting about MCP… It’s not only about using a tool. It’s about discovering what is possible.
If the Agent can discover that it has a governed way to create a SharePoint site, provision a Power Platform environment, query ServiceNow, deploy a solution, run an approved PowerShell operation or check compliance…
Why would I need to build one big kick as* App, just to glue all of those together? 🤠
We expose the capabilities, context and intent decide how they get used !
… and yes, the possibilities for this to go spectacularly wrong are also pretty much exponential ! #beentheredonethat
Usually this is when someone jumps in with “yes, but governance!” … which is funny, because we seem to talk about governance as if AI invented the need for it. 😁 ( oh, the stories ..)
Governance should already be there
Imagine we give an Agent a tool that can deploy something to Production and someone will immediately ask:
“But how do we stop the AI from deploying whatever it wants?”
Fair question…
But how were you stopping anything else from doing that before AI came along? 😁 lol
If the only thing protecting Production was the fact that nobody had connected an AI to the API yet… then Houston we have a problem : I’m not entirely sure AI is the governance problem.
The boundaries should already be there :we should already know who’s making the request, what they’re allowed to access, what they can actually do and where they can do it. Production should already be protected, sensitive operations should already have the right controls around them, and we should already be able to look back and understand exactly who did what.
AI doesn’t suddenly make any of that necessary… it always was.
What AI actually changes is the speed and flexibility with which capabilities get combined… which makes bad governance much easier to find, and a lot more spectacular when it fails.
For Morphic Apps, I think the interesting part can be dynamic, but the stuff underneath really shouldn’t be. The experience can change, the UI can morph around what I’m doing and the Agent can figure out what needs to happen next… but the capabilities it relies on need to be boringly predictable. 😁
If I expose a capability called Deploy Solution, I want Deploy Solution to do exactly that.
No creativity required, no bling-bling thank you.
It should know who’s calling it, respect their permissions, stay inside the boundaries we’ve defined and leave a proper trail of what happened, if I’m asking it to do something I’m not allowed to do…
it should simply say NO*.
Let the Agent be clever. Let the experience morph.
The capabilities underneath? Please be boring.
That’s not really AI governance… it’s just good architecture, let’s be honest, none of this is new.
We should have been doing it long before AI showed up.
Maybe Apps were always just packaging
That’s when I started looking at Apps a little differently.
An App is often just a capabilities set wrapped in something humans can use. We put a UI in front of them, add some navigation, connect a bit of logic and context, and package the whole thing together. It makes sense… people need somewhere to click, type, select, save and move around. But if we now have an intelligent layer that understands what those capabilities do, understands what we are trying to achieve and can put together the right experience when we need it…
…does that package still need to be fixed?
Look at Power Platform: we’ve spent years breaking application development into smaller pieces that are easier to work with, we have connectors exposing what we can do, Dataverse describing the data, flows taking care of processes, reusable components for pieces of the experience, solutions packaging everything together… all things we originally created to make it easier for people to build Apps.
And there’s a funny coincidence here…
Those same building blocks are also much easier for a machine to understand and work with than 200,000 lines of custom code written by Jeff who left the company 15 years ago and that everybody is now afraid to touch.
So maybe Low-Code wasn’t only about building Apps faster…
Maybe, without really intending to, we’ve also been breaking software into pieces that are easier to discover, understand and put back together in completely different ways.
And that’s pretty much exactly what a Morphic environment needs.
Intent becomes the front door
For me this is the bigger shift.
Tomorrow, what we want to do will be the main way we start: I don’t want to start by figuring out which App or system I need to open. I just want to start with what I’m trying to do.
From there, the system should be able to work out what capabilities it needs, understand what I’m allowed to do, bring in the right context and shape an experience around whatever I’m trying to accomplish.
I shouldn’t really need to care whether something came from SharePoint, ServiceNow, Power Platform or some API somewhere… that’s implementation detail.
And none of this means the systems underneath somehow become less important: actually, I think it’s the opposite. If we’re going to stop relying on “static” Apps, those underlying capabilities need to be even more reliable and predictable :they can’t assume they’ll always be called from that one screen, in that one App, following that one predefined path.
And obviously traditional Apps aren’t suddenly going to disappear either:sometimes I absolutely want a fixed, boring, predictable experience that behaves exactly the same way every single time.
That’s fine.
But then I look at the thousands of little Apps we keep building inside companies… the trackers, temporary project Apps, admin tools, approval Apps, that dashboard seven people look at twice a month, the form that basically exists to put a few fields in front of two APIs…
Humm…
Do all of those really need to be Apps?
I’m not convinced all of these need to be permanent Apps anymore.
Maybe the experience just appears when I need it, changes as my context changes and disappears when I’m done. The important stuff doesn’t go anywhere… the data, capabilities, permissions and governance are still there, ready to come together differently next time.
We’ve spent decades putting capabilities inside closed boxes and teaching people which box to open. Maybe it’s time to flip that around. Keep the capabilities. Keep the systems. Keep the controls. And yes… definitely keep the governance.
Just stop assuming that all of those things always need to be packaged into the same fixed App.
Let the intent decide how they come together.
Maybe the future isn’t about building better Apps after all…
Maybe it’s about software that stops asking “Which App do you want to use?", and simply understands what are you trying to do?
Which brings me to SharePoint
Funny enough, I don’t think we need to wait for some far-future Morphic platform to see the first cracks in the old model. SharePoint Copilot Apps already point straight at it: instead of building a fixed list, a fixed form and a fixed set of views and calling that “the App,” you describe the intent and the data, and the experience gets assembled around it.
It’s still early, and it’s still SharePoint doing SharePoint things underneath.
But …
the App stops being the unit you design and becomes the unit that gets generated.
That’s a much bigger deal than it looks like on a slide.
I’ll leave that thought for a future post though… 🤠
PS- Keep an eye on this space: something more practical will surface.