Graph workflows are useless if there are edges without cost or effor attribues and termination states without reward. Such workflow can be vibecoded in one-shot anyone who knows about graphs.

I thought some time ago about expressing SDLC as combination of harness tools, finite state machines with weights (efforts) on edges and rewards on some states. The goal - model queue of tasks as sub-workflows and implement the most valuable. I tried to design approach which will allow to maximize reward with minimal costs and risks via Markov Decision Process. Hypotetically i can implement it. But it all ends up being really hard to wrap your head around because of the state machines, custom runtime for scripts, the agent loop control, supervisor's control mechanisms. Then you have to tune the weighting models. The model can be similar to models from reinforcement learing. Even if I pull it off, I'd have to be damn lucky for even one other person to figure it out. And the project will have from 3 to 5 stars on GitHub because almost nobody will understand what is it and how to use.

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

¡Wepa Miguel! ¡Felicidades y mucho éxito con el release!

Congratulations, and wishing you the best with this release!