Known issues

This page lists what to watch out for in MentorAgent 1.2.0: the defects that are still open, the prerelease packages that MentorAgent depends on, and the package versions to pin. Each defect has what to do about it. The limits that are not defects, such as the platforms MentorAgent runs on, are in Known limitations. What 1.2.0 adds and fixes is in its release notes.

1.2.0 has four known issues of the model's behavior. You can avoid two of them with an option: BUG-118 and BUG-106. BUG-074 is closed by default: it comes back only if you turn on ProactiveNextSteps.

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 S3. With HitlMode.Blocking and a Chat Completions client, the model can announce an action that asks for no confirmation, such as "I'll add the note now", and end its reply without calling it. It happened once in 12 turns on a sample application. RequireActionForChangeRequests does not prevent it, because it forces only actions that ask for confirmation.

What to do. The user can repeat the request. Where it matters, give the action RequiresConfirmation = true: with RequireActionForChangeRequests, a complete request then calls it first, behind the confirmation box. Or use HitlMode.Native with a Responses client, where an earlier measurement saw the action called almost every time.

Severity S2. When the user may not run an action, the model is not offered it. In a language other than English, the model can still offer that action in words. After the user's "yes", it can, rarely, call another action that the user may run in its place: once in 10 tries in Italian, a new expense claim instead of an approval.

What to do. Keep RequireConfirmation and RequireConfirmationForWrites on, as they are by default. The confirmation box then stops the wrong call before it runs.

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 a call to one of your read actions that the user may run, or a handoff to a specialist. With tool filtering on, the read must also be one that the filter selected for that message.

The option needs at least one declared read action that needs no role. It costs one small classifier call on each turn that has a declared read. A startup warning says when the option has no effect.

Severity S3. Since 1.2.0, MentorshipLevel.Proactive does not close its answers with suggested next steps, so by default this defect does not happen. With ProactiveNextSteps on, the model can still offer a step that the application does not have: 4 of 15 closing offers on a sample application.

What to do. Leave ProactiveNextSteps off, unless you accept some suggestions that your application cannot carry out.

Some packages that MentorAgent 1.2.0 depends on have no stable release yet. dotnet add package installs a prerelease only when you pass its version, and its API can still change from one prerelease to the next.

• A2A. A2A and A2A.AspNetCore 1.0.0-preview3 are prereleases. Novior.MentorAgent brings A2A for the client, and Novior.MentorAgent.Server brings A2A.AspNetCore for the A2A server.
• Declarative agents. Novior.MentorAgent.Declarative depends on a prerelease of Microsoft.Agents.AI.Declarative.
• Azure OpenAI. Azure.AI.OpenAI 2.9.0-beta.1, the package that you add for Azure OpenAI, is a prerelease too: see Model providers.

The versions that 1.2.0 is tested with are in Prerequisites.

To pin a package is to give it an exact version, so that NuGet does not move it.

With the Azure OpenAI Responses API, keep OpenAI at 2.10. Azure.AI.OpenAI 2.9.0-beta.1 calls a ResponsesClient constructor that OpenAI 2.11 removed. With OpenAI 2.11 or later, GetResponsesClient() throws MissingMethodException when your code calls it, although the build succeeds.

Some packages bring OpenAI 2.11 or later: Microsoft.Extensions.AI.OpenAI newer than 10.6.0, Microsoft.Agents.AI.Foundry newer than 1.17.0-preview.260804.1, and recent versions of Microsoft.Agents.AI.OpenAI. 1.2.0 is tested with Agent Framework 1.26.0. Which packages to pin, and how, is in Provider package versions. Chat Completions, OpenAI and Ollama need no pin.

A 1.1.0 host that moves A2A or A2A.AspNetCore to 1.0.0-preview3 on its own cannot answer A2A tasks: the handler fails with MissingMethodException when a task arrives. NuGet allows the move without a warning.

What to do. With 1.1.0, keep A2A and A2A.AspNetCore at 1.0.0-preview2. Or upgrade to 1.2.0, which uses preview3.