How to Build a Human-in-the-Loop Review Workflow in OpenClaw

Most agent pipelines run end-to-end without stopping. That works for low-risk tasks, but the moment an agent drafts a client email, generates a deployment diff, or produces a financial report, you want a human to sign off before the side effects fire.

A human-in-the-loop review workflow solves this by splitting the pipeline into stages with explicit checkpoints between them. The agent creates an artifact (a draft, a plan, a batch of invoices), saves it to persistent storage, and then stops. A notification goes out to whatever channel the reviewer uses. The reviewer reads the artifact, approves or rejects it, and only then does the pipeline pick back up.

The critical property is determinism. The pipeline resumes from stored state, not from the agent's memory. If the reviewer takes three hours, three days, or comes back after a server restart, the pipeline resolves the same way. This is what separates a real HITL pattern from just asking a chatbot "should I continue?"

OpenClaw supports this pattern through its hook system for event-driven automation, the Lobster workflow engine for multi-step pipelines, and gateway-level notification routing that works across Telegram, Discord, Slack, and other channels.

The HITL pattern in OpenClaw breaks down into three stages, each with clear inputs and outputs.

Stage 1: Artifact creation and persistence. The agent generates typed output, such as a JSON document with title, content, and risk flags. This artifact gets written to a database row (or any durable store) with a unique identifier. A corresponding review record is created with fields like a review ID, a human-friendly short code, the artifact reference, and a status set to "pending." The key principle: every generated artifact is stored with a unique ID, and the pipeline always resumes by referencing that ID rather than re-deriving context.

Stage 2: Checkpoint and routing. The pipeline evaluates whether human review is needed. In OpenClaw, this can branch three ways: halt and return the review ID for human decision, delegate to a reviewer agent that auto-approves or auto-rejects based on rules, or skip review entirely for low-risk artifacts. When the mode is "human," the pipeline stops and sends a notification through the OpenClaw gateway.

Stage 3: Finalization and side effects. After the reviewer responds, the pipeline reads the artifact and the review decision from storage. It applies any final edits, persists the output, and executes side effects like publishing, deploying, or sending. Side effects only fire after the pipeline confirms the review status is "approved" in the database. This prevents unauthorized advancement, where a bug or race condition could skip the approval gate.

Each stage produces typed outputs validated at the boundary. This prevents what the OpenClaw community calls "memory drift," where an agent's context window accumulates stale or contradictory state over a long conversation.

OpenClaw's hook system is the backbone of event-driven automation in the platform. Hooks fire on lifecycle events including command events (new, reset, stop), session events (compact, patch), message events (received, transcribed, sent), and agent/gateway events (bootstrap, startup, shutdown). Hooks can be internal (triggered by gateway events) or external webhooks that call third-party HTTP endpoints.

For HITL workflows, the notification pattern works through the gateway automation hooks. Rather than embedding channel-specific logic (Discord API calls, Telegram bot messages, Slack webhooks) directly into the pipeline, the system posts to the OpenClaw gateway's wake endpoint with a payload that includes the review ID and a pending notification flag. This wakes the existing agent session that is already connected to whatever channel the reviewer uses.

The result is channel-agnostic notification delivery. The same pipeline code works whether the reviewer gets their approval prompt in a Telegram conversation, a Discord interaction, a Slack workflow, or a CLI session. The OpenClaw gateway handles delivery routing, and the pipeline core never needs to know which channel is active. This design keeps the approval logic clean and portable across deployments.

When a review notification arrives, it includes four components: an identity line with the short code, a clear statement of what approval enables, a scannable summary of the artifact (with collapsed details for lengthy content), and risk flags explaining why human review was triggered. The reviewer responds with minimal syntax, either approving or rejecting with structured feedback.

Store and Review Agent Artifacts in One Place

Fast.io gives your OpenClaw agents persistent storage with built-in approvals, audit trails, and Intelligence Mode. 50 GB free, no credit card, no expiration.

Sign Up Free

Lobster is OpenClaw's workflow engine for running multi-step tool sequences as deterministic pipelines. It adds explicit approval checkpoints and resumable state on top of OpenClaw's conversational agent model.

