Chapter 12: Conclusion
You have reached the end of the io.Assist Anywhere guide.
ACME Banking started with a simple goal: help customer service advisors work faster and with better context by adding an AI assistant to their io.Connect environment. Step by step, you turned that idea into a working, extensible assistant architecture.
The final result is more than a chat window. It is an assistant that understands where it is running, can discover what the user is trying to do, can call platform capabilities safely, can preview interactive workflows, and can follow the user across io.Connect Browser and io.Connect Desktop.
API Reference Map
Use this map when you revisit a specific part of the solution:
- io.Assist NG API Reference
- io.Assist React API Reference
- AI Web API Reference
- MCP Web Server API
- MCP HTTP API Reference
- MCP Core API Reference
- Working Context API Reference
- AI Mastra Bridge API Reference
What You Built
You started with a small guide workspace:
- a client list app
- a client portfolio app
- an io.Connect Browser platform
- a Mastra agent backend
- empty Angular and React assistant shells
Then you extended it into a complete io.Intelligence flow:
| Area | What you added |
|---|---|
| MCP Web | You exposed ACME Banking clients through a static MCP tool backed by an io.Connect interop method. |
| Agent backend | You connected the Mastra backend to the extended AG-UI protocol through the AI Mastra Bridge. |
| io.Assist | You built Angular and React assistant apps that can talk to the backend and the MCP layer. |
| Working Context | You gave the assistant a fresh snapshot of the current workspace context with every request. |
| App definitions | You made apps and workspaces discoverable by describing their purpose, context, and interop capabilities. |
| MCP Apps | You enabled interactive tool UI, including workspace previews through the Workspace Widget. |
| Assistant-hosted MCP Web | You moved MCP Web into the assistant for a simpler Browser deployment model. |
| io.Connect Desktop | You extended the same assistant flow to Desktop using a hidden service app and compatible app definitions. |
| MCP HTTP | You created a dedicated Desktop MCP HTTP server for teams that prefer a server-side MCP architecture. |
| AI Web | You built a custom assistant skin directly on top of the AI Web API. |
By the end, ACME Banking had several deployment options:
- a ready-made Angular assistant
- a ready-made React assistant
- a fully custom AI Web assistant UI
- Browser-hosted MCP Web
- Desktop-hosted MCP Web
- a dedicated Desktop MCP HTTP server
That flexibility is the point of io.Intelligence. You can start with the quickest route, then move lower in the stack when your product needs more control.
The Larger Pattern
The guide used a fictional banking workflow, but the pattern applies to many domains.
You can think of the architecture in layers:
User experience
io.Assist Angular, io.Assist React, or a custom AI Web UI
Browser intelligence runtime
AI Web, Working Context, MCP clients, MCP Apps
Model-facing capabilities
MCP Web or MCP HTTP, static tools, system tools, app and workspace metadata
Backend intelligence
Mastra agent, AI Mastra Bridge, extended AG-UI protocol
io.Connect environment
apps, workspaces, interop, context, layouts, Desktop or Browser
Each layer has a clear job:
- io.Connect knows the user's real working environment.
- MCP describes what the assistant can do.
- Working Context keeps the assistant grounded in the user's current state.
- AI Web coordinates the browser-side assistant runtime.
- AI Mastra Bridge connects the backend agent to the frontend protocol.
- io.Assist provides a complete UI when you do not want to build one yourself.
That separation is what makes the same core assistant portable across frameworks, transports, and io.Connect environments.
Where To Experiment Next
The guide intentionally kept the supporting apps small. That made the io.Intelligence pieces easier to see. In a real project, you can now start replacing the simplified pieces with production capabilities.
Here are a few useful directions:
| Experiment | What you will learn |
|---|---|
| Replace the in-memory clients with a real service | How to expose production data through MCP while keeping schemas clear for the model. |
| Add permission checks to MCP tools | How to make assistant actions respect user roles, entitlements, and compliance requirements. |
| Add more workspace context fields | How richer Working Context improves the quality and consistency of assistant responses. |
| Describe more apps and workspaces | How better metadata improves tool discovery and action selection. |
| Create a custom MCP App | How to turn tool results into interactive UI instead of text-only responses. |
| Add a new backend agent | How different agent instructions and tool sets change the assistant's behavior. |
| Expand the custom AI Web UI | How to build a product-specific assistant experience without giving up the io.Intelligence runtime. |
| Try the same assistant in Desktop and Browser | How much of your assistant logic can remain environment-independent. |
You do not have to do all of these at once. The best next step is usually one small workflow that matters to your users: one task, one source of context, one tool, one measurable improvement.
Final Thought
io.Intelligence is designed to meet you at different levels.
If you want speed, use io.Assist. If you want a custom experience, use AI Web. If you want browser-local capabilities, use MCP Web. If you want server-side capabilities, use MCP HTTP. If you want the assistant to understand the user's environment, add Working Context and rich app metadata.
The pieces are modular, but they are strongest together.
From here, take the ACME Banking example and make it yours. Add one real workflow. Give the assistant one useful capability. Let it see one meaningful piece of context. Then ask what else it could help with.
That is how a demo becomes a tool your users trust.