Rank #5 of 6 in Durable Execution Engines
Hatchet Technologies Inc.
Install
Try itExperimental
See what an agent can do with Hatchet before you ever sign up. Pick a story: recorded sessions replay real probe-harness transcripts; commands tagged live-capable can re-run against the real endpoint from our edge, right now (▶ run live — the exact same request, live and recorded lines always labeled); sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$curl -si https://cloud.onhatchet.run/api/v1/tenants | head -10recorded session — replayed, not liveVerified integrations
No integration evidence found in our corpus for this product yet — that means none was found, never that it doesn’t integrate.
By theme — the product's score on each story themeBy theme
Agent workloads — stories about agent workloads in this arenaAgent workloadsevidence →
Stories about agent workloads in this arena
Agenticness — how well agents can access and operate the productAgenticnessevidence →
How well agents can access and operate the product
Automation depth — how much of the product can run unattendedAutomation depthevidence →
How much of the product can run unattended
Developer experience — stories about developer experience in this arenaDeveloper experienceevidence →
Stories about developer experience in this arena
Human in the loop — stories about human in the loop in this arenaHuman in the loopevidence →
Stories about human in the loop in this arena
Observability debugging — stories about observability debugging in this arenaObservability debuggingevidence →
Stories about observability debugging in this arena
Openness — open source, data portability, and self-hosting storiesOpennessevidence →
Open source, data portability, and self-hosting stories
Operations hosting — stories about operations hosting in this arenaOperations hostingevidence →
Stories about operations hosting in this arena
Performance scale — stories about performance scale in this arenaPerformance scaleevidence →
Stories about performance scale in this arena
Privacy posture — data-handling and privacy storiesPrivacy postureevidence →
Data-handling and privacy stories
Reliability recovery — stories about reliability recovery in this arenaReliability recoveryevidence →
Stories about reliability recovery in this arena
Triggers scheduling — stories about triggers scheduling in this arenaTriggers schedulingevidence →
Stories about triggers scheduling in this arena
Versioning deployment — stories about versioning deployment in this arenaVersioning deploymentevidence →
Stories about versioning deployment in this arena
Workflow authoring — stories about workflow authoring in this arenaWorkflow authoringevidence →
Stories about workflow authoring in this arena
Story verdicts — every judged story with its evidenceStory verdicts
What’s free: 1 free · 0 paid · 1 enterprise · 31 not stated in evidence
Follow the green: where the map greys out is where Hatchet stops today. ✓ full · ~ partial · ! disputed · — none · n/a not applicable.
Agent workloads — stories about agent workloads in this arenaAgent workloads
Stories about agent workloads in this arena
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
✓7/10
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
~6/10
I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes
—–
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
API surface
Drive the product through a documented public API
~6/10
unlocks → Scoped API keys · Machine-readable spec · Versioning policy · I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes · A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives
Subscribe to events via webhooks
~3/10
Build against official SDKs
✓8/10
Issue scoped/least-privilege API credentials for an agent
—–
Connect an agent via an official MCP server
✓7/10
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
—0/10
Test against a sandbox environment without touching production data
~4/10
Explore an interactive API reference with runnable examples
—0/10
Agentic features
Delegate tasks to a built-in AI assistant inside the product
n/an/a
Operate the product with natural-language commands
—0/10
Plug MCP servers into this product so it can use their tools
—0/10
Get AI-generated insights and suggestions from my data inside the product
n/an/a
Set up automations that run autonomously in the background
✓8/10
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
Automation depth
Define rules that trigger actions automatically on events
✓7/10
unlocks → Versioned workflows · I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
Schedule recurring jobs or workflows
✓8/10
unlocks → Versioned workflows
Perform bulk operations across many items at once
~5/10
Version, review, and roll back my automations
—–
Developer experience — stories about developer experience in this arenaDeveloper experience
Stories about developer experience in this arena
Human in the loop — stories about human in the loop in this arenaHuman in the loop
Stories about human in the loop in this arena
Observability debugging — stories about observability debugging in this arenaObservability debugging
Stories about observability debugging in this arena
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
~4/10
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
—–
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
~5/10
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
Operations hosting — stories about operations hosting in this arenaOperations hosting
Stories about operations hosting in this arena
Performance scale — stories about performance scale in this arenaPerformance scale
Stories about performance scale in this arena
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
✓8/10
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
~4/10
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
~6/10
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
Reliability recovery — stories about reliability recovery in this arenaReliability recovery
Stories about reliability recovery in this arena
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
—–
A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
~4/10
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
~6/10
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
~6/10
Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling
Stories about triggers scheduling in this arena
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
~6/10
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
~4/10
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
~5/10
Versioning deployment — stories about versioning deployment in this arenaVersioning deployment
Stories about versioning deployment in this arena
Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring
Stories about workflow authoring in this arena
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
~6/10
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
—0/10
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
~6/10
Sorted by importance (agentic first) (high → low) · 53/53 stories · click a row’s chevron for the rationale and evidence
Connect an agent via an official MCP server G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 7/10 | Cclaimed | |
Drive the product through a documented public API G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | partial | 6/10 | Tprobed | |
Delegate tasks to a built-in AI assistant inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | 0/10 | ||
Plug MCP servers into this product so it can use their tools G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | 0/10 | ||
Point an agent at llms.txt or agent-oriented docs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 9/10 | Tprobed | |
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Xcommunity | |
Run the product headlessly / in CI for automation G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Cclaimed | |
Set up automations that run autonomously in the background G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Xcommunity | |
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Tprobed | |
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 3/10 | Cclaimed | |
Download a machine-readable API spec (OpenAPI or equivalent) G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Explore an interactive API reference with runnable examples G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Rely on versioned APIs with a documented deprecation policy G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Get AI-generated insights and suggestions from my data inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | n/a | untested | none yet | |
Issue scoped/least-privilege API credentials for an agent G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Test against a sandbox environment without touching production data G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 1 | partial | 4/10 | Cclaimed | |
Self-host the core product G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | fullfree | 8/10 | Cclaimed | |
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 3 | full | 7/10 | Cclaimed | |
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run C Agent loops | agent builder | Agent workloads — stories about agent workloads in this arenaAgent workloads | 3 | full | 7/10 | Cclaimed | |
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact C Recovery | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 3 | partial | 6/10 | Cclaimed | |
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding C Retries | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 3 | partial | 6/10 | Xcommunity | |
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL C Authoring | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 3 | partial | 6/10 | Xcommunity | |
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter C Run visibility | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 3 | partial | 5/10 | Xcommunity | |
Export all of my data in open formats and leave G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | partial | 4/10 | Cclaimed | |
A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives C Approvals | backend developer | Human in the loop — stories about human in the loop in this arenaHuman in the loop | 3 | none | untested | none yet | |
I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism C Versioning | platform engineer | Versioning deployment — stories about versioning deployment in this arenaVersioning deployment | 3 | none | untested | none yet | |
Prevent my data from being used to train AI models G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 3 | n/a | untested | none yet | |
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest C Flow control | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 2 | full | 8/10 | Cclaimed | |
Schedule recurring jobs or workflows G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | full | 8/10 | Cclaimed | |
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions C Events | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 2 | partial | 6/10 | Cclaimed | |
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code C Ai integrations | agent builder | Agent workloads — stories about agent workloads in this arenaAgent workloads | 2 | partial | 6/10 | Cclaimed | |
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs C Language coverage | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 2 | partial | 6/10 | Xcommunity | |
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss C Scaling | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 2 | partial | 6/10 | Xcommunity | |
Do everything through the API that I can do in the UI G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | partial | 5/10 | Tprobed | |
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs C Schedules | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 2 | partial | 5/10 | Cclaimed | |
Perform bulk operations across many items at once G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | partial | 5/10 | Cclaimed | |
A workflow can sleep or wait for days to months without holding a server, connection, or billable compute C Long running | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 2 | partial | 4/10 | Cclaimed | |
I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network C Deployment model | platform engineer | Operations hosting — stories about operations hosting in this arenaOperations hosting | 2 | partial | 4/10 | Cclaimed | |
Choose where my data is stored (region/residency) G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | partial | 3/10 | Cclaimed | |
Control data retention and deletion G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | partialenterprise | 3/10 | Cclaimed | |
I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow C Signals | backend developer | Human in the loop — stories about human in the loop in this arenaHuman in the loop | 2 | partial | 3/10 | Cclaimed | |
One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps C Local dev | backend developer | Developer experience — stories about developer experience in this arenaDeveloper experience | 2 | partial | 3/10 | Cclaimed | |
Read the product's source under an open license G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | partial | 3/10 | Cclaimed | |
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination C Composition | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 2 | none | 0/10 | ||
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover C Replay | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 2 | none | untested | none yet | |
I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes C Streaming | ai-native user | Agent workloads — stories about agent workloads in this arenaAgent workloads | 2 | none | untested | none yet | |
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending C Exactly once | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 2 | none | untested | none yet | |
Opt out of telemetry and usage tracking G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave C Metrics | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 1 | partial | 4/10 | Cclaimed | |
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue C Prioritization | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 1 | partial | 4/10 | Cclaimed | |
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want C Flow shaping | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 1 | partial | 4/10 | Cclaimed | |
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | none | untested | none yet |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 39 stories with headroom
What would move Hatchet’s scores — derived from its own judged verdicts, biggest headroom first. Each line quotes what the judge found missing; shipping it (or evidencing it publicly) is the fix.
Agenticness — how well agents can access and operate the productPlug MCP servers into this product so it can use their tools
nonemoves agent-readyimpact 45
Hatchet's MCP-related evidence (hatchet-docs-7, hatchet-docs-34, hatchet-docs-36, hatchet-docs-37) describes the opposite integration direction: exposing Hatchet's own workflows/tasks as tools that external agent frameworks (Claude Agent SDK, OpenAI Agents SDK) can invoke via MCP.
Human in the loop — stories about human in the loop in this arenaA workflow pauses for human approval or input for hours or days and resumes the moment the response arrives
nonemoves PA Scoreimpact 30
No evidence describes a durable pause/resume mechanism for human approval or external event input (e.g., a wait-for-event or signal API); the pack covers retries, cron, scheduling, concurrency, webhooks, and AI-agent tool integrations but never a human-in-the-loop pause/resume pattern.
Versioning deployment — stories about versioning deployment in this arenaI deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism
nonemoves PA Scoreimpact 30
No evidence describes workflow-version pinning for in-flight runs, deterministic replay guarantees, or any mechanism to keep already-started runs on the code version they began with while new versions roll out — the docs cover retries, concurrency, cron, self-hosting, and CLI tooling but never versioning/determinism semantics.
Agenticness — how well agents can access and operate the productOperate the product with natural-language commands
nonemoves Built-in AIimpact 30
Hatchet's evidence shows a structured CLI, TUI, and API/SDKs, plus the ability to expose Hatchet workflows as tools *for* external AI agents (Claude Agent SDK, OpenAI Agents SDK) — but nothing shows a user operating Hatchet itself via natural-language commands (e.g., a chat interface or NL-to-command translation).
Agenticness — how well agents can access and operate the productIssue scoped/least-privilege API credentials for an agent
nonemoves agent-readyimpact 30
No evidence of scoped or least-privilege API credential/token issuance for agents — the pack covers CLI tooling, concurrency, self-hosting, and pricing tiers (SSO/audit logs) but never describes API key scoping or credential minimization features.
Agenticness — how well agents can access and operate the productExplore an interactive API reference with runnable examples
nonemoves API qualityimpact 30
No evidence of an interactive API reference or runnable-example explorer; probes for OpenAPI/Swagger endpoints returned 404s and docs only reference CLI/SDK references and cookbooks, not an interactive API console.
Agenticness — how well agents can access and operate the productDownload a machine-readable API spec (OpenAPI or equivalent)
nonemoves API qualityimpact 30
A direct probe for OpenAPI/swagger spec files at all standard locations returned 404s, and no evidence pack item points to a downloadable API spec; Hatchet does expose an llms.txt but that is not a machine-readable API spec.
Agenticness — how well agents can access and operate the productRely on versioned APIs with a documented deprecation policy
nonemoves API qualityimpact 30
No evidence of API versioning scheme or a documented deprecation policy; the OpenAPI spec probe returned 404s and no changelog/deprecation policy content is present, only a v1 docs path exists without explanation of versioning/deprecation guarantees.
Showing the top 8 of 39 — every none/partial verdict in the story verdicts table is headroom.
Think a verdict is wrong? Every verdicts-table row has a Flag link — see the methodology.
Coverage map — which docs area, API section, or community source covers which judged storiesCoverage map10 surfaces · 36 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
API reference23 stories
- Run the product headlessly / in CI for automation
- Use an official CLI
- Drive the product through a documented public API
- Build against official SDKs
- Set up automations that run autonomously in the background
- Test against a sandbox environment without touching production data
- Perform bulk operations across many items at once
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Do everything through the API that I can do in the UI
- I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network
- I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
- I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
- I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
V1 docs20 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- Run the product headlessly / in CI for automation
- Drive the product through a documented public API
- Subscribe to events via webhooks
- Set up automations that run autonomously in the background
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
- I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
- I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
GitHub README17 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- Run the product headlessly / in CI for automation
- Build against official SDKs
- Set up automations that run autonomously in the background
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Read the product's source under an open license
- Self-host the core product
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
Self hosting docs10 stories
- Run the product headlessly / in CI for automation
- Schedule recurring jobs or workflows
- Do everything through the API that I can do in the UI
- Export all of my data in open formats and leave
- Self-host the core product
- I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network
- Choose where my data is stored (region/residency)
- Control data retention and deletion
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
Hacker News8 stories
- Build against official SDKs
- Set up automations that run autonomously in the background
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Do everything through the API that I can do in the UI
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
Cookbooks docs6 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
- Connect an agent via an official MCP server
- Drive the product through a documented public API
- Build against official SDKs
- Set up automations that run autonomously in the background
Pricing docs3 stories
OpenAPI spec2 stories
Probe proofs — replayable recordings from the probe harnessProbe proofs
Replayable recordings from our probe harness — see the Prove-It protocol to submit one.
$curl -si https://cloud.onhatchet.run/api/v1/tenants | head -10reproduced$ curl -si https://cloud.onhatchet.run/api/v1/tenants | head -10 HTTP/2 403 date: Thu, 10 Sep 2026 18:41:14 GMT content-type: application/json content-length: 5 strict-transport-security: max-age=776000; includeSubDomains; preload content-security-policy: script-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net https://*.posthog.com https://widget.usepylon.com https://*.onhatchet.run; worker-src blob:; frame-ancestors 'self' docs.hatchet.run hatchet.run; object-src 'none'; base-uri 'self' referrer-policy: strict-origin-when-cross-origin x-frame-options: DENY x-content-type-options: nosniff permissions-policy: geolocation=(), midi=(), notifications=(), push=(), sync-xhr=(), microphone=(), camera=(), magnetometer=(), gyroscope=(), speaker=(), vibrate=(), fullscreen=(self), payment=()
$curl -fsSL https://install.hatchet.run/install.sh | head -8reproduced$ curl -fsSL https://install.hatchet.run/install.sh | head -8 #!/bin/bash # Hatchet CLI Installation Script # Supports macOS (Darwin) and Linux on x86_64 and ARM64 architectures # # Usage: # Basic installation: curl -fsSL https://install.hatchet.run | bash # Specific version: curl -fsSL https://install.hatchet.run | bash -s -- v0.73.10
$curl -s https://docs.hatchet.run/llms.txt | head -6reproduced$ curl -s https://docs.hatchet.run/llms.txt | head -6 # Hatchet Documentation > Hatchet is a distributed task queue and workflow engine for modern applications. It provides durable execution, concurrency control, rate limiting, and observability for background tasks and workflows in Python, TypeScript, and Go. ## Guide
$curl -sL https://docs.hatchet.run/cookbooks/hatchet-and-mcp.md | head -8reproduced$ curl -sL https://docs.hatchet.run/cookbooks/hatchet-and-mcp.md | head -8 # Hatchet and MCP: Exposing Tasks and Workflows as Agent Tools The [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) is an open standard for connecting AI agents to external tools, data sources, and services. This guide shows how to expose Hatchet [workflows](/v1/directed-acyclic-graphs) and [standalone tasks](/v1/tasks) as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke. Later cookbooks in this series will show how to integrate those tools into a full agent loop. In this guide, we define a Hatchet workflow and a standalone task, each with a description and a typed input schema, then convert each into an agent tool. When an agent invokes one of those tools, the tool handler submits a run to the Hatchet engine. A worker picks up and executes the workflow or task and reports the result to Hatchet. The tool handler returns that result to the agent. ## What this guide builds
$uvx --from hatchet-sdk python -c 'import importlib.metadata; print("hatchet-sdk", importlib.metadata.version("hatchet-sdk"))'reproduced$ uvx --from hatchet-sdk python -c 'import importlib.metadata; print("hatchet-sdk", importlib.metadata.version("hatchet-sdk"))'
hatchet-sdk 1.40.1
Claims vs evidence — vendor claims reconciled against independent verdictsClaims vs evidence
4 of 11 testable claims verified · 0 contradicted → integrity 36/100
15 distinct capability claims found in Hatchet’s own claimed-docs/GitHub materials, reconciled against our judge’s independent verdicts.
4
Verified
7
Unverified
0
Contradicted
25
Undersold
Verified (6)
“Interact with a deployment via a terminal UI showing real-time task/workflow/worker status”
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filterpartialproof ↗
“Scaffold a new worker project from a template via `hatchet quickstart`”
“Manage multiple Hatchet instances/tenants with named CLI profiles for easy environment switching”
“Full platform providing queuing, automatic retries, durability, real-time monitoring, alerting, and logging”
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffoldingpartialproof ↗
“Full platform providing queuing, automatic retries, durability, real-time monitoring, alerting, and logging”
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filterpartialproof ↗
“Orchestrate background tasks, AI agents, and durable workflows with SDKs for Python, TypeScript, Go, and Ruby”
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKspartialproof ↗
Unverified (9)
“Run a worker locally with automatic reload on code changes via `hatchet worker dev`”
One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked stepspartialproof ↗
“Set per-key concurrency limits using CEL expressions, e.g. higher limits for premium users”
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the restfullproof ↗
“Define concurrency rules shared across multiple workflows, e.g. capping combined runs per user”
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the restfullproof ↗
“Expose workflows and tasks as tools callable by agent frameworks like Claude Agent SDK and OpenAI Agents SDK”
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue codepartialproof ↗
“Self-host the Hatchet control plane that manages workflows, schedules, and worker coordination”
“Full platform providing queuing, automatic retries, durability, real-time monitoring, alerting, and logging”
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehavepartialproof ↗
“Create and manage cron triggers that run workflows on a schedule”
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runspartialproof ↗
“Configure queue-depth-based concurrency strategies that cancel queued runs except the newest/oldest”
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the restfullproof ↗
“Enterprise plan offers extended data retention alongside audit logging and HIPAA compliance”
Undersold (25)
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-runfullproof ↗
Point an agent at llms.txt or agent-oriented docsfullproof ↗
Run the product headlessly / in CI for automationfullproof ↗
Drive the product through a documented public APIpartialproof ↗
Set up automations that run autonomously in the backgroundfullproof ↗
Test against a sandbox environment without touching production datapartialproof ↗
Perform bulk operations across many items at oncepartialproof ↗
Define rules that trigger actions automatically on eventsfullproof ↗
I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflowpartialproof ↗
Do everything through the API that I can do in the UIpartialproof ↗
Export all of my data in open formats and leavepartialproof ↗
Read the product's source under an open licensepartialproof ↗
I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my networkpartialproof ↗
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queuepartialproof ↗
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker losspartialproof ↗
Choose where my data is stored (region/residency)partialproof ↗
A workflow can sleep or wait for days to months without holding a server, connection, or billable computepartialproof ↗
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intactpartialproof ↗
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functionspartialproof ↗
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually wantpartialproof ↗
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSLpartialproof ↗
Claims outside our story set (2)
Real capability claims found in Hatchet’s own materials, but no story in this arena’s taxonomy covers them yet — that’s feedback on the taxonomy, not a mark against the product.
“Evaluate and debug CEL expressions used in event filters and concurrency keys”
source ↗“Enterprise-grade security, compliance, and SSO support”
source ↗
Business model
Cloud: first 100K runs free, then $10/1M task runs; Team $500/mo + usage (10 users, 500 RPS); Scale $1,000/mo + usage (HIPAA, audit logs); Enterprise custom (BYOC, SSO). Self-host free (MIT).
pricing ↗Score trend
How this product’s scores have moved as evidence and verdicts are re-derived — a point per change, not per day.
Try Experimental
Run it in the microterminal →Recorded agent sessions — and a live MCP handshake where the vendor ships one.
Flag
⚑ Flag a verdictThink a verdict is wrong? Opens a prefilled GitHub issue — or use the ⚑ next to any verdict above.
For agents
Agent surface uptime llms.txt up (tracking since Sep 11 '26)