Hatchet vs DBOS

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 DBOS
   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

   DBOS✓fullcommunity9/10

   DBOS has an explicit AI-agent-focused doc set showing durable workflow checkpointing for agent loops (model/tool calls as steps), crash recovery mid-run, human-in-the-loop waits, durable streaming, and integrations with OpenAI Agents SDK/Vercel AI SDK that preserve progress across restarts. This is corroborated by core architecture docs on checkpointing/recovery and independent community confirmation of the durability mechanism (transactional step logging) and real-world usage. Missing for 10: no independent hands-on benchmark specifically for agent-loop workloads (only generic durable-execution HN discussion), and some community concerns about long-running steps holding transactions open.

   • [claimed-docs] “Resilience to failure: Automatically recover your agents from server restarts, process crashes, network hiccups or outages, and other unexpe…”
   • [claimed-docs] “Durable streaming: Stream output from your agents as it's generated to build interactive or conversational flows that recover from any failu…”
   • [claimed-docs] “you can add a line of code to your agent that tells it to wait hours or days for a notification: approval: Optional[HumanResponseRequest] = …”
   • [claimed-docs] “You can use DBOS to add durable execution to an agent built with the OpenAI Agents SDK... you can build reliable agents that preserve progre…”
   • [claimed-docs] “Because every task is checkpointed, your agent can recover from any failure mid-flight without re-running work that already succeeded.”
   • [claimed-docs] “If your process crashes mid-agent, DBOS replays the completed steps from their checkpoints and the agent resumes exactly where it left off.”
   • [claimed-docs] “DBOS checkpoints the state of your workflows and steps to its system database. If your program crashes or is interrupted, DBOS uses this che…”
   • [community] “DBOS co-founder explaining durability: 'DBOS wraps each function (step) to log its output in the database. This ensures that workflows can b…”
   • [community] “Comparison to Temporal: DBOS core team noted 'the biggest difference is that DBOS doesn't require a centralized workflow server, but does al…”
   • [community] “Praise: 'I built a small side thing using DBOS (using python SDK) and the ergonomics were pretty nice.'”

   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 DBOS
   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

   DBOS~partialprobed7/10

   DBOS ships first-party wrappers for at least two agent stacks — the OpenAI Agents SDK (DBOSRunner.run/run_sync as drop-in replacements, dbos-docs-15, dbos-docs-30) and the Vercel AI SDK (dbos-docs-38) — plus an MCP server for tool integration (dbos-docs-14, dbos-probe-3), all giving durability without hand-rolled checkpointing code. However coverage is narrow (only two named agent frameworks, no broad set of model-provider SDKs like OpenAI/Anthropic/LangChain explicitly wrapped) and there's no independent/hands-on confirmation of these specific integrations working in production. Missing for 10: broader roster of first-party model-provider/agent-framework integrations, and independent corroboration of the OpenAI/Vercel AI wrappers actually working end-to-end.

   • [claimed-docs] “Use DBOSRunner.run and DBOSRunner.run_sync as drop-in replacements for Runner.run and Runner.run_sync.”
   • [claimed-docs] “You can use DBOS to add durable execution to an agent built with the OpenAI Agents SDK... you can build reliable agents that preserve progre…”
   • [claimed-docs] “If your process crashes mid-agent, DBOS replays the completed steps from their checkpoints and the agent resumes exactly where it left off.”
   • [claimed-docs] “You can use the DBOS Model Context Protocol (MCP) server to augment your LLM or agent with tools that can analyze and manage your DBOS workf…”
   • [probe] “official MCP server documented at https://docs.dbos.dev/integrations/mcp”
   • [claimed-docs] “Resilience to failure: Automatically recover your agents from server restarts, process crashes, network hiccups or outages, and other unexpe…”
   • [claimed-docs] “Durable streaming: Stream output from your agents as it's generated to build interactive or conversational flows that recover from any failu…”

   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 to DBOS
   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

   DBOS✓fullclaimed8/10

   DBOS explicitly documents 'durable streaming' for streaming agent/model output as it's generated, with persistence guarantees so a reader keeps receiving values without dropping output even mid-restart, directly matching the streaming-progress-into-frontend story. This is backed by first-party docs on streaming plus related agent-progress/checkpoint features, though there's no independent/hands-on corroboration of this specific streaming feature. Missing for 10: independent or community verification of the streaming feature specifically, and concrete frontend integration example.

   • [claimed-docs] “Durable streaming: Stream output from your agents as it's generated to build interactive or conversational flows that recover from any failu…”
   • [claimed-docs] “Every write is persisted, so if a server restarts mid-response the workflow recovers from where it left off and the reader keeps receiving v…”
   • [claimed-docs] “Because every task is checkpointed, your agent can recover from any failure mid-flight without re-running work that already succeeded.”
   • [claimed-docs] “Resilience to failure: Automatically recover your agents from server restarts, process crashes, network hiccups or outages, and other unexpe…”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round drawn
   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

   DBOS✓fullprobed9/10

   A direct probe confirms an llms.txt file exists at https://docs.dbos.dev/llms.txt following the llmstxt.org standard, and DBOS also maintains extensive agent-oriented docs (e.g., docs.dbos.dev/ai/* pages) explicitly targeting AI agent use cases. Missing for 10: independent/community confirmation that agents successfully consume the llms.txt file in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.dbos.dev/llms.txt # DBOS Documentation This file contains links to documentation sections followin…”
   • [claimed-docs] “Resilience to failure: Automatically recover your agents from server restarts, process crashes, network hiccups or outages, and other unexpe…”
   • [claimed-docs] “a human might take hours or days to respond to an agent, so the agent must be able to reliably wait for a long time (during which the server…”
   • [claimed-docs] “you can use the workflow fork operation to reproduce it. Fork restarts a workflow from a completed step, using checkpointed information to d…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   DBOS✓fullclaimed8/10

   DBOS is a library/CLI (`dbos init`, `dbosctl`, `DBOSClient`) that runs as plain Python/TypeScript code with no GUI dependency, making it natively usable in CI/headless pipelines; it supports unit testing via pytest/unittest, programmatic workflow control, and scriptable Conductor API/CLI for automation. missing for 10: no explicit CI pipeline example (e.g., GitHub Actions) or independent report of running DBOS in CI, and no confirmation of headless operation for the Conductor dashboard beyond API/CLI.

   • [claimed-docs] “Because DBOS workflows, steps, and transactions are ordinary Python functions, you can unit test them using any Python testing framework, li…”
   • [claimed-docs] “pip install dbos 'fastapi[standard]'dbos init --template dbos-app-starter”
   • [claimed-docs] “dbosctl is a command-line client for the Conductor API. It manages workflows, queues, schedules, applications, and API keys against DBOS-man…”
   • [claimed-docs] “DBOSClient provides a programmatic way to interact with your DBOS application from external code or from another DBOS application.”
   • [claimed-docs] “Conductor's workflow, queue, and schedule management is available over an OpenAPI-described HTTP API and from the dbosctl command-line clien…”
   • [github] “Instead of managing your own workflow orchestrator or task queue system, you can use DBOS to add durable workflows and queues to your progra…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   DBOS—none0/10

   Evidence only shows DBOS shipping an MCP *server* that exposes DBOS's own workflow-management tools to an LLM (dbos-docs-14, dbos-probe-3) — the opposite direction from the story, which asks whether the product can consume/plug in external MCP servers as a client to gain their tools. No evidence shows DBOS or DBOS-based agents connecting to third-party MCP servers.

   • [claimed-docs] “You can use the DBOS Model Context Protocol (MCP) server to augment your LLM or agent with tools that can analyze and manage your DBOS workf…”
   • [probe] “official MCP server documented at https://docs.dbos.dev/integrations/mcp”

   proof ↗⚑ flag

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

   weight 3 · round to DBOS
   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

   DBOS✓fullprobed8/10

   DBOS documents an official MCP server ([dbos-docs-14]) that lets an LLM/agent connect and use tools to analyze and manage DBOS workflows, confirmed by probe evidence ([dbos-probe-3]). This is first-party, on-topic documentation directly matching the story. Missing for 10: independent/hands-on third-party corroboration of the MCP server working in practice, and more detail on the full tool surface exposed.

   • [claimed-docs] “You can use the DBOS Model Context Protocol (MCP) server to augment your LLM or agent with tools that can analyze and manage your DBOS workf…”
   • [probe] “official MCP server documented at https://docs.dbos.dev/integrations/mcp”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round drawn
   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

   DBOS✓fullprobed8/10

   DBOS ships official CLIs: the `dbos` CLI for project init and running workflows (dbos-docs-24, dbos-docs-41), and `dbosctl` for managing Conductor-hosted workflows/queues/schedules (dbos-docs-18, dbos-docs-33, dbos-probe-4), both well documented with concrete commands. missing for 10: independent/hands-on community confirmation of CLI usage specifically (most community evidence discusses SDK ergonomics, not CLI), and no evidence of AI-native features (e.g., natural-language or agent-oriented CLI commands) beyond standard devops commands.

   • [claimed-docs] “dbosctl login # log in through the device-authorization flow dbosctl whoami # confirm who y…”
   • [claimed-docs] “pip install dbos 'fastapi[standard]'dbos init --template dbos-app-starter”
   • [claimed-docs] “dbosctl is a command-line client for the Conductor API. It manages workflows, queues, schedules, applications, and API keys against DBOS-man…”
   • [claimed-docs] “List workflows run by your application in JSON format ordered by recency (most recently started workflows last).”
   • [probe] “official CLI documented at https://docs.dbos.dev/production/dbosctl”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   DBOS~partialprobed6/10

   DBOS exposes a documented, scriptable Conductor API (OpenAPI-described HTTP API) plus dbosctl CLI and a Python DBOSClient for programmatic control of workflows/queues/schedules, and an official MCP server for LLM/agent access — strong evidence of a documented public API surface. However, the core DBOS library itself is primarily an in-process annotation-based SDK rather than a standalone public API, and probes show no discoverable OpenAPI/swagger spec at the docs root, and Conductor's API management features are tied to a hosted/paid product rather than the core OSS library. missing for 10: a first-party standalone REST/OpenAPI spec for the core library (not just Conductor), independent hands-on confirmation of API completeness, and clarity that Conductor API access isn't gated behind paid tiers.

   • [claimed-docs] “Conductor's workflow, queue, and schedule management is available over an OpenAPI-described HTTP API and from the dbosctl command-line clien…”
   • [claimed-docs] “dbosctl login # log in through the device-authorization flow dbosctl whoami # confirm who y…”
   • [claimed-docs] “register applications with Conductor and tune their settings, search workflows, cancel or fork them, inspect queues and schedules, drive sch…”
   • [claimed-docs] “dbosctl is a command-line client for the Conductor API. It manages workflows, queues, schedules, applications, and API keys against DBOS-man…”
   • [claimed-docs] “DBOSClient provides a programmatic way to interact with your DBOS application from external code or from another DBOS application.”
   • [probe] “official MCP server documented at https://docs.dbos.dev/integrations/mcp”
   • [probe] “official CLI documented at https://docs.dbos.dev/production/dbosctl”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.dbos.dev/openapi.json, https://docs.dbos.dev/swagger.json, https://docs.dbos.dev/api/op…”

   proof ↗⚑ flag

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

   weight 2 · round to DBOS
   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

   DBOS~partialclaimed3/10

   DBOS's Conductor API/CLI mentions managing 'members, roles, and API keys' and dbosctl managing API keys, implying some access-control primitives, but there is no documentation of issuing scoped/least-privilege credentials specifically for an AI agent's use of external APIs or tools. Missing for 10: explicit scoped-credential issuance workflow, per-agent least-privilege token minting, and any documentation tying API keys to agent identity or permission scoping.

   • [claimed-docs] “register applications with Conductor and tune their settings, search workflows, cancel or fork them, inspect queues and schedules, drive sch…”
   • [claimed-docs] “dbosctl is a command-line client for the Conductor API. It manages workflows, queues, schedules, applications, and API keys against DBOS-man…”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   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

   DBOS✓fullcommunity8/10

   DBOS ships official Python and TypeScript SDKs with extensive first-party docs, plus AI-native integrations (OpenAI Agents SDK drop-in runner, Vercel AI SDK, MCP server, DBOSClient) that let developers build agents directly against the library's APIs, corroborated by a community user praising the Python SDK's ergonomics. Missing for 10: broader language SDK coverage (a complaint notes no .NET support) and independent hands-on validation of the AI-specific integrations beyond docs.

   • [claimed-docs] “Use DBOSRunner.run and DBOSRunner.run_sync as drop-in replacements for Runner.run and Runner.run_sync.”
   • [claimed-docs] “You can use DBOS to add durable execution to an agent built with the OpenAI Agents SDK... you can build reliable agents that preserve progre…”
   • [claimed-docs] “You can use the DBOS Model Context Protocol (MCP) server to augment your LLM or agent with tools that can analyze and manage your DBOS workf…”
   • [claimed-docs] “If your process crashes mid-agent, DBOS replays the completed steps from their checkpoints and the agent resumes exactly where it left off.”
   • [claimed-docs] “DBOSClient provides a programmatic way to interact with your DBOS application from external code or from another DBOS application.”
   • [community] “Praise: 'I built a small side thing using DBOS (using python SDK) and the ergonomics were pretty nice.'”
   • [community] “Complaint: 'Bit disappointed, looked for .net core support but no. Languages that are supported: Typescript and Python.'”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Hatchet
   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

   DBOS—none0/10

   DBOS provides durable workflows, messaging, queues, and an MCP server, but no evidence anywhere in the pack describes a webhook subscription mechanism for external events; this is an applicable axis for a workflow/agentic platform but no capability is documented.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   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

   DBOS✓fullcommunity8/10

   DBOS supports scheduled/cron workflows, background workflow starting, queues, durable checkpointing/recovery, and human-in-the-loop waiting, enabling autonomous background automations that survive crashes and restarts. Community evidence corroborates the durability/recovery mechanics (though with some architectural caveats unrelated to this story). missing for 10: independent hands-on validation specifically of long-running autonomous 'automation' use cases (vs. workflow/agent examples), and no evidence of built-in alerting/monitoring for autonomous runs outside Conductor.

   • [claimed-docs] “You can schedule DBOS workflows to run on a cron schedule. Schedules are stored in the database and can be created, paused, resumed, and del…”
   • [claimed-docs] “You can use DBOS.start_workflow to start a workflow in the background. If you start a workflow this way, it returns a workflow handle, from …”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”
   • [claimed-docs] “If a workflow is interrupted for any reason, DBOS automatically recovers its execution from the last completed step.”
   • [claimed-docs] “DBOS checkpoints the state of your workflows and steps to its system database. If your program crashes or is interrupted, DBOS uses this che…”
   • [claimed-docs] “a human might take hours or days to respond to an agent, so the agent must be able to reliably wait for a long time (during which the server…”
   • [claimed-docs] “you can add a line of code to your agent that tells it to wait hours or days for a notification: approval: Optional[HumanResponseRequest] = …”
   • [community] “DBOS co-founder explaining durability: 'DBOS wraps each function (step) to log its output in the database. This ensures that workflows can b…”
   • [community] “Comparison to Temporal: DBOS core team noted 'the biggest difference is that DBOS doesn't require a centralized workflow server, but does al…”

   proof ↗⚑ flag

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

   weight 2 · round to DBOS
   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

   DBOS~partialprobed4/10

   DBOS ships an official MCP server that lets an LLM/agent 'analyze and manage your DBOS workflows,' which enables natural-language operation indirectly through an AI agent, but DBOS itself has no chat/NL interface — operation is otherwise via code, CLI (dbosctl), or the Conductor dashboard. Missing for 10: a first-party conversational/NL interface, evidence of end-to-end NL command execution, and independent confirmation the MCP server actually supports full workflow management in practice.

   • [claimed-docs] “You can use the DBOS Model Context Protocol (MCP) server to augment your LLM or agent with tools that can analyze and manage your DBOS workf…”
   • [probe] “official MCP server documented at https://docs.dbos.dev/integrations/mcp”
   • [claimed-docs] “dbosctl login # log in through the device-authorization flow dbosctl whoami # confirm who y…”
   • [claimed-docs] “dbosctl is a command-line client for the Conductor API. It manages workflows, queues, schedules, applications, and API keys against DBOS-man…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   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

   DBOS—none0/10

   No evidence of an interactive, runnable API reference; the probe for OpenAPI/Swagger endpoints returned 404 on all candidate paths, and while docs mention an OpenAPI-described Conductor API, there's no indication of an in-browser 'try it' console or runnable code playground.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.dbos.dev/openapi.json, https://docs.dbos.dev/swagger.json, https://docs.dbos.dev/api/op…”
   • [claimed-docs] “Conductor's workflow, queue, and schedule management is available over an OpenAPI-described HTTP API and from the dbosctl command-line clien…”

   proof ↗⚑ flag

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

   weight 2 · round to DBOS
   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

   DBOS~partialprobed5/10

   Docs explicitly state Conductor's workflow/queue/schedule management is available over an 'OpenAPI-described HTTP API' (dbos-docs-17), implying a machine-readable spec exists, but no direct link or confirmed downloadable spec file was found — a probe for openapi.json/swagger.json at the docs site returned 404s. Missing for 10: a verifiable, directly downloadable OpenAPI/swagger file or public spec URL, and independent confirmation that the Conductor API's OpenAPI description is accessible to end users.

   • [claimed-docs] “Conductor's workflow, queue, and schedule management is available over an OpenAPI-described HTTP API and from the dbosctl command-line clien…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.dbos.dev/openapi.json, https://docs.dbos.dev/swagger.json, https://docs.dbos.dev/api/op…”

   proof ↗⚑ flag

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

   weight 1 · round to Hatchet
   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

   DBOS—none0/10

   DBOS docs mention unit testing workflows with pytest/unittest (dbos-docs-9) and local self-hosting via Docker Compose (dbos-docs-34), but there is no evidence of a dedicated sandbox/staging environment feature that isolates test runs from production data. missing for 10: explicit sandbox/staging environment, data isolation guarantees, environment-switching tooling, or a documented test-mode that avoids touching production data.

   • [claimed-docs] “Because DBOS workflows, steps, and transactions are ordinary Python functions, you can unit test them using any Python testing framework, li…”
   • [claimed-docs] “There are many ways to self-host Conductor and the DBOS Console on your own infrastructure... you can self-host Conductor and the DBOS Conso…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   DBOS—none0/10

   The evidence only covers strategies for versioning application *workflow code* (patching/versioning) via dbos-docs-10, not a documented policy for DBOS's own library/API versioning or deprecation. No changelog, semver commitment, or deprecation policy for the DBOS SDK/APIs themselves is evidenced.

   ⚑ flag

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

   weight 2 · round to DBOS
   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

   DBOS~partialcommunity6/10

   DBOS queues let users run many workflows at once with managed concurrency and flow control (dbos-docs-6/26), and Conductor/dbosctl provide bulk workflow management (list, cancel, fork, restart) across many workflows (dbos-docs-17, 32, 33, 41). However, this is developer/infra-level bulk operation over workflows, not an end-user-facing 'bulk operate on many items' feature, and there's no first-party UI or API specifically framed for ai-native bulk item operations. missing for 10: a dedicated bulk-operations API/UI for end-user items (vs. workflow-level queue management), independent hands-on evidence of bulk operation at scale, and clarity on limits/performance for very large batch runs.

   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide _flow control_, letting you manage how many workfl…”
   • [claimed-docs] “Conductor's workflow, queue, and schedule management is available over an OpenAPI-described HTTP API and from the dbosctl command-line clien…”
   • [claimed-docs] “register applications with Conductor and tune their settings, search workflows, cancel or fork them, inspect queues and schedules, drive sch…”
   • [claimed-docs] “dbosctl is a command-line client for the Conductor API. It manages workflows, queues, schedules, applications, and API keys against DBOS-man…”
   • [claimed-docs] “List workflows run by your application in JSON format ordered by recency (most recently started workflows last).”
   • [community] “Happy user: 'We are a happy user of DBOS. I've been building out a lightweight TUI for managing our DBOS application internally, since we ha…”

   proof ↗⚑ flag

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

   weight 3 · round to Hatchet
   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

   DBOS~partialclaimed5/10

   DBOS supports automatic triggering of workflows via cron-style schedules (dbos-docs-7) and via message-based signals with DBOS.send/recv (dbos-docs-8, dbos-docs-27, dbos-docs-28), which can act as event-driven triggers for actions, and queues can auto-start workflows on enqueue (dbos-docs-6). However, there's no evidence of a declarative 'rules' definition mechanism (conditional logic tied to arbitrary events like webhooks or external event buses) — it's closer to workflow scheduling/messaging than a rules engine. Missing for 10: explicit rule/condition definition syntax, generic external event source integration, and documented event-trigger examples beyond cron/messaging.

   • [claimed-docs] “You can schedule DBOS workflows to run on a cron schedule. Schedules are stored in the database and can be created, paused, resumed, and del…”
   • [claimed-docs] “You can send messages to a specific workflow. This is useful for signaling a workflow or sending notifications to it while it's running.”
   • [claimed-docs] “You can call `DBOS.send()` to send a message to a workflow. Messages can optionally be associated with a topic and are queued on the receive…”
   • [claimed-docs] “you can add a line of code to your agent that tells it to wait hours or days for a notification: approval: Optional[HumanResponseRequest] = …”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to DBOS
   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

   DBOS✓fullclaimed9/10

   DBOS explicitly supports scheduled/cron workflows stored in the database, which can be created, paused, resumed, and deleted at runtime, plus queues for managing many concurrent workflow runs — directly matching recurring job scheduling. This is well documented first-party with clear API mechanics; missing for 10: independent hands-on validation specifically of the scheduling feature (community evidence covers durability/architecture broadly but not scheduled workflows specifically).

   • [claimed-docs] “You can schedule DBOS workflows to run on a cron schedule. Schedules are stored in the database and can be created, paused, resumed, and del…”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide _flow control_, letting you manage how many workfl…”

   proof ↗⚑ flag

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

   weight 1 · round to DBOS
   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

   DBOS~partialcommunity6/10

   DBOS documents explicit workflow versioning strategies (patching/versioning), fork/replay to reproduce and audit workflow steps, and a Conductor console that lets you 'Monitor, version, fork, replay, and observe' workflows plus pause/restart from any step for incident response. However, this is oriented toward code-version safety and workflow-execution recovery rather than a full audit/review/rollback UI for 'automations' as end-user artifacts, and community feedback notes the web UI/observability console isn't open-source or self-hostable for all users, limiting review access. Missing for 10: independent hands-on confirmation of the Conductor versioning/rollback UI in practice, and a clearer non-technical review/rollback workflow beyond developer-level fork/replay.

   • [claimed-docs] “DBOS supports two strategies for safely upgrading workflow code: patching and versioning.”
   • [claimed-docs] “Manage with Conductor: Monitor, version, fork, replay, and observe durable workflows with DBOS Conductor console.”
   • [claimed-docs] “you can use the workflow fork operation to reproduce it. Fork restarts a workflow from a completed step, using checkpointed information to d…”
   • [claimed-docs] “From the Conductor dashboard, you can pause any workflow execution, start any stopped or enqueued workflow, or restart any workflow from a s…”
   • [claimed-docs] “Because workflows checkpoint the outcome of each step of your workflow, you can review these checkpoints to see the cause of the failure and…”
   • [community] “Comparison: 'I like dbos architecture much more than temporal since it is much easier to operate on small team. But dbos doesn't have openso…”
   • [community] “User complaint: 'I was super interested in DBOS but I had to back out when I figured that the observability isn't self hostable yet,' though…”

   proof ↗⚑ 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 DBOS
   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

   DBOS~partialclaimed4/10

   DBOS clearly delivers the 'one command locally' half of the story: it's a Postgres-backed library with no separate orchestration server, so you just run `python3 main.py` (or `dbos start`) and it seamlessly recovers on restart (dbos-docs-2, dbos-docs-3, dbos-docs-24). However, the testing-utilities half is only thinly evidenced — docs merely state workflows/steps are ordinary Python functions testable with pytest/unittest (dbos-docs-9), with no mention of built-in time-skipping or step-mocking utilities. Missing for 10: documented time-travel/time-skipping test helpers, documented step-mocking/stubbing API, and any hands-on confirmation of these specific testing features.

   • [claimed-docs] “The open-source DBOS library uses Postgres to orchestrate durable workflows and queues. There's no separate orchestration server and no infr…”
   • [claimed-docs] “At any point, crash the app. Then, restart it with `python3 main.py` and watch it seamlessly recover from where it left off.”
   • [claimed-docs] “pip install dbos 'fastapi[standard]'dbos init --template dbos-app-starter”
   • [claimed-docs] “Because DBOS workflows, steps, and transactions are ordinary Python functions, you can unit test them using any Python testing framework, li…”

   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 DBOS
   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

   DBOS✓fullcommunity9/10

   DBOS explicitly documents a human-in-the-loop pattern where DBOS.recv(timeout_seconds=...) lets a workflow pause and wait hours or days for a human response, surviving crashes/restarts via checkpointed state, and resuming exactly where it left off once the message arrives (DBOS.send). This is backed by a dedicated HITL guide, a worked agent-inbox example, and general durable-execution/recovery docs plus community corroboration of the checkpointing mechanism. Missing for 10: independent hands-on validation specifically of the long-duration pause/resume behavior (community evidence covers general durability but not this exact HITL scenario).

   • [claimed-docs] “a human might take hours or days to respond to an agent, so the agent must be able to reliably wait for a long time (during which the server…”
   • [claimed-docs] “you can add a line of code to your agent that tells it to wait hours or days for a notification: approval: Optional[HumanResponseRequest] = …”
   • [claimed-docs] “You can send messages to a specific workflow. This is useful for signaling a workflow or sending notifications to it while it's running.”
   • [claimed-docs] “You can call `DBOS.send()` to send a message to a workflow. Messages can optionally be associated with a topic and are queued on the receive…”
   • [claimed-docs] “We'll see how to build agents that can wait hours or days for human input to arrive (surviving process restarts). We'll also see how to use …”
   • [claimed-docs] “DBOS checkpoints the state of your workflows and steps to its system database. If your program crashes or is interrupted, DBOS uses this che…”
   • [claimed-docs] “If a workflow is interrupted for any reason, DBOS automatically recovers its execution from the last completed step.”
   • [community] “DBOS co-founder explaining durability: 'DBOS wraps each function (step) to log its output in the database. This ensures that workflows can b…”

   proof ↗⚑ 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 DBOS
   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

   DBOS✓fullclaimed9/10

   DBOS provides DBOS.send()/recv() with topic-based queuing to send messages/signals into a specific running workflow from outside, explicitly documented for human-in-the-loop scenarios (e.g., waiting hours/days for approval), plus DBOSClient for interacting with workflows from external code or another DBOS application, and workflow handles for retrieving results. This directly matches the story of signaling a running workflow via API/webhook/another workflow. Missing for 10: independent/hands-on corroboration specifically of the send/recv mechanism (community evidence covers durability/performance but not this exact feature).

   • [claimed-docs] “You can send messages to a specific workflow. This is useful for signaling a workflow or sending notifications to it while it's running.”
   • [claimed-docs] “You can call `DBOS.send()` to send a message to a workflow. Messages can optionally be associated with a topic and are queued on the receive…”
   • [claimed-docs] “you can add a line of code to your agent that tells it to wait hours or days for a notification: approval: Optional[HumanResponseRequest] = …”
   • [claimed-docs] “DBOSClient provides a programmatic way to interact with your DBOS application from external code or from another DBOS application.”
   • [claimed-docs] “a human might take hours or days to respond to an agent, so the agent must be able to reliably wait for a long time (during which the server…”

   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
   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

   DBOS~partialcommunity4/10

   DBOS's Conductor exposes workflow/queue metrics and audit logs via an OpenAPI-described HTTP API and CLI (dbosctl), which could be scripted into external tooling for incident response, and lists 'read metrics and audit logs' as a capability. However, there's no documented native integration with standard observability stacks (Prometheus, OpenTelemetry, Datadog) or any alerting/threshold configuration, and a community user explicitly noted 'the observability isn't self hostable yet' as a blocker before self-hosting was added. Missing for 10: explicit metrics/log export format compatible with common observability backends, documented alerting rules or integrations, and independent confirmation that failure-rate/latency dashboards work as claimed.

   • [claimed-docs] “From the Conductor dashboard, you can pause any workflow execution, start any stopped or enqueued workflow, or restart any workflow from a s…”
   • [claimed-docs] “Conductor's workflow, queue, and schedule management is available over an OpenAPI-described HTTP API and from the dbosctl command-line clien…”
   • [claimed-docs] “register applications with Conductor and tune their settings, search workflows, cancel or fork them, inspect queues and schedules, drive sch…”
   • [claimed-docs] “dbosctl is a command-line client for the Conductor API. It manages workflows, queues, schedules, applications, and API keys against DBOS-man…”
   • [community] “User complaint: 'I was super interested in DBOS but I had to back out when I figured that the observability isn't self hostable yet,' though…”

   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 DBOS
   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

   DBOS✓fullclaimed9/10

   DBOS explicitly documents workflow fork to restart/reproduce a workflow from a specific completed step using checkpointed history (dbos-docs-13), plus checkpoint-based auditing of failure causes (dbos-docs-29) and Conductor UI/CLI/API support to 'restart any workflow from a specific step' for incident response and debugging (dbos-docs-16, dbos-docs-21, dbos-docs-32). This directly matches the replay/rerun-from-step story with both library-level and management-console support. Missing for 10: independent/hands-on community confirmation specifically of the fork/replay-from-step feature (community evidence covers durability/recovery broadly but not this specific fork workflow).

   • [claimed-docs] “you can use the workflow fork operation to reproduce it. Fork restarts a workflow from a completed step, using checkpointed information to d…”
   • [claimed-docs] “Because workflows checkpoint the outcome of each step of your workflow, you can review these checkpoints to see the cause of the failure and…”
   • [claimed-docs] “From the Conductor dashboard, you can pause any workflow execution, start any stopped or enqueued workflow, or restart any workflow from a s…”
   • [claimed-docs] “Manage with Conductor: Monitor, version, fork, replay, and observe durable workflows with DBOS Conductor console.”
   • [claimed-docs] “register applications with Conductor and tune their settings, search workflows, cancel or fork them, inspect queues and schedules, drive sch…”

   proof ↗⚑ 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 to DBOS
   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

   DBOS~partialcommunity6/10

   DBOS's Conductor dashboard provides workflow-level observability — search, filter, audit logs, metrics, pause/restart/fork from specific steps, and CLI/API listing of workflows (dbos-docs-16,17,32,41) — and checkpointing lets teams 'review these checkpoints to see the cause of failure and audit every step' (dbos-docs-29). However, community reports note the dashboard/web UI was not open-source or self-hostable for a period ('observability isn't self hostable yet', 'doesn't have opensource release of web ui') even though later docs claim self-hosting is now possible (dbos-docs-19,34), and no evidence explicitly shows a UI rendering per-step inputs/outputs in a searchable timeline view. Missing for 10: explicit UI screenshots/evidence of input/output per step, independent confirmation that search/filter works well in production, and resolution of the self-host maturity complaint.

   • [claimed-docs] “From the Conductor dashboard, you can pause any workflow execution, start any stopped or enqueued workflow, or restart any workflow from a s…”
   • [claimed-docs] “Conductor's workflow, queue, and schedule management is available over an OpenAPI-described HTTP API and from the dbosctl command-line clien…”
   • [claimed-docs] “Because workflows checkpoint the outcome of each step of your workflow, you can review these checkpoints to see the cause of the failure and…”
   • [claimed-docs] “register applications with Conductor and tune their settings, search workflows, cancel or fork them, inspect queues and schedules, drive sch…”
   • [claimed-docs] “List workflows run by your application in JSON format ordered by recency (most recently started workflows last).”
   • [community] “User complaint: 'I was super interested in DBOS but I had to back out when I figured that the observability isn't self hostable yet,' though…”
   • [community] “Comparison: 'I like dbos architecture much more than temporal since it is much easier to operate on small team. But dbos doesn't have openso…”
   • [claimed-docs] “There are many ways to self-host Conductor and the DBOS Console on your own infrastructure.”
   • [claimed-docs] “There are many ways to self-host Conductor and the DBOS Console on your own infrastructure... you can self-host Conductor and the DBOS Conso…”

   proof ↗⚑ flag

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

   weight 2 · round to DBOS
   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

   DBOS✓fullprobed8/10

   DBOS explicitly documents that everything doable in the Conductor UI (pause/restart/fork workflows, manage queues/schedules, view metrics/audit logs) is also available via an OpenAPI-described HTTP API and the dbosctl CLI, enabling scripting and external tooling parity with the dashboard. Additional programmatic access is provided via DBOSClient and the Python CLI for listing/managing workflows. Missing for 10: independent verification of full UI/API feature parity (the OpenAPI schema wasn't discoverable at standard endpoints per probe) and no hands-on/community confirmation that every UI action is exactly mirrored in the API.

   • [claimed-docs] “From the Conductor dashboard, you can pause any workflow execution, start any stopped or enqueued workflow, or restart any workflow from a s…”
   • [claimed-docs] “Conductor's workflow, queue, and schedule management is available over an OpenAPI-described HTTP API and from the dbosctl command-line clien…”
   • [claimed-docs] “register applications with Conductor and tune their settings, search workflows, cancel or fork them, inspect queues and schedules, drive sch…”
   • [claimed-docs] “dbosctl is a command-line client for the Conductor API. It manages workflows, queues, schedules, applications, and API keys against DBOS-man…”
   • [claimed-docs] “List workflows run by your application in JSON format ordered by recency (most recently started workflows last).”
   • [claimed-docs] “DBOSClient provides a programmatic way to interact with your DBOS application from external code or from another DBOS application.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.dbos.dev/openapi.json, https://docs.dbos.dev/swagger.json, https://docs.dbos.dev/api/op…”

   proof ↗⚑ flag

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

   weight 3 · round to DBOS
   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

   DBOS~partialcommunity6/10

   DBOS's core value proposition is that it's an open-source, Postgres-backed library with no proprietary orchestration server — all workflow/checkpoint state lives in the user's own Postgres database, which is inherently open and exportable via standard SQL tooling (dbos-docs-2, dbos-docs-20, dbos-docs-23, dbos-comm-13). The CLI can list workflows in JSON (dbos-docs-41), and Conductor (the hosted management layer) can also be self-hosted (dbos-docs-19, dbos-docs-34), reducing lock-in risk. However, there is no explicit documented 'export all your data' feature/guide, no migration tooling, and community comments note some hosted pieces (observability) were not self-hostable at points in time (dbos-comm-8), so full data portability for the managed/Cloud tier isn't concretely evidenced. Missing for 10: explicit data-export documentation/tooling, confirmation that Conductor/Cloud-hosted metadata is fully exportable, and independent verification of a clean 'leave' path from the hosted service.

   • [claimed-docs] “The open-source DBOS library uses Postgres to orchestrate durable workflows and queues. There's no separate orchestration server and no infr…”
   • [claimed-docs] “By contrast, DBOS is an open-source Postgres-backed library. To add DBOS to an application, you install the open-source library and annotate…”
   • [claimed-docs] “DBOS checkpoints those workflows and steps to a Postgres database. When failures occur, whether from crashes, interruptions, or restarts, DB…”
   • [claimed-docs] “List workflows run by your application in JSON format ordered by recency (most recently started workflows last).”
   • [claimed-docs] “There are many ways to self-host Conductor and the DBOS Console on your own infrastructure.”
   • [claimed-docs] “There are many ways to self-host Conductor and the DBOS Console on your own infrastructure... you can self-host Conductor and the DBOS Conso…”
   • [community] “User complaint: 'I was super interested in DBOS but I had to back out when I figured that the observability isn't self hostable yet,' though…”
   • [community] “DBOS co-founder explaining durability: 'DBOS wraps each function (step) to log its output in the database. This ensures that workflows can b…”

   proof ↗⚑ flag

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

   weight 2 · round to DBOS
   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

   DBOS~partialcommunity6/10

   DBOS's core library is explicitly described as open-source and its source is published on GitHub (dbos-transact-py), with docs repeatedly calling it an 'open-source Postgres-backed library' ([dbos-docs-2],[dbos-docs-20],[dbos-docs-35],[dbos-gh-1]). However, no evidence specifies the actual license type/terms, and community feedback notes the web UI/Conductor management console is NOT open-sourced ([dbos-comm-11]), limiting full openness to the core library only. Missing for 10: explicit license name/terms (e.g., MIT/Apache) citation, and confirmation that all product components (not just the core library) are open-source.

   • [claimed-docs] “The open-source DBOS library uses Postgres to orchestrate durable workflows and queues. There's no separate orchestration server and no infr…”
   • [claimed-docs] “By contrast, DBOS is an open-source Postgres-backed library. To add DBOS to an application, you install the open-source library and annotate…”
   • [claimed-docs] “The main difference is that Temporal implements durable workflows in a heavyweight orchestration service, whereas DBOS implements them in a …”
   • [github] “Instead of managing your own workflow orchestrator or task queue system, you can use DBOS to add durable workflows and queues to your progra…”
   • [community] “Comparison: 'I like dbos architecture much more than temporal since it is much easier to operate on small team. But dbos doesn't have openso…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   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

   DBOS✓fullcommunity8/10

   The core DBOS product is an open-source, Postgres-backed library with no separate orchestration server, so self-hosting is inherent — you just install the library and point it at your own Postgres instance (dbos-docs-2, dbos-docs-20, dbos-docs-35, dbos-gh-1). Docs also describe self-hosting the optional Conductor/DBOS Console on your own infrastructure via Docker Compose (dbos-docs-19, dbos-docs-34). Missing for 10: independent hands-on confirmation of self-hosted Conductor/observability working smoothly — community reports (dbos-comm-8, dbos-comm-11) note the web UI/observability layer historically wasn't open-source self-hostable, a caveat around the full platform even though the core library itself is trivially self-hostable.

   • [claimed-docs] “The open-source DBOS library uses Postgres to orchestrate durable workflows and queues. There's no separate orchestration server and no infr…”
   • [claimed-docs] “By contrast, DBOS is an open-source Postgres-backed library. To add DBOS to an application, you install the open-source library and annotate…”
   • [claimed-docs] “The main difference is that Temporal implements durable workflows in a heavyweight orchestration service, whereas DBOS implements them in a …”
   • [github] “Instead of managing your own workflow orchestrator or task queue system, you can use DBOS to add durable workflows and queues to your progra…”
   • [claimed-docs] “There are many ways to self-host Conductor and the DBOS Console on your own infrastructure.”
   • [claimed-docs] “There are many ways to self-host Conductor and the DBOS Console on your own infrastructure... you can self-host Conductor and the DBOS Conso…”
   • [community] “User complaint: 'I was super interested in DBOS but I had to back out when I figured that the observability isn't self hostable yet,' though…”
   • [community] “Comparison: 'I like dbos architecture much more than temporal since it is much easier to operate on small team. But dbos doesn't have openso…”

   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 DBOS
   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

   DBOS✓fullcommunity8/10

   DBOS's architecture is exactly this split: the DBOS library runs as workers inside the customer's own application/infrastructure, checkpointing all workflow state to the customer's own Postgres (code and data stay in-network) [dbos-docs-2, dbos-docs-4, dbos-docs-23], while DBOS Conductor is a separate control-plane service (vendor-hosted by default, but also self-hostable) that provides orchestration/observability, workflow management, and recovery routing via a dashboard, HTTP API, and dbosctl CLI [dbos-docs-16, dbos-docs-17, dbos-docs-18, dbos-docs-19, dbos-docs-31, dbos-docs-33, dbos-docs-34]. Community corroboration confirms the no-central-orchestrator, Postgres-in-your-infra execution model [dbos-comm-1, dbos-comm-14], though one user noted observability/self-hosting was initially incomplete before being added [dbos-comm-8]. Missing for 10: independent/hands-on verification that Conductor never touches actual business payload data (only orchestration metadata), and more detail on network/security boundaries between self-hosted workers and the vendor control plane.

   • [claimed-docs] “The open-source DBOS library uses Postgres to orchestrate durable workflows and queues. There's no separate orchestration server and no infr…”
   • [claimed-docs] “DBOS checkpoints the state of your workflows and steps to its system database. If your program crashes or is interrupted, DBOS uses this che…”
   • [claimed-docs] “From the Conductor dashboard, you can pause any workflow execution, start any stopped or enqueued workflow, or restart any workflow from a s…”
   • [claimed-docs] “Conductor's workflow, queue, and schedule management is available over an OpenAPI-described HTTP API and from the dbosctl command-line clien…”
   • [claimed-docs] “dbosctl login # log in through the device-authorization flow dbosctl whoami # confirm who y…”
   • [claimed-docs] “There are many ways to self-host Conductor and the DBOS Console on your own infrastructure.”
   • [claimed-docs] “Conductor automatically detects when a workflow is interrupted (for example, if its executor disconnects or crashes) and recovers the workfl…”
   • [claimed-docs] “dbosctl is a command-line client for the Conductor API. It manages workflows, queues, schedules, applications, and API keys against DBOS-man…”
   • [claimed-docs] “There are many ways to self-host Conductor and the DBOS Console on your own infrastructure... you can self-host Conductor and the DBOS Conso…”
   • [community] “DBOS co-founder: 'DBOS runs as a library inside your program... A state transition in DBOS requires only a database write (~1 ms) whereas in…”
   • [community] “Comparison to Temporal: DBOS core team noted 'the biggest difference is that DBOS doesn't require a centralized workflow server, but does al…”
   • [community] “User complaint: 'I was super interested in DBOS but I had to back out when I figured that the observability isn't self hostable yet,' though…”

   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
   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

   DBOS~partialcommunity5/10

   DBOS queues explicitly provide 'managed concurrency' and 'flow control' to cap how many workflows run at once or how often they start, which covers per-workflow/queue concurrency and rate limiting (dbos-docs-6, dbos-docs-26). However, there is no evidence of first-class per-key or per-tenant rate-limit/concurrency scoping (e.g., a tenant-id dimension), and a community critique raises unresolved concerns about coordinating rate limits globally across workers (dbos-comm-6). Missing for 10: documented per-tenant/per-key limiting semantics, worked examples of multi-tenant fairness, and independent verification that limits hold under contention.

   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide _flow control_, letting you manage how many workfl…”
   • [community] “Hatchet co-founder critique: 'Durable execution engines deployed as an external orchestrator will always be slower... but the 1ms delay vers…”

   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
   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

   DBOS—none0/10

   DBOS documents queues with concurrency limits and flow control (rate limiting, max concurrent workflows) but the evidence pack contains no mention of assigning priorities to individual runs or fair-share scheduling across tenants — only global concurrency/rate controls are described.

   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide _flow control_, letting you manage how many workfl…”

   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 drawn
   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

   DBOS~partialcommunity6/10

   DBOS's queues provide managed concurrency/flow control across many workflows (dbos-docs-6/26), and Conductor explicitly detects when a workflow's executor disconnects or crashes and recovers it onto another healthy executor (dbos-docs-31), which directly supports fleet-wide load-balancing and worker-loss tolerance. However, community critique raises concerns about worker contention using FOR UPDATE SKIP LOCKED and potential Postgres bottlenecks at scale (dbos-comm-6, dbos-comm-7), suggesting real-world scaling limits are not fully proven. Missing for 10: independent benchmarks or case studies showing throughput actually scaling linearly with added workers, and resolution/rebuttal of the contention/lock-based scaling concerns.

   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide _flow control_, letting you manage how many workfl…”
   • [claimed-docs] “Conductor automatically detects when a workflow is interrupted (for example, if its executor disconnects or crashes) and recovers the workfl…”
   • [community] “Hatchet co-founder critique: 'Durable execution engines deployed as an external orchestrator will always be slower... but the 1ms delay vers…”
   • [community] “Skeptical comment: 'If the step takes a long time, it'll keep the transaction open with it for that time... As your scale grows, you'll see …”

   proof ↗⚑ flag

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

   weight 2 · round to Hatchet
   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

   DBOS—none0/10

   DBOS is Postgres-backed and self-hostable, meaning users could theoretically control data location by choosing their own Postgres deployment region, but no evidence pack item mentions region selection, data residency controls, or compliance features for DBOS Cloud/Conductor hosting.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Hatchet
   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

   DBOS—none0/10

   DBOS is a durable-execution/workflow library storing checkpoints in Postgres, but the evidence pack contains no documentation of data retention policies, TTL/expiry settings, or user-facing deletion/erasure controls for workflow state or checkpoints. No mention of GDPR-style deletion, retention configuration, or data lifecycle management is present. Missing for 10: retention/TTL configuration docs, deletion/erasure APIs or commands, data lifecycle policy documentation.

   ⚑ flag

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

   weight 2 · round drawn
   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

   DBOS—none0/10

   No evidence pack item mentions telemetry, usage data collection, analytics, or any opt-out/opt-in privacy control for DBOS; this is an applicable axis for a developer library/platform but no documentation or community evidence addresses it.

   ⚑ 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 DBOS
   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

   DBOS~partialcommunity6/10

   DBOS's checkpointing and @DBOS.Transaction step semantics deliver exactly-once step execution and automatic recovery, and a co-founder explicitly states transactions provide exactly-once execution (dbos-comm-2, dbos-docs-4/23/25). However, the evidence never explicitly documents an 'idempotency key' API for deduplicating external triggers (e.g., webhook/payment retries), and community discussion notes durability is bounded by Postgres's own replication guarantees (dbos-comm-3), a real caveat for exactly-once claims under failure. missing for 10: explicit idempotency-key API/documentation for deduping external triggers, and stronger evidence addressing the sync-replication durability caveat.

   • [claimed-docs] “DBOS checkpoints the state of your workflows and steps to its system database. If your program crashes or is interrupted, DBOS uses this che…”
   • [claimed-docs] “DBOS checkpoints those workflows and steps to a Postgres database. When failures occur, whether from crashes, interruptions, or restarts, DB…”
   • [claimed-docs] “If a workflow is interrupted for any reason, DBOS automatically recovers its execution from the last completed step.”
   • [community] “User: 'Maybe I'm not seeing it, but why do none of these postgres durable packages ever integrate with existing transactions?' DBOS responde…”
   • [community] “Critique: 'If Postgres deployments have synchronous replication turned off... pg could journal the step, formally acknowledge it, and then t…”
   • [community] “DBOS co-founder explaining durability: 'DBOS wraps each function (step) to log its output in the database. This ensures that workflows can b…”

   proof ↗⚑ 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 DBOS
   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

   DBOS✓fullclaimed8/10

   DBOS docs explicitly describe workflows waiting hours-to-days for human input via DBOS.recv(timeout_seconds=...) surviving process restarts and server upgrades, backed by Postgres checkpointing rather than any held server/connection (dbos-docs-12, dbos-docs-28, dbos-docs-39, dbos-docs-2, dbos-docs-4). The architecture is confirmed as a library with no dedicated orchestration server, only Postgres, so a sleeping workflow consumes no compute (dbos-docs-2, dbos-docs-20, dbos-docs-35). missing for 10: explicit mention of multi-month sleep durations (only 'hours or days' is documented), and independent/third-party confirmation of zero billable compute during long sleeps.

   • [claimed-docs] “a human might take hours or days to respond to an agent, so the agent must be able to reliably wait for a long time (during which the server…”
   • [claimed-docs] “you can add a line of code to your agent that tells it to wait hours or days for a notification: approval: Optional[HumanResponseRequest] = …”
   • [claimed-docs] “We'll see how to build agents that can wait hours or days for human input to arrive (surviving process restarts). We'll also see how to use …”
   • [claimed-docs] “The open-source DBOS library uses Postgres to orchestrate durable workflows and queues. There's no separate orchestration server and no infr…”
   • [claimed-docs] “DBOS checkpoints the state of your workflows and steps to its system database. If your program crashes or is interrupted, DBOS uses this che…”
   • [claimed-docs] “DBOS checkpoints those workflows and steps to a Postgres database. When failures occur, whether from crashes, interruptions, or restarts, DB…”
   • [claimed-docs] “By contrast, DBOS is an open-source Postgres-backed library. To add DBOS to an application, you install the open-source library and annotate…”

   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 DBOS
   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

   DBOS✓fullcommunity9/10

   DBOS's core architecture is built around checkpointing every workflow step to Postgres and automatically resuming from the last completed step after a crash, restart, or deploy, documented extensively (dbos-docs-3,4,23,25,31) and explained by co-founders on HN (dbos-comm-1,13,14). Community testimony corroborates real-world use of this durability model at scale (dbos-comm-9,15), with one nuanced caveat that guarantees depend on Postgres's own replication durability settings (dbos-comm-3), which is a configuration caveat rather than a contradiction of the core recovery mechanism. Missing for 10: independent third-party benchmark or incident report specifically validating crash-recovery behavior in production beyond vendor/community anecdote.

   • [claimed-docs] “At any point, crash the app. Then, restart it with `python3 main.py` and watch it seamlessly recover from where it left off.”
   • [claimed-docs] “DBOS checkpoints the state of your workflows and steps to its system database. If your program crashes or is interrupted, DBOS uses this che…”
   • [claimed-docs] “DBOS checkpoints those workflows and steps to a Postgres database. When failures occur, whether from crashes, interruptions, or restarts, DB…”
   • [claimed-docs] “If a workflow is interrupted for any reason, DBOS automatically recovers its execution from the last completed step.”
   • [claimed-docs] “Conductor automatically detects when a workflow is interrupted (for example, if its executor disconnects or crashes) and recovers the workfl…”
   • [community] “DBOS co-founder: 'DBOS runs as a library inside your program... A state transition in DBOS requires only a database write (~1 ms) whereas in…”
   • [community] “DBOS co-founder explaining durability: 'DBOS wraps each function (step) to log its output in the database. This ensures that workflows can b…”
   • [community] “Comparison to Temporal: DBOS core team noted 'the biggest difference is that DBOS doesn't require a centralized workflow server, but does al…”
   • [community] “Critique: 'If Postgres deployments have synchronous replication turned off... pg could journal the step, formally acknowledge it, and then t…”
   • [community] “Happy user: 'We are a happy user of DBOS. I've been building out a lightweight TUI for managing our DBOS application internally, since we ha…”

   proof ↗⚑ flag

Retries

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

   weight 3 · round to Hatchet
   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

   DBOS~partialclaimed5/10

   DBOS's checkpointing and automatic workflow/step recovery (dbos-docs-4, dbos-docs-25, dbos-docs-23, dbos-docs-38) means failures are handled without manual try/catch scaffolding, and dbos-docs-30 mentions surviving 'transient API failures.' However, the evidence pack never documents configurable per-step retry counts, backoff strategies, or timeout policies (e.g., a retries_allowed/backoff/interval API), which the story explicitly asks for. Missing for 10: documentation of configurable retry counts, backoff intervals, and per-step timeout/failure policy settings, plus independent confirmation that this granular retry config works as advertised.

   • [claimed-docs] “DBOS checkpoints the state of your workflows and steps to its system database. If your program crashes or is interrupted, DBOS uses this che…”
   • [claimed-docs] “DBOS checkpoints those workflows and steps to a Postgres database. When failures occur, whether from crashes, interruptions, or restarts, DB…”
   • [claimed-docs] “If a workflow is interrupted for any reason, DBOS automatically recovers its execution from the last completed step.”
   • [claimed-docs] “You can use DBOS to add durable execution to an agent built with the OpenAI Agents SDK... you can build reliable agents that preserve progre…”
   • [claimed-docs] “If your process crashes mid-agent, DBOS replays the completed steps from their checkpoints and the agent resumes exactly where it left off.”

   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
   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

   DBOS~partialcommunity6/10

   DBOS supports queue-based fan-out (many workflows run concurrently with managed flow control), cron-scheduled workflows, external triggering via DBOSClient/HTTP endpoints, and community evidence of a Kafka-consumer pipeline processing events exactly-once — covering the 'trigger from queues/events, fan out to many functions' pattern. However, there's no explicit declarative webhook/event-trigger decorator shown (e.g., an @DBOS.webhook or built-in Kafka trigger annotation), and fan-out is implemented via manual queue.enqueue calls rather than a single declarative trigger-to-many mapping. Missing for 10: explicit declarative webhook trigger primitive, native queue/broker trigger decorators (e.g. Kafka consumer decorator), and independent hands-on confirmation of fan-out from a single event.

   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide _flow control_, letting you manage how many workfl…”
   • [claimed-docs] “You can schedule DBOS workflows to run on a cron schedule. Schedules are stored in the database and can be created, paused, resumed, and del…”
   • [claimed-docs] “DBOSClient provides a programmatic way to interact with your DBOS application from external code or from another DBOS application.”
   • [community] “User use case: a Kafka-consumer customer used DBOS to build an event processing pipeline that ran exactly-once per Kafka message, avoiding t…”
   • [claimed-docs] “pip install dbos 'fastapi[standard]'dbos init --template dbos-app-starter”

   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 to Hatchet
   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

   DBOS~partialclaimed3/10

   DBOS queues provide 'flow control' letting you limit how many workflows run at once or how often they are started, which can throttle bursty event streams, but there is no documented debounce, dedup, or batching primitive that collapses multiple noisy triggers into a single run. Scheduled workflows (cron) and pub/sub messaging (send/recv) address timing and signaling, not trigger coalescing. Missing for 10: explicit debounce/coalesce API, batch-trigger aggregation, or dedup-by-key mechanism, and any hands-on evidence of collapsing noisy streams into one run.

   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide _flow control_, letting you manage how many workfl…”
   • [claimed-docs] “You can schedule DBOS workflows to run on a cron schedule. Schedules are stored in the database and can be created, paused, resumed, and del…”
   • [claimed-docs] “You can call `DBOS.send()` to send a message to a workflow. Messages can optionally be associated with a topic and are queued on the receive…”

   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 DBOS
   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

   DBOS~partialclaimed6/10

   DBOS documents cron-based scheduled workflows stored in the database that can be created, paused, resumed, and deleted at runtime, and Conductor adds pause/restart/fork controls plus schedule inspection via dashboard, API, and dbosctl CLI. However, there's no explicit mention of overlap policies (e.g., skip/allow-overlap behavior for cron runs) or a dedicated 'upcoming runs' forecast view — visibility is framed around workflow/queue/schedule management rather than a forward-looking schedule calendar. missing for 10: explicit overlap-policy configuration for cron schedules, dedicated upcoming-run preview/forecast UI, independent hands-on confirmation of pause/resume behavior in practice.

   • [claimed-docs] “You can schedule DBOS workflows to run on a cron schedule. Schedules are stored in the database and can be created, paused, resumed, and del…”
   • [claimed-docs] “From the Conductor dashboard, you can pause any workflow execution, start any stopped or enqueued workflow, or restart any workflow from a s…”
   • [claimed-docs] “Conductor's workflow, queue, and schedule management is available over an OpenAPI-described HTTP API and from the dbosctl command-line clien…”
   • [claimed-docs] “register applications with Conductor and tune their settings, search workflows, cancel or fork them, inspect queues and schedules, drive sch…”
   • [claimed-docs] “dbosctl is a command-line client for the Conductor API. It manages workflows, queues, schedules, applications, and API keys against DBOS-man…”

   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 DBOS
   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

   DBOS✓fullclaimed7/10

   DBOS docs explicitly describe versioning and patching as supported strategies for safely upgrading workflow code, and Conductor's console lets you 'version' and 'fork' workflows, directly addressing deploying new code while in-flight workflows continue on their original version. Missing for 10: independent/hands-on confirmation that in-flight runs deterministically finish on the original code version after a deploy, and more detail on how version pinning is enforced at runtime.

   • [claimed-docs] “DBOS supports two strategies for safely upgrading workflow code: patching and versioning.”
   • [claimed-docs] “Manage with Conductor: Monitor, version, fork, replay, and observe durable workflows with DBOS Conductor console.”
   • [claimed-docs] “DBOS checkpoints the state of your workflows and steps to its system database. If your program crashes or is interrupted, DBOS uses this che…”
   • [claimed-docs] “From the Conductor dashboard, you can pause any workflow execution, start any stopped or enqueued workflow, or restart any workflow from a s…”

   proof ↗⚑ 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 DBOS
   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

   DBOS✓fullcommunity9/10

   DBOS workflows are written as ordinary Python/TypeScript functions with annotations, not YAML/DSL, and steps are automatically checkpointed to Postgres for durable recovery, confirmed by docs and community reports of ergonomic, low-code integration. missing for 10: independent third-party benchmark/audit of checkpointing correctness beyond vendor/community anecdotes, and broader language coverage evidence (only Python/TS confirmed).

   • [claimed-docs] “DBOS is a library for building reliable programs. Add a few annotations to your application to durably execute it and make it resilient to a…”
   • [claimed-docs] “At any point, crash the app. Then, restart it with `python3 main.py` and watch it seamlessly recover from where it left off.”
   • [claimed-docs] “DBOS checkpoints the state of your workflows and steps to its system database. If your program crashes or is interrupted, DBOS uses this che…”
   • [claimed-docs] “Because DBOS workflows, steps, and transactions are ordinary Python functions, you can unit test them using any Python testing framework, li…”
   • [claimed-docs] “By contrast, DBOS is an open-source Postgres-backed library. To add DBOS to an application, you install the open-source library and annotate…”
   • [github] “Instead of managing your own workflow orchestrator or task queue system, you can use DBOS to add durable workflows and queues to your progra…”
   • [community] “Praise: 'I built a small side thing using DBOS (using python SDK) and the ergonomics were pretty nice.'”
   • [community] “DBOS co-founder explaining durability: 'DBOS wraps each function (step) to log its output in the database. This ensures that workflows can b…”

   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 DBOS
   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

   DBOS~partialclaimed6/10

   DBOS docs show the building blocks for this pattern — DBOS.start_workflow to launch child/background workflows and get a handle to wait on results (fan-in), and Queues for running many workflows concurrently with managed concurrency (fan-out over batches) — all without a separate orchestrator, per dbos-docs-5, dbos-docs-6, dbos-docs-26. However, the evidence never explicitly documents parallel-step composition, a dedicated child-workflow API/pattern, or dynamic-batch fan-out/fan-in as a named recipe. missing for 10: explicit child-workflow documentation/pattern, explicit parallel-steps-within-a-workflow guidance, and a concrete fan-out/fan-in-over-dynamic-batches tutorial or example.

   • [claimed-docs] “You can use DBOS.start_workflow to start a workflow in the background. If you start a workflow this way, it returns a workflow handle, from …”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide _flow control_, letting you manage how many workfl…”
   • [claimed-docs] “You can send messages to a specific workflow. This is useful for signaling a workflow or sending notifications to it while it's running.”
   • [claimed-docs] “You can call `DBOS.send()` to send a message to a workflow. Messages can optionally be associated with a topic and are queued on the receive…”

   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 to Hatchet
   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

   DBOS~partialcommunity5/10

   DBOS ships and documents both a Python SDK (dbos-transact-py, extensive Python tutorials) and a TypeScript SDK, and its docs show consistent workflow/queue/schedule/communication primitives across at least those two languages, suggesting some cross-language design consistency. However, a community comment explicitly states 'Languages that are supported: Typescript and Python' with no Go or .NET support, directly contradicting the story's expectation of Go (or broader) language coverage, and no evidence documents explicit feature-parity guarantees between the SDKs. missing for 10: Go/other language SDKs, explicit cross-SDK feature-parity documentation, independent confirmation of parity between TS and Python APIs.

   • [github] “Instead of managing your own workflow orchestrator or task queue system, you can use DBOS to add durable workflows and queues to your progra…”
   • [claimed-docs] “You can use DBOS.start_workflow to start a workflow in the background. If you start a workflow this way, it returns a workflow handle, from …”
   • [claimed-docs] “You can use queues to run many workflows at once with managed concurrency. Queues provide flow control, letting you manage how many workflow…”
   • [claimed-docs] “You can schedule DBOS workflows to run on a cron schedule. Schedules are stored in the database and can be created, paused, resumed, and del…”
   • [claimed-docs] “You can send messages to a specific workflow. This is useful for signaling a workflow or sending notifications to it while it's running.”
   • [community] “Complaint: 'Bit disappointed, looked for .net core support but no. Languages that are supported: Typescript and Python.'”

   proof ↗⚑ flag