Bring Context to the User, Not Just the Model

You click a ticker, trade, or client name in your AI chat.

Nothing happens.

The response may be useful. It may raise the right next question or prompt the right next action: a list of instruments worth a look, products to discuss with a client, or exceptions to clear.

The applications with the context you need are already open on your desktop, most likely alongside the AI chat interface: the chart, the portfolio, the CRM, the risk app, the twenty-year-old in-house tool.

You should not have to ask the AI another question for data within those applications. But in many AI experiences, that is the only available path. You ask a follow-up question and the chat you were working in scrolls away, buried beneath the next response. A deterministic lookup becomes another model round trip.

Nor should you have to copy text out of the reply and paste it into your own applications, one at a time, stopping the action completely.

Moving from the AI response to the relevant application context should be one click away.

That dead click is enterprise AI’s quietest failure. It happens with nearly every significant AI reply, on every desk we work with, and nobody logs it as a failure. It is simply how things are. And every dead click is paid for twice: in tokens and in attention.

The model needs context to respond well. The user needs context to keep working.

The context nobody talks about

Saanya Ojha wrote recently in her article, The Token Stops Here, that “the best enterprise AI products may be the ones that know when not to use AI.” I would add this: the best enterprise AI products also work for the person, not just the model.
The industry has spent two years working on context, meaning the model’s context. Better prompts, bigger context windows, context engineering, retrieval, memory, and tools. All of it is about giving the model what it needs to answer well.

But the person reading a good reply needs context too, and ideally they need that context without losing their place in the answer they are working through.

There are attempts to address this, but most focus on changes inside the chat itself: better citations, better canvases, better widgets, better generated charts. Those features can be useful, but they still keep the user inside the chat’s own frame.

The user’s context lives somewhere else. It lives in the applications the user already runs and trusts.

An old attitude in a new window

There is a conversation I have been having with application developers for twenty years (not the ones we hire at interop.io). Ask them what they do, and the answer is almost always some version of: “I deliver my app to my users so they can do something.” Ask what else their user runs, and they often do not know. They may not care. They may not even understand why it is an interesting question.

Every silo on the enterprise desktop was built by someone who thinks like that.

LLMs and chat windows have arrived with the same attitude. Their version is easy to state: the way to support the user is to do more inside the chat window. Need the price history? Ask the AI another question. Need the client holdings? Ask the AI another question. Need the order history? Ask the AI another question.

But the moment you do that, the response you were focused on gets pushed out of view. We have all been there. You start in one place and feel like you are getting close, but each subsequent question drives a wedge between the answer you were looking for and the text now sitting in the chat UI. It becomes exhausting, nearly impossible, to remember where you were when you started.

You have paid a model round trip for data that was sitting one inch away.

There are good technical reasons for isolating and sandboxing applications. Enterprise applications and web apps should not all reach into each other casually. But there is a difference between uncontrolled integration and governed interoperability.

Interoperability provides a safe, manageable way for applications to coordinate context, transfer control, and integrate the user experience.

The context is already on your desk

The context a user needs is mostly not the model’s to give. As mentioned above, it lives in the applications the user already runs and trusts.

So the fix is not simply a cleverer suggestion from the model or an enhanced chat UI. The fix is a connected desktop.

Make the AI text clickable, and make the applications beside it listen. That is click-to-sync: click a ticker, trade, or client name in the response, and the relevant applications sync to that context. A chart, portfolio view, and news feed can respond to an instrument. A CRM, holdings view, and service history can respond to a client.

The relevant chat stays exactly where it is, in front of you. If an application that would help is not running, it can be started and placed beside the chat UI.

Desktop, in this sense, does not only mean native Windows or macOS applications. The same requirement applies when the workspace is browser-based. The point is not the operating system. The point is that the user’s working applications should be able to respond to the user’s click in the AI answer.

The plumbing for this is not new. In financial services, FDC3 is one useful standard for context sharing between applications. Interoperability is broader than FDC3, because it also covers application lifecycle, workspaces, notifications, connectors, and user-experience management.

Nor is the pattern limited to financial services. The same problem exists anywhere people work across multiple applications and where AI can support the user.

In practice, this means the chat UI should not sit outside the workspace. It should participate in the same interoperability layer as the other applications on the desktop, sharing context and responding to user actions in a governed way.

Once the chat UI is interop-enabled, the AI’s response can become a starting point for action rather than a static block of text.

Applications can join through an interop API if you own the code, or a connector if you do not. That is a known, practical shape. It is not a research project. All your applications, bought or built, web or legacy, can take part.

AI actions as support versus delegation

When I think about how interop can help the user work with AI, I think about two key styles of interaction: delegation and support.

Sometimes you want to delegate to the AI. Draft the note. Fill in the ticket. Start the workflow. Drive the applications, within whatever governance the firm requires.

But there are also many moments when you are working through an AI’s response and you do not want delegation. You want support. You want the environment to bring the relevant context quietly to your desktop and leave you in charge of your own attention.

The simple version is a cup of tea (I am English). You can break off from what you are doing and go make one. Or an ideal assistant can bring one to your desk without being asked, set it down quietly, and leave you to drink it when you want. That second approach is support. I have never had an assistant, but I can dream.

Enterprise AI needs to make use of both delegation and support. Sometimes the AI should act. Sometimes the environment should respond to the user’s need for context without turning that need into another chat exchange.

Where MCP fits

This distinction also helps answer a common question: MCP tools already let AI take action, so why do we need interoperability?

MCP tools are useful, and interoperability makes full use of that mode of integration. But an MCP tool call is the model’s decision, made while composing or extending a reply. That helps delegation. It lets the AI use systems on the user’s behalf.

Support is different. The user is already reading the reply. They may need more context to understand, check, or act on it, but they do not want another AI turn, another generated reply, or another application taking over the screen. They want to click something in the reply and have the applications they already use show the relevant context beside it. That is the distinction.

MCP helps the model call tools and systems. Interop helps the user’s application environment respond, coordinate and share context while the user works.

There are deeper questions about MCP tools, delegation, focus, tool scale, code mode, and orchestration. Those are important too, but they are different posts. This piece is about the first gap: helping the user work within the AI’s response.

The question to take away

How do you work with the response once the model has done the clever part?

Do you find yourself asking follow-up questions in chat for information that already exists in the applications running on your desktop? Do you find yourself copying from the AI chat into other applications to recover context the desktop already has?

If the honest answer is yes, the model is not the only thing that needs context.