Alex Milowski argues that workflows are graphs of tasks that manipulate data, produce results, and trigger downstream work.
2
Layering workflows lets an organization separate technical model training and evaluation from the business process that decides whether a model reaches production.
3
Workflow tools are moving toward Python and annotations, but Alex Milowski says this can make workflows harder for non-programmers to understand and discuss.
Summary
Alex Milowski explains how workflow orchestration grew from business process systems and rule engines into the tools used for data engineering and MLOps. He describes workflows as graphs of tasks, while stressing that a technical workflow is often only one part of a larger organizational process. At Stitch Fix, a domain-specific language hid Airflow and batch execution from data scientists. In a later company, diagrams helped scientists, robots, and machine learning systems agree on laboratory procedures. Milowski's survey of 79 open-source workflow projects found separate communities for business process automation, scientific computing, data engineering, machine learning, and operations. He sees a current move from declarative workflow definitions toward Python code and annotations. This makes authoring compact, but it can turn the workflow into a black box for people who cannot read code. He also discusses agents as embedded or dynamic workflow engines, and argues that regulated organizations need human approval and traceable decisions when models move into production.
A workflow is a graph of tasks that produces results and triggers downstream work
Alex Milowski traces the modern idea of a workflow to rule-based expert systems and business process modeling. A workflow contains steps that manipulate data, produce results, or create side effects. When one task completes successfully, a downstream task is enabled. He describes the workflow as a graph rather than only a script or a filter. Business Process Model and Notation gives organizations a visual way to describe these processes, while technical workflow systems implement selected parts of them.
Laboratory automation showed why technical workflows sit inside larger human processes
At a previous company, Milowski worked with scientists, robots, and machine learning systems in the same laboratory process. A human might prepare a plate, a robot might handle it, and a machine learning step might process the resulting data. The team needed to record what happened before each automated task could begin. Diagrams helped people from different roles agree on the full process, even when only part of it became executable. Milowski calls this workflows inside workflows.
Workflow layers separate model operations from the business decision around the model
Milowski recommends viewing a model workflow as a smaller component inside an organizational workflow. The technical layer may train or evaluate a model and produce a score or other evidence. A larger process decides what to do with that result. Deployment might be automatic when criteria are met, or it might require a person to approve the next step. This layered view lets teams choose different workflow technologies for technical tasks and business processes while still connecting them.
A domain-specific language can hide orchestration complexity from its users
At Stitch Fix, more than 40 data scientists used workflows for research and recurring organizational tasks. The users wrote descriptions in a domain-specific language, while the system ran Airflow underneath and executed tasks on a batch system. They did not need to become experts in Airflow or deployment. The executor could retry a task with more memory after an out-of-memory failure and learn suitable parameters. Milowski presents this as an example of orchestration improving productivity by keeping infrastructure details out of the user's way.
Process engineering is difficult because practitioners do not naturally describe familiar work as a graph
Scientists often record laboratory work as operating procedures with nested instructions. They may not think in terms of tasks, dependencies, data inputs, controls, and failure states because they already know the equipment and the procedure. That detail becomes necessary when an organization wants to automate, scale, or measure the work. Milowski says teams need a clear reason to do the process engineering. Demonstrations and prototypes can show the value before an organization asks people to document everything.
Workflow projects are growing across several distinct technical communities
Milowski surveyed 79 open-source workflow systems and grouped them into areas such as business process automation, scientific computing, data engineering, machine learning, and operations. He says business process projects include some of the oldest repositories, while data science and machine learning projects became more prominent around 2015. He also found active development across the categories, although projects vary from personal experiments to commercial products. The result is a wide range of choices for teams looking for orchestration.
Python annotations make authoring easier while reducing the workflow's visibility to non-programmers
Milowski sees a current move away from separate workflow languages and toward Python code with annotations. This can be compact and elegant for technical users who are already writing PyTorch or other application code. The cost is that the workflow may only be understandable by reading or running the code. A separate declarative artifact can be parsed, stored, and turned into a diagram without recreating the execution environment. He does not reject code-based workflows, but says tools do not consistently provide those readable artifacts.
Human approval can make model release a traceable business process
Milowski describes a future in which technical workflows test models, assess risks, and produce evidence, while a business-level workflow controls release. A product manager or another decision-maker could approve a model after reviewing the results. The workflow would record who made the decision and which version was released. This matters when models are difficult to assess with a simple pass or fail, and when organizations need to explain their decisions during audits. Milowski connects this design to regulated environments and human-in-the-loop control.
