Production checklist

Use this page to go through the settings before real users reach your agent, and again after each upgrade of MentorAgent. Each item says what to check and where it is explained. The complete configuration at the end puts the options together.

If you have little time, check these five items first:

• every endpoint that you map requires authentication;
• users sign in, and every action that is not for everyone has RequiredRoles;
• every action that changes data asks for confirmation;
• the model key comes from a secret store or an environment variable;
• RateLimitPerUser and MaxMessageLength fit your use.

The roles and the confirmation boxes of your actions can be checked by automated tests on every build, without a model: see Test without a model.

• Every endpoint you map requires authentication. The hub, /mentor/chat and /a2a run turns on your model, and /mcp runs your actions directly. See Secure the endpoints. A Blazor Server app that maps none of them can skip this item.
• Blazor Server has a signed-in user. Without authentication every user is anonymous and every action with RequiredRoles is refused: see Blazor Server app.
• AnonymousIdentity stays PerSession on any application with more than one user. Shared puts every anonymous user on one memory and one rate-limit count.
• The admin views are protected. With Novior.MentorAgent.Server, DashboardRole guards GET /mentor/admin/metrics. The cost dashboard component, MentorDashboard, checks nothing: put it on a page with [Authorize(Roles = "Admin")].
• CORS lists your real origins. The /mcp endpoint has no Cross-Origin Resource Sharing (CORS) policy by default, which suits desktop and IDE clients. If a browser-based client calls it, define the MentorAgentMcp policy with your origins and apply it with RequireCors: see Model Context Protocol (MCP) server.

• Keys come from a secret store or environment variables. User secrets load only in the Development environment. On Azure, Entra ID with a managed identity removes the key: see Model providers.
• Public URLs are the production ones, such as A2AServerUrl: see Agent-to-Agent (A2A) server.

• Every action is declared. Check each action against Every declaration, on every channel. Declare ReadOnly = true on an action that only reads, and RequiresConfirmation = false only on a write that must run without asking. Mark a method that changes data with [MentorAction]: a method with only [Description] asks for nothing. Give RequiredRoles to every action that only some users may run. Without RequiredRoles, every user can run the action. See Two checks, in this order.
• RequireConfirmationForWrites stays true. With false, only RequiresConfirmation = true asks.
• Read the warning about writes. When MentorAgent first reads your classes, it logs a warning with two lists of writes that run without confirmation: the [MentorAction] methods that opted out, and the methods with only [Description] that are not declared read-only. Treat each name as a decision. Confirmation by default explains when the warning appears.
• Tools you cannot annotate are gated by name with RequiresApproval: see Tools you cannot annotate.
• RequireConfirmation stays true. false turns off the confirmation boxes of your actions, agents and gated tools. The only approvals that still appear are those for the MCP servers that the model provider calls directly (HostedMcpServers).
• IncludeWorkflowExceptionDetails stays false. Set to true, it puts exception messages from specialists and teams in the reply the user reads.
• Your methods still filter records per user. Roles decide who may call an action, not which records it returns. A rule per record or per company before a call runs is an action policy, IMentorActionPolicy: see What stays in your code.

Two options make the agent call an action before it says anything. Both are off by default, both need a ChatClient, and each adds one small classifier call to most turns. RequireActionForChangeRequests also needs EnableToolFiltering and an EmbeddingGenerator.

• RequireLookupForRecordQuestions makes the agent read a value before it answers a question about your records. Without it, a question about a price can still be answered with an offer to look the value up. Declare your reads first, with ReadOnly = true or IsReadOnlyAction. The option can require only the actions that you declare as reads and that the user may run. Without tool filtering, the first call must be one of those reads, or a handoff to a specialist. With tool filtering, it must be one that the filter selected for the message.
• RequireActionForChangeRequests makes the agent call an action that needs confirmation before it says anything, when the message asks for it and gives every input. Without it, the model can answer "Stock updated" with no tool called: no box appears, and nothing changes. Keep RequireConfirmation on, because only actions that show a box are required. Every [MentorAction] that asks for confirmation and that the user may run can be required, the writes that ask by default included.

• MaxMessageLength refuses long messages before the model is called.
• RateLimitPerUser is off by default. It counts messages per signed-in user within RateLimitWindowSecs.
  • The user id is the NameIdentifier claim or, if that claim is missing, sub, oid or the name.
  • MCP tool calls count too, in an allowance of their own.
  • A caller with no such claim and no name is counted by remote address, when IHttpContextAccessor is registered (AddMentorAgentServer() and AddMentorAgentA2A() register it). Otherwise all such callers share one allowance.
  • The limit does not bound anonymous chat users or unidentified A2A tasks: Secure the endpoints adds a limit on the endpoints.
