In many environments, especially in financial services, work is spread across many applications. A user may have a CRM, market data tools, order management systems, research portals, portfolio views, communication tools, spreadsheets, and internal workflow applications open at the same time.
A chat assistant can be useful, but it is only one possible interface. In an application-heavy workspace, AI may be more valuable when it can help users find applications, open the right workspace, pass context between tools, or surface interactive components instead of only producing text.
Bob covers three patterns in the video:
- Pulling data into chat
- Using AI to navigate users to source applications
- Rendering application experiences inside chat
It also discusses the standards that make these patterns possible and the trade-offs.
The Standards Behind These Patterns
Model Context Protocol
Model Context Protocol, or MCP, is a standard that allows LLMs to connect to external systems. These systems can expose data, tools, or actions that the model can discover and use.
FDC3
For AI workflows, FDC3 provides useful building blocks because it already describes how applications can declare:
- What context they can handle
- What actions or intents they support
- How they can be discovered by other parts of the platform
- How applications can participate in coordinated workflows
FDC3-style metadata gives the AI a structured map of the workspace.
A2UI and Generative UI
A2UI refers to the idea of application-to-user-interface patterns where AI can work with UI components, not just text. More broadly, this belongs to the direction of generative UI: interfaces that can be retrieved, assembled, or generated dynamically based on what the user is trying to do.
Traditional enterprise software relies on predefined user interfaces. Every screen, component, and workflow is designed in advance. AI changes that model because users can describe what they need, and the system can potentially assemble a temporary interface around that task.
This does not mean existing applications become obsolete. In the near term, most enterprise AI experiences will still rely heavily on trusted applications and predefined components. But over time, AI may increasingly compose interfaces dynamically from approved building blocks.
Pattern 1: Pulling Data into Chat
The first pattern is the most familiar one: the user asks a question in chat, and the AI pulls data from multiple systems into the chat experience via tools/MCP.
For example, a user might ask:
Show me this client’s current portfolio exposure, recent activity, and relevant market news.
The AI assistant retrieves information from a CRM, portfolio system, market data provider, and research database. It combines that information and returns a generated answer in the chat.
This pattern works well when the task is exploratory or informational, but has several UX limitations like:
- Trust and Verification
- Cognitive Overload
- Action Gap
When This Pattern Is Useful:
- The user needs a summary across multiple systems
- The task is primarily informational
- The output is short enough to be read comfortably
- The user does not need to take immediate action
- The risk of misinterpretation is low or can be mitigated with source references
It is less suitable when:
- The data is large or complex
- The user needs visual analysis
- The answer must be verified against source systems
- The user needs to continue working inside specialized applications
- The workflow requires actions, not just answers
Pattern 2: Using AI as a Universal Remote Control
The second pattern uses the AI assistant less as a place where work happens and more as a way to navigate the user to the right applications. In this model, the user still expresses intent through natural language. But instead of pulling all relevant data into chat, the AI identifies which applications are needed and opens them in the right context.
The AI can then inspect the application directory, identify applications that can handle the relevant context, and launch the appropriate views. It might open a portfolio application, a research viewer, a market data application, and a client profile, all already filtered to the correct client or instrument.
In this pattern, the AI becomes a navigation and orchestration layer. It helps the user get to the right working environment faster.
This is where application directories and FDC3-style metadata become important. If applications declare their capabilities clearly, the AI can use that information to determine which tools are relevant to the user’s request.
The AI does not need to ingest all the underlying business data. It mainly needs enough metadata to select the right applications and pass the correct context.
Benefits of This Pattern
- Reduces the amount of data sent to the LLM.
- Keeps users closer to trusted source applications.
- Reduces hallucination risk for the business data itself. The AI is not generating the portfolio view or inventing the source data. It is helping the user reach the application where that data already exists.
- Supports action. Once the user is inside the relevant applications, they can use the tools, workflows, and controls already designed for that task.
When This Pattern Is Useful
- The enterprise already has trusted applications
- The user needs to act, not just read
- Data should remain inside source systems
- Applications expose useful metadata and context handling
- Users struggle with application discovery or workspace setup
It is less suitable when:
- The user only needs a short answer
- The application estate lacks metadata
- Applications cannot receive context
- The workflow requires generating a new analysis that no source application can display
Pattern 3: Rendering Application Experiences Inside Chat
The third pattern sits between the first two. Instead of pulling only text into chat or sending the user out to full applications, the AI assistant can render interactive application components inside the chat experience.
This is where an MCP App becomes relevant. It’s an interactive component made available by an application team. For example, a CRM team, trading platform team, or analytics team could expose a compact UI component that can be rendered inside an AI chat experience, but the application team still controls the component. The chat assistant is not inventing the UI from scratch. It is rendering an approved experience provided by the relevant application or platform capability.
When This Pattern Is Useful:
- The user benefits from staying in the chat flow
- The output requires interaction, not just text
- Application teams can provide approved components
- The component is short-lived or can be promoted into a workspace
- The chat experience is already central to the user’s desktop
It is less suitable when:
- The user needs to work with the component for a long time
- The conversation becomes too long to navigate
- The component requires a large amount of screen space
- The workflow belongs better in a full application or workspace
The best experiences may be to combine these patterns. The AI may answer some questions directly, open applications when source systems are more appropriate, and render interactive components when text is not enough.