OpenClaw vs Make: Maintaining a Workflow That Needs Retries and Human Handoffs

Published July 6, 2026 · OpenClawBlog Team · Documentation checked September 13, 2026.

Scope. This is a documentation-led comparison. It does not claim a hands-on run, benchmark, or production deployment. The linked products change, so the September 13 documentation check matters more than the backdated publication date for current behavior.

A workflow with a person in the middle fails differently from a simple scheduled task. The first attempt may work. The reviewer may never answer. A provider may accept a request just before the connection drops. An operator may then press retry without knowing whether the original action happened.

OpenClaw and Make can both sit around this kind of process, but they put the maintenance boundary in different places. OpenClaw gives you a Gateway, task records, and a durable flow model that can represent waiting and resuming. Make gives you module-level error handlers, incomplete executions, scenario history, and a webhook queue that can carry a review decision.

The practical question is not which product has more automation features. It is which one leaves the next operator with a clear answer to four questions: what state was reached, what was retried, who still needs to act, and whether the external side effect is known to have happened.

The workflow to put under pressure

Use the same example for both products: a support request arrives, an assistant gathers account information, drafts a reply, and sends the reply only after a person approves it. A temporary account-service failure may be retried. A missing field should stop the item. A final send timeout should create an unknown state, not an automatic duplicate.

Before choosing a platform, write down the record that must survive a restart or a handoff. This is a proposed application record, not a built-in schema:

request_id=support-1842
state=pending_review
attempts=2
action_id=reply-1842-v3
payload_hash=recorded-before-approval
review_deadline=2026-07-06T16:00:00Z
side_effect=unconfirmed

The reviewer should approve that exact action. A new recipient, changed body, or altered account should create a new review step. That rule matters more than the label attached to the automation tool.

Short answer

Choose Make when the workflow is a fairly fixed business process and an operations team needs a visible place to inspect failed runs, retry an incomplete bundle, or correct a module before continuing. Its error handlers and execution history make the repair path easier to find.

Choose OpenClaw when the workflow belongs to an agent that must reason over context, use several capabilities, and pause at an explicitly modelled state. Its Task Flow and background-task records give a developer more control over the handoff contract, but that control comes with controller code, permission design, and recovery tests to maintain.

For a high-impact action, neither product should be treated as an exactly-once delivery system by default. Store an action identifier, reconcile the destination after an ambiguous timeout, and keep the final permission separate from the assistant's ability to prepare the action.

Compare the same criteria

OpenClaw: explicit state, more design work

Documented behavior. OpenClaw's automation guide says jobs run inside the Gateway, while job definitions, runtime state, and run history persist in a shared SQLite database. Each detached automation run also creates a background-task record. That gives an operator a place to inspect work, but the Gateway must be running for schedules to fire.

For a multi-step handoff, Task Flow is the important distinction. The documentation describes a durable record with JSON state, a revision counter, and linked tasks that survives Gateway restarts. A managed flow has a controller that advances between states such as running, waiting, and terminal. Transitions require the latest revision, which prevents an old reviewer response from silently overwriting a newer state.

That is a strong foundation for the support example. The controller can move an item to pending_review, store the exact draft and action identifier, and accept a later resume only if it refers to the current revision. The reviewer interface is still yours to build or connect. Task Flow describes the durable controller contract; it does not by itself give every installation a ready-made approval form with the identity rules your business may need.

OpenClaw's background-task documentation also separates execution from result delivery. A task can succeed while delivery is queued or blocked. The operator can inspect blocked work, retry a retained completion, or dismiss intentional non-delivery. The documentation warns that retrying after an ambiguous provider acknowledgement can duplicate a visible result. That caveat is useful because it keeps a delivery retry from being confused with a safe replay of the underlying action.

There is a narrower restart guarantee to keep in mind. The restart guide describes recovery for interrupted sessions, including bounded automatic dispatch attempts and a durable dispatch identifier. That is evidence for session recovery, not proof that every custom API tool has exactly-once semantics. If the final step changes a ticket, sends money, or publishes a message, the tool wrapper still needs an idempotency key or a destination lookup.

Permissions are another maintenance boundary. Exec approvals guard commands on a Gateway or node host when policy, allowlist, and optional user approval agree. That control applies to host execution. If the side effect is performed by a direct API or plugin tool, put the approval gate around that actual tool instead of assuming host-command approval covers it.

Make: a clearer repair queue, a handoff you must model

Documented behavior. Make's Retry error handler pauses a failed bundle, stores the error and mappings, and keeps the remaining flow available as an incomplete execution. It can retry automatically after a chosen number of attempts and interval, or leave the item for a person to resolve. Other bundles can continue while the failed bundle waits.

The separate automatic retry documentation lists rate-limit, connection, and module-timeout errors among the cases that can be retried automatically. It uses a backoff schedule and limits concurrent retries from the same scenario. Data or runtime errors generally need a module or scenario correction before the incomplete execution can be resolved.

This is a practical maintenance advantage. An operator can open the failed module, inspect the original data, fix the mapping or connection, and continue from the point of failure. The incomplete-execution guide also makes the destructive option clear: deleting an incomplete execution removes it from the list and it cannot be restored.