• EnableSafetyCheck checks each message with one classifier call, for prompt injection, jailbreaks and attempts to extract the system prompt or credentials. Point ClassifierChatClient at a small, fast model.
• SafetyCheckFailure decides what happens when a check gives no verdict, after a timeout or a provider error. Allow, the default, answers and logs a warning; Block refuses the message. Choose Block when a message the check could not screen must never reach the model; Allow keeps the agent available when the classifier is down.
• EnableOutputSafetyCheck and RefuseOutOfScope are further checks on the reply and on the topic. The output safety check holds the whole reply until it is checked, so the answer no longer streams. RefuseOutOfScope refuses only a message that plainly has nothing to do with your application, and answers when unsure. Each refusal counts as a guardrail block in the dashboard. A guardrail is a check on a message or a reply, built in or written by you: see InputGuardrail.
• OnException maps an exception to the message that the user reads. When you set it, the chat never shows the text of a tool's exception. It shows your message, or "The action could not be completed." if the hook returns none. The model receives your message too. If the hook returns none, the model receives the text of the exception and can repeat it in its reply. Return a message for every exception whose text must not reach the user.

What each of these options reduces, what it costs in model calls, and how to measure your app: Cost and latency.

• ClassifierChatClient runs MentorAgent's own short decisions: the safety checks, the off-topic check (RefuseOutOfScope), the facts to remember, and the checks behind RequireLookupForRecordQuestions and RequireActionForChangeRequests. It defaults to ChatClient. A small model makes them cheaper and faster.
• StrongChatClient with a RoutingStrategy sends only the hard questions to a stronger model. If the strategy lacks what it needs, MentorAgent logs a warning and every turn stays on ChatClient. Each strategy needs something:
  • Custom, the default, needs your router in UseStrongModelAsync or UseStrongModel.
  • Semantic needs an EmbeddingGenerator, which turns text into numbers so MentorAgent can compare meanings.
  • Classifier needs nothing more. It makes one short call per turn to decide whether the turn needs the strong model. The call runs on RoutingClassifierClient or, if that is not set, on ChatClient. The complete configuration below uses this strategy.
• EnableToolFiltering sends only the relevant tools, and needs an EmbeddingGenerator. An action that changes data and asks for no confirmation can reach the model on any message, so the items on confirmation above matter here too: see Tool filtering and confirmation and EnableToolFiltering.
• EnableCompaction shrinks long conversations before each call. It changes what is sent to the model, never what is stored. It works with ChatClient and a history kept by your application, and it is not installed with UseServiceManagedHistory.
• WarmUpAtStartup does the shared setup work, such as tool embeddings and, with ChatClient, remote agent cards, once the host has started and is listening, so the first user does not wait for it. A failed warm-up never stops the app. An invalid configuration stops the app, because MentorAgent validates the options at start. A .NET MAUI app runs no hosted service, so there the option does nothing.
• ModelPricing turns the dashboard's token counts into costs. MentorAgent ships no prices. Enter them under the model id that the dashboard shows; on Azure OpenAI, that id is your deployment name. The counts live in memory unless you register an IMentorMetricsStore before AddMentorAgent().

The providers and the embedding model are set up in Model providers.

