<@UTC9JTKS8>, looking at your devoxx slides. i had...

# koog-agentic-framework

[Gabriel Duncan]

@Vadim Briliantov, looking at your devoxx slides. i had a question. you have the graph described this way

edge(nodeStart forwardTo identifyProblem)
edge(identifyProblem forwardTo fixProblem onCondition { problem -> !problem.resolved })
edge(identifyProblem forwardTo nodeFinish onCondition { it.resolved } transformed { it.emptyUpdate() })
edge(identifyProblem forwardTo fixProblem)
edge(fixProblem forwardTo verifySolution)
edge(verifySolution forwardTo nodeFinish onCondition { it.successful } transformed { it.input })
edge(verifySolution forwardTo adjust onCondition { !it.successful } transformed { it.feedback })
edge(adjust forwardTo verifySolution)

one thing that isn't clear to me is why identifyProblem goes to fixProblem both with and without a condition. if it forwards to fixProblem without a condition, doesn't that make the condition redundant?

[Gabriel Duncan]

also would be cool to see an example where you stream results and possibly publish stream updates to an event queue for consumers (just an idea).

[Vadim Briliantov]

Hi! identifyProblem goes to nodeFinish on condition, and goes to fixProblem otherwise (without a condition).
Usually you have to write conditions for all cases but because it starts checking them starting from the first one — I can drop the last condition because it essentially serves as “else”.

Hope it makes sense

[Vadim Briliantov]

As for the streaming example, I believe @Konstantin has one

[Gabriel Duncan]

just to be clear, you mean you CAN'T drop the last because the first two are condition based forwarding so you need an "else" path?

[Gabriel Duncan]

if that's the case i personally think a tweak to the API would be more obvious if it looked like a when statement for sealed interfaces.

something like

edge(someEdge when { result.x -> anotherEdge; result.y -> yetAnotherEdge; else -> terminalEdge })

just thinking out loud...

[Vadim Briliantov]

I mean that you can write:

edge(a forwardTo b onCondition { f(it) })
edge(a forwardTo c onCondition { !f(it) })

but you can also write:

edge(a forwardTo b onCondition { f(it) })
edge(a forwardTo c)

That is equivalent in practice.


It’s actually a hacky way because it abuses the internal implementation (every condition is being checked in the order they were defined for the current node “a”). But I wanted to save the screen space on my slides :)

[Vadim Briliantov]

We were considering to also add multi-choice conditions like in your “when” proposal. But for me it makes it harder to reason about from the business logic perspective.

[Gabriel Duncan]

is there an open discussion about that somewhere?

[Konstantin]

The streaming example is here
Checkout the repo and run the server. You may access web ui on github pages. There is also a strategy graph visualiser under the ❓menu

[Gabriel Duncan]

@Vadim Briliantov maybe i'm just being dumb but i'm still confused about your example

edge(identifyProblem forwardTo fixProblem onCondition { problem -> !problem.resolved })
edge(identifyProblem forwardTo nodeFinish onCondition { it.resolved } transformed { it.emptyUpdate() })
edge(identifyProblem forwardTo fixProblem)

wouldn't the same thing happen with

edge(identifyProblem forwardTo nodeFinish onCondition { it.resolved } transformed { it.emptyUpdate() })
edge(identifyProblem forwardTo fixProblem)

[Gabriel Duncan]

the only time you don't forward to fixProblem is when the problem is resolved in which case you go to the finish node.