AI-Centric Desktop: New UX Patterns Beyond the Chat Interface

My name is Bob Myers. I'm the Chief Product Officer here at interop.io, and I run our io.Intelligence business unit. You've heard from a lot of our engineers today. My talk is just gonna be a little bit of notes from the field and observations on some of the UX patterns that we're seeing at clients and maybe what's working, what's falling down, and where things are going if we look around a couple of corners. So you'll leave today's conversation maybe with some challenges, and I welcome any challenges back and experiences that you're having. But we kind of start with this observation that a lot of enterprise AI today is focused on assistance and copilots, and that's a pretty logical place to start. I think a lot of times those are retrieval augmented generation based copilots. They might be tapped into a knowledge knowledge base. They can answer questions, but they can't always take actions. Depends on which study you look at, but a lot of enterprise spend, at least into the first part of this year, was focused on those copilots. But I think as everybody in this room knows, a lot of the work isn't happening there. It's happening twenty, thirty applications. We were with a client earlier today that had a hundred and twenty applications in a trader workspace. And there's just this disconnect right now of if that's where AI is actually participating, how can it become better integrated into the work that's actually being done? And so the questions that we're asking and and we're being asked about are where does chat live? Is it a part of the platform? Is it tightly coupled a single application? How can it be more useful? And so today, I'll walk you through a couple of the patterns that we're seeing and the pros and cons of of each approach. This will be a quick refresher. I think this group is is probably very familiar with these protocols. But everything I'm gonna show you from this point on, it's not really focused on io.Intelligence as much as it is the standards that are evolving in this space. And so the first one we'll talk about model context protocol, which everybody in this room will be familiar with. I think the difference in how we view MCP versus a lot of providers is it's not just about pulling data into an LLM, though it can do that. It's about finding tools and executing, methods or actions. And so that's our unique perspective on that. It's useful for gathering data, but it might be better for actually piloting your platforms and applications. That standard's evolving quickly. We're actually part of the Agentic AI Foundation, which now owns the MCP standard. We're involved in those working groups. So we're excited to see that standard evolve in places like MCP apps. So how do you make that protocol, which is a universal connector for LLMs to find data and applications, become even more useful? And Kalin talked a little bit earlier about MCP apps. We do think that's a very useful addition to the standard. FDC3, certainly not many people are talking about FDC3 in the same way that they were a couple years ago. AI has taken a lot of the the air out of the room. But this is a critical standard in our opinion, and it has a lot of the building blocks for what you need to have AI participate in the enterprise kind of workflows. So that's everything from context that's explicitly declared, intents or actions, which AI can can take care of, and just as a really metadata rich standard that unlocks a lot of the capabilities that we'll show in this presentation. And then Kalin also mentioned this. We're not going to show any A2UI today, but this idea that we're moving from a world where, UX was explicitly defined to now it can be retrieved by AI to it can be built on the fly using component libraries and standards and sort of ephemeral experiences, I think is the direction of travel. But the building blocks are here. So I think if there's any takeaway from this talk, there's plenty of standards that have evolved to the point where you have a lot of control over the experiences that want to give your end users. You just have to be clear about what you want to accomplish, with AI. So we're going to talk about, a couple of patterns here. The first one is what we demonstrated at our Client Forum, in early 2025, which I would call pull to chat. And so this is taking any, chat UI, that's an MCP, in this case, enabled chat experience and pulling data into it. So it's I call it the blender. It's a really powerful concept. I wanna pull data from a CRM. I wanna get market pricing. I wanna do analysis on, my client's portfolio. And you can actually get all that data pulled into a chat experience using MCP, which is now not as novel as it was when we first showed this, but it's pretty magical. And the first time you see this, you realize that the work's never gonna really be the same. Again, I didn't have to go get all this information. This falls apart almost immediately in our experience in terms of the end user experience. So there's a couple of issues with this. The first one is trust. So that end user that's just looking at this sort of wall of text that's been delivered across these different data sources does not really have a great way to validate that data. And if they can trust it to make a decision, this is not going be a talk about hallucinations with LLMs or evals to prevent that. But it's just a call out that if you're just taking data and using an LLM to analyze it, you're disconnected from the source applications. And so Ivan did a nice job earlier of showing what this can look like when you don't go down this path and actually still give the user the ability to eye check at least the data. Cognitive overload is very real. I think when we see long running sessions with users, so eight hour days using AI to ask questions and explore data, it's unrealistic to think that people are reading those walls of text that are generated in these chat experiences. It just doesn't happen. And so the way that I like to think about it is AI generates it's it's a fast producer of information, and humans are slow consumers. And this just breaks down. Most of my career has been spent in business intelligence trying to compress large amounts of data into visualizations that summarize that information and allow users to get insights out of it, text might be the worst way to do that. So if you're using chat, just think about the fact that you've now asked for the cognitive burden to be a long form readout and the human's probably not going to actually be able to grok all that information. And the last is an action gap. So MCP is great for pulling data. It could be market data. It could be internal data sources. But it doesn't always allow you to take actions. This is changing a little bit, but at interop.io, we've seen this from the beginning. I need to send an email. I need to actually open up an order to potentially make a trade. So that last ability to say what applications exist, what actions can I take, is a huge differentiator, and most chat experiences just really don't enable that? It's still about getting answers, not about taking actions. All that being said, I still think it's pretty magical. It's very valuable to pull data together from multiple sources. There are just some downsides that you need to be aware of from a UX perspective. All right. The next pattern is one that we've been pushing a lot of clients of interop.io to explore. And the way I would think about this is navigating to the source application and turning any LLM into a universal remote control. That's probably the best analogy that I can think of. So a lot of the system tools that Kalin and his team have built are around discovering the applications that exist that are interop-enabled and registered in the app directory, for a platform, and then being able to figure out what those applications do and the context that they can handle. So if you imagine in this world, instead of saying, you know, I wanna see client A's Tesla position and research and pulling that data into the chat experience. Now we're finding the right applications, and we're going to be opening those up. So this is a schematic. I'm trying to compress a lot of information here. But how would this actually work in practice? You've got an application directory with explicit descriptions of not only what the application can do, but what the intents or actions inside of that application are capable of and the context that it can handle. And you've now got the ability to take that FDC3 concept of an app directory and the metadata and the APIs underlying that or underpinning that. And with io.Intelligence, LLM can actually discover which applications to pick. So in this case, we found four applications. This was the example that Kalin showed earlier, and we're gonna actually open those up, and that's where the user is going to work. So in this case, instead of us looking at a wall of text in a chat experience, we're actually opening up either a pre created workspace or a dynamically created workspace that has all the applications with the context. And again, this is an example, Tesla, for example, in in context, and that's where the user can get to work. And they're working in that application. This is their entitlements. There's probably been a lot of design work spent thinking about the user experience, and there were going to be visualizations that compress some of that data. This is taking advantage of the application estate that you have today with the LLM actually helping to navigate or pilot your platform. And again, there's a lot of benefits to this approach. The first is that it's relatively cheap compared to pulling data into a context window. So in this case, the context window is really just used to look for applications that can handle the user's request as opposed to pulling in a data package and and analyzing it. Depending on your stance on privacy or LLMs handling PII, you also aren't really sending any of that sensitive data to an external LLM if that's what you're using. And that may be less important depending on your firm, but in this case, you're really just using the LLM to pilot your applications. For the user, you don't have to worry about hallucinations. This is a preexisting trusted application with your entitlements filtered to the context that you need to use that you've probably been trained on previously that you're leveraging alongside the LLM. So you can trust that you can take actions, and it's been built to work with your cognitive abilities. It's got visualizations. It's got progressive discovery. It's got all the things that you would need as an end user. So for me, this is probably a better place to start than a pure chat experience where you're dumping all that information on the user. A lot of you have very complex platforms and application estates. And navigating them, I think one of the top requests that we get is how can we make discoverability easier for our end users? And I think LLMs are a great way to accomplish that alongside the FDC3 standard. All right. The last pattern, kind of a blend of these two, but it's taking advantage of some of the evolution of the MCP standard. So MCP apps is a very cool concept that keeps power with the application developer. I don't know if that came across earlier, but these MCP apps are designed by the same app teams that are building out their actual application. You can think about it as an interactive widget that they can make available to be used in a chat experience. So this isn't something that on the io.Assist side we're defining. We have built some MCP apps as our sort of reference implementation or for platform capabilities, but this would still come from your CRM, from your trading platform if it was available. So those app developers still have full control over this experience. What's happening is it's actually being rendered back into the chat experience. So now we're not going to the source application. We're keeping it in one modality. In this case, that's chat. And as Kalin elegantly showed before, this is really cool until you have a long running conversation and that beautiful visualization gets buried in the upper regions of the chat. And now you're scrolling. And so the the chat as a modality across long running sessions, I really think starts to fall down. These conversations are long. If you need to go back to information, it's buried above. And the best way to solve that right now, in our opinion, is to take advantage of something like workspaces to offload those visualizations into. So in this case, we've got the ability to open it in a workspace, which is part of what the io.Intelligence package offers. And again, it's a basic UX concept, but I think this is the opportunity as we all serve end users to think about what this experience should look like. Are you gonna dump all of your data into chat and have me read it? Are you gonna return an interactive widget? Is that widget gonna live on the side? Is it gonna create a new workspace for me? These are the building blocks and the types of questions that you're going to want to challenge yourself as you think about the end user experience. So the patterns that we're seeing, and if I was giving this talk next week, there'd be probably a couple more columns. Leslie and I were talking about interaction models that are able to actually move from turn-based AI experiences, which is still what we're really talking about. The user interacts with the LLM in a turn-based fashion. So I'm not looking at that yet. But the recap here is you can pull all the data to the chat. You can use the LLM to find applications and workspaces and platforms for the user, which I think to me is a sweet spot right now that if you're not using, I would highly recommend. And then if chat is your common modality, think about maybe a Microsoft Teams experience where it's just a it's such a common piece of the desktop already, maybe you do want to pull applications in there. And so surfacing an application inside of something that already owns real estate and users are comfortable with might be a way to really get distribution of a capability that's buried somewhere else, in your enterprise. So those are the three patterns that we're seeing today. Pros and cons, but all of those are opportunities to think about end users receiving value from AI and LLMs. In terms of where we're going, we talked about A2UI earlier. Right now, I think it's still all around predefined user interfaces, whether those are MCP apps or your existing application estate. And I'm not a Luddite, but I don't think we need to immediately burn everything down and move away from the existing applications that have been built and that are trusted. In fact, for me, I think it's more about finding value with AI and those user experiences. That being said, it's very clear that as users think about describing what they want and building on-the-fly workspaces that take those components and compose them together on the fly, there's a lot of opportunity in the middle. And the frontier, if we think about pulling data into the chat experience, what's powerful about it is that data actually doesn't live together today. It might be information on the market. It might be information on a user's portfolio that is useful to have together. My biggest criticism of that modality is that it's a wall of text. But what if a generative UI interface that actually takes that information and delivers it in a way that humans can get information quickly using visualizations and progressive discovery could be built. And I think that's what we're seeing with A2UI and other components is that's not that far away to say you don't actually have to have a predefined application. It can be built on the fly for you using AI. I don't think we're there yet, but I think we all see that that's an interesting direction of travel. So the desktop is definitely changing. The speed at which applications can be built and integrated, as Graham showed in his presentation, is changing. For us, I think it's about meeting this moment with the investments you've already made, interop.io as an enabler, and LLMs to really add value to your users. But I would just be cautious in terms of what that end user experience is, how much it can be trusted, and a lot of the considerations that we talked about earlier from Ivan's conversation around just lessons learned, cost, value, ROI, those types of things are really important as well. So we'd be happy to talk to you about those experiences. Quick plug for io.Intelligence, it enables all of those patterns, everything from MCP apps to chat experiences and piloting your platform. So if you haven't taken a look at that, highly encourage you to do that. I think that'll be useful. Looking ahead on the road map, we've accomplished the first set of capabilities that we really set out to build. I'm really proud of the team, really appreciative of all the client feedback we got along the way. But we've got a framework that is ready to go and meet you wherever you are in your AI journey. If you've got nothing, we can get you started very quickly with an AI experience and chat assistant. If you already have those capabilities, we've got system tools that immediately allow you to leverage the interop.io platform, find applications, find workspaces, open them, and so much more. Where we're focused going forward is really around trying to be better stewards of things like tokens. So tokenomics is a is a very real consideration. I think we're all in a little bit of sticker shock looking at what the input and output prices are for tokens going forward. And so where we fit into this is finding ways to manage context windows, compression algorithms for our io.Assist application. But probably more importantly, and I'm gonna turn it over to Kalin to talk about this in practice, introducing some new capabilities like a governed sandbox where the LLM can actually write code as opposed to calling tools. We think this will significantly reduce the amount of token spend, and we plan to ship with io.Intelligence our own sandbox with Code Mode in the coming months. But I'm gonna turn it over to Kalin to give you a real-life example of what that looks like as it's coming soon to the product. Thank you.