What's new

New to MentorAgent? You can skip this page for now. Start with What is MentorAgent? and the Quickstart. This page is for developers who already use an earlier version.

MentorAgent 1.0.0 was published on NuGet on 13 October 2026. It is the first stable version. From now on, a breaking change to the public contract comes only with a new major version: see Versioning and support. The release notes on NuGet ↗ (external site) have the same entries as this page. The Changelog lists every version.

The packages have new IDs. From this version they are Novior.MentorAgent and the four Novior.MentorAgent.* packages; up to 1.0.0-rc.15 they were MentorAgent and MentorAgent.*. The namespaces, the assemblies, the path of the widget's static files and the log categories follow. The methods, types and attributes that your code calls keep their names. Read Move to the Novior.MentorAgent packages before you upgrade.

The version also closes seven defects, listed under Fixed. One of them can stop an application at startup: see BUG-153.

The five packages, their namespaces, their assemblies, the path of the widget's static files and the log categories start with Novior. from this version. Up to 1.0.0-rc.15 the IDs were MentorAgent and MentorAgent.*. Each package now requires the others at exactly its own version. Move to the Novior.MentorAgent packages lists the steps and what stays the same.

The five packages are published as Novior.MentorAgent.* from 1.0.0. The MentorAgent.* IDs end with 1.0.0-rc.15: nothing newer is published under them. The move is a change of packages, using lines and paths.

If you upgrade from a version older than 1.0.0-rc.15, also read the Breaking entries in the Changelog. Read them for every version after yours, up to and including 1.0.0-rc.15.

1. Swap the packages in every project that references one, class libraries included. For example:

   Terminal

   dotnet remove package MentorAgent.Server
   dotnet add package Novior.MentorAgent.Server

   Novior.MentorAgent.Abstractions comes with the other packages, so a project that gets it only through them needs no line of its own.

2. Check that no old package is left. The old and the new packages build side by side without an error. Your using MentorAgent.* lines keep reaching the old package, and the application goes on running 1.0.0-rc.15. In every project, run:

   Terminal

   dotnet list package --include-transitive

   The list must show no package whose ID is MentorAgent or starts with MentorAgent..

3. Change the namespaces. MentorAgent.X becomes Novior.MentorAgent.X in every using and @using, _Imports.razor included, and in every fully qualified name. The type names stay. Change only those lines, not every MentorAgent in your code: AddMentorAgent(), MapMentorAgent…(), [MentorAgent] and MentorAgentBlazorOptions keep their names.

   Program.cs

   using Novior.MentorAgent.Extensions;           // was MentorAgent.Extensions
   using Novior.MentorAgent.Abstractions.Models;  // was MentorAgent.Abstractions.Models

4. Change the path of the static files in a page you wrote. The widget's stylesheet and script are served under the package ID: _content/Novior.MentorAgent.Abstractions/. On a Blazor Server or Blazor Web App page, <ChatWidget /> adds them for you, so nothing changes. If a page links the files by hand, change the path. This applies to the wwwroot/index.html of a Blazor WebAssembly client or of a .NET MAUI app:

   HTML

   <link rel="stylesheet" href="_content/Novior.MentorAgent.Abstractions/css/MentorAgent.css" />
   <script src="_content/Novior.MentorAgent.Abstractions/js/MentorAgent.js"></script>

   The old path answers 404, and nothing else complains: the widget shows without its styles and without voice. The file names do not change.

5. Change the log filters. The log categories follow the namespaces: MentorAgent.Core.MentorOrchestrator is now Novior.MentorAgent.Core.MentorOrchestrator. A filter on "MentorAgent" no longer matches anything, and the Debug lines it turned on stop without a warning:

   appsettings.Development.json

   { "Logging": { "LogLevel": { "Novior.MentorAgent": "Debug" } } }

6. Upgrade the five packages together. Each package requires the others at exactly its own version. For example, Novior.MentorAgent.Server 1.0.0 needs exactly Novior.MentorAgent 1.0.0. A later version does not satisfy it.

These stay the same:

• the methods, types and attributes you call, such as AddMentorAgent(), AddMentorAgentServer(), MapMentorAgent…(), MentorOptions, [MentorAgent] and [MentorAction], and the "MentorAgent" configuration section;
• the routes (/mentor-hub, /mentor/…, /mcp, /a2a), the CSS classes and what the widget keeps in the browser;
• the names of the telemetry: the MentorAgent source and meter (ObservabilitySourceName), and the mentoragent.* metrics;
• session snapshots: one saved by 1.0.0-rc.15 is restored by 1.0.0;
• the MentorAgentMcp Cross-Origin Resource Sharing policy, the MentorAgent.css and MentorAgent.js files, and window.MentorAgent.

