gotoHuman vs Hatchet

gotoHuman

Built for agent review, with TypeScript and Python SDKs, a 3-tool MCP server, an n8n node and a Make app. No status page, published rate limits or documented error responses.

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.

gotoHuman

1. Call get-form-schema before request-human-review-with-form, since the field data must match the review type
2. Send agentId on every API request, because the API reference marks it required even though the JS SDK doesn't
3. Pass a webhookUrl per request when the review type has no default, or the answer has nowhere to go
4. Deduplicate webhook calls on the Idempotency-Key header, since delivery is at least once
5. Set your own deadline on the agent side and treat silence as a rejection

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