I'll study it as I am toying with "what should a workflow definition language look like".
My current vision, and prototype, is that it should be as close as possible to a "real" language as possible so that both the user and the agent know immediately how to use it and how it functions.
So for `pi` it means using typescript.
Then the UI is derived from the AST / code as much as possible and for things that aren't neatly possible like that I eventually add small semantic helpers that define the UI.
I'll study it as I am toying with "what should a workflow definition language look like".
My current vision, and prototype, is that it should be as close as possible to a "real" language as possible so that both the user and the agent know immediately how to use it and how it functions.
So for `pi` it means using typescript.
Then the UI is derived from the AST / code as much as possible and for things that aren't neatly possible like that I eventually add small semantic helpers that define the UI.
For example "plan -> execute" is:
( simplified code ) in my implementation and `unroll` is only there to have a nice UI instead of a plain "Plan · 1/3" UI with no detail (which would happen if I just used a for loop, yes it works)