.NET: Make Todo, Mode and FileMemory providers more configurable

[westey (westey-m)]

Motivation and Context

Users should be able to configure providers as far as possible for their own scenarios, including customizing instructions.

Description

• Allow users to provide their own instructions for the Todo and FileMemory providers.
• Change function tool names to start with consistent prefixes.
• Improve the Mode provider to configure the set of modes and instructions. Also update it to inject a message after the user changes the mode, so that the LLM is notified that there was an update.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the Contribution Guidelines
• All unit tests pass, and I have added new tests where possible
• Is this a breaking change? If yes, add "[BREAKING]" prefix to the title of the PR.

[github-actions]

Automated Code Review

Reviewers: 2 | Confidence: 94% | Result: All clear

Reviewed: Correctness, Design Approach

---

Automated review by westey-m's agents

[Copilot]

Pull request overview

This PR makes the built-in Harness providers (Todo, FileMemory, AgentMode) more configurable by adding options for custom instructions, standardizing tool name prefixes, and enhancing AgentMode behavior to support configurable mode sets and external mode-change notifications.

Changes:

• Added *ProviderOptions types to allow custom instructions for Todo and FileMemory providers.
• Renamed Todo and AgentMode function tools to consistent prefixes (TodoList_*, AgentMode_*) and updated samples/tests accordingly.
• Enhanced AgentModeProvider to accept configurable modes/default mode and to inject a notification message when the mode is changed externally.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
dotnet/src/Microsoft.Agents.AI/Harness/Todo/TodoProvider.cs	Adds options-based instructions + renames todo tool names.
dotnet/src/Microsoft.Agents.AI/Harness/Todo/TodoProviderOptions.cs	New options type for Todo provider instructions.
dotnet/src/Microsoft.Agents.AI/Harness/FileMemory/FileMemoryProvider.cs	Adds options-based instructions.
dotnet/src/Microsoft.Agents.AI/Harness/FileMemory/FileMemoryProviderOptions.cs	New options type for FileMemory provider instructions.
dotnet/src/Microsoft.Agents.AI/Harness/AgentMode/AgentModeProvider.cs	Adds configurable modes + external change notification + renames tools.
dotnet/src/Microsoft.Agents.AI/Harness/AgentMode/AgentModeProviderOptions.cs	New options type for modes/default/instructions configuration.
dotnet/src/Microsoft.Agents.AI/Harness/AgentMode/AgentModeState.cs	Adds notification state tracking + default mode string change.
dotnet/tests/.../TodoProviderTests.cs	Updates tool names + adds options instruction tests.
dotnet/tests/.../FileMemoryProviderTests.cs	Adds options instruction tests.
dotnet/tests/.../AgentModeProviderTests.cs	Updates tool names + adds options/mode list + notification tests.
dotnet/samples/.../Harness_Step01_Research/Program.cs	Updates sample instructions to reference mode tools / behavior.
dotnet/samples/.../ToolCallFormatter.cs	Updates tool name formatting mappings.
dotnet/samples/.../HarnessConsole.cs	Updates mode coloring + mode command handling.

Comments suppressed due to low confidence (2)

dotnet/samples/02-agents/Harness/Harness_Shared_Console/HarnessConsole.cs:289

• HandleModeCommand previously normalized "plan"/"execute" case-insensitively, but that logic was removed. As a result, /mode PLAN (or other casing) will now throw even for the default provider, which is a UX regression in the sample console. Consider restoring case-insensitive normalization for the built-in default modes (using string literals if you no longer expose constants).

 string newMode = parts[1];
try
{
modeProvider.SetMode(session, newMode);
System.Console.ForegroundColor = GetModeColor(newMode);
System.Console.WriteLine($"\n Switched to {newMode} mode.\n");

dotnet/src/Microsoft.Agents.AI/Harness/FileMemory/FileMemoryProvider.cs:86

• This constructor signature change removes the previously published (fileStore, stateInitializer) overload and replaces it with a 3-parameter overload with an optional options parameter. That is a binary breaking change for already-compiled consumers. Consider reintroducing the original constructor overload and chaining to the new one so existing binaries keep working.

 /// <summary>
/// Initializes a new instance of the <see cref="FileMemoryProvider"/> class.
/// </summary>
/// <param name="fileStore">The file store implementation used for storage operations.</param>
/// <param name="stateInitializer">
/// An optional function that initializes the <see cref="FileMemoryState"/> for a new session.
/// Use this to customize the working folder (e.g., per-user or per-session subfolders).
/// When <see langword="null"/>, the default initializer creates state with an empty working folder.
/// </param>
/// <param name="options">Optional settings that control provider behavior. When <see langword="null"/>, defaults are used.</param>
/// <exception cref="ArgumentNullException">Thrown when <paramref name="fileStore"/> is <see langword="null"/>.</exception>
public FileMemoryProvider(AgentFileStore fileStore, Func<AgentSession?, FileMemoryState>? stateInitializer = null, FileMemoryProviderOptions? options = null)
{
Throw.IfNull(fileStore);
this._fileStore = fileStore;
this._instructions = options?.Instructions ?? DefaultInstructions;
this._sessionState = new ProviderSessionState<FileMemoryState>(
stateInitializer ?? (_ => new FileMemoryState()),
this.GetType().Name,
AgentJsonUtilities.DefaultOptions);
}