• Hacker News
  • new|
  • comments|
  • show|
  • ask|
  • jobs|
  • lubosPetorvic 9 hours

    [dead]

  • frank_clover 1 hours

    [dead]

  • ethan1998 5 hours

    [dead]

  • JustFinishedBSG 1 hours

    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}` },
          );
    
    ( simplified code ) in my implementation and `unroll` is only there to have a nice

          ● Plan r1 · 1/3 · active
           1. Inspect parser behavior
          ● 2. Add empty-input coverage
          ○ 3. Run focused checks
    
    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)

    dummydummy1234 11 minutes

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

    JustFinishedBSG 45 seconds

    Only state I keep is filesystem and last message (but even that is persisted in the filesystem). Each agent gets its own btrfs volume, when it’s done the “next” agent get the previous agent work mounted in its own filesystem ( and told about it ). Agent is also able to “promote” files if it wants and they are mounted in a more prominent place.

    I don’t know yet if it’s a good solution. But only thinking in terms of files / filesystem sure make things easier.

    Also makes branching “easier”: no handling of merging or conflicts, the receiving agent just gets N file systems and decides how to handle things.