Type-safe code. Workflows are not configuration! If I wanted YAML hell I could stick to Github Actions.

But that's only the start. There are a lot of other things I would expect of a new workflow orchestrator in 2026 so if you are not comparing yourself to the competition you probably don't know what you're getting yourself into.

▲

afshinmeh 3 hours ago | parent [-]

Yeah, that makes sense. I looked at a few workflow orchestrators and I'm building something that I will release soon, but my thinking is that the "workflow engine" should be an abstraction that takes the input and executes the steps. "What" you use to define that workflow is probably the SDK layer though, but I can certainly see the value in using type safe code to define as opposed to a YAML file.

I'm mainly focusing on the portability aspect of it (e.g. use TS/Python/etc. to define the workflow/steps or just simple a simple YAML file).

▲

verdverm 2 hours ago | parent | next [-]

Are you planning to map those varied definitions onto varied orchestrators?

▲

afshinmeh 2 hours ago | parent [-]

Sort of. My thinking is that the input to define the workflow should be anything you prefer to use (TS, Go, YAML, etc.) and the orchestrator's job is to model that and execute the job, given your deployment model.

	▲	verdverm 23 minutes ago \| parent [-]
		There are a number of widely used orchestrators, it would be nice to deploy to one of those vs a new kid on the block

▲

esafak 3 hours ago | parent | prev [-]

[dead]