Each defect has a severity, from S1, the most severe, to S4. S1 is data loss, a security hole or a crash. S2 is a documented feature that does not work, or documentation that leads to a broken result. S3 is wrong behavior in an edge case, or documentation that contradicts the code. S4 is cosmetic.

Severity S3. AddMentorAgentMcp() registers the Model Context Protocol (MCP) server, and AddMentorAgentA2A() registers the Agent-to-Agent (A2A) server. In two cases, these calls registered nothing and said nothing:

• the call came before AddMentorAgent();
• McpServerEnabled or A2AServerEnabled was turned on after AddMentorAgent() had read it, with a Configure or PostConfigure of MentorOptions.

The map call then failed with an error. In the second case, the error told you to add a call that the host had already made. Now the host stops at startup with the reason and the fix.

What to do: call AddMentorAgentMcp() and AddMentorAgentA2A() after AddMentorAgent(), and set the two options in the AddMentorAgent callback. A host that ran without its MCP server or A2A agent because of this defect no longer starts until you do. See The app stops at startup: Cannot map the MCP or A2A endpoint.

Severity S3. Four warnings logged a whole exception, with its text. That text comes from your code. These warnings are outside the checks of roles and confirmation. They were about:

• a UI action that threw, with a ChatClient;
• a UI action that threw, with a prebuilt Agent;
• an OnToolResult that threw on the MCP server;
• a McpCallerPrincipal that threw on the MCP server.

As in the checks, the warnings now name the type of the exception. The whole exception is logged at Debug.

• BUG-154 (S3): the warning about writes that run without confirmation appears the first time MentorAgent reads your actions. It does not always appear at startup. It appears at startup only with WarmUpAtStartup or MapMentorAgentA2A(). Otherwise it appears with the first conversation or the first MCP or tour request. With only [Description], the warning also names the methods that only read, until IsReadOnlyAction or [MentorAction(ReadOnly = true)] declares them.
• BUG-155 (S3): the minimal SignalR client sends the hub's credentials with Stop, the confirmations and the session calls, like the complete components. The README no longer says that the MCP and A2A servers are in the core package.
• BUG-156 (S4): only AppName is read at registration, as the name of the MCP server. The A2A card is built from the real options when MapMentorAgentA2A() runs.
• BUG-157 (S3): the MAUI steps now name using System.Reflection;, using Microsoft.Extensions.Configuration; and the Microsoft.Extensions.Configuration.UserSecrets package. They also say that AddUserSecrets needs the UserSecretsId of the project, and that it finds the secrets only on the development machine.
• BUG-158 (S3): the core package references ModelContextProtocol. ModelContextProtocol.AspNetCore is in the Server package since 1.0.0-rc.15.

1.0.0 has four known issues. You can avoid three of them: BUG-118 and BUG-106 with an option, and the snapshot issue by keeping the default HitlMode.Blocking. BUG-074 is still open: it has no fix in this version. It happens only with MentorshipLevel.Proactive, which is not the default.

Severity S3. With MentorshipLevel.Proactive, the prompt tells the model to offer a next step only when something can carry it out: a tool of the current request, a page, a skill, a specialist or a team. Otherwise the model must offer none. The model does not always follow this rule. On a sample application, 3 turns in 15 still offered a step that does not exist, such as "add it to the cart". Proactive is not the default value of MentorshipLevel: the default is Standard. See MentorshipLevel.

What to do. If you use Proactive, expect some suggestions that your application cannot carry out. The defect stays open in this version: the offers that the agent adds at the end of a reply keep their current wording.

Severity S2. Without RequireActionForChangeRequests, the model can describe an action it never performed: "stock updated" with no tool called, or "here is the Products page" with no navigation. No confirmation box appears, and nothing changes. The checks are not bypassed: the action did not run.

What to do. Turn on RequireActionForChangeRequests. A classifier model reads each message:

• If the message asks for one of your actions that need confirmation, and gives every input that the action needs, the first model call must call that action. The confirmation box then comes first.
• If the message asks for one of your [MentorPage] pages, the first call must be navigate_to.
• A request that leaves an input out is never forced, and the agent may ask for it.

The option needs EnableToolFiltering and an EmbeddingGenerator. It costs one small classifier call on most turns. A startup warning says when the option has no effect. The Debug log shows what the classifier decided.

MentorAgent forces the action only when the classifier recognizes a complete request. Otherwise the request runs as it would without the option.

Severity S2. Without RequireLookupForRecordQuestions, the model can answer a question about your records with "I cannot see the price. Shall I look it up?", although a read action could answer. It can also write "price not available" without calling the action.

