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.
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.
So this means that every node in the graph has to be a fully fledged agent runtime with the smarts to handle an arbitrary filesystem.
I guess there is some sort of tool call that the agent has to tell the runtime 'I am done, and I succeeded go to the success node in the parent state machine'
---
I think I have been trying to approach a slightly different problem where you have a mostly deterministic control flow of steps/ nodes in the graph, but individual nodes can be pretty stupid/ small models, so having a more constrained universe should be more reliable. (My intuition)
My example is a citation checker for an essay -
1. generate a list of claims in a paragraph,
For each claim:
Read the attached citation, validate that it backs up that claim.
The output is a nested json structure with a list of claims with a explanation+binary classification of whether each one is supported.
This is not really agentic, and the nodes would be claim identification > validate claims (in parallel) > deterministically merge the validated claims into a unified module.
It should be very token efficient, and since it is so constrained I think I can get away with tiny models, and small context.
At least that is my hope... But I think I need typed IO/state so that the llm that writes the graph can deterministically say that the individual nodes complete the problem wholly.
This matches how i think about realtime voice: keep call control deterministic,
and give model steps clear inputs and outputs.
How would you handle retries when a step fails ?
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.
Agree, it’s not the graph representation that’s valuable, it’s the attribution and business logic of the workflows themselves. The concrete values and weights that go into making these deterministic decisions.
This is just a custom workflow engine, but for sth like that you could have used any of the existing ones and given it to agents. Stuff like, Temporal, Erandril have a durable workflow solution build on pg only as well, or windmill/airflow depending on how you look at it. But without the nice ui given by these tools.
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)How are you thinking about state management when you handle things? I have been playing around this and the state gets messy fast.
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.
Ahh, OK
Thanks!
So this means that every node in the graph has to be a fully fledged agent runtime with the smarts to handle an arbitrary filesystem.
I guess there is some sort of tool call that the agent has to tell the runtime 'I am done, and I succeeded go to the success node in the parent state machine'
---
I think I have been trying to approach a slightly different problem where you have a mostly deterministic control flow of steps/ nodes in the graph, but individual nodes can be pretty stupid/ small models, so having a more constrained universe should be more reliable. (My intuition)
My example is a citation checker for an essay -
1. generate a list of claims in a paragraph, For each claim: Read the attached citation, validate that it backs up that claim.
The output is a nested json structure with a list of claims with a explanation+binary classification of whether each one is supported.
This is not really agentic, and the nodes would be claim identification > validate claims (in parallel) > deterministically merge the validated claims into a unified module.
It should be very token efficient, and since it is so constrained I think I can get away with tiny models, and small context.
At least that is my hope... But I think I need typed IO/state so that the llm that writes the graph can deterministically say that the individual nodes complete the problem wholly.
This matches how i think about realtime voice: keep call control deterministic, and give model steps clear inputs and outputs. How would you handle retries when a step fails ?
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.
Agree, it’s not the graph representation that’s valuable, it’s the attribution and business logic of the workflows themselves. The concrete values and weights that go into making these deterministic decisions.
This is just a custom workflow engine, but for sth like that you could have used any of the existing ones and given it to agents. Stuff like, Temporal, Erandril have a durable workflow solution build on pg only as well, or windmill/airflow depending on how you look at it. But without the nice ui given by these tools.
Interesting use of Jev-as-a-judge.
How do you deal with having to reason before judging a step?
¡Wepa Miguel! ¡Felicidades y mucho éxito con el release!
Congratulations, and wishing you the best with this release!
Interesting, I want to know more about the comparison test with running codes directly.
Consider hosting your use case article somewhere else (also)