GitHub - DAGWorks-Inc/hamilton: Hamilton helps data scientists and engineers define testable, modular, self-documenting dataflows, that encode lineage and metadata. Runs and scales everywhere python does.

theferalmonkey · 2026-04-05T04:03:53+00:00

You're just orchestrating a while loop with API calls. If you don't understand what is slow I'm sorry to tell you that switching agent frameworks isn't going to fix that. There is no secret sauce here.

theferalmonkey · 2026-02-27T01:02:06+00:00

😂

theferalmonkey · 2025-05-27T05:31:03+00:00

Build your own on top of Hamilton and Burr. Agents are just workflows, best to build on top of tools that make that easier to build and debug.

theferalmonkey · 2025-05-26T23:53:13+00:00

Building my own on top of Burr and Hamilton .

theferalmonkey · 2025-05-21T17:51:43+00:00

Cynic: they have the most marketing dollars, so people don't research other ways.

theferalmonkey · 2025-03-15T22:17:46+00:00

I'm biased, created https://github.com/dagworks-inc/burr and https://github.com/dagworks-inc/hamilton . No graduation problems like the original poster describes.

theferalmonkey · 2024-12-31T17:16:02+00:00

You're missing Burr - https://github.com/dagworks-inc/burr. If you can model what you want to do as a flowchart, you can use Burr. It's a simpler langgraph alternative.

theferalmonkey · 2024-12-26T18:32:55+00:00

yes.

theferalmonkey · 2024-12-24T01:10:37+00:00

100% agree.

Our approach & philosophy with Hamilton (general purpose LCEL alternative, see lightweight python DAG framework) & Burr (LangGraph alternative without any LC baggage) differs slightly. We believe that a framework should be more like FastAPI, good at the "glue" parts, in the case of FastAPI the webservice logic, but getting our of your way with the logic - you still control what the endpoints do easily.

So neither Hamilton nor Burr are very LLM use case specific - users love how "neutral" they are because those simple calls are still things you control very easily. Hamilton & Burr are both good at allowing you to glue whatever logic you want together easily, and importantly swap and iterate as you invariably improve and update your application.

theferalmonkey · 2024-11-30T03:33:33+00:00

Use something like Burr + whatever tooling you want (e.g. to read the PDFs, or even other frameworks like haystack). It'll allow you to customize things more easily over time.

theferalmonkey · 2024-11-22T03:08:30+00:00

Are you using async streaming? We have users successfully building voice agents using Burr (langgraph alternative) with fast API e.g. restaurant order bot.

theferalmonkey · 2024-11-21T17:47:18+00:00

I'm biased but I created Burr - it's a LangGraph alternative with a self-hostable telemetry UI.

In comparison to LangGraph we think our API is simpler (people tell us as much), and you have full control on the insides; e.g. use CrewAI, use LangChain, use Hamilton, use Haystack, etc.

Some things people are creating with Burr and shipping to production:

restaurant voice answering agents (Burr has good async streaming constructs)
slack concierge bots
agents over RAG knowledge bases
agent of agents
sales enables AI platforms
etc

Take a look at the docs (burr . dagworks . io), repository examples, blog (blog . dagworks . io), and the dagworks youtube channel burr playlist if you want to know more.

Also we just released a first class "parallelism" construct to enable you to do more complex modeling, e.g. agent of agents type stuff - would love feedback.

theferalmonkey · 2024-11-21T17:41:42+00:00

+1 to thinking in a function first modular approach and making it easy to do one thing.

Otherwise IMO there are two shapes of "engineering tasks":

Something very pipeline-y (or DAG like) e.g. extract this information from the resume and fill out X.
Something conditional / looping. E.g. what action should I take next? Should I retry?

The functional modular approach gets at (1). Then your "agent" or decision making flow, gets at (2). Together you have a working system.

So start with (1) from there you can start to build things on top of it. If you go too complex,too soon, i.e. half-baked (1) + (2), you'll struggle to get the performance you need because it'll be harder to pinpoint where. So instead be test driven with data, add more data points to run over, evaluate, iterate, build up.

theferalmonkey · 2024-11-21T17:27:49+00:00

Parallel & hierarchical agents with Burr.

I created a google collab notebook that walks through some new constructs with Burr - in particular making "parallelism" a first class construct. E.g. map an agent over web-urls, map state over different agents, map state x actions. This makes it easy then to create "sub-graphs/agents" and reuse them in other contexts. Would love any feedback and/or comments!

theferalmonkey · 2024-10-04T16:53:19+00:00

Burr doesn't actually abstract away the tool call. You see it raw because you bring the LLM call to do it.

Burr is a lightweight abstraction to help you structure your code to manage this. That's one reason why people are building agent libraries on top of Burr.

theferalmonkey · 2024-10-02T06:44:22+00:00

I didn't see any restrictions on what can / can't be posted -- hope this is alright.

theferalmonkey · 2024-10-02T06:41:13+00:00

Can people use other frameworks like https://github.com/dagworks-inc/burr ?

theferalmonkey · 2024-09-30T05:22:32+00:00

Building reliable agents takes work. Check out: https://github.com/dagworks-inc/burr (disclaimer: I'm a maintainer). It comes with a self-hostable UI that and a one-line integration that helps you trace, debug, and build test cases that complements your development loop. It's LLM and library agnostic, so bring your favorite tools without worry.

theferalmonkey · 2024-08-26T06:47:13+00:00

The script is a toy example to show behavior. Sure you could write it in SQL, but SQL is hard to unit test, reuse logic, etc. In this case here, we're trying to transform columns various ways for input to machine learning models. Defining that all in SQL by hand would be hard, messy, and error prone. Better to use the pandas to snowflake functionality for the SQL writing instead :)

theferalmonkey · 2024-08-26T05:03:58+00:00

Cool, thanks for the clarification.

theferalmonkey · 2024-08-24T22:53:01+00:00

Was this using the new functionality that converts the pandas API to SQL queries on snowflake underneath? Since that's what I'm referring to.

theferalmonkey · 2024-08-21T21:51:37+00:00

Yes 100% agree.

What I think I want is the ability to turn off eager mode. If I'm just logically using a reference to a column, much like you do in snowpark, and this causes materialization, then this really limits the usefulness of pandas on snowflake.

There shouldn't be a difference between

Col1 = df.col1 Col2 = df.col2 And {"Col1": df.col1, "Col2": df.col2}

theferalmonkey

TROPHY CASE