The design philosophy here is unusual and worth understanding because it explains everything else about the project. Most workflow tools are built by infrastructure engineers and expose infrastructure concepts, which means the data scientist has to learn a new domain to use them. This was built inside an organisation with a large population of data scientists who needed to run substantial computations and who were not going to become infrastructure engineers, and the design goal was to let them keep writing Python and get scale anyway. Whether that is the right philosophy is arguable and it produces a genuinely distinctive tool.
The core abstraction is a flow class with steps as methods, connected by explicit transitions. You write ordinary Python. Data passes between steps as instance attributes, which sounds trivial and is actually the key insight, because those attributes are automatically persisted, versioned and made retrievable later. You do not write serialisation code.
You do not decide where artifacts live. It happens, and every run of every flow by every person is recoverable afterwards. The documentation explains this well and the payoff is larger than it first appears. Six months later, when someone asks what data went into the model you shipped in March, you can answer precisely rather than reconstructing it from memory and half-remembered notebook state.
The local to cloud transition is the headline feature and it holds up. You develop and run on your laptop with small data. You add a decorator specifying memory and CPU or GPU requirements to the steps that need it, and those steps execute on cloud compute while the rest still runs locally. You add a flag and the entire flow runs remotely.
The mental model does not change between those modes, which is genuinely rare, and it means the gap between exploration and production is much smaller than usual. Parallelism through the foreach construct is elegantly done. Fanning a step out over many inputs is a single call, each branch runs independently on its own resources, and a join step collects the results. Training thirty model variants in parallel is a few lines.
The documentation explains the pattern clearly and it is one of those abstractions that changes how you approach problems once you have it. Resume deserves particular mention because it saves real time. When step seven of a nine step pipeline fails after two hours, you fix the bug and resume from step seven using the artifacts already computed. Anyone who has re-run a long pipeline from the beginning because of a typo in the last step will understand immediately why this matters.
Now the honest limitations. The cloud setup is the wall and the documentation is too breezy about it. Running locally is trivially easy. Running on cloud compute requires configured infrastructure, roles and permissions, storage buckets, a metadata service, container job configuration.
There are templates and there is a managed offering from the company that maintains this, and none of that changes the fact that someone with cloud competence has to do a day or more of work before the decorators do anything. A data scientist reading the getting started material will not anticipate this, and the framing of the documentation, which is entirely about how simple it is, contributes to that surprise. The AWS bias is real. Support for other clouds exists and it is visibly less mature, with fewer examples and thinner documentation.
If you are on a different cloud you can make it work and you will be following a less trodden path than the marketing suggests. The positioning question is worth raising for teams. If your organisation already runs a general purpose orchestrator for data engineering, adding a second workflow system specifically for data science means two systems, two sets of operational knowledge, and arguments about which belongs where. The case for this tool is strongest where data scientists are underserved by existing infrastructure, and weakest where a competent platform already exists.
The documentation understandably does not discuss when not to adopt it. Production operation is thinner than development ergonomics. Scheduling, alerting on failure, monitoring long-running flows, managing dependencies between flows owned by different teams. These get coverage and it is noticeably less loving than the material on writing flows.
The tool is built for the develop and iterate loop and it shows in what the documentation chooses to explain well. My three point eight is for a genuinely thoughtful design aimed at the right audience, automatic versioning that pays off repeatedly, a local to cloud story nobody else matches this cleanly, and elegant parallelism. Marked down for understating the infrastructure prerequisite, for uneven cloud support, and for treating production operation as secondary. If you have a data science team and someone to do the plumbing, this is a very good choice.