How Agent Frameworks Solve Human-in-the-Loop

When we are demoing an agentic product, it always looks clean and clear: the agent pauses, the human approves or rejects, and execution continues. But what happens when the human actually says no?

Human-in-the-loop (HITL) sounds like a single feature. In practice, it covers a wide design space: 

• Do you pause mid-execution or notify asynchronously? 
• Is the human a peer agent or an external approver?
• Can the human edit the action, or only approve or reject it?
• Does the framework resume execution exactly where it paused, or is there anything else?

These questions yield different answers across all major agent frameworks, and those answers have very real production consequences. I assumed that all frameworks would converge on a single pattern for HITL design, but I found them to be very different. This article compares the six frameworks and their implementations of HITL.

What You Will Learn

By the end of this article, you will be able to:

1. Distinguish the three fundamental HITL patterns - durable graph interrupt, message-loop injection, and blocking gate, and know which framework implements each.
2. Read working code for all six frameworks and understand the exact execution pause and how it resumes for the frameworks.
3. Pick the right framework for your use case.

The Fundamental Divide

The three distinct HITL patterns can be described as

1. Durable graph interrupt: In this pattern, the execution graph serializes the entire graph state and suspends at the exact node where approval was needed. Nothing happens until a decision is made. If the process exits, then it's saved in an external checkpointer, and the run resumes from the point of suspension. 

   
   

2. Message loop injection: In this pattern, there is no suspension as such. Humans act as a first-class participant in a multi-agent conversation, steering a reply like any other agent. The loop runs continuously, and the human response is just another round.
3. Blocking gate/run-termination: In this pattern, the framework runs or ends the run cleanly at a designated point, either blocking in process until the caller responds or terminating and returning an approval pending object that the human needs to resolve before resuming. Resuming the run is the human's responsibility.  

pip install deepagents langgraph
# Python >=3.10 required
# Docs: https://docs.langchain.com/oss/python/deepagents/human-in-the-loop

from deepagents import create_deep_agent
from langchain.agents.middleware import HumanInTheLoopMiddleware, InterruptOnConfig

hitl = HumanInTheLoopMiddleware(
    interrupt_on={
        # True = approve / edit / reject all allowed
        "delete_file": True,

        # Restrict to approve/reject only, with static description
        "run_bash": InterruptOnConfig(
            allowed_decisions=["approve", "reject"],
            description="Review this shell command before execution",
        ),

        # Dynamic description generated from the tool call at runtime
        "send_email": InterruptOnConfig(
            allowed_decisions=["approve", "edit", "reject"],
            description=lambda tool_call, state, runtime: (
                f"Approve sending email to: {tool_call['args'].get('to')}"
            ),
        ),
    }
)

agent = create_deep_agent(
    model="anthropic:claude-sonnet-4-6",
    middleware=[hitl],
)

# Surfaced to the reviewer when delete_file is triggered
{
    "action_requests": [
        {
            "name": "delete_file",
            "args": {"path": "/workspace/output.log"},
            "description": "Tool execution requires approval\n\nTool: delete_file\nArgs: ..."
        }
    ],
    "review_configs": [
        {
            "action_name": "delete_file",
            "allowed_decisions": ["approve", "edit", "reject"]
        }
    ]
}

from langgraph.types import Command

# Approve — run as-is
graph.invoke(
    Command(resume={"decisions": [{"type": "approve"}]}),
    config={"configurable": {"thread_id": "session-123"}},
)

# Edit — change args before running
graph.invoke(
    Command(resume={
        "decisions": [{
            "type": "edit",
            "edited_action": {
                "name": "delete_file",
                "args": {"path": "/workspace/old-backup.log"}
            }
        }]
    }),
    config={"configurable": {"thread_id": "session-123"}},
)

# Reject — agent receives explanation and stops retrying
graph.invoke(
    Command(resume={
        "decisions": [{
            "type": "reject",
            "message": "Do not delete production logs. Archive instead."
        }]
    }),
    config={"configurable": {"thread_id": "session-123"}},
)

# Single interrupt — two pending actions simultaneously
graph.invoke(Command(resume={
    "decisions": [
        {"type": "approve"},
        {"type": "reject", "message": "rm -rf is too broad — use a specific path"}
    ]
}))

pip install autogen-agentchat autogen-ext
# Docs: https://microsoft.github.io/autogen/stable/

Conclusion

There is no universal answer to HITL in agent frameworks. The right choice depends on three questions before choosing your framework: at what granularity does a human need to intervene (tool call, step, or task output), whether the reviewer responds in real time or hours later, and whether you need the process to survive a restart between the interrupt and the resume.

If the answer to any of the last two is "yes," deepagents with a LangGraph checkpointer is the only framework that handles both today. For everything else, the landscape is richer than it first appears: Pydantic AI's Deferred Tools give you structured tool-call-level approval without a graph runtime; Agno gives you powerful step-level gates with retry semantics; and OpenAI Agents SDK gives you the simplest possible approve/reject path when you control the process lifecycle.

The mistake most teams make is treating HITL as an afterthought. The primitives each framework exposes are not interchangeable, and switching from an observational callback to a durable interrupt requires rearchitecting the execution model, not just swapping a parameter. The decision tree above is meant to surface that choice before it becomes expensive to undo.