For the human step, use a proposed design rather than assuming that a queue item is an approval record. After Make prepares the reply, send a review request to a controlled form or internal service. That service returns the decision to a Make webhook with the request ID, action ID, reviewer identity, decision, and expiry. Make's webhook documentation describes a per-webhook processing queue and an option to process requests in order instead of in parallel.

The queue helps transport the response. It does not tell you whether the caller was the intended reviewer or whether an old approval should still be accepted. Add authentication, check the stored action hash, reject expired decisions, and make the resume route idempotent. Those are application controls, not claims about a built-in Make approval ledger.

Make's scenario history gives an operator run status, module outputs, execution details, and a change log. The page also says history retention depends on the pricing plan, while full-text execution search is limited to higher tiers. This makes the plan choice part of incident response. A workflow that must be investigated weeks later should not be evaluated only on the cost of its normal runs.

Costs are easier to see but can be less predictable than the headline subscription. The current pricing page counts module actions as credits and places features such as custom variables, full-text execution search, team roles, and advanced controls in different tiers. Use the live plan page when estimating a real workload; this article does not turn a changing price table into a permanent recommendation.

Build one recovery contract for either product

Editorial inference. The safest comparison is not a feature checklist. It is one contract implemented twice.

1. Record the request and a stable action ID before any external side effect.
2. Separate transient errors from invalid data, expired approval, and unknown provider outcomes.
3. Retry only the operation that is safe to repeat. Keep the attempt count and next retry time visible.
4. Store the reviewer decision against the exact action ID and payload hash. A changed payload requires another decision.
5. When a provider times out after accepting a request, query the provider or route the item to a person. Do not infer failure from the missing response.
6. Keep a final state such as confirmed, cancelled, or unknown. Do not let a successful model response stand in for an external receipt.

OpenClaw implementation sketch

This is a proposed design using the documented runtime surfaces. A managed Task Flow controller creates the state, links the agent work, moves the flow to waiting, and resumes it after an authenticated reviewer response. The action tool checks the revision and action ID before executing. The automation or task ledger reports progress and delivery separately. An operator can use openclaw tasks audit and openclaw tasks maintenance as part of the runbook.

Make implementation sketch

Build the same stages as modules. Attach a retry handler to the temporary account lookup, store the review envelope before calling the reviewer service, and resume through an authenticated webhook. Use scenario history and incomplete executions for repair. Put the final action behind a module that checks the action ID and destination status before sending. A visual branch is useful only if every route that can reach the side effect is visible and reviewed.

Failure paths worth testing

Proposed tests. No OpenClaw Gateway, Make scenario, or live support system was run for this article. Use harmless records and a downstream test endpoint before connecting real customer data.

1. Make the account lookup fail twice, then succeed. Check that both systems respect the retry limit and leave the final state unambiguous.
2. Send malformed input. Confirm that the item stops for correction instead of consuming the retry budget indefinitely.
3. Leave the reviewer silent past the deadline. The item should become expired or held, never approved by timeout.
4. Restart the Gateway or workflow host while the item waits. Confirm that the same request and action ID remain recoverable.
5. Accept the final request at the test endpoint, then return a timeout. Verify that recovery checks the endpoint before attempting another send.
6. Start two copies of the same request. Confirm that only one can claim the action or that the destination rejects the duplicate.

Capture the state record, run identifier, reviewer decision, retry history, and downstream receipt for every test. That evidence tells you more about maintenance than a successful first run.

Conditional recommendation

Make is the safer starting point for a fixed integration workflow maintained by operators who want module-level retries, incomplete-execution repair, a visual scenario, and familiar run history. Its main limits are plan-dependent retention, queue behavior, and the application work needed to make a webhook handoff trustworthy.

OpenClaw is the better fit when an agent is already the operator's interface and the workflow needs a durable state machine that can pause, resume, and retain context across several kinds of work. The tradeoff is real: you own the controller, the tool boundary, the reviewer identity check, the Gateway, and the tests that prove recovery.

If the workflow can create an expensive or irreversible side effect, choose based on the recovery record you can maintain. The platform is only one part of that record. The action identifier, approval boundary, and destination reconciliation matter more than whether the workflow is drawn on a canvas or described in a task controller.

Sources

• Automation - OpenClaw — Gateway scheduling and automation boundaries.
• Task Flow - OpenClaw — durable flow state, waiting, resume, and revisions.
• Background tasks - OpenClaw — task lifecycle, delivery recovery, audit, and retention.
• Restart recovery - OpenClaw — interrupted-session recovery and bounded retries.
• Exec approvals - OpenClaw — host-command approval boundaries.
• Retry error handler - Make — failed bundles and retry handling.
• Automatic retry of incomplete executions - Make — retry classes, backoff, and concurrency.
• Manage incomplete executions - Make — manual repair, retry, and deletion behavior.
• Webhooks - Make — queues, ordering, and webhook processing.
• Scenario history - Make — run details, logs, change history, and retention.
• Make pricing — current credit and plan structure.