Proposal: Version-aware application knowledge layer for AI assistants

[Aladincz]

AI applications such as Buzz and Odysses that I now discover can connect to many different LLM providers and models. However, the connected model usually does not actually know the application it is operating in: its current UI, settings, provider behavior, tools, limitations, release changes, or known issues.

This leads to inaccurate or outdated answers. The model may confidently describe a setting that does not exist, confuse Chat mode with Agent mode, or provide instructions from an older version. Users should not need to teach the model the application manually every time they connect a new provider.

Odysses already has Skills, Memory, tools, and MCP Server support, so this proposal could provide an official application knowledge source that those mechanisms can consume. There are two other ideas concerning documentation or manuals #3325 and #4582 but i would like to propose it in more standardized way.

I propose adding an official, version-aware knowledge layer for the application itself.

The application should provide its documentation and current capabilities to the selected LLM through a local or remote knowledge source. This could be implemented using MCP resources/tools, an integrated RAG index, Skills, or a combination of these. The important part is that the information is maintained by the application and matched to the installed version.

The knowledge source could include:

• user documentation and help pages;
• settings and configuration options;
• providers and model backends;
• Chat mode and Agent mode behavior;
• available tools and Skills;
• MCP and Memory functionality;
• experimental features;
• release notes;
• known issues and limitations;
• version-specific changes;
• optionally, the current non-sensitive runtime configuration.

The assistant should consult this source when the user asks how to use or configure the application. It should distinguish between features available in the installed version, experimental features, planned features, and behavior from older versions. If the documentation does not contain an answer, the assistant should say so instead of guessing.

A possible MCP-oriented interface could expose resources such as:

• product information and current version;
• capabilities;
• settings;
• providers;
• tools;
• documentation;
• release notes;
• known issues.

It could also provide search functions such as:

• search application documentation;
• get documentation for a setting, provider, or tool;
• get changes for a specific version;
• search known issues.

The documentation could be fetched from the official online repository and cached locally. This would avoid requiring every LLM to have product knowledge in its training data, while still allowing users to connect local models, Gemini, Groq, OpenAI-compatible servers, or other providers.

Buzz and Odysses already contain parts of this architecture, such as Memory, Skills, tools, and MCP Servers. The missing part is a systematic and officially maintained knowledge source describing the application itself.

I would also encourage the project, together with other AI application developers and the MCP community, to consider defining an open convention or industry standard for this type of application knowledge layer. MCP could provide the transport and interface, while the standard could define common resource names, metadata, version handling, and expected documentation categories.

The immediate implementation could be application-specific. However, designing it around an open and reusable convention would allow any compatible LLM client or agent to understand the application it is operating in.

The goal is not to train another model. The goal is to provide every connected model with accurate, current, version-aware knowledge about the application in which it is being used.

Idea was described with Ai based on our discusion above topic.