A key addition in Lobster is the "needs_input" status, which goes beyond simple yes/no approval gates. When a workflow step requires structured human input, it pauses with a JSON Schema definition describing what data is needed. The pause envelope includes the prompt, the schema, default values, and the resolved subject (the context shown to the reviewer). On resume, the human's response is validated against the stored schema before execution continues.

This distinction matters. Traditional HITL gates are binary: approve or reject. Lobster's input steps can ask "which environment should I deploy to?" with an enum constraint, or "what feedback do you have on this draft?" with a freeform text field. The workflow stores both what was shown to the human (the subject) and what the human answered (the response), so later steps can reference both.

Lobster also supports extended conditionals that go beyond checking approval status. Workflow steps can branch on deep field access into response objects, use equality and inequality checks, combine conditions with logical operators, and negate results. This lets you build workflows where, for example, a deployment only proceeds if the reviewer approved AND selected "prod" as the target environment.

For feedback loops, the "next" field enables non-linear execution. A review step can route back to a drafting step if the reviewer requests changes, creating a revise-review cycle that repeats until the reviewer approves. A configurable iteration limit (defaulting to 20) prevents runaway loops from badly written workflows.

The HITL pattern depends entirely on durable storage. If the artifact or review state disappears between checkpoint and approval, the pipeline breaks. You have several options for the storage layer, each with different tradeoffs.

Local database (SQLite or Postgres). The simplest option for single-server deployments. The Medium walkthrough by Zeeshan Ahmad describes a Postgres-backed approach where artifacts and review records live in dedicated tables. This works well when the pipeline and the reviewer operate in the same environment, but it requires you to manage backups, handle schema migrations, and solve the problem of giving reviewers access to artifacts stored in a database they cannot browse directly.

Object storage (S3, R2, GCS). Good for large artifacts like generated PDFs or media files. You get durability and scalability, but you need to manage access control (signed URLs, IAM policies) and build a separate system for tracking review state.

Fast.io workspaces. A workspace gives you file storage with versioning, access control, audit logs, and built-in AI indexing in one layer. Agents upload artifacts through the Fast.io MCP server or REST API. Reviewers open the workspace in their browser to preview files, leave comments, and track changes. Fast.io's Review and Approvals feature provides a native 4-step flow (Submit, Review, Approve/Reject, Complete) with an immutable audit trail, which maps directly to the HITL state machine. The free agent plan includes 50 GB of storage and 5,000 monthly credits with no credit card required, which covers a significant volume of review artifacts. For teams that need more, the platform scales through paid plans.

The practical advantage of a workspace-based approach is that it collapses file hosting, review UI, audit logging, and access control into one system. You do not need to stitch together S3 for storage, a custom dashboard for review, and a separate logging pipeline for compliance.

Building a production HITL workflow in OpenClaw means connecting these pieces into a reliable system. Here is what to verify before going live.

Start with artifact persistence. Every stage in the pipeline should write its output to durable storage with a unique ID. Review records need short codes, status fields, and timestamps. If you are using Lobster, the workflow engine handles pause state and resume tokens natively. If you are building a custom pipeline, make sure your checkpoint logic is idempotent and that resume always references stored state rather than conversation memory.

Configure notifications through OpenClaw's hook system. The gateway automation hooks approach keeps your pipeline channel-agnostic. Test that notifications arrive correctly in your team's primary channel, whether that is Telegram, Discord, Slack, or another platform. Include the short code, artifact summary, risk flags, and clear response syntax in every notification.

Set up your storage layer. For Fast.io, create a workspace for review artifacts, enable Intelligence Mode for automatic indexing, and configure the approval workflow. Agents authenticate through the MCP server and upload artifacts directly. Reviewers access the workspace through the web interface. The activity log captures every upload, review, and approval for compliance.

Handle edge cases. Add review expiration so stale approvals do not get acted on weeks later. Implement multi-reviewer quorum for high-risk artifacts, requiring two or more sign-offs before the pipeline proceeds. Make sure rejected reviews require feedback so the agent has actionable input for the next draft. Build a status check command so reviewers can query where a review stands without digging through chat history.

Finally, test the failure modes. Restart the server mid-review and confirm the pipeline resumes correctly. Send duplicate approval requests and verify idempotency. Simulate a rejected review and confirm the feedback loop routes back to the drafting stage. These are the scenarios that distinguish a demo from a production system.