Human in the Loop AI Workflow: Diagram, Steps and Design Patterns

What is a human in the loop AI workflow?

A human in the loop AI workflow is a sequence of steps in which an AI agent stops before a consequential action, sends the details to an authorised person, and waits for that person to approve, reject or amend it. The agent then continues or stops based on the decision, and every step is recorded for later review.

The human in the loop AI guide explains what the term means and when an agent should ask a person. This page goes one level deeper: the individual steps of the workflow, how common agent and automation platforms pause for approval, what an approval request should contain, and how to handle the cases where nobody answers.

Human in the loop AI workflow diagram

The diagram shows the seven steps most human-in-the-loop implementations share, with the two branches that matter most in practice: low-risk actions that skip approval, and requests that escalate when the approver does not respond.

Steps 4 and 5 are highlighted because they are where most workflows fail. The logic that pauses an agent is usually reliable; the human step that follows it often is not.

How do human-in-the-loop workflows work?

Human-in-the-loop workflows work by inserting a checkpoint between an AI agent deciding to act and the action taking place. At the checkpoint the agent saves its state, a request is sent to a named approver, and the agent waits. The decision is passed back, the agent resumes or stops, and the whole exchange is logged.

Each step has a specific job:

1. Check policy. Before acting, the agent checks the action against an approval policy. Payments over a threshold, external messages and permission changes are typical triggers. Low-risk actions proceed without a pause, under monitoring.
2. Pause. The agent saves its state so it can wait minutes, hours or days without losing its place or repeating work it has already done.
3. Request. The workflow sends an approval request to a delivery system, usually through an API call or a webhook. The request carries a unique identifier so the decision can be matched to the right paused task.
4. Deliver. The request reaches a named person, or a group they belong to, on a channel they will actually notice, with enough context to judge it without opening other systems.
5. Decide. The approver approves, rejects or amends the action. If nobody responds before the deadline, the request escalates to a backup approver rather than proceeding by default.
6. Resume. The decision is returned to the paused task. On approval the agent carries out the action; on rejection it stops and records the reason.
7. Record. The request, the approver, the decision, any amendments and the timestamps are stored as an audit trail.

How do AI agent frameworks pause for human approval?

Most AI agent and automation frameworks pause for human approval by suspending the run, saving its state, and exposing a pending task that an outside system can resolve. A separate call then resumes the run with the person's decision. The pause mechanism is built in; delivering the request to a person is left to you.

The pattern is the same across all four: the framework handles pausing and resuming, but it does not guarantee that a person sees the request. That is a delivery problem, and it sits outside the agent framework.

Two implementation details catch teams out. First, some frameworks re-run code that came before the pause when they resume; LangGraph, for example, restarts the node that called interrupt(), so side effects should sit after the pause or in a separate step. Second, a pause that can last for days needs durable storage, not memory that disappears when a server restarts.

What should an approval request contain?

An approval request should contain everything the approver needs to make a real judgement in one place: what the agent wants to do, why, the data it is acting on, the consequence of approving, the deadline, and the options available. It should also carry a unique identifier linking the decision back to the paused task.

• The proposed action, in plain language, such as "Refund 1,240 pounds to customer account 88231".
• The reason the agent chose it and the policy rule that triggered the approval.
• The evidence: the key inputs, or a link to them, so the approver can check the agent's reasoning.
• The consequence of approving, including whether the action can be reversed.
• The deadline and what happens if it passes.
• The choices: approve, reject, or amend with a comment.
• A request identifier that ties the response to the right task and appears in the audit trail.

Keep requests short enough to read in under a minute. If approvers routinely open three other systems before deciding, the request is missing context.

What happens if nobody approves the request?

If nobody approves the request, the workflow should escalate it to a backup approver after a set time and, if that also fails, stop the action and record that it timed out. An unanswered request should never approve itself, because a default approval turns the human step into a delay rather than a control.

This is known as failing closed. Some platforms make it straightforward to configure: AWS Step Functions, for example, supports a heartbeat timeout so a waiting task fails rather than waiting indefinitely (AWS documentation). Whatever the platform, decide in advance:

• How long each type of request can wait before escalating
• Who the backup approver is, and whether that is a person or a group
• Whether reminders are sent before escalation
• What the agent does after a final timeout, and who is told

Deadlines should reflect the business impact. A refund can usually wait until the next working day; a request to block a suspicious payment may need an answer within minutes.

Common human in the loop workflow mistakes

• Approving everything. If every action needs sign-off, approvers stop reading and start clicking. Reserve approval for actions that are irreversible, external, financially significant or access-related.
• Shared channels with no named owner. A request posted to a busy team chat is visible to everyone and owned by nobody. Our article on why Slack and email are not a human-in-the-loop strategy covers this in detail.
• Anonymous approvals. If the response is not tied to an authenticated individual, the audit trail cannot show who decided.
• No record of what the approver saw. Logging the decision without the request content makes it hard to review later whether the decision was reasonable.
• Timeouts that approve by default. As above, an unanswered request should escalate or stop.

Regulation is pushing in the same direction. For high-risk AI systems, the EU AI Act requires that people assigned to oversight can decide not to use the system's output and can intervene in or stop its operation (Regulation (EU) 2024/1689, Article 14). A workflow that cannot reliably reach those people makes that harder to show.

Where Heed fits in a human in the loop AI workflow

Heed is internal communication software built to make sure important messages are seen, acknowledged and recorded. In a human in the loop AI workflow it handles steps 4 and 5: getting the approval request in front of the right person and capturing a named, timestamped response.

• Triggered by your workflow. Desktop alerts can be triggered via API and webhooks, or from ServiceNow, Splunk, SCOM and Jira, so an agent or orchestration platform can raise a request at the checkpoint.
• Sent to the right person. Requests can be targeted by department, location or role through Active Directory and SAML sync.
• Answered from the alert. Alerts can include inline action buttons so approvers can respond directly from the notification, as described on our approvals solution page.
• Escalated when unanswered. Escalation can notify a secondary approver or manager, with follow-up alerts for requests that are still waiting.
• Recorded. Acknowledgement can be required before an alert is dismissed, giving named, timestamped proof of who confirmed each request.
• Deployed where your data must stay. Heed offers true on-premises deployment as well as regional cloud options, and is ISO 27001 certified.

Heed does not decide which actions need approval, and it does not make an AI system compliant on its own. It provides the dependable human step that an approval policy relies on. For the bigger picture of where oversight belongs as AI use matures, see the three stages of AI adoption, or book a demo to see the approval flow in action.