• The history is in memory by default, one per circuit or connection, and a restart loses it.
• To keep it, use ChatHistoryProviderFactory. It builds one history provider per circuit, hub connection or app run. It receives the IServiceProvider of that circuit, connection or app run, so your history provider can store each user's history separately. Setting ChatHistoryProvider instead gives one instance to every user of the process.
• Your history provider is not trimmed. MaxSessionMessages and ChatReducer apply only to the built-in history. Give your history provider its own limit. MentorChatReducer, in the Novior.MentorAgent.Core namespace, is the reducer that MentorAgent uses by default: it keeps every tool call together with its result and cuts whole turns. A ChatReducer set next to your own history provider, or with UseServiceManagedHistory, is not used, and a warning says so.
• The built-in history counts every message. Tool calls and their results count against MaxSessionMessages and stay in the history, so the model still sees the data that a tool read on the next turn. A session holds fewer turns for the same limit. Set ChatReducer to use another reducer.
• Memory is held in RAM too. With UseMemoryContext, register your own IMentorMemoryStore before AddMentorAgent(). The built-in store loses everything on restart, and each server instance has its own. A signed-in user is keyed by the NameIdentifier claim or, if that claim is missing, by sub, oid or the name. A key from a claim other than NameIdentifier carries the name of the claim, such as sub:…. ClearAsync on the store is where you erase a user's data.
• Your history provider keeps the transcript in the session, not in a field. One history provider serves a circuit or connection for its whole life. The widget's reset button, the hub's ResetSession and ResetSessionAsync start a new conversation. A new conversation is a new session, not a new history provider. So a history provider that keeps the messages in a field carries the previous conversation into the new one. The same rule applies to the key of a database row: keep it in the session, for example as a conversation ID in the StateBag, not in a field of the history provider.
• A saved conversation is the conversation in plain text. SerializeSessionAsync returns it as it is, and the model trusts a restored one as history. Keep it on the server, or in ProtectedLocalStorage, never as text that a user can read or edit. GET /mentor/session returns a protected snapshot instead, bound to the signed-in user. To restore after a restart, or on another instance, persist and share the ASP.NET Core Data Protection key ring ↗ (external site), as you do for authentication cookies.

In a history provider of your own, keep the messages in the session's StateBag, as the built-in provider does. Agent Framework's ProviderSessionState<T> does the bookkeeping:

using Microsoft.Agents.AI;       // ChatHistoryProvider, ProviderSessionState<T>
using Microsoft.Extensions.AI;   // ChatMessage, AIJsonUtilities
public sealed class CaseHistoryProvider : ChatHistoryProvider
{
    // The transcript lives in the session's StateBag, not in a field:
    // a new conversation is a new session.
    private readonly ProviderSessionState<List<ChatMessage>> _transcript =
        new(_ => [], nameof(CaseHistoryProvider), AIJsonUtilities.DefaultOptions);

    protected override ValueTask<IEnumerable<ChatMessage>>
        ProvideChatHistoryAsync(
            InvokingContext context, CancellationToken cancellationToken = default)
    {
        var history = _transcript.GetOrInitializeState(context.Session);
        return ValueTask.FromResult<IEnumerable<ChatMessage>>([.. history]);
    }

    protected override ValueTask StoreChatHistoryAsync(
        InvokedContext context, CancellationToken cancellationToken = default)
    {
        var history = _transcript.GetOrInitializeState(context.Session);
        history.AddRange(context.RequestMessages);
        history.AddRange(context.ResponseMessages ?? []);
        _transcript.SaveState(context.Session, history);
        return ValueTask.CompletedTask;
    }
}

Register it with the factory, so that each circuit and connection gets its own history provider:

options.ChatHistoryProviderFactory = _ => new CaseHistoryProvider();

• EnableObservability emits OpenTelemetry traces and metrics. The coordinator's model calls on Path A follow the OpenTelemetry conventions for generative AI. MentorAgent traces no other model call: to trace the embedding generator, the ClassifierChatClient, the agents under the coordinator or a prebuilt Agent, wrap the client with UseOpenTelemetry() before you pass it in. MentorAgent adds a mentor.turn span per turn, a mentor.tool.{toolName} span per tool call, a mentor.mcp.tool.{toolName} span per call to the MCP server, and four counters: mentoragent.turns, mentoragent.tool_calls, mentoragent.errors and mentoragent.guardrail_blocks, which includes the refusals of RefuseOutOfScope.
• Your application exports them. Add the source and the meter named by ObservabilitySourceName, MentorAgent by default, to your OpenTelemetry tracing and metrics. MentorAgent includes no OpenTelemetry exporter.
• ObservabilityIncludeSensitiveData stays false outside development: it puts prompts and replies in the telemetry.
• The logs. MentorAgent logs under categories that start with Novior.MentorAgent.
  • At Debug level, the logs show what each session was built with and which model the model routing chose.
  • Each MCP tool call writes one Information line, with a fingerprint of the caller and never the caller's ID.
  • A reset of the conversation writes one Information line too.
  • A refused role check names the user by a fingerprint (caller#…), never by name.
  • A failing tool is logged by the type of its exception. The whole exception is logged at Debug.

To send the traces and metrics to an OpenTelemetry collector, add the OpenTelemetry packages for the host and for the OpenTelemetry Protocol (OTLP) exporter. The example is compiled with these versions:

dotnet add package OpenTelemetry.Extensions.Hosting --version 1.15.3
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol --version 1.15.3

Turn the telemetry on in AddMentorAgent, then add the source and the meter to OpenTelemetry:

using Microsoft.Extensions.AI;          // AsIChatClient
using Novior.MentorAgent.Extensions;    // AddMentorAgent
using OpenAI;                           // OpenAIClient
using OpenTelemetry.Metrics;            // AddMeter, AddOtlpExporter
using OpenTelemetry.Trace;              // AddSource, AddOtlpExporter

var openAI = new OpenAIClient(builder.Configuration["OpenAI:Key"]
    ?? throw new InvalidOperationException("Set OpenAI:Key in a secret store."));

builder.Services.AddMentorAgent(options =>
{
    options.AppName = "Case management";
    options.ChatClient = openAI.GetChatClient("gpt-4o-mini").AsIChatClient();
    options.ScanAssemblies = [typeof(Program).Assembly];

    options.EnableObservability = true;
    // Prompts and replies in the spans: only on your own machine
    options.ObservabilityIncludeSensitiveData =
        builder.Environment.IsDevelopment();
});

// "MentorAgent" is the default of ObservabilitySourceName
builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource("MentorAgent")
        .AddOtlpExporter())
    .WithMetrics(metrics => metrics
        .AddMeter("MentorAgent")
        .AddOtlpExporter());

