← Back to context

Comment by dummydummy1234

3 hours ago

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

2 comments

dummydummy1234

Reply
JustFinishedBSG  3 hours ago

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.

  • dummydummy1234  35 minutes ago

    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.