Every team reaches the same point. You have a script that runs on a schedule. Then it needs to run after another script. Then one step needs retrying when an API is flaky.
Then you need to know when it failed, and when it failed at three in the morning you need to know which step and why, and you need to re-run just that part. At some point the cron entry and the try-except block stop being adequate and you need orchestration. The question is how much machinery you take on to get it, and this framework's answer is refreshingly little. The core ergonomics are the selling point.
You decorate a function as a task and a function as a flow, and your existing Python is now orchestrated. No separate definition file, no domain-specific language, no rewriting your logic into a framework's shape. For a team whose work already exists as Python scripts, the migration path is close to trivial, and the documentation demonstrates this honestly rather than overselling it. The dynamic control flow is the genuine technical differentiator and the documentation explains it well.
Many orchestrators require you to declare the shape of your workflow before it runs, which means loops with a number of iterations you do not know yet, or branches that depend on data you have not fetched, require awkward workarounds. Here the workflow is just Python that executes, so a loop over whatever the first task returned is a loop. If your pipelines have data-dependent structure, this is a substantial practical advantage and the docs make the case clearly. The reliability features are done properly and this is where the value actually shows up.
Retries with configurable backoff, caching so a re-run skips work whose inputs have not changed, timeouts, state handlers and notification integrations. These are the things you would otherwise write badly yourself, and having them as decorator arguments rather than infrastructure is the right level of abstraction. The caching in particular saves real time and money on expensive steps and the documentation covers cache key design sensibly. The hosted free tier is a good decision for evaluation.
You can run flows locally and see them appear in a proper interface with run history, logs and state, without deploying anything. That removes the usual barrier where evaluating an orchestrator requires standing up an orchestrator, and it means you can form a real opinion in an afternoon. Now the problems. The version history is the first thing anyone should be warned about.
There have been major releases with substantial API changes, and the internet is consequently full of tutorials, forum answers and blog posts using patterns that no longer exist or now mean something different. The official documentation is current and clear about which version it describes. Everything outside it is a minefield, and a beginner following a well-written article from a couple of years ago will hit errors they cannot diagnose because they do not yet know that the API changed underneath them. Check the version on anything you find.
The deployment model is the conceptually hardest part and I do not think the documentation has cracked explaining it. Flows are easy. Then you want them to run on a schedule, somewhere other than your laptop, and you meet deployments, work pools, workers and infrastructure blocks. These concepts are individually reasonable and collectively form a mental model that takes real effort to assemble, and the documentation explains each piece competently without ever quite drawing the whole picture in one place.
This is the step where evaluations stall, and it deserves a better conceptual overview than it has. The self-hosted story is real and second class. You can run the server yourself and the documentation covers it, and the depth, the examples and the operational guidance are visibly thinner than for the hosted product. That is a commercially rational choice and it is worth knowing if self-hosting is a requirement rather than a preference, because you will be on a quieter path than the documentation's confidence suggests.
The missing honesty, common to every tool in this category, is about when you do not need it. A daily job that runs one script and emails on failure does not need an orchestration platform, and adopting one adds a control plane, a dependency and an operational surface for very little. The threshold where this pays off is somewhere around several interdependent workflows with real failure handling requirements, and no vendor documentation will ever tell you that you are below it. My three point seven is for genuinely low-friction orchestration, dynamic workflows that solve a real limitation of the alternatives, reliability features implemented properly, and an evaluation path that costs nothing.
Marked down for a version history that has poisoned the external material, for a deployment model explained in pieces rather than as a whole, and for a self-hosted path that lags. A good tool, well documented, with one significant conceptual gap.