• Where the data goes. The OTLP exporter sends to http://localhost:4317 unless the OTEL_EXPORTER_OTLP_ENDPOINT environment variable names another address. Use the exporter of your backend instead, if it has one.

• The tags of a tool span. Each mentor.tool.{toolName} and mentor.mcp.tool.{toolName} span carries:

  • mentoragent.tool, the tool name;
  • mentoragent.tool.outcome, the last outcome of the call, such as executed, failed, denied or rejected;
  • mentoragent.tool.confirmation, such as none, requested, confirmed, rejected or timed-out;
  • mentoragent.surface, the channel: in-process, hub, sse, a2a or mcp.

  The counter mentoragent.tool_calls carries the mentoragent.tool tag.

• On Path B you get the mentor.* spans and the mentoragent.* counters only. The model calls of your prebuilt agent are traced only if you instrument its chat client yourself.

• Several instances. Each instance exports its own data, and your backend adds it up. The dashboard's counts are per instance: see Run on several instances.

MentorAgent keeps the state of a conversation in the memory of the process that serves it. Behind a load balancer, every request of a client must reach the instance that serves it:

• Turn on session affinity ("sticky sessions") in your load balancer, for example with an affinity cookie.
• Affinity covers the hub connection and the HTTP requests of the same client: /mentor/approve, /mentor/cancel and /mentor/session. Affinity on the SignalR connection alone is not enough.
• Blazor Server already needs affinity for its circuits. A Blazor Server host that also maps the hub, /mentor/chat, MCP or A2A needs it for those too.
• No backplane is needed. MentorAgent sends each hub event only to the connection that asked for the turn, from the instance that holds it. A SignalR backplane, such as Redis or Azure SignalR Service, would not help: confirmations, Stop and sessions are found in the memory of the instance, not through SignalR groups.

Where each part of the state lives, and what it needs on several instances:

Some more things are held or counted per instance:

• RateLimitPerUser: a user spread over N instances gets up to N times the limit.
• The MCP server keeps each Mcp-Session-Id in the memory of the process, and another instance answers that session with 404. MCP clients need affinity too. MentorAgent always runs the MCP server with sessions, and has no option for the stateless mode of the MCP SDK.
• The A2A server keeps its tasks in memory: GetTask and CancelTask on another instance do not find them. Only the instance that runs a turn can stop it, so a shared ITaskStore would not be enough.
• The generated tour costs one model call per instance, and the caches of embeddings and A2A agent cards are per instance, like the connections to MCP servers and remote agents.

Each instance needs the same key ring for the snapshots, and a time limit for the confirmations whose answer can be lost on another instance:

using Microsoft.AspNetCore.DataProtection;  // PersistKeysToFileSystem
using Microsoft.Extensions.AI;              // AsIChatClient
using Novior.MentorAgent.Extensions;        // AddMentorAgent
using OpenAI;                               // OpenAIClient

// One key ring and one application name for every instance:
// a session snapshot saved on one instance opens on the others.
var keys = builder.Configuration["DataProtection:KeysPath"]
    ?? throw new InvalidOperationException("Set DataProtection:KeysPath.");
builder.Services.AddDataProtection()
    .SetApplicationName("case-management")
    .PersistKeysToFileSystem(new DirectoryInfo(keys));

