Live data from Hacker News

Apache Burr: Build reliable AI agents and applications

burr.apache.org

11–20 of 125 posts

Re: Apache Burr: Build reliable AI agents and applications

#12
post #2

I couldn't find an explicit reference for the naming, but for anyone wondering there is a Hamilton example: https://github.com/apache/burr/tree/main/examples/multi-agen...

Burr is named after Aaron Burr, founding father, third VP of the United States, and murderer/arch-nemesis of Alexander Hamilton. What's the connection with Hamilton? This is DAGWorks' second open-source library release after the Hamilton library We imagine a world in which Burr and Hamilton lived in harmony and saw through their differences to better the union. We originally built Burr as a harness to handle state between executions of Hamilton DAGs (because DAGs don't have cycles), but realized that it has a wide array of applications and decided to release it more broadly.

https://pypi.org/project/burr/

Re: Apache Burr: Build reliable AI agents and applications

#13
A builder pattern and decorators.

Yes, Python has decorators, but they're best used as "filters" that apply to functions or methods. Cache this, serialize the output of this function always, prepare this function to be used as a tool by an agentic harness. Not registration, not flow control. You may disagree but someone has to say it; FastAPI influenced the modern use of decorators far too much in the wrong direction.

Builder patterns are a Rust convention, because Rust has no named keyword arguments. A Python function already exposes a named contract. There is very little reason to ever to sequentially pass configuration parameters in chained method calls. If you need to add state that doesn't exist yet to a constructor or factory, that is not a builder pattern. That is registration. The one place where builder patterns should be tolerated is query builders. They iteratively build on a concept and having the additional "slot" for metadata (method name plus keyword arguments) is genuinely useful. Using methods which accept single parameter instead of keyword arguments is incorrect.

Re: Apache Burr: Build reliable AI agents and applications

#14
The best agent framework is Pi (pi.dev). It is minimal and doesn't assume a use case, runs fine interactively or non-interactively, has an active community building with it and supports everything you need to build whatever kind of agent you want with plugins.

Re: Apache Burr: Build reliable AI agents and applications

#15
post #6

I'm still on the fence about agent frameworks, they have their place, and it depends on the nature of the agent: e.g. "Low latency, return a good enough response in 3 seconds, vs. working for 3 hours on a problem." BUT, if you boil it down, an agent really is context building, making an LLM call, executing requested tool calls, parsing the final model output, returning it to some frontend. There's extensions like mem…

Couldn't agree more - tried to convince a business that doubling down on OpenClaw wasn't going to solve problems except for some 0-1 stuff, and that almost immediately they'd run into roadblocks because most of the product wouldn't serve their use case. 4 months of mostly spinning their wheels later they launched a really lackluster OC product that's effectively DOA.

OpenClaw is an application, not a harness. Yes, it contains a harness, but it is a complete product.

When building an agentic workflow there are enough primitives that rewriting them from scratch every time makes zero sense.

What is a tool? How does the LLM understand the tool? Formatting a native function into a serializable input/output pattern makes sense to generalize and that does not need to exist repeated in everyones application code.

We use libraries to interact with the APIs themselves; nobody would say writing a spec-compliant API client was poor practice. Agentic harnesses are just one layer above: I need to call the API and I need to do it with certain expected conventions.

Re: Apache Burr: Build reliable AI agents and applications

#16
post #13

A builder pattern and decorators. Yes, Python has decorators, but they're best used as "filters" that apply to functions or methods. Cache this, serialize the output of this function always, prepare this function to be used as a tool by an agentic harness. Not registration, not flow control. You may disagree but someone has to say it; FastAPI influenced the modern use of decorators far too much in the wrong direction…

Builder pattern isn't only used in Rust, but I agree it's hideous to use in Python.

Re: Apache Burr: Build reliable AI agents and applications

#17
post #13

A builder pattern and decorators. Yes, Python has decorators, but they're best used as "filters" that apply to functions or methods. Cache this, serialize the output of this function always, prepare this function to be used as a tool by an agentic harness. Not registration, not flow control. You may disagree but someone has to say it; FastAPI influenced the modern use of decorators far too much in the wrong direction…

Builder pattern isn't only used in Rust, but I agree it's hideous to use in Python.

Fair point. I should have said "popularized in the modern software vernacular by Rust".

Re: Apache Burr: Build reliable AI agents and applications

#19
post #6

I'm still on the fence about agent frameworks, they have their place, and it depends on the nature of the agent: e.g. "Low latency, return a good enough response in 3 seconds, vs. working for 3 hours on a problem." BUT, if you boil it down, an agent really is context building, making an LLM call, executing requested tool calls, parsing the final model output, returning it to some frontend. There's extensions like mem…

It’s painfully obvious that you can just open your coding harness and… tell it you’d like to make an agent. They’re simple to write.

Re: Apache Burr: Build reliable AI agents and applications

#20
post #8
post #4

First time I hear about Burr, curious why it was incubated in Apache.

Why wouldn't it? The ASF has a long history of incubating new FOSS projects. Some graduate and become household names. Others fail and end up in the attic. The ASF can provide organisational support and generally fosters good communities.

My point was this is a crowded market now, why would they pick a platform that is not known? I did search HN and this platform was only shown once 2 years ago, and from their releases, they are still 0.42 after two years.

It might sounded that I’m against the move, but I’m just curious as what apache found in the platform to get incubated

Post reply on HN