What to do. Declare your read actions with [MentorAction(ReadOnly = true)], or by tool name with IsReadOnlyAction. Then turn on RequireLookupForRecordQuestions. A classifier model reads each message. If the message asks for a value of your records, the first model call must be one of two things: a call to a read action that the tool filter selected for that message, or a handoff to a specialist.

The option needs:

• EnableToolFiltering;
• an EmbeddingGenerator;
• at least one declared read action that needs no role.

It costs one small classifier call on each turn whose selection holds a declared read. A startup warning says when the option has no effect.

With HitlMode.Native, a confirmation closed by Stop is closed only in memory. The next message in the same conversation works. A session snapshot saved in that state, and restored, still carries the open request. The next turn can then fail with this message: ToolApprovalRequestContent found with FunctionCall.CallId(s) … that have no matching ToolApprovalResponseContent.

What to do: keep the default HitlMode.Blocking: the defect happens only with Native. If a restored conversation fails this way, start a new conversation.

These are not defects: they are how 1.0.0 works. Each one links to the page that explains it.

• .NET 10 only. MentorAgent does not run on .NET 8 or .NET 9: see Prerequisites.
• Prerelease dependencies. The A2A packages that MentorAgent uses have no stable release yet, and Novior.MentorAgent.Declarative also depends on a prerelease of Agent Framework: see Prerequisites.
• Azure Responses and OpenAI versions. With the Azure OpenAI Responses API, keep OpenAI at 2.10. Azure.AI.OpenAI 2.9.0-beta.1 does not work with OpenAI 2.11. Some recent Agent Framework packages bring OpenAI 2.11 or later, for example Microsoft.Agents.AI.Foundry newer than 1.17.0-preview.260804.1. 1.0.0 is tested with Agent Framework 1.18.0. See Provider package versions.
• Roles, not records. The role check reads the user's role claims: there are no per-record or per-company permissions. See What stays in your code.
• Hosted tools skip MentorAgent's checks. Some tools run on the provider, such as web search or the code interpreter (HostedTools). They never pass through MentorAgent, so roles, confirmation, OnToolResult and the per-tool metrics do not apply to them. You control what the provider may do: which tools you declare, which vector stores file search reads, and which tools of a hosted MCP server are allowed or need approval.
• Methods with only [Description] run without confirmation. A [MentorAction] that is not read-only asks for confirmation by default. A method with only [Description] runs without asking. MentorAgent publishes it on /mcp, and with tool filtering on, it can reach the model on any message. Use [MentorAction] for every method that changes data.
• Endpoints open by default. The SignalR hub, Server-Sent Events, /mcp and /a2a answer everyone until you protect them. See Secure the endpoints.
• Session snapshots without sign-in. On a host without authentication, every visitor is the same anonymous user. So a snapshot from /mentor/session cannot be read or edited, but it restores into any connection of the application.
• Safety checks and limits are off by default. The safety check on messages is off by default. When it is on and gives no verdict, for example after a timeout, it lets the message through (SafetyCheckFailure = Allow). The per-user message limit, RateLimitPerUser, is 0 by default, which means no limit. See Limits and safety checks.
• A2A chains and remote agents. A chain of MentorAgent hosts, such as A → B → C, is not supported. When a task arrives over A2A, the host that receives it answers the task. The host never passes the task on to its own remote agents. A remote agent has no role check of its own: any user of the host can reach it. See A2A server and MentorRemoteAgent.

The policy is in the "Versioning and support" section of the MentorAgent README on NuGet ↗ (external site).

• One version for the family. Novior.MentorAgent, Novior.MentorAgent.Abstractions, Novior.MentorAgent.Blazor, Novior.MentorAgent.Server and Novior.MentorAgent.Declarative are released together, with one version number, and each one requires the others at exactly that version. Upgrade them together.
• Semantic Versioning 2.0.0, from 1.0.0. A breaking change to the public contract ships only in a new major version. Minor versions add features; patch versions fix defects.
• What the contract covers:
  • the public C# API of the five packages;
  • the hub methods, hub events, Server-Sent Events frames and HTTP endpoints documented in the Novior.MentorAgent.Server README;
  • the names of the tools that the library itself gives the model, such as route_to_specialist, navigate_to and load_skill;
  • the documented configuration keys.
• What it does not cover: what the model says, or which tool it chooses on a given turn; the wording of the prompts that the library builds; log messages. The Novior.MentorAgent prefix of the log categories is stable, but the text after it is not.
• Dependencies. A minor version may move the Microsoft packages listed in Prerequisites to a newer compatible version, including packages with no stable release yet. The packages of your model provider are not among them: their versions are yours.
• Support. MentorAgent supports .NET 10. Fixes go to the latest minor version of the current major version.
• What changed. Every package contains CHANGELOG.md with the whole history, and its release notes on NuGet are the section of that version. The Changelog has the same entries.