Restate vs Hatchet

Agent loops

1. agent builderI run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run

   weight 3 · round to Restate
   Restate✓fullcommunity9/10

   Restate's docs extensively document durable execution for agent loops: ctx.run checkpoints LLM/tool calls, automatic retries with exponential backoff, crash recovery, durable timers, human-in-the-loop, and dedicated AI-agent patterns (sequential, parallel, orchestrator, rollback/compensation) explicitly built for agentic workflows. Independent HN commentary corroborates real-world usage of durable execution, though not agent-loop-specific. missing for 10: independent/hands-on evidence specifically validating agent-loop crash recovery in production (community evidence is about general durable execution, not LLM agent loops specifically).

   • [claimed-docs] “Automatically retry transient errors like rate limits and network failures. Persist steps (LLM calls, tools) and recover previous progress a…”
   • [claimed-docs] “Build AI agents that survive crashes and recover automatically. Every LLM call, tool execution, and routing decision is durably persisted.”
   • [claimed-docs] “Use `ctx.run` to safely wrap any non-deterministic operation, like HTTP calls or database responses, and have Restate store its result in th…”
   • [claimed-docs] “By default, Restate does infinite retries with an exponential backoff strategy.”
   • [claimed-docs] “Agents that pause for human approval and resume when it arrives, even across restarts and infrastructure changes.”
   • [claimed-docs] “Chain agentic and traditional steps in sequence. Each step is recorded for automatic recovery.”
   • [claimed-docs] “Have an agent generate output, evaluate it with a second LLM call, and loop until quality meets your criteria. Each iteration is checkpointe…”
   • [claimed-docs] “An orchestrator agent dynamically plans tasks and dispatches them to worker agents. Plans and results are durably persisted.”
   • [claimed-docs] “Guaranteed compensation: If the main workflow fails, compensation handlers are reliably executed”
   • [community] “the restate server does handle the durable execution journal / orchestration, while the user code runs in a separate process, we don't host …”

   proof ↗⚑ flag

   Hatchet✓fullclaimed7/10

   Hatchet is explicitly positioned as an orchestration engine for AI agents and durable workflows, with first-party docs on retry policies, durability, concurrency, cron/scheduled runs, and dedicated cookbooks showing Claude Agent SDK / OpenAI Agents SDK integration and a support-agent workflow example, matching the checkpointed/retried step model for agent loops. Missing for 10: independent/hands-on evidence of crash-mid-run recovery specifically for LLM tool-call loops, and more detail on how model/tool call state is checkpointed rather than just task-level retries.

   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [claimed-docs] “Retry Policies”
   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [claimed-docs] “Hatchet Agent Tools”
   • [claimed-docs] “Support Agent”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”
   • [claimed-docs] “Concurrency”

   proof ↗⚑ flag

Ai integrations

1. agent builderFirst-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code

   weight 2 · round to Restate
   Restate~partialclaimed7/10

   Restate documents explicit first-party integrations for AI stacks: the Vercel AI SDK ("excellent fit for Restate integration"), the OpenAI Agents SDK ("fault-tolerant agent execution with automatic retries and durable state"), and observability integration with Langfuse for tracing LLM calls/tool executions, plus a library of durable agent patterns (multi-agent, human-in-the-loop, tools-as-services) that wrap durability around agent workflows without extra glue code. However, this is limited to a small named set of frameworks/providers (no broad list of model providers or other popular agent frameworks like LangChain/LlamaIndex/CrewAI), and all evidence is vendor docs with no independent/hands-on confirmation of how seamless these specific SDK integrations are in practice. Missing for 10: broader roster of first-party model-provider/framework integrations, independent hands-on reports validating these SDK integrations work glue-code-free.

   • [claimed-docs] “The Vercel AI SDK is an excellent fit for Restate integration.”
   • [claimed-docs] “Integrate OpenAI Agents SDK with Restate for fault-tolerant agent execution with automatic retries and durable state.”
   • [claimed-docs] “Trace and monitor your Restate AI agents with Langfuse. Get full visibility into LLM calls, tool executions, and workflow steps.”
   • [claimed-docs] “Route tasks between specialized agents with durable decisions. Coordinate agents within the same process using handoffs and tools.”
   • [claimed-docs] “Deploy complex tool logic as separate durable services. Scale tools independently, use any language, and get end-to-end durability.”

   proof ↗⚑ flag

   Hatchet~partialclaimed6/10

   Hatchet documents first-party cookbooks/integrations for the Claude Agent SDK and OpenAI Agents SDK (exposing Hatchet workflows/tasks as durable tools these frameworks can invoke) plus an MCP-based agent-tools pattern and a support-agent cookbook, directly supporting durability for agent steps without custom glue code for those specific frameworks. However, coverage is limited to two named agent SDKs and MCP — there's no evidence of broader first-party wrappers for other AI SDKs (e.g., LangChain, LlamaIndex) or direct model-provider clients (OpenAI/Anthropic APIs) beyond the agent-SDK cookbooks. Missing for 10: integrations/cookbooks for additional AI SDKs and model providers, and independent confirmation of ease-of-use/durability in production for these integrations.

   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [claimed-docs] “Hatchet Agent Tools”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”
   • [claimed-docs] “Support Agent”

   proof ↗⚑ flag

Streaming

