Hatchet vs withHuman

Hatchet

A durable task waits for a keyed event without holding a worker slot, and resumes from its event log after a restart, in Python, TypeScript, Go or Ruby. Hatchet supplies only the pause and resume. It has no approver inbox, notification channel or record of who answered, and its MCP server cannot push the event.

withHuman

The approval API is small and carefully specified, with a public OpenAPI 3.1 document, mandatory idempotency keys and agent credentials that can never approve. The service is in early access under its own terms, with no status page, published rate limits or changelog, and the open-source repository the site links to returned 404 on 8 October 2026.

Hatchet

1. Put the approval wait in a durable task, and keep API calls, database reads and random values in child tasks, because the code between checkpoints is replayed
2. Add a sleep condition in the same or group as the event condition to set a deadline, and treat the sleep firing first as a timeout
3. Give the event a scope and the wait a lookback window when the answer can arrive before the wait starts. Both must be set together
4. Filter with a CEL expression such as input.user_id == '1234' so one approval key cannot resume another request's task
5. Push the answer with the SDK's event push or POST /api/v1/tenants/{tenant}/events. The MCP server has no tool for it
6. Grant the MCP server one profile with hatchet mcp auth --grant <profile>. It refuses profiles that were not granted

withHuman

1. Send an Idempotency-Key header on POST /api/aap/v1/requests. The call answers 400 without one
2. Read the decision with GET /api/aap/v1/requests/{id}?wait=30s and repeat while status is pending. wait is capped at 30 seconds
3. Set timeout between one second and seven days, and treat expired and cancelled as a refusal
4. Start an approved call within five minutes of decided_at, because the decision carries an expires_at
5. Cancel a request when you stop waiting, so reviewers stop seeing it