Great question - This whole space is evolving quickly and has been a fantastic mental challenge to shed my old habits of how these apps get built - so this is my current perspective.

The “use an LLM assistant to execute a tool” trend of late benefits one party - LLM API providers. I’ve read over a LOT of repo’s, and have played with a lot of toys.

That’s why this foundational repo has ZERO LLM or AI code in it. At this foundational layer, LLM tool calling as a first class citizen didn’t feel right.

Don’t get me wrong, I wrote this to integrate with LLM’s - but the Elixir way is to build with pure data structures and minimal dependencies on OTP. That’s the purpose of this package.

As a sneak peek - here’s a Jido Action which implements a call to Anthropic Claude using instructor_ex to fetch a “Chat Completion” - aka agent chatting: jido_ai/lib/jido_ai/anthropic.ex at main · agentjido/jido_ai · GitHub

Agents as GenServers is implemented and tested. I’m not entirely happy with the API yet so I didn’t include it in this official release. They each spin up a DynamicSupervisor and can manage delegating tasks to other agents, starting and stopping Signals and doing all sorts of other cool things.

I see a future where we each have thousands of Agents working for us constantly - like a swarm of ants. No other framework or platform comes close to making this happen - so I started from first principles with Elixir.

Enjoy!

EDIT: There will be many examples coming soon to demonstrate the scope of what Agents with Jido are capable of.

Correct - the foundational library can be used without LLM’s. During planning, I felt it was important to simplify down to the base data structures and interaction patterns - get those correct - and then build LLM interaction patterns on top of that.

You can see an initial implementation of a Jido.Action that calls an LLM in the jido_ai package here: https://github.com/agentjido/jido_ai/blob/main/lib/examples/politician.ex

This example uses instructor_ex - but langchain or any other Elixir AI package could easily be integrated for an LLM response.

Yes, exactly - or even Broadway. This problem space of data transformation pipelines has a lot of solutions.

Each solution has it’s strengths. I love and have used each of these tools many times.

Jido won’t be the best at raw throughput as it does not use GenStage - like Broadway or Flow. Jido does not assume a database, if you need a database backed Job Processing system, you should use Oban.

Jido is aimed at the space where a particular agent (or queue?) is built to facilitate a wide variety of output - because a LLM is typically involved. Low throughput, high variety.

Where the Agent space gets crazy-weird is when you let the LLM pick the next action. It’s not random … but it’s not idempotent either. Jido agents natively support a list of “allowed” actions (https://hexdocs.pm/jido/agents.html#creating-your-first-agent) for this reason - it provides a small level of control over this use case.

I purpose built Directives to help provide some control over these advanced use cases.

This space evolves weekly - and I’m constantly learning and evolving my thinking here as well.

The primitives share similarities with Oban - but the use-cases are different.

Agent techniques like “Chain of Thought” (Chain-of-Thought Prompting | Prompt Engineering Guide<!-- -->) string together several actions with an LLM’s response deciding which next-action to choose. This simulates human reasoning leading to higher-quality outputs.

Jido was tailored towards these use cases. But, as I explained above, as I worked through my own prompting pipelines, I got annoyed with LLM’s being slow an flaky. When I set out to build Jido, I wanted to ensure the building blocks didn’t make assumptions about LLM’s being involved, but also supported classical AI planning algorithms - a currently neglected sector of artificial intelligence research.

Think about video game NPC’s - the AI used to power them are most often things like Behavior trees or Zipper trees.

Elixir has a solid base of these algorithms available as Hex packages now and there was even a talk at ElixirConf about them in 2018

• zipper | Hex
• GitHub - jschomay/elixir-behavior-tree: Elixir library for building AI's from composable behavior trees
• https://www.youtube.com/watch?v=3sLYzxuKGXI

A lot of the latest AI research focus has gone towards LLM’s lately, but I find algorithms like behavior trees to be more practical in the real-world because they are more reliable in several ways.

Really appreciate the questions here- I’m adding clarifications to the README along the way to hopefully answer some of these questions for others in the future.

Nice - I’m a fan of Scala and Akka

The determinism vs. non-determinism when you introduce LLM’s is a challenge. That’s part of the reason why I chose to keep LLM’s out of the Jido foundation - I wanted a clean workspace. That said, a lot of the features in the foundation were built with LLM’s in mind such as validating Agent schema’s and allow-listing Actions that Agents can run.

Your visualization is super cool! I’d definitely welcome a conversation.

I’m finalizing the Jido 1.1 release this week and then will be building loads of demo’s into jido_workbench - a Phoenix instance with Agents hooked into LiveView. It’s my current messy playground - but once the dust settles on the framework it will be fun to add a bunch of demo’s.

This code is stale and has been completely re-written, but it gives you a flavor of what I’m aiming for: jido_workbench/lib/jido_workbench_web/live/jido_live.ex at main · agentjido/jido_workbench · GitHub

Is there any support for parallelism in Jido?

Nothing explicit other than Jido.Exec having both a run/4 and run_async/4 methods.

The vision is to utilize existing OTP patterns for any concurrency. I’m working on publishing a Roadmap - but here’s the gist:

• DONE - Stateless Agents
  • This is the foundation of Agents as data structures only with Jido.Exec focused on safely executing a single Action at a time
• 98% DONE - Stateful Agents
  • This milestone wraps a GenServer around the Stateless Agent and adds the Jido.Signal as the foundation for inter-process communication
  • No parallelization at this layer other then cast/2 to call an Agent with a Signal, receive a ref and wait for the Agent to send you the result of the Action - but this is more async then parallel
• 50% - Orchestrated Agents
  • This is what I’ve been working on the last few weeks and is the mode where a lead agent orchestrates child agents towards accomplishing its objective
  • The centerpiece of this layer is a runtime-based workflow orchestrator that coordinates and optimizes multi-agent signals in parallel - no explicit parallel coordination will be required - you get it for free
  • You can see some of the brainstorming here: https://x.com/mikehostetler/status/1906504395795161178

After orchestrated agents are done, there will be plenty of work building out extras and examples.

In Jido’s current state, I would create an Action that wraps Jido.Exec.run_async calls to the 3 actions you want to run in parallel - then await the results of all three before returning itself.

Here’s a quick gist that Claude built for me to model this: Parallel Jido Actions · GitHub

Let me know if that works for you and I’ll whip up a guide for this and throw together a Livebook to put into the Workbench cookbook permanently.

Good luck!