Actually, I’m curious to hear your (and @zblanco) thoughts about using DAG since you guys are already exploring a solution for this type of workflow. Do you share the same perception around limiting factors of DAGs?
lostbean
mikehostetler
The major issue so far is the limitation of acyclic topologies
Yep, this is one of the challenges. When expand this out to a multi-process architecture it begins to look a lot more like distributed event sourcing.
There’s a constant tension between having a human design the system/workflow and letting the LLM choose it’s own adventure via tool calling.
Less LLM’s produces more reliable outcomes - More LLM’s produces less reliable outcomes but more serendipity and value.
I really think as developers we should have all of these tools at our disposal - with an easy way to integrate them.
I think Elixir really has an opportunity to shine here. I have some early ideas - but the community needs to talk about this a lot more. It’s a new sub-category of orchestration that needs grounded in the real world.
Thankfully there’s a lot of “Agent Frameworks” and Examples popping up on the web to look at.
I personally found it pretty hilarious that all of OpenAI’s background agents use a durable workflow system like Temporal - which means they haven’t solved this either despite headlines to the contrary.
2
MrDoops
The solution in Runic (despite being a DAG) for stateful expressions is to evaluate in a loop by taking outputs of the workflow and feeding them back in for further reactions. The DAG’s constraints of avoiding loops in the dataflow edges mean you have a guarantee of the computation ending once you evaluate to the leaf nodes. This is especially useful for lazy evaluation and avoiding assumptions of how the actual tasks are executed at runtime and why DAGs are common in compute scheduling problems.
There are also stateful components that can be added to workflows who accumulate across evaluations or reduce many facts into one.
e.g.
state_machine =
Runic.state_machine(
name: "transitional_factor",
init: 0,
reducer: fn
num, state when is_integer(num) and state >= 0 and state < 10 -> state + num * 1
num, state when is_integer(num) and state >= 10 and state < 20 -> state + num * 2
num, state when is_integer(num) and state >= 20 and state < 30 -> state + num * 3
_num, state -> state
end
)
|> Runic.transmute()
# or for a map/reduce
reduce_example =
Runic.workflow(
name: "reduce test",
steps: [
{Runic.step(fn num -> Enum.map(0..3, &(&1 + num)) end),
[
{Runic.map(fn num -> num * 2 end),
[
Runic.reduce([], fn num, acc -> [num | acc] end)
]}
]}
]
)
Here’s a couple notebooks I made recently:
Most of the agents we’re seeing so far are a conversation loop of messages (role + content) and tool calling and/or some RAG.
Where I see workflows/dags come into play are when you want a dynamically composed program (generated by an agent such as chains of tools tool calls) that you want to execute deterministically and manage the concurrency.
Or by orchestrating many agents, LLM calls, structured extraction steps, etc into something useful like in the first notebook.
Likewise there is no reason your conversation loop couldn’t be expressed in a workflow using a reduce + rules or a statemachine component but I’d recommend using Runic for only the dynamic composition use cases or where the data flow parallelism is needed.
3
lostbean
Hey @MrDoops, thanks for sharing how Runic would handle this type of flow. The livebooks were very helpful to start exploring how you’re approaching this. After playing around a little bit, I’ve got some feedback and a bunch of questions. And I’m still trying to form a solid mental model, especially around rules, state machines.
Another question is regarding the current and future state of the project. I see it not yet published on Hex, and this functionality is not available on main. How do you see Runic moving forward? I’m considering it to be eventually used in a production environment.
I don’t want to hijack the thread, so maybe we can create a new one or move to a new environment (GH issues or similar)?
2
MrDoops
I’m working on a 0.1.0 release for Runic. Current effort is around supporting long running durable workflows with stream/log persistence semantics and ironing out named component APIs.
I can probably merge latest in the meantime. Feel free to open a discussion on GH or dm me on the Elixir Slack @zblanco if you want to discuss.
3
lostbean
Thanks @MrDoops! I’ll reach out to you.
In the meantime, I’m making a PR to add some level of recursion to Reactor (improvement: add support for recursive sub-reactors by lostbean · Pull Request #215 · ash-project/reactor · GitHub). Not as flexible as Runic, but this could unblock another set of AI workflows to use Reactor.
2
alexandre
How do you ensure security? Does it have a proper container? Otherwise, I believe it’s impossible to prevent leaking prod secrets.
Can’t find those answers in code/docs.
0
mikehostetler
Current Jido core puts the tools into a developers hands to implement whatever flavor of security is needed for their project.
I have seen projects that implement all sorts of approaches with Jido. I put a security guide on my TODO list to showcase this better.
2
byu
@mikehostetler : Congrats on Jido 2.0. 
I see Jido’s start_agent/3 , stop_agent/2, and InstanceManager use local node DynamicSupervisor and Registry functionality.
Are there any directions for, or plans to support, cluster-wide process distribution with something like process_hub or horde? Or are Jido instances intended to be single-node only?
Example use-case: A coordinator agent that then instantiates individual worker agents – Parent-Child agent hierarchies guide– MyApp.Orders.OrderWorkerAgent for each order (“order-123”, “order-234”, etc). There should only be one agent for any given order in the cluster?
1
mikehostetler
TigerBeetle’s approach of building mini-games to demonstrate their favorite features inspires me.
I dream of a Jido demo orchestrating agents across a worldwide system where we can kill machines and “cut” connections and the systems absorbs and thrives under these conditions.
Agent durability? Yes
Agents handling network topology changes? Absolutely
Agents merging conflicts on network healing? So cool
So yes, it’s still mostly a dream - but that’s where this is going.
I started some code here - but it’s VERY early
2