Is io.Intelligence trying to replace an existing AI platform/vendor?
No. The idea is not to replace existing AI platforms, models, or agent frameworks.
io.Intelligence focuses on the interoperability layer: helping LLMs understand and interact with io.Connect applications, workspaces, context, tools, methods, and intents. It is designed to fit into existing AI initiatives rather than require teams to start over.
What are the main modules in io.Intelligence?
- Working Context provides awareness of selected business context from the user’s current workflow.
- MCP SDK exposes io.Connect capabilities as tools that AI assistants can discover and invoke.
- AI Web provides the frontend runtime for building custom assistant experiences.
- AI Server provides server-side integrations that connect agent backends to io.Intelligence frontends.
- io.Assist provides a ready-made assistant UI built on AI Web, available for React and Angular.
io.Intelligence also includes Code Mode, an optional capability that lets an assistant orchestrate tools by writing code that runs in an isolated sandbox. This can help with workflows that combine several tool calls or process their results, while the integration controls which tools the code can access. Framework overview
What is Working Context?
Working Context is a JavaScript/TypeScript library that collects and maintains selected business context from io.Connect. Its schema supports global shared contexts, workspace contexts, channel contexts, and application-instance contexts.
When Working Context is integrated into AI Web or io.Assist, a fresh context snapshot can accompany each request to the backend, allowing the assistant to use the current selection without first calling a context-retrieval tool. When Working Context is configured only through the io.Intelligence MCP server, it is exposed through a tool that the model must invoke to retrieve the current context. Working Context guide
Does Working Context send all application data to the LLM?
No. Developers explicitly define which properties to track, including each property’s type, source, and path within that source. Working Context does not automatically collect all io.Connect state. For example, a schema could track a userId at a specific path in a named global shared context. Schema configuration
Why is Working Context useful?
Working Context allows the assistant to become situationally aware.
For example, if a user selects a client in an application, the assistant can understand who the current client is without the user having to type the client’s name again. The user can ask “Who is my client?” or “Open the portfolio for my client,” and the assistant can use the current context to respond or act.
This reduces the need for explicit prompts and makes the assistant behave more naturally inside an application workspace.
Does Working Context require tool calling?
Not necessarily. The current context can be inserted into the assistant’s system instructions, so the model has access to fresh contextual information before deciding what to do.
This is different from a flow where the model must repeatedly decide to call a tool to retrieve the current state.
What is the MCP SDK?
The MCP SDK connects io.Connect capabilities to LLMs through the Model Context Protocol.
It allows io.Connect methods, intents, FDC3 intents, and system capabilities to be exposed as tools that an LLM can discover and invoke. This lets the assistant do more than answer questions. It can interact with the application environment.
What are dynamic tools?
Dynamic tools are tools registered by applications at runtime.
An application can register an interop method with additional metadata, such as a tool name, description, input schema, and output schema. The MCP SDK detects that metadata and exposes the method to the LLM as a tool.
Dynamic tools are flexible because application teams can expose capabilities directly from their applications. However, they also require care. If too many tools are exposed, or if their descriptions and schemas are unclear, the LLM may struggle to choose the correct tool.
What are static tools?
Static tools are defined during MCP SDK initialization.
Instead of letting applications expose tools dynamically, an administrator or platform team can define a controlled list of tools. Each static tool includes configuration such as name, description, input schema, output schema, and the interop method, intent, or FDC3 intent that should handle execution.
Static tools give more governance over what the LLM can access and how tools are described.
What is the difference between constant and variable availability for static tools?
Static tools can use different availability modes:
Constant availability means the tool is exposed to the LLM when the MCP server starts, even if the underlying interop method is not currently available.
Variable availability means the tool is exposed only when the underlying method is actually available.
Constant availability can help keep the tool list stable, which can improve prompt caching, speed, and cost. The trade-off is that the model might call a tool whose underlying method is not available, which results in an error.
Variable availability avoids exposing tools that cannot currently execute, but the available tool list can change during the session.
What are system tools?
System tools are built-in io.Connect-aware tools provided by the MCP SDK.
They help the LLM understand the application environment. For example, the assistant can search for applications or workspaces that match the user’s intent, understand what type of context those applications expect, and start the relevant applications or workspace. Instead of requiring the user to know which application to open, the user can describe the task. The assistant can then search available applications and workspaces, decide which ones are relevant, and start them with the right context.
This is useful in environments with many applications, where discoverability is a common problem.
For example: the user asks to review a client’s portfolio performance and check whether rebalancing is needed. The assistant uses system tools to identify several relevant applications, create a workspace, and pass the selected client context into each application.
What is AI Web?
AI Web is the front-end SDK for building assistant experiences in io.Connect environments.
It does not provide a visual UI by itself. Instead, it provides APIs and runtime capabilities for working with agents, threads, Working Context, tools, prompts, MCP Apps, MCP servers, io.Connect operations, and AI Server communication.
It is framework-agnostic and can be used in both io.Connect Browser and io.Connect Desktop.
What does AI Web handle?
AI Web handles much of the front-end complexity needed for an assistant experience, including:
-
Connecting to MCP servers
-
Working with io.Connect
-
Managing Working Context
-
Handling agent threads
-
Supporting tool flows
-
Supporting MCP Apps
-
Communicating with compatible backend agent systems
-
Applying built-in prompts that help the LLM use tools and context correctly
This lets teams build their own assistant UI without reimplementing the underlying integration logic.
What is AI Server?
AI Server is the server-side module area of io.Intelligence. Its first released integration, AI Mastra Bridge, connects Mastra-based backends to AI Web and io.Assist.
These frontends communicate with backends through the io.Intelligence Agent Protocol. The protocol uses AG-UI streaming and adds the HTTP routes and behavior needed for agent discovery, thread management, and frontend tool-result reporting. AI Server overview, Agent Protocol
What is io.Assist?
io.Assist is a ready-to-use assistant UI built on top of AI Web.
It provides the chat interface and visual layer, while AI Web handles the underlying assistant logic. It is available in React and Angular versions.
io.Assist is useful when teams want to get a working assistant running quickly without building the entire front-end experience from scratch.
Can teams replace io.Assist with their own UI?
Yes.
io.Assist is intentionally a thin UI layer on top of AI Web. Teams can start with io.Assist for speed, then replace it later with a custom assistant interface if they need a different user experience.
The video also mentions that the documentation includes a guide showing how to remove io.Assist and build a custom chat experience with AI Web.
What are MCP Apps?
MCP Apps are interactive UI components that can be rendered by an assistant instead of returning only text.
For example, instead of answering with plain text, the assistant can render a widget, selector, table, chart, or other interactive component.
This makes the assistant experience more useful when the user needs to inspect or interact with structured information.
How does io.Intelligence handle MCP Apps differently?
The standard MCP App experience usually renders interactive components inside the chat canvas.
io.Intelligence supports that, but also allows MCP Apps to be rendered beside the chat inside an io.Connect workspace. This means users can keep the chat visible while interacting with one or more apps side by side.
This is useful for comparisons, multitasking, and better use of screen space.
Why render MCP Apps in a workspace instead of inside chat?
Rendering MCP Apps inside chat works for simple cases, but it can become difficult in long conversations.
If the user has many interactive components in the chat history, they may need to scroll back and forth to compare or reuse them. By placing MCP Apps in a workspace, the user can keep relevant apps visible and interact with them more like normal workspace components.
The demo shows this with weather and flight widgets rendered side by side.
Can multiple instances of the same MCP App be opened?
Yes. You can set it in a way that the user is asked whether to replace the existing one or open a new instance. This allows the user to compare two apps side by side instead of overwriting the previous result.
Can MCP Apps preserve state?
Yes, AI Web can manage the communication with the workspace, saves the state, and restores it when needed.
Do MCP Apps need to understand the io.Connect API?
MCP Apps can interoperate with the io.Connect world without directly understanding the io.Connect API. AI Web acts as the bridge between the MCP App, the assistant, and the io.Connect environment.
This allows standard MCP Apps to participate in io.Connect workflows while keeping the integration layer separate.
Can MCP Apps still be rendered in the standard chat format?
Yes, if io.Assist is running as a normal window rather than inside a workspace, MCP Apps can be rendered inside the chat canvas as expected.
Can the same assistant work in both browser and desktop?
Yes. The same assistant workflow can run in io.Connect Browser and io.Connect Desktop, with environment-specific integration changes. For example the io.Assist Anywhere guide reuses the application capabilities and configuration patterns while adapting hosting, startup, app definitions, and platform configuration.