var openAI = new OpenAIClient(builder.Configuration["OpenAI:Key"]
    ?? throw new InvalidOperationException("Set OpenAI:Key in a secret store."));

builder.Services.AddMentorAgent(options =>
{
    options.AppName = "Case management";
    options.ChatClient = openAI.GetChatClient("gpt-4o-mini").AsIChatClient();
    options.ScanAssemblies = [typeof(Program).Assembly];

    // An answer that reaches another instance gets 404:
    // after five minutes the confirmation counts as rejected.
    options.ConfirmationTimeout = TimeSpan.FromMinutes(5);
});

A folder on a shared volume is the simplest place for the keys. ASP.NET Core can also keep them in Azure Blob Storage or Redis, and protect them at rest: see Configure ASP.NET Core Data Protection ↗ (external site).

MentorAgent is a library inside your ASP.NET Core app, so the app goes in a container like any other. MentorAgent ships no image and no Dockerfile. This one is a common two-stage build for an app whose project is CaseManagement.csproj:

# Build and publish with the .NET SDK
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish CaseManagement.csproj -c Release -o /app

# Run on the ASP.NET Core runtime, as the non-root user of the image
FROM mcr.microsoft.com/dotnet/aspnet:10.0
WORKDIR /app
COPY --from=build /app .
RUN mkdir /keys && chown $APP_UID /keys
ENV DataProtection__KeysPath=/keys
USER $APP_UID
EXPOSE 8080
ENTRYPOINT ["dotnet", "CaseManagement.dll"]

• The model key comes from the environment, never from the image. Pass it when the container starts, for example docker run -e OpenAI__Key=<your-key>, or from your platform's secret store. ASP.NET Core reads OpenAI__Key as OpenAI:Key. User secrets are not loaded: the image runs in the Production environment.

• The Data Protection keys need a volume. Without one, a new container starts with new keys, and the session snapshots saved before no longer open. The Dockerfile points DataProtection:KeysPath of the example for several instances at /keys: mount a volume there, the same one for every instance, for example docker run -v case-keys:/keys.

• The app listens on port 8080. The .NET images set it, and run the app as a user without root rights. Put HTTPS on your proxy or ingress, and use the forwarded headers middleware ↗ (external site) behind it.

• Files that MentorAgent reads must be in the image. The SKILL.md files of your skills are read from the content root, /app here, and YAML agents from the application folder. dotnet publish copies a Markdown or YAML file only if the project says so:

  CaseManagement.csproj

  <ItemGroup>
    <None Update="Skills\**\SKILL.md"
          CopyToPublishDirectory="PreserveNewest" />
  </ItemGroup>

• Several containers need what several instances need: session affinity, a shared key ring and the other items of Run on several instances.

The tests of this documentation check the text of this Dockerfile: the .NET version, the user, the port and the key folder. They do not build or run it, and MentorAgent's release tests do not run the library in a container.

Your roles and confirmation boxes can be checked by automated tests on every build, with a fake model: no key, no network, the same result every time. Test without a model shows the fake model, the app under test and the tests.

• What a fake model tests: which actions a user can run, which ones ask for confirmation, what runs after the user confirms or rejects, and what your methods return.
• What it does not test: whether your real model chooses the right action, or understands your users' words. Run a few conversations with the real model before each release: see Catch regressions with the real model.

What your deployment sends to other services, for your privacy notice and your security review:

• The model provider receives the conversation and its context:

  • the user's messages and the replies;
  • the system prompt, with the address and name of the current page, the signed-in user's name and roles, and the data the page hands over through IMentorPageContext;
  • the results of your actions (the data your methods read, from your database too);
  • retrieved documents and the user's memories, when you turn them on;
  • the names, descriptions and required inputs of your actions and the descriptions of your pages, when you use RequireLookupForRecordQuestions or RequireActionForChangeRequests: the classifier model receives them.

  With a local model, none of this leaves your network: see Ollama and other local models.

• The remote systems you configure receive what is handed to them. The MCP servers in McpServers receive the tool calls, and the A2A agents in RemoteAgents the requests sent to them. The servers in HostedMcpServers are called by the provider, with the headers you set.

• Nothing goes to the authors of MentorAgent. The library sends no telemetry of its own. Traces and metrics go only to the exporter you configure, and carry the text of prompts and replies only with ObservabilityIncludeSensitiveData.

• The widget requests nothing from a third party. The package ships its two fonts, Sora and JetBrains Mono, so the stylesheet loads no file from another origin, and the widget works offline.

