Good idea, works really well for companies with "established" operations. However, the missing problem we've found (and are investing significant resources int

Good idea, works really well for companies with "established" operations. However, the missing problem we've found (and are investing significant resources internally to fix) is that, in a lot of situations (especially in a startup), you don't actually know what you're doing operationally at a detailed enough level to have engineers write code for, or even humans to "do". You're learning as you go, but still need everything in the database as you do so you can automate thing sooner rather than later. So, automation is still required. But not yet! You need a way for humans to do things, then automation, and back again...on a "flow" (to use your terminology) that is radically changing as you learn. In our case, new business opportunities require creating and/or updating tens of millions of rows in our Postgres database, but can start out very small as we learn—say, 5000 independent flows. Oftentimes, we need to temporarily "fix" things that we've already done a lot of work on—again, with a mix of human and compute tasks, depending on what's going on. Those fixes are temporary and we remove them once the data in Postgres is clean. Another major area is, for lack of a better term, "tech onboarding". There's a lot of work that's effectively one-off, needs to be done at scale, and yet each day it's something different. (Imaging ramping up some service over four weeks—a literal situation we encounter regularly.) Being able to mix human and automation there is again critical, but really no tooling that I'm aware of exists to help with. Anyway…congrats on the launch. I can definitely see it working for really well-defined operation systems that just need that extra touch of automation to reduce the busy work when humans are inserted into flows.