burr

an product between the two (e.g. run over prompts and actions/agents and do it in a loop to modify them...) More details here - https://burr.dagworks.io/concepts/parallelism/. Things not mentioned but useful in this parallel context, Burr comes with pluggable durability/persistence/memory (see https://burr.dagworks.io/concepts/state-persistence/). We'd love to get any early feedback from the HN community, ideas for where you'd like the framework to go, or UI/UX experiences in this space. We will be in the comments for the next few hours to respond! Or leave an issue or discussion here - https://github.com/dagworks-inc/burr. Thanks!

ctor.com/blog/2024/07/11/youtube-tra... - Full-stack example of a streaming app: https://towardsdatascience.com/how-to-build-a-streaming-agen... - Human-in-the-loop app with Burr: https://towardsdatascience.com/building-an-email-assistant-a...

ability constructs. We value clarity and customization over terseness (we do not have a graduation problem). You can find the repository here: https://github.com/dagworks-inc/burr. We are really excited about the following new features: - Recursive, Parallel Agents: Model multi-agent hierarchies and track directly in the UI - UI Annotations: Mark production data to review and gather post-execution evaluation/test datasets - OpenTelemetry Integration: Log to OpenTelemetry and ingest OTel in the Burr UI to improve and customize visibility - Reloading, Time Travel, and Forking: Debug by reloading any point in the execution history to replay and fix issues. - Production-Ready Monitoring: Deploy with a simple self-hosted S3-based system. Since releasing, people are building & successfully shipping: concierge agents for slack, voice answer agents for restaurants, agents over RAG systems, co-pilots for internal business workflows, to name a few. On top of this we have an exciting set of blog posts, writeups, and user testimony – we’ll be sharing this + more links to get started in a comment below!

d build their own stuff.

esponse}, state.append(response=full_response) Then you would call `application.stream_result()` function, which would give you back a container object that you can stream to the user: streaming_result_container = application.stream_result(...) action_we_just_ran = streaming_result_container.get() print(f"getting streaming results for action={action_we_just_ran.name}") for result_component in streaming_result_container: print(result_component['response']) # this assumes you have a response key in your result # get the final result final_state, final_result = streaming_result_container.get() Its nice in a web-server or a streamlit app where you can use streaming responses to connect to the frontend. Here's how we use it in a streamlit app -- we plan for a streaming web server soon: https://github.com/DAGWorks-Inc/burr/blob/main/examples/stre....

rs and used printlines to debug. We found that everyone wanted the ability to pull up the state of an application at a given point, poke at it to debug/tweak code, and use for later testing/evaluation. People integrating with LLMOps tools fared slightly better, but these tend to focus solely on API calls to test & evaluate prompts, and left the problem of logically modeling/checkpointing unsolved. Having platform tooling backgrounds, we felt that a good abstraction would help improve the experience. These problems all got easier to think about when we modeled applications a state machines composed of “actions” designed for introspection (for more read https://blog.dagworks.io/p/burr-develop-stateful-ai-applicat...). We don’t want to limit what people can write, but we do want to constrain it just enough that the framework provides value and doesn’t get in the way. This led us to design Burr with the following core functionalities: 1. BYOF. Burr allows you to bring your own frameworks/delegate to any python code, like LangChain, LlamaIndex, Hamilton, etc. inside of “actions”. This provides you with the flexibility to mix and match so you’re not limited. 2. Pluggability. Burr comes with APIs to allow you to save/load (i.e. checkpoint) application state, run custom code before/after action execution, and add in your own telemetry provider (e.g. langfuse, datadog, DAGWorks, etc.). 3. UI. Burr comes with its own UI (following the python batteries included ethos) that you can run locally, with the intent to connect with your development/debugging workflow. You can see your application as it progresses and inspect its state at any given point. The above functionalities lend themselves well to building many types of applications quickly and flexibly using the tools you want. E.g. conversational RAG bots, text based games, human in the loop workflows, text to SQL bots, etc. Start with LangChain and then easily transition to your custom code or another framework without having to rewrite much of your application. Side note: we also see Burr as useful outside of interactive GenAI/LLMs applications, e.g. building hyper-parameter optimization routines for chunking and embeddings & orchestrating simulations. We have a swath of improvements planned. We would love feedback, contributions, & help prioritizing. Typescript support, more ergonomic UX + APIs for annotation and test/eval curation, as well as integrations with common telemetry frameworks and capture of finer grained information from frameworks like LangChain, LlamaIndex, Hamilton, etc… Re: the name Burr, you may recognize us as the authors of Hamilton (github.com/dagworks-inc/hamilton), named after Alexander Hamilton (the creator of the federal reserve). While Aaron Burr killed him in a duel, we see Burr being a complement, rather than killer to Hamilton ! That’s all for now. Please don’t hesitate to open github issues/discussions or join our discord https://discord.gg/6Zy2DwP4f3 to chat with us there. We’re still very early and would love to get your feedback!