• Voice input goes through the browser. With EnableVoiceInput, off by default, the widget uses the browser's speech recognition. In Chrome, for example, the browser sends the audio to its vendor's recognition service. Only the transcript reaches MentorAgent.

With any option, the widget and <MentorDashboard /> work under a policy with default-src 'self' and without 'unsafe-inline'. They load their fonts and images from your own origin. The themes are stylesheets of the package, PrimaryColor is set by the widget's script, and the dashboard draws with classes and SVG.

A WebAssembly client has two requirements. They come from Blazor, not from MentorAgent:

• script-src 'wasm-unsafe-eval', for the .NET runtime;
• in a Blazor Web App, the inline import map that <ImportMap /> renders.

See the Content Security Policy guidance in the ASP.NET Core Blazor documentation ↗ (external site).

The options from this list in one registration, next to the endpoint protection of Secure the endpoints:

using Novior.MentorAgent.Extensions;   // AddMentorAgent
using Novior.MentorAgent.Options;      // MentorRoutingStrategy and others
using Microsoft.Extensions.AI;         // AsIChatClient
using OpenAI;                          // OpenAIClient

var openAI = new OpenAIClient(builder.Configuration["OpenAI:Key"]
    ?? throw new InvalidOperationException("Set OpenAI:Key in a secret store."));

builder.Services.AddMentorAgent(options =>
{
    options.AppName = "Case management";
    options.AppDescription = "Support cases: status, notes and closure";
    options.ChatClient = openAI.GetChatClient("gpt-4o-mini").AsIChatClient();
    options.ScanAssemblies = [typeof(Program).Assembly];

    // Governance: the defaults, written out so nobody changes them by accident
    options.RequireConfirmation = true;
    options.RequireConfirmationForWrites = true;
    options.IncludeWorkflowExceptionDetails = false;

    // Limits, counted per signed-in user
    options.MaxMessageLength = 2000;
    options.RateLimitPerUser = 20;
    options.RateLimitWindowSecs = 60;

    // Safety checks, on a model smaller and faster than the main one
    options.EnableSafetyCheck = true;
    options.ClassifierChatClient =
        openAI.GetChatClient("gpt-4.1-nano").AsIChatClient();
    // No verdict, for example after a timeout: answer and log a warning
    options.SafetyCheckFailure = MentorSafetyCheckFailure.Allow;

    // Cost: a stronger model only for the hard questions, and shorter histories
    options.StrongChatClient = openAI.GetChatClient("gpt-4o").AsIChatClient();
    options.RoutingStrategy = MentorRoutingStrategy.Classifier;
    options.EnableCompaction = true;
    options.WarmUpAtStartup = true;

    // OpenTelemetry: traces and metrics under the "MentorAgent" source and meter
    options.EnableObservability = true;
    // Prompts and replies stay out of telemetry
    options.ObservabilityIncludeSensitiveData = false;
});

Every option is in Configuration options, and the limits under Security and limits.

• The key is not found once deployed. User secrets are not loaded outside Development. Set the key as an environment variable or in your secret store.
• The strong model is never used, and the log says "routing disabled (cheap model only)". The strategy lacks what it needs: UseStrongModelAsync or UseStrongModel for Custom, an EmbeddingGenerator for Semantic.
• Users see each other's memories or history. AnonymousIdentity is Shared, or one ChatHistoryProvider object serves every user.
• A new conversation still knows the previous one. Your history provider keeps the transcript in a field: keep it in the session, as in Conversation history and memory.
• The app stops at startup with "Both ChatHistoryProvider and ChatHistoryProviderFactory are set." MentorAgent checks the options when the host starts. Keep ChatHistoryProviderFactory alone.
• The safety check is skipped with a timeout warning. The classifier model is too slow: set a faster ClassifierChatClient or raise SafetyCheckTimeout.
• Replies arrive all at once instead of streaming. A check on the reply is on: EnableOutputSafetyCheck or an OutputGuardrail holds each reply until it is checked.
• Behind a load balancer, Approve or Stop answers 404, and the confirmation box stays. The request reached another instance. Give the HTTP requests the same affinity as the hub connection, and set ConfirmationTimeout: see Run on several instances.
• A saved conversation does not open on another instance, and /mentor/session answers 400. The instances do not share the Data Protection keys or the application name.
• No traces arrive. The MentorAgent source and meter are not in your OpenTelemetry setup, or ObservabilitySourceName gives them another name.