Super excited to show @anyscalecompute 's @raydistributed integration with Burr. What it is? It enables you to distribute "agents" (well sub-graphs) as tasks on Ray, along with fault tolerance! Read more about it here: blog.dagworks.io/p/parallel-…

A @burr_framework user shared this video piped.video/watch?v=evmZTh7l… with me on the "problem with frameworks". Worth a watch. I 💯% agree with the take home. The "coupling problem" is the reason why people graduate out of frameworks like @langchain & @llama_index. You become overly coupled and then find yourself overtime asking why am I using this? It's not that the framework authors did this maliciously, it's just that they optimized for their needs, in this case for POCs, which is not the same as long lived maintainable code. That's why we see people either build their own frameworks, or they hopefully discover @hamilton_os & @burr_framework and realize that there are frameworks that allow "loose coupling" that don't get in your way (as a platform person and framework author we optimize for maintainable code). A good example of this is @FastAPI - very easy to not couple your business logic and iterate quickly no matter the age of the code. So how can you tell where a framework lies on the spectrum of tight coupling versus not? Some tests: (1) How many "objects" do I need to use from the framework to couple the logic I want to happen? The fewer the better. E.g. with @hamilton_os by default it's 0. With @burr_framework it's just 1 and that's due to state for edge transitions, but that's easy to decouple from. (2) How many framework imports do you need to get something to run? The less the better - consider @burr_framework vs @langchain using #langgraph (see images) If you're feeling framework pains, or are curious on how it can be done right, checkout: github.com/DAGWorks-Inc/burr (agents) github.com/DAGWorks-Inc/hami… (pipelines/tools) or subscribe to our blog - blog.dagworks.io/ #python #opensource #genai #llmops