This is an overview of io.Intelligence framework: what is available today, why the modules were built, and how they work together to bring AI into io.Connect environments.
1. Working Context
Working Context is a JavaScript module that gives the LLM controlled awareness of the user’s current state using global context, window context, workspace context, channel context, or application-specific context.
By default, nothing is tracked. The developer explicitly defines the schema, such as: track userId from a specific path in global context. Working Context then keeps a fresh snapshot of that data and makes it available to the assistant.
This is useful because the assistant can gets the context without the user having to repeat information. For example, once a client is selected in an application, the user can ask “Who is my client?” or “Open the portfolio for my client,” and the assistant can understand the current client from context.
2. MCP SDK
The MCP SDK connects io.Connect capabilities to LLMs through tools.
Dynamic tools
Dynamic tools are 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 this and exposes it to the LLM as a callable tool. This is useful because application teams can expose their own capabilities directly. However, it also needs governance. If too many tools are registered dynamically, or if their schemas and descriptions are unclear, the model may struggle to choose and use them reliably.
Static tools
Static tools are configured when the MCP SDK starts. Instead of allowing any application to expose any tool dynamically, administrators can define a controlled list of tools with clear descriptions, schemas, and allowed handlers.
This gives more controл. In addition static tools can use different availability modes:
-
Constant availability means the tool is always exposed to the LLM, even if the underlying interop method is not currently available.
-
Variable availability means the tool is only exposed when the underlying method is actually present.
System tools
The MCP SDK also includes io.Connect-aware system tools. These help the LLM discover and use the application environment.
For example, the assistant can search for applications or workspaces that match the user’s intent, understand what context each application expects, and then start the right applications or compose a workspace.
Example: the user asks to review a client’s portfolio performance and check whether rebalancing is needed. The assistant identifies the relevant applications, understands that they can work together in a workspace, starts them, and passes the correct client context into each one.
3. AI Web
AI Web is the front-end SDK for building AI assistants in io.Connect environments.
It does not provide a UI by itself. Instead, it provides the APIs and runtime capabilities needed to build assistant experiences (threads, Working Context, tools, prompts, MCP apps, MCP server connections, io.Connect operations, communication with AI Server.
AI Web is framework-agnostic and works across io.Connect Desktop and io.Connect Browser. It allows you to build custom assistant interface while reusing the underlying logic for context, tools, MCP connectivity, and io.Connect integration.
4. io.Assist
io.Assist is the ready-to-use UI layer built on top of AI Web, available in React and Angular versions. It provides the visual chat interface, while AI Web handles the deeper integration with agents, tools, context, and MCP apps.
Use it to get a working chat assistant quickly without building the front-end experience from scratch, then later replace or customize the UI if needed.
5. AI Server
AI Server is a set of adapters and extensions that help io.Intelligence work with existing AI backends.The first AI Server adapter is the Mastra Bridge, which allows Mastra-based backends to work with io.Intelligence. AI Server allows io.Intelligence to ealily plug into different agent architectures (for example if you already use something like Mastra or LangGraph).
MCP Apps and Workspaces
MCP Apps allow an assistant to render interactive UI elements instead of returning only text. The io.Connect ecosystem allows for:
-
Rendering MCP Apps inside the chat canvas.
-
Rendering MCP Apps beside the chat in an io.Connect workspace.
The workspace approach solves a common chat UX problem, that interactive widgets can become buried in the conversation history. By rendering them in a workspace, users can compare apps side by side, manage screen real estate better, and continue working with the UI without scrolling through chat.
MCP Apps don’t need to understand io.Connect directly. AI Web bridges the MCP App world and the io.Connect world, handling workspace placement, lifecycle, and state behind the scenes.