Proposal: Version-aware application knowledge layer/documentation for AI assistants

## Motivation

Users can connect Buzz to different LLM providers and models, including local and OpenAI-compatible models. However, the selected model usually does not have reliable, current knowledge about Buzz itself: its UI, settings, providers, agent behavior, tools, MCP integration, experimental features, release changes, or known limitations.

This creates a recurring problem when users ask an agent how to configure or use Buzz. The model may rely on outdated training data, confuse Chat and Agent behavior, invent settings that do not exist, or describe functionality from another version. This affects both local-model users and users connecting remote providers.

Buzz already contains several relevant pieces, such as agent memory/engrams and MCP Server support, but there is no official, version-aware knowledge source that agents can consult when answering questions about Buzz.

Open issues and PRs searched: I have found that address related issue #3088 but not in this broader, application-wide knowledge layer. I may not found all related as it is question what keywords to use.

## Proposed solution

Provide an official, version-aware knowledge source describing Buzz and make it available to agents through MCP resources/tools, an integrated RAG index, or a similar mechanism.

The source could include:

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

When a user asks how to use or configure Buzz, the agent should be able to search this source before answering. It should distinguish between features available in the installed version, experimental features, planned features, and behavior documented for older versions. If the documentation does not contain an answer, it should say so instead of guessing.

The documentation could be maintained in the repository and fetched or refreshed from the official online source. It could also be cached locally and matched to the installed Buzz version.

A possible MCP-oriented interface could provide resources or tools such as:

- search Buzz documentation;
- get documentation for a setting, provider, or tool;
- get release notes for a version;
- search known issues;
- inspect supported capabilities;
- inspect the current non-sensitive configuration.

#### The first implementation could be Buzz-specific. However, it would be valuable to design it around an open convention that could be reused by other AI applications. MCP could provide the transport and interface, while a broader standard could define common resource categories, version metadata, documentation structure, and discovery behavior.

## Alternatives considered

- Relying on the LLM's general training knowledge. This is often outdated and cannot describe the current Buzz version or the user's actual configuration.
- Adding the documentation to the system prompt. This consumes context on every request, is difficult to update, and does not scale well.
- Asking users to create their own Skills or Memory entries. This can help temporarily, but it duplicates work and does not provide an official or version-aware source.
- Maintaining a separate external wiki without direct integration. This would still require the agent or user to discover and retrieve the information manually.
- Training or fine-tuning a model specifically for Buzz. This would be more expensive and less flexible than providing current documentation through retrieval.

## Additional context

This proposal is related to the existing work around local models, OpenAI-compatible providers, agent configuration, Memory/engrams, and MCP Servers. Those features provide important building blocks, but they do not currently form a systematic product-knowledge layer.

The goal is not to train a new model. The goal is to allow any connected model — local or remote — to obtain accurate, current, version-aware knowledge about the application in which it is operating.

A useful long-term direction would be an open, reusable standard for application knowledge sources. An application could publish its version, capabilities, settings, providers, tools, documentation, release notes, and known issues in a format that any compatible LLM client or agent can discover and query.

Request is mostly AI generated on behalf my discussion of this topic with it and better formulated. I proposed the same to Odysseus project I discover recently as well.
You are free to propose it elsewhere if it resonate with you.