Are event-driven AI workflows something new?
"The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun. Is there any thing whereof it may be said, See, this is new? It hath been already of old time, which was before us. There is no remembrance of former things; neither shall there be any remembrance of things that are to come with those that shall come after." (Ecclesiastes 1.9-11, King James Version)
At times, if you listen to some of the Generative AI discourse, it may seem like not only did LLMs transform our ability to work with natural language data, but they also necessitated a whole new tooling ecosystem for composing, monitoring, and scaling the multi-agent AI systems that you need to make the most of Generative AI's potential.
Yet upon a closer look, we can't help but feel that many of the new tools built and promoted by the major LLM frameworks are little more than a twist on concepts that have been around for a while. A case in point are LllamaIndex's Workflows, which offer event-driven computation semantics underpinned by Python's asyncio.
For those of you with a background in financial services, the concept of event-driven systems is not a new one. For instance, Egor delivered a talk on event-driven systems with asyncio and Kafka back in 2017, when asyncio was still fairly new, but event-driven systems were already a well-established approach.
As any seasoned developer or data scientist can attest, the use of proven technologies is generally preferred. This is because they have undergone extensive testing, and their rough edges have been smoothed over time. Moreover, they benefit from a larger community and a wealth of online knowledge. Is there such a technology for async event-driven computation semantics in Python? A quick search reveals that Faust, a framework built on top of Kafka and using asyncio, is a clear winner (based on GitHub stars). How does it compare to LllamaIndex Workflows?
As our notebook shows, the concepts map very nearly one-to-one. Workflows' Event classes correspond to channels in Faust (which can be in-memory or underpinned by Kafka topics). A minor difference is that each Event class in Workflows has its own data model (thus conflating the data model definition and the definition of an edge in the event propagation graph, arguably not the cleanest design), whereas different channels in Faust can share the same Record data model. However, data model reuse in Workflows can be easily done for example by inheriting Event classes just to rename them, so it's not a big deal.
The global context concept in Workflows roughly corresponds to Tables in Faust, though the semantics are somewhat different. The one thing we've seen that is not as easy in Faust as in LllamaIndex workflows is generating a pretty graph of your workflow.
Just for fun, we've written a thin wrapper over Faust (also shown in the notebook) that emulates LlamaIndex Workflows' syntax and some of its functionality (please let us know in the comments if you want us to expand that :) ), including the pretty graphs.
What does this mean for you? Should you use Faust instead of Workflows? As always, the answer depends on your context. If you already have a Kafka infrastructure in production or are even using Faust already, the answer is possibly yes. The distributed, well-scaling, resilient nature of Kafka and the RocksDB tables backend might well work for you.
On the other hand, if you simply like the event-driven semantics as a way of structuring your LLM-using code, you might prefer LlamaIndex Workflows with their multitude of great examples, and scale either via llama_deploy or via something like Ray.
Taking a step back, we believe the trend to watch out for is the rejoining of LLM-specific frameworks and tooling with the older, mature solutions for the same or very similar problems, such as event-driven orchestration, observability, etc. Would you agree?