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:

      await flow.unroll(
      remaining.map(point => ({
          key: point.id,
          label: point.objective,
      })),
      async () => {
          for (const point of remaining) {
          await flow.item(point.id, async () =>
              await flow.agent(executePoint, {
              title: `Point ${point.id}`,
              prompt: point.objective,
              }));
          }
      },
      { title: `Plan r${planRevision}` },
      );

      ● Plan r1 · 1/3 · active
       1. Inspect parser behavior
      ● 2. Add empty-input coverage
      ○ 3. Run focused checks

How are you thinking about state management when you handle things? I have been playing around this and the state gets messy fast.