Microsoft Agent Framework Guide: HITL Requests and Checkpoint Resume

InYourLeague Research · 2026-08-30

Answer in brief

Microsoft Agent Framework supports human-in-the-loop interaction through typed request and response mechanisms that wait for external input before execution continues. Only the documented Python example establishes state preservation across multiple run calls; the supplied evidence does not document durable checkpoint serialization, cross-process restoration, or a general later-run resume guarantee for .NET or Go.

Key facts at a glance

Failure modes and verification

FAQ

What causes a Microsoft Agent Framework workflow to wait for human input?

An unresolved request issued through the documented request mechanism causes the workflow to wait. .NET and Go use RequestPort, while Python uses ctx.request_info(), as shown in the HITL documentation.

How does a response reach the correct executor?

The framework correlates the response with the original request and routes it to the associated executor. Python exposes a request_id; the documented .NET example creates the response from the request object carried by RequestInfoEvent.

Can a Python pending request be answered in a later run call?

Yes. The documented Python example says state is preserved across multiple run calls and collects pending request_id values for subsequent responses. This statement is specific to the Python example in the HITL documentation.

Does the evidence establish durable checkpoint restoration after a process restart?

No. The supplied sources do not specify checkpoint serialization, a persistence store, a loading API, or cross-process recovery. Python multi-run state preservation should not be presented as durable checkpoint restoration.

How are agents orchestrated in the documented workflow example?

The Agents in Workflows guide connects specialized agents sequentially with WorkflowBuilder and direct edges. In its .NET example, a TurnToken triggers processing after messages have been cached.

How are .NET agent updates streamed?

The documented .NET agent workflow uses a StreamingRun and exposes incremental agent responses through AgentResponseUpdateEvent. The supplied evidence does not establish that these updates and HITL request events occur together in one stream.

Which selectable model ID does Microsoft Agent Framework publish?

The two supplied official sources do not identify a product-level selectable model ID. Their agent examples use a model or deployment value configured in the Azure Foundry environment.

Sources and freshness

• Official source
• Official source
• Last verified: 2026-08-30

Extended guide

Direct answer

According to Microsoft’s Human-in-the-loop workflow documentation, an executor can issue a request to an external operator or system and wait for a response before continuing. In .NET and Go, RequestPort defines a typed request-and-response boundary. In Python, an executor calls ctx.request_info() and handles the returned value through a method registered with @response_handler.

This mechanism can represent human approval, additional data collection, or another asynchronous operation. The documented behavior is request, wait, receive a correlated response, and continue. Durable checkpoint recovery is a separate concern and is not established by the supplied evidence.

Documented request and response contract

Human approval flow

1. Define the decision contract. The documented Go approval example uses a RequestPort whose request is a string and whose response is a bool.
2. Connect the port to the executor that consumes the decision. In that example, FinalizeExecutor converts the Boolean response into an approved or rejected result.
3. Start execution and observe its events. The .NET example obtains a StreamingRun from InProcessExecution.RunStreamingAsync(...) and reads events with WatchStreamAsync().
4. When a RequestInfoEvent arrives, collect and validate the external answer. The user interface, approval service, or other integration operates outside the workflow.
5. Return the answer with handle.SendResponseAsync(requestInputEvt.Request.CreateResponse(value)). This preserves the correlation represented by the event’s request object; the evidence does not require a separately stored .NET request identifier.
6. Continue reading the stream until output is produced or another request requires attention.

Python follows a related but language-specific pattern. The host collects request_info events, associates answers with their request_id values, and supplies those responses in subsequent calls. The executor’s @response_handler is selected from the annotated original-request and response types.

Pending requests, checkpoints, and resume

The Python example explicitly says that runs are not isolated and that workflow state is preserved across multiple run calls. It therefore supports describing Python continuation in which pending request IDs are collected and answered through later calls on that workflow instance.

That evidence must not be generalized to every SDK. The supplied .NET example answers within the same StreamingRun, while the Go excerpt demonstrates waiting for an external response but not a later-run restoration procedure. Neither source specifies a durable checkpoint object, persistence provider, serialization format, checkpoint-loading API, process-restart procedure, or cross-process recovery guarantee. Those capabilities should remain described as undocumented here, not inferred from Python’s in-memory multi-run continuation.

Agent orchestration and streaming

The separate Agents in Workflows guide demonstrates specialized agents connected sequentially with WorkflowBuilder and direct edges. In its .NET example, agents cache messages and begin processing after receiving a TurnToken. A streaming run exposes incremental agent output through AgentResponseUpdateEvent.

The supplied sources show agent-update streaming and HITL request handling in separate examples. They do not prove that both event categories will appear together in one execution, so a combined-stream claim would require additional evidence.

Implementation checklist

• Declare exact request and response types.
• Validate external values before returning them.
• In Python, retain each pending request_id needed for a later response.
• In .NET, preserve and answer through the event’s request object as documented.
• Continue consuming events after sending a response.
• Distinguish Python multi-run state preservation from durable checkpoint restoration.
• Send TurnToken when following the documented .NET agent workflow pattern.
• Treat workflow output, request events, and agent updates according to their specific APIs.

These two supplied sources do not identify a product-level selectable model ID for Microsoft Agent Framework. Their agent examples instead accept a model or deployment configured in the Azure Foundry environment.

Model availability note: The official source does not specify a selectable model ID.