1. ai-native userI stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes

   weight 2 · round drawn
   Restate—none0/10

   The evidence pack covers durable execution, retries, state, timers, and human-approval signals, but nothing describes streaming live step updates or model tokens from a running workflow to a frontend (e.g., SSE/WebSocket support or streaming handler responses). Missing for 10: any documentation of streaming outputs, live progress push to clients, or token-by-token delivery mechanisms.

   ⚑ flag

   Hatchet—none0/10

   Hatchet's evidence covers real-time observability via its TUI/dashboard and general monitoring/logging, but nothing describes a mechanism for streaming step updates or model tokens into a consumer's own frontend as a workflow executes (no SSE/websocket API, event-stream docs, or token-streaming cookbook is cited). Given Hatchet explicitly targets AI-agent orchestration, this is a fair axis to expect evidence for, but none is present.

   ⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Restate✓fullprobed9/10

   Restate has a confirmed live llms.txt file (HTTP 200) at docs.restate.dev/llms.txt, plus a dedicated AI-assistant/coding-agent plugin page teaching agents how to build with Restate, satisfying the agent-oriented docs story. missing for 10: no independent/community confirmation that agents actually consume llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.restate.dev/llms.txt # Restate > Restate is the simplest way to build resilient applications. - […”
   • [claimed-docs] “The Restate plugin teaches your coding agent how to build Restate apps: Durable Execution, service types, SDK APIs, common pitfalls, and AI …”
   • [claimed-docs] “The Restate documentation and templates integrate with AI coding agents like Claude Code, Codex, and Cursor so you can get expert help while…”

   proof ↗⚑ flag

   Hatchet✓fullprobed9/10

   A direct probe confirms llms.txt is live at https://docs.hatchet.run/llms.txt returning HTTP 200 with structured documentation content, which an agent could be pointed at directly. Missing for 10: no independent/community corroboration of agents actually consuming it in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.hatchet.run/llms.txt # Hatchet Documentation > Hatchet is a distributed task queue and workflow en…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Restate✓fullclaimed8/10

   Restate is distributed as a single self-contained binary with no external dependencies, deployable to containers, VMs, Kubernetes, serverless, and can be invoked via HTTP/CLI/typed clients without any UI, making it well-suited for headless/CI automation; it also has a documented CLI for introspection and management. missing for 10: no explicit CI pipeline example/tutorial or independent hands-on report confirming headless CI usage.

   • [claimed-docs] “Restate is distributed as a single binary that implements all features required to run a single- or multi-node cluster”
   • [claimed-docs] “Restate is a single self-contained binary. No external dependencies needed.”
   • [claimed-docs] “Restate is distributed as a single binary that implements all features required to run a single- or multi-node cluster, making it easy to ru…”
   • [claimed-docs] “Deploy anywhere: Services run in your infrastructure as containers, serverless functions, VMs, or Kubernetes pods”
   • [claimed-docs] “You can use the CLI to interact with Restate, and manage your services, deployments and invocations.”
   • [claimed-docs] “Use typed clients from external applications to invoke Restate handlers”
   • [claimed-docs] “To call a function over HTTP, send a request to the Restate Server, specifying the service and the function you want to invoke.”

   proof ↗⚑ flag

   Hatchet✓fullclaimed8/10

   Hatchet is a headless orchestration engine by design: workers run as background processes (hatchet worker dev / production worker run), SDKs exist for Python/TypeScript/Go/Ruby for scripted automation, and self-hosting/control-plane docs plus cron/scheduled runs support CI-driven and unattended execution. missing for 10: explicit CI pipeline examples (e.g., GitHub Actions integration) and independent confirmation of headless CI usage beyond docs.

   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected”
   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected.”
   • [claimed-docs] “Running Workers Locally”
   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Restate—none0/10

   Restate documents an MCP server it exposes to teach coding agents (Claude Code, Cursor, etc.) how to build Restate apps, but this is Restate acting as an MCP *server* for external agents, not Restate itself consuming/plugging in external MCP servers to use their tools. No evidence shows Restate agents built on the platform connecting to arbitrary MCP servers as a client.

   • [claimed-docs] “The Restate plugin teaches your coding agent how to build Restate apps: Durable Execution, service types, SDK APIs, common pitfalls, and AI …”
   • [claimed-docs] “The Restate plugin teaches your coding agent how to build Restate apps: Durable Execution, service types, SDK APIs, common pitfalls, and AI …”
   • [claimed-docs] “The Restate documentation and templates integrate with AI coding agents like Claude Code, Codex, and Cursor so you can get expert help while…”
   • [probe] “official MCP server documented at https://docs.restate.dev/develop/ai-assistant”
   • [claimed-docs] “Deploy complex tool logic as separate durable services. Scale tools independently, use any language, and get end-to-end durability.”
   • [claimed-docs] “Integrate OpenAI Agents SDK with Restate for fault-tolerant agent execution with automatic retries and durable state.”

   proof ↗⚑ flag

   Hatchet—none0/10

   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. There is no evidence that Hatchet itself can plug in external MCP servers to consume their tools within its workflows or workers.

   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [claimed-docs] “Hatchet Agent Tools”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Hatchet
   Restate~partialprobed6/10

   Restate documents a 'Restate plugin' that integrates with coding agents (Claude Code, Codex, Cursor) and a probe confirms an official MCP server is documented at the ai-assistant page, so the axis is met. However, the docs mostly describe it as teaching the agent Restate's SDK/patterns rather than exposing full tool/service invocation via MCP, and there's no independent hands-on confirmation of the MCP server's behavior. Missing for 10: detailed MCP tool schema/spec, independent/hands-on validation of the MCP server working end-to-end, and clarity on what tools/capabilities are exposed beyond coding guidance.

   • [claimed-docs] “The Restate plugin teaches your coding agent how to build Restate apps: Durable Execution, service types, SDK APIs, common pitfalls, and AI …”
   • [claimed-docs] “The Restate plugin teaches your coding agent how to build Restate apps: Durable Execution, service types, SDK APIs, common pitfalls, and AI …”
   • [claimed-docs] “The Restate documentation and templates integrate with AI coding agents like Claude Code, Codex, and Cursor so you can get expert help while…”
   • [probe] “official MCP server documented at https://docs.restate.dev/develop/ai-assistant”

   proof ↗⚑ flag

   Hatchet✓fullclaimed7/10

   Hatchet's official docs describe an MCP integration cookbook that exposes Hatchet workflows and standalone tasks as tools invocable by agent frameworks like the Claude Agent SDK and OpenAI Agents SDK, i.e. an official MCP server surface for connecting agents. This is first-party documented but only via a cookbook page rather than a deeply spec'd MCP server reference, and there's no independent/hands-on corroboration. Missing for 10: dedicated MCP server reference docs beyond the cookbook, and independent verification of it working end-to-end.

   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [claimed-docs] “Hatchet Agent Tools”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round drawn
   Restate✓fullprobed8/10

   Restate ships an official CLI used to interact with the server, manage services/deployments/invocations, and inspect state (restate-docs-10, restate-docs-43, restate-probe-4), which is core to its agentic/durable-execution workflows for AI-native users. Missing for 10: no independent/hands-on community corroboration specifically praising the CLI, and no detail on AI-native-specific CLI features (e.g., natural-language or agent-invocation commands).

   • [claimed-docs] “Restate exposes information on invocations and application state via its CLI and Introspection SQL API.”
   • [claimed-docs] “You can use the CLI to interact with Restate, and manage your services, deployments and invocations.”
   • [probe] “official CLI documented at https://docs.restate.dev/installation”

   proof ↗⚑ flag

   Hatchet✓fullprobed8/10

   Hatchet ships an official CLI documented with multiple subcommands (worker dev, tui, quickstart, profile) for local dev, observability, scaffolding, and environment management, confirmed by docs and a dedicated CLI reference page. Missing for 10: independent hands-on community review specifically of the CLI's agentic/AI-native workflows and broader third-party validation beyond docs.

   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected”
   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”
   • [claimed-docs] “the `hatchet quickstart` command generates a worker project from a template to help you get started quickly”
   • [claimed-docs] “Profiles: the `hatchet profile` commands allow you to manage multiple Hatchet instances and tenants with named profiles, making it easy to s…”
   • [probe] “official CLI documented at https://docs.hatchet.run/reference/cli”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round to Restate
   Restate✓fullprobed8/10

   Restate documents multiple ways to drive the product programmatically: HTTP invocation, typed SDK/ingress clients across languages, a CLI, an Admin API, and an Introspection SQL API, plus per-service OpenAPI 3.1 specs for handlers — all first-party documented and usable by an AI-native/agentic consumer. Missing for 10: no global top-level OpenAPI spec was found (probe shows 404s at common paths) and no independent/hands-on corroboration of API completeness beyond vendor docs.

   • [claimed-docs] “To call a function over HTTP, send a request to the Restate Server, specifying the service and the function you want to invoke.”
   • [claimed-docs] “Use typed clients from external applications to invoke Restate handlers”
   • [claimed-docs] “Restate exposes information on invocations and application state via its CLI and Introspection SQL API.”
   • [claimed-docs] “There are three ways to invoke a handler: over HTTP, using typed clients, or through Kafka topics.”
   • [claimed-docs] “The Restate SDK client library lets you invoke Restate handlers from anywhere in your application.”
   • [claimed-docs] “You can use the CLI to interact with Restate, and manage your services, deployments and invocations.”
   • [claimed-docs] “Inspect the status of invocations/services.”
   • [claimed-docs] “Cluster state endpoint”
   • [claimed-docs] “Returns the OpenAPI 3.1 specification for the service, describing all handlers and their request/response schemas.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.restate.dev/openapi.json, https://docs.restate.dev/swagger.json, https://docs.restate.d…”
   • [probe] “official CLI documented at https://docs.restate.dev/installation”

   proof ↗⚑ flag

   Hatchet~partialprobed6/10

   Hatchet documents multi-language SDKs (Python, TypeScript, Go, Ruby) with detailed API surfaces (retry policies, cron, concurrency, rate limits, webhooks, OpenTelemetry, embedded mode) and a CLI, giving AI-native users multiple documented ways to drive the product programmatically, including MCP/agent-tool integrations. However, a probe for a standard public REST/OpenAPI spec returned 404s across all expected paths, suggesting no first-class REST API doc is discoverable, only SDK/CLI-level docs. Missing for 10: a discoverable OpenAPI/REST API reference, and independent hands-on confirmation that the documented API surface is complete/accurate.

   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [claimed-docs] “Retry Policies”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Concurrency”
   • [claimed-docs] “Rate Limits”
   • [claimed-docs] “Webhooks”
   • [claimed-docs] “OpenTelemetry”
   • [claimed-docs] “Embedded Mode”
   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hatchet.run/openapi.json, https://docs.hatchet.run/swagger.json, https://docs.hatchet.r…”
   • [probe] “official CLI documented at https://docs.hatchet.run/reference/cli”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Restate—none0/10

   Restate's security docs describe request identity verification and restricting network access to services (proxying), but there is no evidence of issuing scoped/least-privilege API credentials or tokens specifically for AI agents (e.g., per-agent API keys, OAuth-style scopes, or permission policies).

   • [claimed-docs] “Restate has a native request identity feature which can be used in the SDK to cryptographically verify that requests have come from a partic…”
   • [claimed-docs] “Only Restate needs to be able to make requests to your services. The Restate Server will proxy all requests for these services.”
   • [claimed-docs] “Restrict access to Restate services”

   proof ↗⚑ flag

   Hatchet—none0/10

   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.

   ⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Restate✓fullcommunity8/10

   Restate ships official SDKs for TypeScript, Java/Kotlin, Python, Go, and Rust (restate-gh-2), with extensive first-party documentation on building AI agents, durable agent patterns, and direct integrations with AI-specific SDKs like OpenAI Agents SDK and Vercel AI SDK (restate-docs-88, restate-docs-89, restate-docs-15-17). Community evidence corroborates real-world SDK usage (restate-comm-1, restate-comm-3) though feedback is general rather than AI-specific; missing for 10: hands-on independent review of the AI-agent-specific SDK ergonomics and broader third-party corroboration beyond a single HN thread.

   • [github] “Restate supports the following SDKs: * [Typescript] * [Java and Kotlin] * [Python] * [Go] * [Rust]”
   • [claimed-docs] “The Vercel AI SDK is an excellent fit for Restate integration.”
   • [claimed-docs] “Integrate OpenAI Agents SDK with Restate for fault-tolerant agent execution with automatic retries and durable state.”
   • [claimed-docs] “Build AI agents that survive crashes and recover automatically. Every LLM call, tool execution, and routing decision is durably persisted.”
   • [claimed-docs] “Automatically retry transient errors like rate limits and network failures. Persist steps (LLM calls, tools) and recover previous progress a…”
   • [community] “The cloud setup was super fast! I used it for an existing app + restate TS sdk, really took a few steps to get things up and running! Lookin…”
   • [community] “Being fairly familiar with Temporal, I definitely appreciate your cleaner architectural choices. Add a Go SDK and I'll definitely give this …”

   proof ↗⚑ flag

   Hatchet✓fullcommunity8/10

   Hatchet ships official SDKs for Python, TypeScript, Go, and Ruby, confirmed both in docs and independently by community members who verified multi-language SDK support, and these SDKs are the basis for building AI agent workflows (including cookbooks integrating Claude Agent SDK and OpenAI Agents SDK). missing for 10: no independent quality/maturity comparison across SDKs and a community complaint that SDK/doc specs are sometimes incomplete or have broken links.

   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [community] “This looks very cool! I see a lot of Python in the docs; is it usable in other languages? [confirmed SDKs exist for Python, Typescript and G…”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”
   • [community] “Why not fix all the broken doc links and make sure you have the full sdk spec down first, ready to go? ... this came off as extremely unprof…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Restate
   Restate✓fullclaimed7/10

   Restate explicitly documents durable webhooks: 'Any handler can be a durable webhook endpoint. No need to do anything special or extra!' with automatic exactly-once processing and idempotency-key deduplication of incoming events, plus broader signal/event handling for agent coordination and human approvals. This directly satisfies subscribing to events via webhooks for AI-native agentic workflows. Missing for 10: independent/hands-on corroboration of webhook subscription setup, and detail on webhook-specific security/verification beyond generic request-identity docs.

   • [claimed-docs] “Restate persists all incoming events, and ensures that they are processed exactly once, across failures and restarts... Let Restate deduplic…”
   • [claimed-docs] “Any handler can be a durable webhook endpoint. No need to do anything special or extra!”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are processed exactly once, across failures and restarts.”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are **processed exactly once**, across failures and restarts.”
   • [claimed-docs] “Coordinate long-running processes, human approvals, listen to webhooks and other signals.”
   • [claimed-docs] “Restate provides three durable coordination primitives for this: ... Communication between ongoing invocations, agent steering, and human ap…”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   There is a dedicated docs page titled "Webhooks" indicating Hatchet supports webhook functionality, but no detail is given on whether this covers subscribing to Hatchet's own workflow/task events (vs. using webhooks as workflow triggers), and no independent confirmation of this specific direction. missing for 10: description of webhook event subscription semantics, example payloads/config, and community/hands-on confirmation of outbound event webhooks.

   • [claimed-docs] “Webhooks”

   proof ↗⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Hatchet
   Restate✓fullclaimed7/10

   Restate's docs explicitly support durable background automation: durable timers/sleep/schedule, waiting for external events and webhooks, long-running process coordination, and human approvals, plus dedicated AI-agent durability guarantees (persisted LLM/tool calls, automatic recovery) that let agents run autonomously without babysitting. Missing for 10: independent/hands-on corroboration specifically of long-running autonomous background automations (community evidence is about general architecture, not this specific capability).

   • [claimed-docs] “Sleep, schedule, and wait for external events with durable timers.”
   • [claimed-docs] “Coordinate long-running processes, human approvals, listen to webhooks and other signals.”
   • [claimed-docs] “Automatically retry transient errors like rate limits and network failures. Persist steps (LLM calls, tools) and recover previous progress a…”
   • [claimed-docs] “A few lines turn your agent into a durable agent.”
   • [claimed-docs] “Build AI agents that survive crashes and recover automatically. Every LLM call, tool execution, and routing decision is durably persisted.”
   • [claimed-docs] “Restate provides three durable coordination primitives for this: ... Communication between ongoing invocations, agent steering, and human ap…”
   • [claimed-docs] “If your handler runs on function-as-a-service platforms like AWS Lambda, Restate suspends the handler while it is sleeping, to free up resou…”

   proof ↗⚑ flag

   Hatchet✓fullcommunity8/10

   Hatchet is fundamentally a background task/workflow orchestration engine with cron triggers, scheduled runs, durable retries, concurrency control, and explicit support for orchestrating AI agents autonomously (docs-16, docs-26, docs-27, docs-25, docs-11, gh-2, gh-3), and community evidence confirms real production use as a background job/workflow runner replacing Celery. Cookbooks show integration with Claude/OpenAI Agents SDKs for agentic workflows (hatchet-docs-34/36/37). missing for 10: no independent hands-on account of a fully autonomous multi-day agent running unattended, and some community reports note scaling/reliability caveats under heavy load (hatchet-comm-11) rather than confirming flawless long-running autonomy.

   • [claimed-docs] “A single platform for orchestrating AI agents, scheduling background tasks, and running mission-critical workflows”
   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Retry Policies”
   • [claimed-docs] “Hatchet Agent Tools”
   • [claimed-docs] “Claude Agent SDK”
   • [claimed-docs] “OpenAI Agents SDK”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [github] “An orchestration engine for background tasks, AI agents, and durable workflows”
   • [community] “Looks pretty great! My biggest issue with Celery has been that the observability is pretty bad. Even if you use Celery Flower, it still just…”
   • [community] “Great job so far- The flow-based UI with triggers is killer! AFAIK, this surpasses what Celery includes.”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   Restate—none0/10

   Restate is developer infrastructure (durable execution server, CLI, SDKs, typed HTTP APIs) with no evidence of a natural-language command interface for operating the product itself; the MCP server and CLI are for programmatic/coding-agent integration, not NL control of Restate's own operations.

   ⚑ flag

   Hatchet—none0/10

   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). The MCP/agent-tools integration is about agents consuming Hatchet, not about a human issuing NL commands to Hatchet.

   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”
   • [claimed-docs] “expose Hatchet workflows and standalone tasks as tools that frameworks like the Claude Agent SDK and OpenAI Agents SDK can invoke”
   • [claimed-docs] “Hatchet Agent Tools”
   • [probe] “official CLI documented at https://docs.hatchet.run/reference/cli”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Restate—none0/10

   Evidence shows Restate can generate an OpenAPI 3.1 spec per service (restate-docs-76) and has admin API docs, but there is no evidence of an interactive, runnable API reference/playground on the docs site — in fact the probe explicitly found openapi.json/swagger.json endpoints returning 404 (restate-probe-2). No mention of a Swagger UI, try-it-now console, or embedded runnable examples anywhere in the pack.

   • [claimed-docs] “Returns the OpenAPI 3.1 specification for the service, describing all handlers and their request/response schemas.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.restate.dev/openapi.json, https://docs.restate.dev/swagger.json, https://docs.restate.d…”

   proof ↗⚑ flag

   Hatchet—none0/10

   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.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hatchet.run/openapi.json, https://docs.hatchet.run/swagger.json, https://docs.hatchet.r…”
   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.hatchet.run/llms.txt # Hatchet Documentation > Hatchet is a distributed task queue and workflow en…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Restate—none0/10

   Restate exposes HTTP invocation and introspection APIs, but a direct probe for an OpenAPI/Swagger spec at all standard locations returned 404s, and no documentation mentions a downloadable machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.restate.dev/openapi.json, https://docs.restate.dev/swagger.json, https://docs.restate.d…”
   • [claimed-docs] “To call a function over HTTP, send a request to the Restate Server, specifying the service and the function you want to invoke.”
   • [claimed-docs] “Restate exposes information on invocations and application state via its CLI and Introspection SQL API.”

   proof ↗⚑ flag

   Hatchet—none0/10

   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.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hatchet.run/openapi.json, https://docs.hatchet.run/swagger.json, https://docs.hatchet.r…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.hatchet.run/llms.txt # Hatchet Documentation > Hatchet is a distributed task queue and workflow en…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Restate
   Restate~partialclaimed6/10

   Restate's TypeScript SDK ships a testing library that uses Testcontainers to spin up an isolated Restate Server in Docker for testing handlers, and docs describe local dev environment setup — both let a user test app logic without touching a production Restate deployment. However, this is generic developer testing tooling, not something framed or documented specifically as an AI-agent 'sandbox vs production' workflow, and there's no mention of test data isolation, staging environments, or independent corroboration of the testing experience. Missing for 10: explicit sandbox/staging environment guidance distinct from local Docker testing, AI-agent-specific sandbox framing, and community/hands-on validation of the testing workflow.

   • [claimed-docs] “This uses [Testcontainers](https://testcontainers.com/) to run a Restate Server in a Docker container and let you test your Restate handlers…”
   • [claimed-docs] “The Typescript SDK has a companion library which makes it easy to test against a Restate container”
   • [claimed-docs] “Utilities to test your handler logic.”
   • [claimed-docs] “Learn how to set up your local Restate development environment.”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet supports local development via `hatchet worker dev` for local execution and `hatchet profile` for switching between separate named environments/tenants, which could be used to isolate a sandbox from production, but there is no explicit documentation of a dedicated sandbox/staging environment or test-data isolation feature. missing for 10: explicit sandbox/test-environment documentation, isolation guarantees between environments, and any hands-on confirmation that switching profiles avoids touching production data.

   • [claimed-docs] “Profiles: the `hatchet profile` commands allow you to manage multiple Hatchet instances and tenants with named profiles, making it easy to s…”
   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected.”
   • [claimed-docs] “Profiles: the `hatchet profile` commands allow you to manage multiple Hatchet instances and tenants with named profiles, making it easy to s…”
   • [claimed-docs] “Running Workers Locally”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Restate
   Restate~partialclaimed3/10

   Restate documents versioning support for user services (immutable deployments, requests pinned to a single code version) via restate-docs-24/41, and SDK changelogs show incremental API evolution (restate-docs-44,73,74), but there is no documented deprecation policy for Restate's own APIs/SDKs that an AI-native consumer could rely on. missing for 10: an explicit deprecation policy or versioning guarantees for Restate's public APIs/SDKs, timeline for API sunset, and independent confirmation of long-term API stability.

   • [claimed-docs] “Restate then makes sure that requests start and end on the same version, by sending any retry attempts always to the same endpoint.”
   • [claimed-docs] “Restate helps via the concept of immutable deployments. When you deploy a version of your code, you giv”
   • [claimed-docs] “The new restate.iface lets you declare service interfaces, including input/output serdes, and use them to both implement the service and cal…”
   • [claimed-docs] “The new `restate.iface` lets you declare service interfaces, including input/output serdes, and use them to both **implement** the service a…”
   • [claimed-docs] “The SDK now generates a typed `<Type>IngressClient` for every impl-block service, virtual object, and workflow.”

   proof ↗⚑ flag

   Hatchet—none0/10

   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.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hatchet.run/openapi.json, https://docs.hatchet.run/swagger.json, https://docs.hatchet.r…”
   • [claimed-docs] “Retry Policies”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Hatchet
   Restate—none0/10

   Restate is a durable-execution/workflow engine; while it supports concurrency limits and orchestrating many invocations (restate-docs-4, restate-docs-11), there is no evidence of a bulk/batch operation API or UI for acting on many items at once as a single operation.

   ⚑ flag

   Hatchet~partialclaimed5/10

   Hatchet is a workflow/task orchestration engine that supports bulk-style operations via concurrency rules across many workflow runs, cron-triggered batch scheduling, and per-key concurrency limits (e.g., letting many tasks/workflows run concurrently up to a limit), which indirectly supports bulk processing of many items. However, there is no explicit evidence of a bulk API/CLI operation (e.g., bulk-cancel, bulk-retry, batch-trigger-many-runs-at-once) designed for an AI-native user to invoke as a single bulk action. missing for 10: explicit bulk-operation API/CLI (batch trigger, bulk cancel/retry across many runs), documentation or examples showing an AI agent invoking such bulk operations, and independent confirmation of bulk operation reliability at scale.

   • [claimed-docs] “set concurrency limits on a per-key basis using a CEL expression. For example, let premium-tier users run 10 workflows simultaneously while …”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Hatchet
   Restate~partialclaimed6/10

   Restate supports event-triggered automation via durable webhooks, external events, timers/cron, and workflow patterns (human-in-the-loop, orchestrator, multi-agent) that react to signals and trigger durable actions, but this is a developer-defined-code framework rather than a declarative 'rules engine' for non-developers to define trigger-action rules. missing for 10: a declarative rule-definition UI/DSL for non-coders, independent hands-on evidence of rule-based automation working end-to-end, and explicit 'if-this-then-that' style rule authoring rather than SDK code.

   • [claimed-docs] “Sleep, schedule, and wait for external events with durable timers.”
   • [claimed-docs] “Coordinate long-running processes, human approvals, listen to webhooks and other signals.”
   • [claimed-docs] “Restate provides three durable coordination primitives for this: ... Communication between ongoing invocations, agent steering, and human ap…”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are processed exactly once, across failures and restarts... Let Restate deduplic…”
   • [claimed-docs] “Any handler can be a durable webhook endpoint. No need to do anything special or extra!”
   • [claimed-docs] “Agents that pause for human approval and resume when it arrives, even across restarts and infrastructure changes.”
   • [claimed-docs] “Restate provides durable, fault-tolerant timers that allow you to: Sleep... Send delayed messages... Set timeouts... Implement patterns like…”
   • [claimed-docs] “Build async notification systems for your agents with just a few lines of code.”

   proof ↗⚑ flag

   Hatchet✓fullclaimed7/10

   Hatchet's docs describe core event-driven automation: workflows can be triggered on schedules (cron, scheduled runs), via webhooks, and filtered/gated with CEL-based event filters and concurrency rules, all managed by a control plane that automatically dispatches tasks to workers on these triggers. This directly matches 'define rules that trigger actions automatically on events' for an orchestration/automation platform. Missing for 10: explicit first-party documentation of arbitrary custom event triggers (e.g., pub/sub event names beyond cron/webhook) and independent hands-on confirmation that event-triggered rules work reliably in production.

   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Webhooks”
   • [claimed-docs] “Evaluate and debug CEL expressions used in event filters and concurrency keys”
   • [claimed-docs] “Concurrency”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Hatchet
   Restate~partialclaimed5/10

   Restate provides durable timers to sleep/schedule/wait for events (restate-docs-5, restate-docs-21), which can be composed into recurring workflows (e.g., a handler that re-schedules itself), and supports human/webhook triggers (restate-docs-6, restate-docs-20). However, there's no explicit first-class 'recurring job' or cron-style scheduler documented — recurrence would require custom loop/timer logic rather than a built-in feature. Missing for 10: explicit cron/interval scheduling API, dashboard/UI for managing recurring jobs, and independent evidence of recurring-job use cases in production.

   • [claimed-docs] “Sleep, schedule, and wait for external events with durable timers.”
   • [claimed-docs] “If your handler runs on function-as-a-service platforms like AWS Lambda, Restate suspends the handler while it is sleeping, to free up resou…”
   • [claimed-docs] “Coordinate long-running processes, human approvals, listen to webhooks and other signals.”
   • [claimed-docs] “Restate provides three durable coordination primitives for this: ... Communication between ongoing invocations, agent steering, and human ap…”

   proof ↗⚑ flag

   Hatchet✓fullclaimed8/10

   Hatchet explicitly documents Cron Runs and Scheduled Runs as first-class workflow trigger types, alongside concurrency/rate-limit controls, giving clear support for scheduling recurring jobs/workflows (hatchet-docs-16, hatchet-docs-26, hatchet-docs-27). This is corroborated by the general orchestration platform framing in GitHub docs and self-hosting control plane description. Missing for 10: independent/hands-on community confirmation specifically of cron/scheduled run reliability at scale, and more detail on failure/edge-case handling for recurring jobs.

   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Restate
   Restate~partialclaimed6/10

   Restate documents immutable/versioned deployments that pin invocations to a single code version (restate-docs-24, restate-docs-41), an observability/control surface to inspect invocation journals and cancel/kill stuck agents (restate-docs-64, restate-docs-65), and explicit compensation/rollback patterns to undo partial agent work on failure (restate-docs-59, restate-docs-85). This covers the core of version/inspect/rollback for automations at the infrastructure level, but it's developer-facing (CLI/API/journal inspection) rather than a reviewable, user-facing change-history or diff UI. Missing for 10: a UI/dashboard for comparing or reviewing automation versions side-by-side, self-service 'rollback to previous deployment' action, and any independent/community corroboration that versioning or rollback works as documented in practice.

   • [claimed-docs] “Restate then makes sure that requests start and end on the same version, by sending any retry attempts always to the same endpoint.”
   • [claimed-docs] “Restate helps via the concept of immutable deployments. When you deploy a version of your code, you giv”
   • [claimed-docs] “Guaranteed compensation: If the main workflow fails, compensation handlers are reliably executed”
   • [claimed-docs] “Implement compensation and rollback mechanisms for agents that need to undo partial work when failures occur.”
   • [claimed-docs] “Full visibility into agent execution. Inspect journals, export traces, and cancel or kill stuck agents.”
   • [claimed-docs] “Invocations list: See all running, suspended, and completed agent invocations”

   proof ↗⚑ flag

   Hatchet—none0/10

   No evidence in the pack describes versioning, review, or rollback of workflows/automations — the docs cover CLI tools, concurrency, retries, cron/scheduled runs, and self-hosting, but nothing about workflow version history, diff/review workflows, or rollback to a prior version. This is a fair axis for a workflow orchestration platform, so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag

Local dev

1. backend developerOne command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps

   weight 2 · round to Restate
   Restate~partialclaimed5/10

   Restate ships as a single self-contained binary with no external dependencies that can run a local dev environment (restate-docs-26, restate-docs-13, restate-docs-75), and it provides testing utilities/companion libraries (Testcontainers-based) to test handler logic against a real Restate server (restate-docs-23, restate-docs-31, restate-docs-79). However, the evidence never mentions time-skipping/simulated clocks for durable timers in tests, nor explicit mocking of steps within unit tests — testing appears to rely on spinning up a real container rather than in-memory time-travel mocks. Missing for 10: explicit time-skipping/clock-mocking test utility, explicit mocked-step/unit-test isolation feature, and an explicit single 'one command' CLI invocation for the whole engine.

   • [claimed-docs] “Restate is a single self-contained binary. No external dependencies needed.”
   • [claimed-docs] “Restate is distributed as a single binary that implements all features required to run a single- or multi-node cluster”
   • [claimed-docs] “Learn how to set up your local Restate development environment.”
   • [claimed-docs] “This uses [Testcontainers](https://testcontainers.com/) to run a Restate Server in a Docker container and let you test your Restate handlers…”
   • [claimed-docs] “The Typescript SDK has a companion library which makes it easy to test against a Restate container”
   • [claimed-docs] “Utilities to test your handler logic.”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   Docs show `hatchet worker dev` for running a worker locally with auto-reload and mention an 'Embedded Mode' page, which partially supports a lightweight local run, but there is no evidence of a single command spinning up the full engine (control plane) locally, nor any documented unit-testing utilities, time-skipping, or step mocking for workflows. Missing for 10: dedicated single-command full-engine local runner, workflow unit-testing framework, time-skipping/mocked-step utilities, and any independent confirmation of these testing features.

   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected”
   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected.”
   • [claimed-docs] “Embedded Mode”
   • [claimed-docs] “Running Workers Locally”

   proof ↗⚑ flag

Approvals

1. backend developerA workflow pauses for human approval or input for hours or days and resumes the moment the response arrives

   weight 3 · round to Restate
   Restate✓fullclaimed8/10

   Restate docs explicitly describe durable coordination primitives for human approvals, external events, and durable timers/sleep that can span hours or days, with suspension freeing resources on FaaS while waiting, and automatic resumption when signals arrive (restate-docs-6, restate-docs-20, restate-docs-5, restate-docs-21). This directly matches pausing for human approval/input and resuming on response. Missing for 10: no independent/hands-on case study specifically demonstrating a multi-day human-approval pause in production, and no detail on UI/notification mechanisms for prompting the human.

   • [claimed-docs] “Coordinate long-running processes, human approvals, listen to webhooks and other signals.”
   • [claimed-docs] “Restate provides three durable coordination primitives for this: ... Communication between ongoing invocations, agent steering, and human ap…”
   • [claimed-docs] “Sleep, schedule, and wait for external events with durable timers.”
   • [claimed-docs] “If your handler runs on function-as-a-service platforms like AWS Lambda, Restate suspends the handler while it is sleeping, to free up resou…”
   • [claimed-docs] “Use `ctx.run` to safely wrap any non-deterministic operation, like HTTP calls or database responses, and have Restate store its result in th…”

   proof ↗⚑ flag

   Hatchet—none0/10

   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.

   ⚑ flag

Signals

1. backend developerI send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow

   weight 2 · round to Restate
   Restate✓fullclaimed8/10

   Restate provides durable coordination primitives explicitly for external signals/events/human approvals (restate-docs-6, restate-docs-20, restate-docs-48), supports invoking handlers via HTTP, typed clients, or Kafka from outside services (restate-docs-8, restate-docs-9, restate-docs-28, restate-docs-39), and documents durable webhook endpoints with exactly-once processing for external event delivery into running workflows (restate-docs-37, restate-docs-38, restate-docs-81). This directly covers sending signals/events/messages from APIs, webhooks, or other workflows into a running workflow. missing for 10: independent/hands-on confirmation of this specific external-signal delivery pattern (community evidence only covers general SDK setup, not event/webhook injection into running workflows).

   • [claimed-docs] “Coordinate long-running processes, human approvals, listen to webhooks and other signals.”
   • [claimed-docs] “Restate provides three durable coordination primitives for this: ... Communication between ongoing invocations, agent steering, and human ap…”
   • [claimed-docs] “Agents that pause for human approval and resume when it arrives, even across restarts and infrastructure changes.”
   • [claimed-docs] “To call a function over HTTP, send a request to the Restate Server, specifying the service and the function you want to invoke.”
   • [claimed-docs] “Use typed clients from external applications to invoke Restate handlers”
   • [claimed-docs] “There are three ways to invoke a handler: over HTTP, using typed clients, or through Kafka topics.”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are processed exactly once, across failures and restarts... Let Restate deduplic…”
   • [claimed-docs] “Any handler can be a durable webhook endpoint. No need to do anything special or extra!”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are **processed exactly once**, across failures and restarts.”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   Docs reference 'Webhooks' and CEL-based 'event filters' for triggering workflows externally, implying some external event-to-workflow capability, but there is no concrete documentation of sending a signal/event into a specific *already-running* workflow instance (e.g., a signal API) as opposed to triggering new runs. Missing for 10: explicit signal-to-running-workflow API docs, examples of external systems pushing data into an in-flight workflow, and independent confirmation this works in practice.

   • [claimed-docs] “Webhooks”
   • [claimed-docs] “Evaluate and debug CEL expressions used in event filters and concurrency keys”

   proof ↗⚑ flag

Metrics

1. platform engineerFailure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave

   weight 1 · round drawn
   Restate~partialclaimed4/10

   Restate exposes invocation status, journals, and traces via CLI, Introspection SQL API, and admin API, and docs mention 'export traces' for observability-control, which supports building metrics/alerts pipelines, but there is no concrete evidence of native export to standard observability stacks (Prometheus/OpenTelemetry metrics, Grafana dashboards) or built-in alerting on failure rates/latencies/queue depths. missing for 10: documented Prometheus/OTel metrics export, native alerting integration, queue-depth/latency dashboards, and independent confirmation these integrations work in practice.

   • [claimed-docs] “Restate exposes information on invocations and application state via its CLI and Introspection SQL API.”
   • [claimed-docs] “Full visibility into agent execution. Inspect journals, export traces, and cancel or kill stuck agents.”
   • [claimed-docs] “Invocations list: See all running, suspended, and completed agent invocations”
   • [claimed-docs] “Inspect the status of invocations/services.”
   • [claimed-docs] “Cluster state endpoint”
   • [claimed-docs] “Trace and monitor your Restate AI agents with Langfuse. Get full visibility into LLM calls, tool executions, and workflow steps.”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet documents an OpenTelemetry integration page and its GitHub README claims 'real-time monitoring, alerting, and logging' as part of the platform, plus a TUI for real-time observability into tasks/workflows/workers. However, there is no concrete detail on which metrics (failure rates, latencies, queue depths) are exported, no evidence of alert rule configuration, and no independent confirmation that alerting actually fires as described. Missing for 10: detailed OpenTelemetry metrics/export documentation, explicit failure-rate/latency/queue-depth metric definitions, documented alerting configuration/integration with observability stacks (Grafana/Datadog/PagerDuty), and hands-on or community confirmation that alerts work in practice.

   • [claimed-docs] “OpenTelemetry”
   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”

   proof ↗⚑ flag

Replay

1. platform engineerI replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover

   weight 2 · round to Restate
   Restate~partialclaimed5/10

   Restate automatically persists completed steps and resumes execution from the point of failure (restate-docs-1, restate-docs-15, restate-docs-18), and introspection tools (CLI/SQL API) expose invocation history (restate-docs-10). However, there is no documented explicit 'replay from a specific step' or manual rerun/time-travel debugging feature — recovery is automatic on retry/crash rather than an operator-triggered replay from an arbitrary chosen step. missing for 10: explicit support for manually triggering a replay/rerun of a completed or failed workflow from a chosen step, UI/CLI commands for selective replay, and independent/hands-on evidence of this debugging workflow in practice.

   • [claimed-docs] “Code automatically stores completed steps and resumes from where it left off when recovering from failures.”
   • [claimed-docs] “Automatically retry transient errors like rate limits and network failures. Persist steps (LLM calls, tools) and recover previous progress a…”
   • [claimed-docs] “Use `ctx.run` to safely wrap any non-deterministic operation, like HTTP calls or database responses, and have Restate store its result in th…”
   • [claimed-docs] “Restate exposes information on invocations and application state via its CLI and Introspection SQL API.”

   proof ↗⚑ flag

   Hatchet—none0/10

   The evidence pack covers retries, concurrency, scheduling, and TUI-based observability, but nothing describes replaying or rerunning a failed workflow from recorded history, let alone from a specific step. Retry Policies (hatchet-docs-25) is only a title with no detail confirming step-level replay/rerun-from-history semantics.

   ⚑ flag

Run visibility

1. platform engineerEvery run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter

   weight 3 · round drawn
   Restate~partialcommunity5/10

   Restate documents strong introspection: an invocations list showing running/suspended/completed invocations, journal inspection, trace export, and a SQL Introspection API plus CLI for querying invocation/service state (restate-docs-64,65,66,10,43), which supports searchable, filterable visibility into steps, retries, and errors. However, a hands-on community comment explicitly notes Restate lacks the diagram/visualization of execution history that competitors like Step Functions provide (restate-comm-4), and no evidence describes a polished, purpose-built dashboard UI (only CLI/SQL API), so the 'dashboard' framing of the story is only partly substantiated. Missing for 10: explicit dashboard UI screenshots/documentation, confirmation of per-step input/output display in a UI, and independent corroboration that search/filter works well in practice.

   • [claimed-docs] “Full visibility into agent execution. Inspect journals, export traces, and cancel or kill stuck agents.”
   • [claimed-docs] “Invocations list: See all running, suspended, and completed agent invocations”
   • [claimed-docs] “Inspect the status of invocations/services.”
   • [claimed-docs] “Restate exposes information on invocations and application state via its CLI and Introspection SQL API.”
   • [claimed-docs] “You can use the CLI to interact with Restate, and manage your services, deployments and invocations.”
   • [community] “One thing that Step Functions probably has over Restate is the diagram visualization of your state machine definition and execution history.…”

   proof ↗⚑ flag

   Hatchet~partialcommunity5/10

   Hatchet's docs and GitHub description claim 'real-time monitoring, alerting, and logging' and a TUI/dashboard for observability into tasks and workflows, and community feedback confirms a 'flow-based UI' seen as an improvement over Celery's observability. However, no evidence explicitly describes a searchable/filterable dashboard showing per-step inputs, outputs, retries, and errors in a timeline view — retry policies and OpenTelemetry integration are documented separately but not tied to a unified searchable timeline UI. Missing for 10: explicit documentation or screenshots of a step-level timeline view, confirmation of search/filter capability in the dashboard, and independent hands-on verification of this specific UI feature.

   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”
   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”
   • [claimed-docs] “Retry Policies”
   • [claimed-docs] “OpenTelemetry”
   • [community] “Looks pretty great! My biggest issue with Celery has been that the observability is pretty bad. Even if you use Celery Flower, it still just…”
   • [community] “Great job so far- The flow-based UI with triggers is killer! AFAIK, this surpasses what Celery includes.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Restate
   Restate✓fullclaimed7/10

   Restate explicitly states that all information available in its UI (invocation status, application state) is also exposed via the CLI and Introspection SQL API, and all core operations (invoking, managing, deploying) are done via HTTP/typed-client APIs rather than requiring the UI — a strong API-first design consistent with AI-native/programmatic use. Missing for 10: no exhaustive UI-feature-by-feature parity confirmation or independent hands-on report explicitly verifying no UI-only functionality exists.

   • [claimed-docs] “Restate exposes information on invocations and application state via its CLI and Introspection SQL API.”
   • [claimed-docs] “To call a function over HTTP, send a request to the Restate Server, specifying the service and the function you want to invoke.”
   • [claimed-docs] “Use typed clients from external applications to invoke Restate handlers”
   • [claimed-docs] “Restate is distributed as a single binary that implements all features required to run a single- or multi-node cluster”

   proof ↗⚑ flag

   Hatchet~partialprobed5/10

   Hatchet offers SDKs (Python/TS/Go/Ruby) and CLI tools for managing workflows, tasks, cron, concurrency, etc., implying broad API-driven access, but there is no explicit documentation or OpenAPI spec confirming full parity between API/SDK capabilities and the web UI, and the openapi probe returned 404s. missing for 10: a published OpenAPI/API reference confirming API parity, explicit statement or evidence that every UI action (e.g., dashboards, tenant/user management, alerting config) is achievable via API/SDK, and independent confirmation of this parity.

   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.hatchet.run/openapi.json, https://docs.hatchet.run/swagger.json, https://docs.hatchet.r…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Profiles: the `hatchet profile` commands allow you to manage multiple Hatchet instances and tenants with named profiles, making it easy to s…”
   • [community] “This looks very cool! I see a lot of Python in the docs; is it usable in other languages? [confirmed SDKs exist for Python, Typescript and G…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Hatchet
   Restate—none0/10

   Restate documents introspection (CLI, SQL API) and self-hosting/BYOC options, but there is no evidence of an explicit data-export mechanism or open-format export/backup tooling that would let a user extract all their data and migrate away. Community commentary even disputes the 'open source' framing due to the BSL license, further undercutting an openness/exit narrative. Missing for 10: documented bulk data export feature, explicit open-format (e.g. JSON/SQL dump) export tooling, and confirmation that self-hosted state is portable without vendor lock-in.

   • [claimed-docs] “Restate exposes information on invocations and application state via its CLI and Introspection SQL API.”
   • [claimed-docs] “You can use the CLI to interact with Restate, and manage your services, deployments and invocations.”
   • [claimed-docs] “You can use Restate Cloud, run a managed Restate region in your cloud account with Restate BYOC, or operate Restate yourself.”
   • [community] “Looks very interesting, but calling it Open Source is misleading. BSL is not "minimal Amazon defense". It effectively prevents any meaningfu…”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet is open-source and self-hostable, meaning users control their own Postgres-backed control plane and inherently retain access to underlying data (hatchet-docs-8, hatchet-docs-17, hatchet-docs-23), which supports an exit path. However, there is no explicit documented data-export feature, open-format export tooling, or migration/export API mentioned anywhere in the evidence. Missing for 10: explicit data export command/API, documentation on open-format export (e.g. JSON/CSV dumps), and independent confirmation that a full data export is possible beyond raw DB access.

   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the Hatchet Control Plane - the central orchestration system that manages workflows,…”
   • [claimed-docs] “Run Hatchet yourself”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Hatchet
   Restate!disputedcontradicted4/10

   Restate's source is publicly viewable on GitHub (restate-gh-1, restate-gh-2), suggesting readability, but a hands-on community comment explicitly disputes that it qualifies as open license: 'calling it Open Source is misleading. BSL is not minimal Amazon defense. It effectively prevents any meaningful dynamic functionality to be built on top of it without a commercial subscription' (restate-comm-5). This is a concrete, specific contradiction of an open-license claim rather than mere skepticism. Missing for 10: no first-party confirmation of license terms in the evidence pack, no independent legal/OSI-approval analysis, no rebuttal from Restate addressing the BSL concern.

   • [github] “Restate provides a distributed durable version of your everyday building blocks, letting you build a wide range of use cases”
   • [github] “Restate supports the following SDKs: * [Typescript] * [Java and Kotlin] * [Python] * [Go] * [Rust]”
   • [community] “Looks very interesting, but calling it Open Source is misleading. BSL is not "minimal Amazon defense". It effectively prevents any meaningfu…”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   The product's source is publicly hosted on GitHub (hatchet-dev/hatchet), which lets users read the code, but the evidence pack never states or documents an explicit open-source license (e.g., MIT/Apache) for that repository. missing for 10: explicit license text/badge, license file reference, confirmation the full engine (not just SDKs) is open-licensed.

   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [github] “An orchestration engine for background tasks, AI agents, and durable workflows”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Restate✓fullcommunity8/10

   Restate is distributed as a single self-contained binary with no external dependencies, explicitly designed to be run yourself (self-hosted) as an alternative to Restate Cloud/BYOC, deployable on your own infra, containers, VMs, or Kubernetes. Community evidence (restate-comm-9) corroborates that the server/orchestration runs independently of any vendor-hosted service. Missing for 10: independent hands-on report of a full production self-hosted deployment, and clarity on licensing terms (BSL concerns raised in community comments) that could affect what 'self-host' fully entails commercially.

   • [claimed-docs] “Deploy anywhere: Services run in your infrastructure as containers, serverless functions, VMs, or Kubernetes pods”
   • [claimed-docs] “Restate is distributed as a single binary that implements all features required to run a single- or multi-node cluster”
   • [claimed-docs] “You can use Restate Cloud, run a managed Restate region in your cloud account with Restate BYOC, or operate Restate yourself.”
   • [claimed-docs] “Restate is a single self-contained binary. No external dependencies needed.”
   • [community] “the restate server does handle the durable execution journal / orchestration, while the user code runs in a separate process, we don't host …”
   • [community] “Looks very interesting, but calling it Open Source is misleading. BSL is not "minimal Amazon defense". It effectively prevents any meaningfu…”

   proof ↗⚑ flag

   Hatchet✓fullclaimed8/10

   Hatchet has dedicated self-hosting docs explicitly stating you can run your own Hatchet Control Plane instance, with a full self-hosting guide and 'Run Hatchet yourself' section, and is open-source on GitHub. Missing for 10: independent hands-on confirmation of a successful self-hosted deployment (community discussion focuses on managed/product feedback rather than self-host experience) and more detail on infra requirements/HA in self-hosted mode.

   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the Hatchet Control Plane - the central orchestration system that manages workflows,…”
   • [claimed-docs] “Run Hatchet yourself”
   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”

   proof ↗⚑ flag

Deployment model

1. platform engineerI run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network

   weight 2 · round to Restate
   Restate✓fullcommunity7/10

   Restate explicitly offers a BYOC model where the vendor runs a managed orchestration control plane inside the customer's own cloud account while worker code executes separately, and community confirmation notes 'we don't host the code ourselves ... it is really easy to deploy it wherever you wish' — matching the exact split described in the story. Additional docs reinforce that services can run anywhere (containers, serverless, VMs, k8s) while the server handles the durable execution journal/orchestration. missing for 10: independent/hands-on validation of BYOC specifically (only vendor docs + one community comment), and no detail on data-residency/network isolation guarantees for BYOC deployments.

   • [claimed-docs] “You can use Restate Cloud, run a managed Restate region in your cloud account with Restate BYOC, or operate Restate yourself.”
   • [claimed-docs] “Deploy anywhere: Services run in your infrastructure as containers, serverless functions, VMs, or Kubernetes pods”
   • [community] “the restate server does handle the durable execution journal / orchestration, while the user code runs in a separate process, we don't host …”
   • [claimed-docs] “Restate is distributed as a single binary that implements all features required to run a single- or multi-node cluster”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet's architecture separates a 'worker' component (run via `hatchet worker dev`) from a central control plane, and `hatchet profile` lets you connect a local worker to different named Hatchet instances/tenants, which is consistent with running workers in your own infra against a vendor-hosted control plane; pricing tiers also imply a hosted/Cloud offering distinct from self-hosting. However, the evidence never explicitly states that when using the hosted (Cloud) control plane, task code/data stays inside the customer's network — the only explicit control-plane documentation describes full self-hosting (running your own control plane), not the hybrid vendor-managed-plane/self-hosted-worker model the story describes. Missing for 10: explicit vendor statement or docs describing the hybrid 'Cloud control plane + self-hosted workers, data stays in your network' architecture, and any data-residency/security claims tied to that specific topology.

   • [claimed-docs] “the `hatchet worker dev` command lets you run a worker locally with automatic reloading when code changes are detected”
   • [claimed-docs] “Profiles: the `hatchet profile` commands allow you to manage multiple Hatchet instances and tenants with named profiles, making it easy to s…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the Hatchet Control Plane - the central orchestration system that manages workflows,…”
   • [claimed-docs] “Get up and running in minutes. When you’re ready to scale, upgrade anytime and only pay for what you use.”
   • [claimed-docs] “Running Workers Locally”

   proof ↗⚑ flag

Flow control

1. platform engineerI cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest

   weight 2 · round to Hatchet
   Restate~partialclaimed6/10

   Restate's flow-control docs explicitly support concurrency limits 'per scope' (service, virtual object/key) to protect downstream services and control cost (restate-docs-4, restate-docs-11, restate-docs-32, restate-docs-67), which covers the per-workflow/per-key concurrency-capping part of the story. However there's no explicit evidence of rate limiting (requests/sec throttling) as distinct from concurrency caps, nor any documented per-tenant scoping/isolation construct. Missing for 10: explicit rate-limit (not just concurrency) primitives, and documented per-tenant multi-tenancy fairness controls.

   • [claimed-docs] “Shape traffic with concurrency limits per scope to control cost, protect downstream services, and keep scheduling fair.”
   • [claimed-docs] “This is especially valuable for AI agents, where each concurrent invocation can translate directly into model or API spend. A concurrency li…”
   • [claimed-docs] “Flow control lets you shape the traffic flowing through Restate instead of letting invocations run unbounded.”
   • [claimed-docs] “Shape and limit concurrent invocations with scope”

   proof ↗⚑ flag

   Hatchet✓fullclaimed8/10

   Docs explicitly cover per-key concurrency limits via CEL expressions (e.g., premium vs standard tiers), shared concurrency rules across workflows per user, configurable queue-depth strategies (CANCEL_QUEUED_EXCEPT_NEWEST/OLDEST), and a dedicated Rate Limits reference page alongside a Concurrency reference page, directly matching the per-workflow/per-key/per-tenant throttling story. missing for 10: no independent/hands-on validation of rate-limit or per-tenant isolation behavior under real load, and no explicit doc example scoping limits strictly 'per tenant' as opposed to per-key/user.

   • [claimed-docs] “set concurrency limits on a per-key basis using a CEL expression. For example, let premium-tier users run 10 workflows simultaneously while …”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”
   • [claimed-docs] “Concurrency”
   • [claimed-docs] “Rate Limits”
   • [claimed-docs] “Evaluate and debug CEL expressions used in event filters and concurrency keys”

   proof ↗⚑ flag

Prioritization

1. platform engineerI assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue

   weight 1 · round to Hatchet
   Restate~partialclaimed3/10

   Restate's flow-control docs mention shaping concurrency 'per scope' to 'control cost, protect downstream services, and keep scheduling fair,' which gestures at fairness but never describes assigning priorities to runs or multi-tenant fair queuing as an explicit scheduler feature. Missing for 10: documented priority levels/weights for invocations, explicit multi-tenant fair-scheduling algorithm (vs. simple concurrency caps), and any independent/hands-on evidence that scheduling is fair across tenants rather than FIFO-per-scope.

   • [claimed-docs] “Shape traffic with concurrency limits per scope to control cost, protect downstream services, and keep scheduling fair.”
   • [claimed-docs] “This is especially valuable for AI agents, where each concurrent invocation can translate directly into model or API spend. A concurrency li…”
   • [claimed-docs] “Flow control lets you shape the traffic flowing through Restate instead of letting invocations run unbounded.”
   • [claimed-docs] “Shape and limit concurrent invocations with scope”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet documents per-key concurrency limits driven by CEL expressions that can differentiate tenants/tiers (e.g., premium users get 10 concurrent runs vs 1 for others) and multiple concurrency strategies, which gives some tenant-level fairness/resource allocation. However, there is no documented 'priority' field or priority-based scheduler for runs, nor explicit anti-starvation FIFO-replacement mechanism — the evidence only covers concurrency caps, not priority assignment. Missing for 10: explicit run/task priority attribute, priority-aware scheduler documentation, and independent confirmation that concurrency limits actually produce fair scheduling across tenants under load.

   • [claimed-docs] “set concurrency limits on a per-key basis using a CEL expression. For example, let premium-tier users run 10 workflows simultaneously while …”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”
   • [claimed-docs] “Concurrency”

   proof ↗⚑ flag

Scaling

1. platform engineerThroughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss

   weight 2 · round to Hatchet
   Restate~partialcommunity5/10

   Restate documents that services can run as many replicas across containers/VMs/k8s (restate-docs-7, restate-docs-34), that the server proxies/routes invocations to services (restate-docs-33, restate-comm-9), and that failures/retries are handled automatically so worker crashes don't lose progress (restate-docs-1, restate-docs-15, restate-docs-30). Concurrency/flow-control primitives (restate-docs-4, restate-docs-32, restate-docs-67) let engineers shape traffic across a scope, implying multi-worker fairness. However, there's no explicit documentation of a load-balancing algorithm distributing tasks across a worker fleet or any benchmark/independent evidence of horizontal throughput scaling as workers are added. Missing for 10: explicit load-balancing mechanism across worker replicas, and independent/hands-on evidence of throughput scaling with added workers.

   • [claimed-docs] “Deploy anywhere: Services run in your infrastructure as containers, serverless functions, VMs, or Kubernetes pods”
   • [claimed-docs] “Only Restate needs to be able to make requests to your services. The Restate Server will proxy all requests for these services.”
   • [claimed-docs] “Restate is distributed as a single binary that implements all features required to run a single- or multi-node cluster, making it easy to ru…”
   • [claimed-docs] “Code automatically stores completed steps and resumes from where it left off when recovering from failures.”
   • [claimed-docs] “Automatically retry transient errors like rate limits and network failures. Persist steps (LLM calls, tools) and recover previous progress a…”
   • [claimed-docs] “By default, Restate does infinite retries with an exponential backoff strategy.”
   • [claimed-docs] “Shape traffic with concurrency limits per scope to control cost, protect downstream services, and keep scheduling fair.”
   • [claimed-docs] “Flow control lets you shape the traffic flowing through Restate instead of letting invocations run unbounded.”
   • [community] “the restate server does handle the durable execution journal / orchestration, while the user code runs in a separate process, we don't host …”

   proof ↗⚑ flag

   Hatchet~partialcommunity6/10

   Hatchet's architecture (separate control-plane service, Postgres-backed queue, retries/durability, concurrency-key limits) implies workers can be added to a fleet and tasks distributed/retried on failure (hatchet-gh-1, hatchet-gh-2, hatchet-docs-5/6/18), and the founder describes the control plane as coordinating worker execution independently of client polling (hatchet-comm-6). However, the founder's own account of a scaling pathology at ~25k queries/s with many workers long-polling causing 'runaway CPU deterioration' (hatchet-comm-11) shows real limits to clean horizontal scaling that aren't fully resolved in the evidence, and there's no explicit documentation of automatic failover/rebalancing when a worker dies. Missing for 10: explicit docs on worker-loss recovery/rebalancing, independent throughput benchmarks confirming linear scaling with added workers, and confirmation the 25k qps bottleneck is fully resolved.

   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [claimed-docs] “set concurrency limits on a per-key basis using a CEL expression. For example, let premium-tier users run 10 workflows simultaneously while …”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”
   • [community] “pg-boss comparison from founder: 'The core difference is that pg-boss is a library while Hatchet is a separate service which runs independen…”
   • [community] “Founder on scaling: 'FOR UPDATE SKIP LOCKED does not scale to 25k queries/s'... pathological case was many tasks in backlog, many workers, w…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Restate
   Restate~partialclaimed5/10

   Restate lets users fully control data location by self-hosting anywhere or running BYOC (bring-your-own-cloud) in their own infrastructure/region, and it's a single dependency-free binary that can run in any datacenter (restate-docs-7, restate-docs-13, restate-docs-14, restate-docs-26). However, there is no explicit documentation of a region-selection mechanism or formal data-residency guarantee for the managed Restate Cloud offering itself. Missing for 10: explicit region-picker/residency policy for Restate Cloud, documented compliance/residency guarantees, independent confirmation of BYOC regional isolation.

   • [claimed-docs] “You can use Restate Cloud, run a managed Restate region in your cloud account with Restate BYOC, or operate Restate yourself.”
   • [claimed-docs] “Deploy anywhere: Services run in your infrastructure as containers, serverless functions, VMs, or Kubernetes pods”
   • [claimed-docs] “Restate is distributed as a single binary that implements all features required to run a single- or multi-node cluster”
   • [claimed-docs] “Restate is a single self-contained binary. No external dependencies needed.”

   proof ↗⚑ flag

   Hatchet~partialclaimed3/10

   Hatchet supports full self-hosting of its Control Plane, which lets an operator choose the physical location/region of their own infrastructure and thus control data residency indirectly, but there is no documented cloud-based region-selection feature or explicit data-residency guarantee. Missing for 10: an explicit region/residency selector for Hatchet Cloud, documentation of where hosted data is stored, and compliance certifications tied to specific regions.

   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the Hatchet Control Plane - the central orchestration system that manages workflows,…”
   • [claimed-docs] “Everything in Team, plus:Unlimited users & tenants7-day data retentionAudit logs & HIPAA”
   • [claimed-docs] “Enterprise-grade security, compliance, and SSO.”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Hatchet
   Restate—none0/10

   Restate persists state, invocation journals, and execution history (restate-docs-2, restate-docs-10, restate-docs-64-66), and offers self-hosted/BYOC deployment (restate-docs-14, restate-docs-70) which implies some infrastructure-level control, but the evidence pack contains no explicit documentation of data retention policies, TTL/expiration settings, or deletion/purge APIs for stored state or journals.

   ⚑ flag

   Hatchet~partialclaimed3/10

   Evidence shows fixed data-retention windows tied to pricing tiers (3-day/7-day retention) and the option to self-host the control plane, which gives an operator ultimate control over their own Postgres-backed data including deletion. However, there is no documented user-facing deletion API, configurable retention policy, or GDPR-style erasure workflow for the hosted product. missing for 10: explicit data-deletion/purge API, user-configurable retention settings, compliance documentation (e.g., GDPR erasure) beyond generic 'Audit logs & HIPAA' mention.

   • [claimed-docs] “Everything in Team, plus:Unlimited users & tenants7-day data retentionAudit logs & HIPAA”
   • [claimed-docs] “Everything in Developer, plus:10 users & 5 tenants3-day retention500 RPS throughput”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Run Hatchet yourself”
   • [claimed-docs] “Enterprise-grade security, compliance, and SSO.”

   proof ↗⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Restate—none0/10

   No evidence pack material addresses telemetry collection or an opt-out mechanism for Restate; since Restate is a self-hostable durable execution server, this privacy-posture question is a fair one to ask but is simply unanswered. Missing for 10: any mention of telemetry collection, data sent to Restate Inc., or an opt-out/disable-telemetry flag or setting.

   ⚑ flag

   Hatchet—none0/10

   No evidence pack item mentions telemetry, usage tracking, or any opt-out mechanism for Hatchet; this is a self-hostable orchestration platform where such a privacy control is a fair question but unaddressed in the evidence.

   ⚑ flag

Exactly once

1. backend developerIdempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending

   weight 2 · round to Restate
   Restate✓fullclaimed8/10

   Restate's docs explicitly describe idempotency-key deduplication and exactly-once processing for events/invocations (restate-docs-37, restate-docs-47, restate-docs-81), plus guaranteed exactly-once service calls (restate-docs-3) and durable step persistence/retry semantics (restate-docs-15, restate-docs-18, restate-docs-30) that together prevent duplicate side effects like double-charging or double-sending. Missing for 10: independent/hands-on verification specifically of idempotency-key deduplication behavior in production (community evidence is about general product experience, not this feature).

   • [claimed-docs] “Restate persists all incoming events, and ensures that they are processed exactly once, across failures and restarts... Let Restate deduplic…”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are processed exactly once, across failures and restarts.”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are **processed exactly once**, across failures and restarts.”
   • [claimed-docs] “Call services sync or async with guaranteed execution and exactly-once semantics.”
   • [claimed-docs] “Automatically retry transient errors like rate limits and network failures. Persist steps (LLM calls, tools) and recover previous progress a…”
   • [claimed-docs] “Use `ctx.run` to safely wrap any non-deterministic operation, like HTTP calls or database responses, and have Restate store its result in th…”
   • [claimed-docs] “By default, Restate does infinite retries with an exponential backoff strategy.”

   proof ↗⚑ flag

   Hatchet—none0/10

   The evidence pack covers retries, concurrency limits, cron/scheduled runs, and rate limits, but nowhere mentions idempotency keys or exactly-once step execution guarantees to prevent duplicate side effects like double-charging. Missing for 10: any documentation of idempotency key APIs, deduplication mechanisms, or exactly-once semantics guarantees.

   ⚑ flag

Long running

1. backend developerA workflow can sleep or wait for days to months without holding a server, connection, or billable compute

   weight 2 · round to Restate
   Restate✓fullclaimed8/10

   Restate's durable timers let handlers sleep, schedule, or wait for events, and docs explicitly state that on FaaS platforms like AWS Lambda the handler is suspended while sleeping to free up resources, and idle agents are suspended to save cost — directly matching the 'no held server/compute' requirement. This is documented across sleep/timer, AI-agent, and FaaS-specific pages, covering days-scale patterns like cron jobs and delayed messages. Missing for 10: independent/hands-on verification of multi-month sleep durations in production and explicit confirmation of zero billable compute during suspension on non-serverless deployments.

   • [claimed-docs] “Sleep, schedule, and wait for external events with durable timers.”
   • [claimed-docs] “If your handler runs on function-as-a-service platforms like AWS Lambda, Restate suspends the handler while it is sleeping, to free up resou…”
   • [claimed-docs] “Restate provides durable, fault-tolerant timers that allow you to: Sleep... Send delayed messages... Set timeouts... Implement patterns like…”
   • [claimed-docs] “Automatically retry transient errors like rate limits and network failures. Persist steps (LLM calls, tools) and recover previous progress a…”
   • [claimed-docs] “Durable timers, sche”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet's docs reference Scheduled Runs and Cron Runs, which imply workflows can be deferred to future times without an always-on process, and the control-plane architecture persists workflow state in Postgres rather than in worker memory. However, no evidence explicitly documents a 'durable sleep' primitive, confirms sleeps can span months, or states that no billable compute/connection is held during a sleep. Missing for 10: explicit sleep/durable-execution API docs, confirmation of long-duration (weeks/months) sleeps, and any statement about compute/connection cost during sleep.

   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”

   proof ↗⚑ flag

Recovery

1. backend developerA workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact

   weight 3 · round to Restate
   Restate✓fullcommunity9/10

   Restate's core durable execution model persists completed steps and journal entries so invocations resume exactly from the last completed step after crashes, deploys, or infra failures, with strong first-party documentation across retries, versioning-safe redirects, and state durability (restate-docs-1, restate-docs-15, restate-docs-18, restate-docs-24, restate-docs-30, restate-docs-37). Community feedback corroborates the durable execution model works in practice for real apps (restate-comm-1, restate-comm-9). Missing for 10: independent third-party benchmarking or incident-report evidence specifically confirming resume-after-crash behavior in production at scale beyond vendor docs and anecdotal HN comments.

   • [claimed-docs] “Code automatically stores completed steps and resumes from where it left off when recovering from failures.”
   • [claimed-docs] “Automatically retry transient errors like rate limits and network failures. Persist steps (LLM calls, tools) and recover previous progress a…”
   • [claimed-docs] “Use `ctx.run` to safely wrap any non-deterministic operation, like HTTP calls or database responses, and have Restate store its result in th…”
   • [claimed-docs] “Restate then makes sure that requests start and end on the same version, by sending any retry attempts always to the same endpoint.”
   • [claimed-docs] “By default, Restate does infinite retries with an exponential backoff strategy.”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are processed exactly once, across failures and restarts... Let Restate deduplic…”
   • [community] “The cloud setup was super fast! I used it for an existing app + restate TS sdk, really took a few steps to get things up and running! Lookin…”
   • [community] “the restate server does handle the durable execution journal / orchestration, while the user code runs in a separate process, we don't host …”

   proof ↗⚑ flag

   Hatchet~partialclaimed6/10

   Hatchet is explicitly marketed as a 'durable workflow' engine with automatic retries and durability built into the queuing layer (gh-1, gh-2, gh-3), and has a dedicated Retry Policies doc (hatchet-docs-25) plus separate control-plane architecture (hatchet-docs-8/17) that decouples worker crashes from task state. However, there is no first-party or community evidence detailing exact step-level checkpointing/resume semantics after a crash, deploy, or infra failure, and no hands-on confirmation from users that a workflow actually resumes mid-execution rather than restarting. Missing for 10: explicit documentation of step-level state persistence/checkpointing, and independent/hands-on evidence confirming resume-from-last-step behavior after real crashes or deploys.

   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [github] “An orchestration engine for background tasks, AI agents, and durable workflows”
   • [claimed-docs] “Retry Policies”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the **Hatchet Control Plane** - the central orchestration system that manages workfl…”
   • [claimed-docs] “Self-hosting Hatchet means running your own instance of the Hatchet Control Plane - the central orchestration system that manages workflows,…”

   proof ↗⚑ flag

Retries

1. backend developerEvery step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding

   weight 3 · round to Restate
   Restate✓fullclaimed8/10

   Restate's ctx.run wraps arbitrary steps with automatic retries, configurable backoff/retry policies, and terminal errors to bypass retries, plus durable timers/timeouts, all without manual try/catch scaffolding (restate-docs-18, restate-docs-19, restate-docs-22, restate-docs-5, restate-docs-15). missing for 10: independent hands-on validation of the retry/backoff configuration specifically (community evidence is general product sentiment, not focused on retry policy behavior), and no explicit example of a configured failure-policy edge case in the evidence pack.

   • [claimed-docs] “Use `ctx.run` to safely wrap any non-deterministic operation, like HTTP calls or database responses, and have Restate store its result in th…”
   • [claimed-docs] “You can customize how `ctx.run` retries via:”
   • [claimed-docs] “For failures for which you do not want retries, but instead want the invocation to end and the error message to be propagated back to the ca…”
   • [claimed-docs] “Sleep, schedule, and wait for external events with durable timers.”
   • [claimed-docs] “Automatically retry transient errors like rate limits and network failures. Persist steps (LLM calls, tools) and recover previous progress a…”
   • [claimed-docs] “Code automatically stores completed steps and resumes from where it left off when recovering from failures.”

   proof ↗⚑ flag

   Hatchet~partialcommunity6/10

   Hatchet has a dedicated 'Retry Policies' docs page and GitHub explicitly touts 'automatic retries' as part of the platform, and the founder's HN comments describe a declarative workflow model that avoids try/catch scaffolding for step execution. However, the evidence pack gives only page titles for retries/rate-limits/concurrency without concrete detail on configurable backoff curves, per-step timeouts, or failure-policy semantics. Missing for 10: explicit documentation of backoff configuration options, timeout settings per step, and failure-policy examples beyond a bare page title.

   • [claimed-docs] “Retry Policies”
   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [community] “abelanger (Hatchet founder) explained: 'unlike many alternatives, the execution path of a multi-step workflow in Hatchet is declared ahead o…”
   • [claimed-docs] “Rate Limits”

   proof ↗⚑ flag

Events

1. backend developerEvents from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions

   weight 2 · round drawn
   Restate~partialclaimed6/10

   Restate supports webhook-triggered handlers (any handler can be a durable webhook endpoint, exactly-once processing) and Kafka topic invocation as a trigger mechanism, plus explicit fan-out patterns ('Fan out work to multiple agents, then combine the results') and parallel tool-call execution. However, triggering is code-based (write a handler, wire up webhook/Kafka), not a declarative trigger-definition config, and there's no explicit mention of generic app-event buses beyond webhooks/Kafka fanning out to many arbitrary functions declaratively. Missing for 10: a declarative trigger/rule definition mechanism (e.g. YAML/config-based event routing), explicit multi-function fan-out from a single generic app event (not just AI-agent patterns), and independent/community validation of this specific flow.

   • [claimed-docs] “Restate persists all incoming events, and ensures that they are processed exactly once, across failures and restarts... Let Restate deduplic…”
   • [claimed-docs] “Any handler can be a durable webhook endpoint. No need to do anything special or extra!”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are processed exactly once, across failures and restarts.”
   • [claimed-docs] “There are three ways to invoke a handler: over HTTP, using typed clients, or through Kafka topics.”
   • [claimed-docs] “Fan out work to multiple agents, then combine the results. Failed agents are retried independently while successful results are preserved.”
   • [claimed-docs] “Restate eliminates this complexity by providing **lightweight, transactional event processing** with zero consumer management and built-in s…”
   • [claimed-docs] “Coordinate long-running processes, human approvals, listen to webhooks and other signals.”

   proof ↗⚑ flag

   Hatchet~partialclaimed6/10

   Hatchet's docs show declarative workflow triggering via webhooks, event filters (CEL expressions), and cron/scheduled runs, and its DAG-based workflow model with shared concurrency rules across multiple workflows (docs-6) implies coordinated multi-workflow execution from shared triggers. However, there's no explicit worked example or documentation of a single event fanning out to multiple distinct functions/workflows, and no independent hands-on confirmation of this exact pattern. missing for 10: concrete example/doc of one event triggering multiple downstream workflows/functions, independent verification of fan-out behavior.

   • [claimed-docs] “Webhooks”
   • [claimed-docs] “Evaluate and debug CEL expressions used in event filters and concurrency keys”
   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”

   proof ↗⚑ flag

Flow shaping

1. backend developerI debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want

   weight 1 · round drawn
   Restate~partialclaimed4/10

   Restate offers building blocks that could be used to approximate debounce/batch/delay behavior—durable timers for delayed messages and cron-like scheduling (restate-docs-29), idempotency-key deduplication of duplicate events (restate-docs-37, restate-docs-81), and concurrency-limiting flow control to shape bursty traffic (restate-docs-4, restate-docs-32, restate-docs-67)—but there is no documented first-class debounce or batching primitive that collapses a noisy stream of triggers into a single consolidated run. missing for 10: explicit debounce/coalescing API, windowed batching of events, and any hands-on example showing noisy triggers collapsed into one run.

   • [claimed-docs] “Restate provides durable, fault-tolerant timers that allow you to: Sleep... Send delayed messages... Set timeouts... Implement patterns like…”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are processed exactly once, across failures and restarts... Let Restate deduplic…”
   • [claimed-docs] “Restate persists all incoming events, and ensures that they are **processed exactly once**, across failures and restarts.”
   • [claimed-docs] “Shape traffic with concurrency limits per scope to control cost, protect downstream services, and keep scheduling fair.”
   • [claimed-docs] “Flow control lets you shape the traffic flowing through Restate instead of letting invocations run unbounded.”
   • [claimed-docs] “Shape and limit concurrent invocations with scope”

   proof ↗⚑ flag

   Hatchet~partialclaimed4/10

   Hatchet's concurrency strategies (e.g. CANCEL_QUEUED_EXCEPT_NEWEST/OLDEST) and per-key concurrency limits can approximate collapsing noisy triggers into a single desired run, and rate limits/cron/scheduled runs give some control over trigger cadence, but there is no explicit debounce, batching-window, or delay-trigger primitive described in the evidence. missing for 10: explicit debounce/delay trigger API, event batching/aggregation over a time window, and any hands-on confirmation these concurrency strategies are actually used for debounce-style use cases.

   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”
   • [claimed-docs] “set concurrency limits on a per-key basis using a CEL expression. For example, let premium-tier users run 10 workflows simultaneously while …”
   • [claimed-docs] “create concurrency rules that many tasks and workflows consume simultaneously, e.g. limiting `workflow_a` and `workflow_b` to 10 concurrent …”
   • [claimed-docs] “Concurrency”
   • [claimed-docs] “Rate Limits”
   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Scheduled Runs”

   proof ↗⚑ flag

Schedules

1. backend developerI schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs

   weight 2 · round to Hatchet
   Restate—none0/10

   Restate offers durable timers/sleep and states you can 'implement patterns like cron jobs' (restate-docs-29), plus general invocation introspection, but there is no evidence of native cron-expression scheduling, overlap policies, pause/resume controls, or a view of upcoming scheduled runs — these are DIY patterns built on timers, not a documented scheduler feature.

   • [claimed-docs] “Restate provides durable, fault-tolerant timers that allow you to: Sleep... Send delayed messages... Set timeouts... Implement patterns like…”
   • [claimed-docs] “Sleep, schedule, and wait for external events with durable timers.”
   • [claimed-docs] “Restate exposes information on invocations and application state via its CLI and Introspection SQL API.”
   • [claimed-docs] “Invocations list: See all running, suspended, and completed agent invocations”

   proof ↗⚑ flag

   Hatchet~partialclaimed5/10

   Hatchet documents cron triggers, scheduled runs, and concurrency strategies (including queue-depth overlap-like policies such as CANCEL_QUEUED_EXCEPT_NEWEST/OLDEST) plus TUI/dashboard observability into tasks and workflows, giving partial coverage of scheduling and visibility. However, there is no explicit documentation tying overlap policies specifically to cron jobs, and no evidence of a pause/resume feature for scheduled workflows. Missing for 10: explicit cron-specific overlap/skip policy docs, pause/resume of cron schedules, and independent confirmation of upcoming-run visibility UI.

   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”
   • [claimed-docs] “Cron Runs”
   • [claimed-docs] “Scheduled Runs”
   • [claimed-docs] “Two new concurrency strategies, `CANCEL_QUEUED_EXCEPT_NEWEST` and `CANCEL_QUEUED_EXCEPT_OLDEST`: configure the queue depth for each concurre…”
   • [claimed-docs] “the `hatchet tui` command lets you interact with your Hatchet deployment through a terminal user interface (TUI) that provides real-time obs…”

   proof ↗⚑ flag

Versioning

1. platform engineerI deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism

   weight 3 · round to Restate
   Restate✓fullclaimed8/10

   Restate documents immutable deployments and versioning explicitly: in-flight invocations continue running on the code version they started with, and retries are always routed to the same endpoint version, directly addressing safe versioning without breaking determinism (restate-docs-24, restate-docs-41). This is corroborated by broader durable execution guarantees (journal replay, exactly-once) that make this safe. missing for 10: independent/hands-on verification of version-pinning behavior in production, and detail on how new versions are rolled out/deprecated operationally.

   • [claimed-docs] “Restate then makes sure that requests start and end on the same version, by sending any retry attempts always to the same endpoint.”
   • [claimed-docs] “Restate helps via the concept of immutable deployments. When you deploy a version of your code, you giv”
   • [claimed-docs] “Restate is distributed as a single binary that implements all features required to run a single- or multi-node cluster”
   • [claimed-docs] “Deploy anywhere: Services run in your infrastructure as containers, serverless functions, VMs, or Kubernetes pods”

   proof ↗⚑ flag

   Hatchet—none0/10

   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. This is a reasonable axis for a durable workflow engine, so absence of evidence means 'none' rather than 'na'.

   ⚑ flag

Authoring

1. backend developerI write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL

   weight 3 · round to Restate
   Restate✓fullclaimed8/10

   Restate lets developers write handlers as ordinary code (TypeScript, Java/Kotlin, Python, Go, Rust) using constructs like ctx.run for automatic checkpointing of steps, with no YAML/DSL involved — confirmed by docs on durable steps, durable execution, and SDK support. missing for 10: independent hands-on developer testimony specifically praising 'no DSL/code-first' authoring (community evidence focuses on other aspects like cloud setup and architecture), and no direct comparison showing absence of any config-based workflow definition.

   • [claimed-docs] “Code automatically stores completed steps and resumes from where it left off when recovering from failures.”
   • [claimed-docs] “Use `ctx.run` to safely wrap any non-deterministic operation, like HTTP calls or database responses, and have Restate store its result in th…”
   • [claimed-docs] “You can customize how `ctx.run` retries via:”
   • [github] “Restate supports the following SDKs: * [Typescript] * [Java and Kotlin] * [Python] * [Go] * [Rust]”
   • [claimed-docs] “Restate provides **durable execution primitives** that make distributed systems resilient by default, without the operational overhead.”

   proof ↗⚑ flag

   Hatchet~partialcommunity6/10

   Hatchet's SDKs (Python, TypeScript, Go, Ruby) and cookbooks show workflows/tasks defined as ordinary code rather than YAML, and 'durability'/retry features are documented, implying step-level state persistence, and a founder comment confirms multi-step execution paths are declared in code ahead of time. However, there's no explicit documentation of 'automatic checkpointing' semantics or a direct contrast against YAML/DSL approaches, and no independent hands-on report specifically validating this authoring model works smoothly in production. Missing for 10: explicit automatic-checkpointing mechanics, explicit no-DSL/no-YAML framing, independent developer confirmation of code-first authoring experience.

   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [github] “Hatchet provides a full platform for queuing, automatic retries, durability, real-time monitoring, alerting, and logging.”
   • [community] “abelanger (Hatchet founder) explained: 'unlike many alternatives, the execution path of a multi-step workflow in Hatchet is declared ahead o…”
   • [claimed-docs] “Retry Policies”

   proof ↗⚑ flag

Composition

1. backend developerI compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination

   weight 2 · round to Restate
   Restate~partialclaimed3/10

   Restate's docs describe durable async/sync service invocation, coordination primitives, and event-based signaling that could underlie fan-out patterns, but none of the evidence explicitly documents parallel-step composition, fan-out/fan-in over dynamic batches, or child-workflow invocation as first-class constructs. missing for 10: explicit fan-out/fan-in APIs, dynamic batch parallelism, child/sub-workflow spawning and joining semantics, and any example or docs page dedicated to this composition pattern.

   • [claimed-docs] “Call services sync or async with guaranteed execution and exactly-once semantics.”
   • [claimed-docs] “Restate provides three durable coordination primitives for this: ... Communication between ongoing invocations, agent steering, and human ap…”
   • [claimed-docs] “Coordinate long-running processes, human approvals, listen to webhooks and other signals.”
   • [github] “Restate provides a distributed durable version of your everyday building blocks, letting you build a wide range of use cases”

   proof ↗⚑ flag

   Hatchet—none0/10

   The evidence pack contains no documentation or discussion of Hatchet's DAG/parallel-step syntax, fan-out/fan-in over dynamic batches, or child-workflow composition — only a general founder comment that 'the execution path of a multi-step workflow ... is declared ahead of time' (hatchet-comm-5), which does not demonstrate these specific coordination primitives. Missing for 10: docs/examples of parallel step definitions, fan-out/fan-in over dynamic batch sizes, and child workflow invocation/spawning.

   • [community] “abelanger (Hatchet founder) explained: 'unlike many alternatives, the execution path of a multi-step workflow in Hatchet is declared ahead o…”

   proof ↗⚑ flag

Language coverage

1. backend developerI author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs

   weight 2 · round drawn
   Restate~partialcommunity6/10

   Restate officially lists five supported SDKs (TypeScript, Java/Kotlin, Python, Go, Rust) covering the mainstream backend languages, and shows some cross-language evidence (Go/Rust client docs, Rust SDK typed ingress clients) alongside deep TypeScript-specific guides for durable steps, timers, error handling, and testing. However, most detailed capability documentation (ctx.run, error handling, testing, AI-assistant integration) is TypeScript-centric, with only shallow mentions for Go/Rust and none for Python/Java, and a community comment notes Go SDK was a later addition, suggesting the SDKs haven't always had lockstep parity. Missing for 10: explicit feature-parity statement across SDKs, equally deep Python/Java/Go documentation, and independent verification that all SDKs support the same primitives (workflows, virtual objects, timers) equivalently.

   • [github] “Restate supports the following SDKs: * [Typescript] * [Java and Kotlin] * [Python] * [Go] * [Rust]”
   • [claimed-docs] “The Go SDK client library lets you invoke Restate handlers from anywhere in your application.”
   • [claimed-docs] “The SDK now generates a typed `<Type>IngressClient` for every impl-block service, virtual object, and workflow.”
   • [claimed-docs] “The SDK now generates a typed <Type>IngressClient for every impl-block service, virtual object, and workflow.”
   • [claimed-docs] “Use `ctx.run` to safely wrap any non-deterministic operation, like HTTP calls or database responses, and have Restate store its result in th…”
   • [claimed-docs] “This uses [Testcontainers](https://testcontainers.com/) to run a Restate Server in a Docker container and let you test your Restate handlers…”
   • [community] “Being fairly familiar with Temporal, I definitely appreciate your cleaner architectural choices. Add a Go SDK and I'll definitely give this …”

   proof ↗⚑ flag

   Hatchet~partialcommunity6/10

   Hatchet officially ships Python, TypeScript, Go and Ruby SDKs (hatchet-gh-2, hatchet-docs-24) and community members confirm using it across multiple languages (hatchet-comm-15), supporting the core 'author in your language' claim. However, several documented features (CEL expression debugging, cron creation via Python reference) are only shown in Python-specific docs, and there is no explicit cross-SDK feature-parity matrix or changelog confirming equal capabilities across all four SDKs. Missing for 10: explicit feature-parity documentation/matrix across SDKs, confirmation that newer features (e.g., CEL debug tools, concurrency strategies) are available uniformly in Go/Ruby/TypeScript, and independent hands-on validation of parity beyond basic usability.

   • [github] “Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. It supports applications written in Pyt…”
   • [claimed-docs] “Python SDK TypeScript SDK Go SDK Ruby SDK”
   • [community] “This looks very cool! I see a lot of Python in the docs; is it usable in other languages? [confirmed SDKs exist for Python, Typescript and G…”
   • [claimed-docs] “Evaluate and debug CEL expressions used in event filters and concurrency keys”
   • [claimed-docs] “Create and manage cron triggers that run workflows on a schedule”

   proof ↗⚑ flag