MentorHitlMode enum
The MentorHitlMode enum of Novior.MentorAgent.Options: How MentorAgent implements human-in-the-loop tool approval (roadmap #16). Both modes show the same…
On this page
How MentorAgent implements human-in-the-loop tool approval (roadmap #16). Both modes show the same confirmation banner and use the same client protocol (ConfirmationRequired → RespondToApproval), so switching mode never requires a client change.
Definition
Section titled “Definition”Namespace: Novior.MentorAgent.Options. Package: Novior.MentorAgent.
public enum MentorHitlMode
dotnet add package Novior.MentorAgentValues
Section titled “Values”| Value | Number | Description |
|---|---|---|
Blocking | 0 | MentorAgent's own flow (default). The tool invocation is intercepted inside MentorAgentUIMiddleware and the AI thread is parked on a TaskCompletionSource until the user answers, so the agent run — and its streaming — stays alive for the whole turn. Fewer moving parts and one agent run per turn; use it unless you need AF interop. Both modes make the same model calls. |
Native | 1 | The Agent Framework standard flow. Tools that need approval are wrapped in ApprovalRequiredAIFunction; the framework's function-invoking chat client stops before invoking them and returns a ToolApprovalRequestContent, and MentorAgent resumes the run by sending back a ToolApprovalResponseContent on the same session. Choose this for interop: an AF workflow, DevUI or any AF-native host that consumes the agent sees the standard approval protocol instead of MentorAgent's internal one. It makes the same model calls as MentorHitlMode.Blocking, approved or declined: what it adds is one agent run per round of confirmations (the run stops at the request, and a second one carries the answers), and the reply arrives in two streamed segments (before and after the banner). |