Apache Burr: Build reliable AI agents and applications

Posted by anhldbk 1 hour ago

Counter60Comment29OpenOriginal

Comments

Comment by brotchie 1 hour ago

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 memory, async tool calls, etc, but not THAT complicated from a traditional software engineering perspective.

Everyone seems to want to build their agent framework. But if you're tasked with building an agent, I've found it much easier and more maintainable to just build 1:1 code for THAT agent: most of the abstractions you get from an agent framework purely get in the way and obfuscate core agent logic.

You end up being forced to use the abstractions chosen by the agent framework, which sometimes are a mismatch for what you're actually trying to do.

Comment by pianopatrick 1 minute ago

I like to think of it as "AI prompting algorithms". Like instead of just this prompt gets this result it's A prompt then B prompt the C prompt gets a result.

And just like when people were trying to figure out which sorting algorithm made the most sense, we are all just trying to figure out which prompt algorithms with which models lead to good results.

Comment by kristjansson 19 minutes ago

Obscuring core logic is the most egregious part of most agent frameworks. One needs a clear view of what, exactly, is being sent to the underlying language model, and what's coming back. Everything in an 'agentic' application is realized as a sequence of tokens or a call to a provider eventually. It should be clear and obvious from ~all layers of the app what that's going to look like.

Comment by throw1234567891 7 minutes ago

Have a look at pi.

Comment by vanuatu 23 minutes ago

my job rn is just building agents

the hard part about building agents isnt the framework it's discovery, context, traditional engineering, handling the last mile

there are some invariants like the loop, tools, observability, guardrails, monitors etc...

Comment by brotchie 10 minutes ago

100% agreed, the "this is what an agent looks like to write" is the wrong pitch for a new agent framework.

The better pitch would be, "this is how easy observability, guardrails, monitoring, deployment, evals, versioning, A/B testing are with our framework." What the agent code looks like is somewhat incidental.

Comment by hilariously 59 minutes ago

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.

Comment by tcdent 45 minutes ago

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.

Comment by trollbridge 28 minutes ago

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.

Comment by tcdent 49 minutes ago

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.

Comment by mkarrmann 42 minutes ago

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

Comment by giancarlostoro 19 minutes ago

Doesn't look any different than doing the same in C# or Java to me, it is kind of pointless in Python, the one thing the pattern gives you is building a class in such a way that you the developer know exactly what's what, so its really a developer ergonomics thing is how it looks like to me.

Comment by tcdent 38 minutes ago

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

Comment by giancarlostoro 25 minutes ago

I think of Java immediately when I hear Builder Pattern, and I think anyone who has ever touched Java does as well.

Comment by CuriouslyC 47 minutes ago

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.

Comment by mooreds 22 minutes ago

How are agents authenticated?

I searched the docs for authentication and mcp (one of the protocols which, among other things, handles some pieces of authentication/authorization) but didn't see any results.

What did I miss?

Comment by hmokiguess 1 hour ago

How does this compare to https://strandsagents.com/ ? I'm interested in tools in this space, right now I'm not attached to one, but Bedrock + Serverless on Agent Core feels like the "easy guided path" though I don't like the platform lock-in

Comment by thedougd 11 minutes ago

Curious about other experiences.

I’ve been playing with this stack and left wondering if Strands provides any secret sauce with Agent Core. So far it doesn’t feel that way and sometimes they even feel at odds with each other.

Comment by Oras 1 hour ago

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

Comment by elric 59 minutes ago

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.

Comment by Oras 26 minutes ago

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

Comment by mzaccari 1 hour ago

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...

Comment by abirch 53 minutes ago

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/

Comment by vanuatu 53 minutes ago

vibe coded landing page

reddit user testimonial

framework is for state machines

why man..

Comment by pixel_popping 26 minutes ago

The vibe coded landing page (at least in its look) is really degrading Apache foundation image imo.

Comment by ivanmontillam 36 minutes ago

Don't ask the why, ask the how. How did they get acceptance into an incubation stage with what you just mentioned?

Comment by drchaim 1 hour ago

I just create a MVP chatbot for a client that has a Django app. I took the route to no frameworks. Claude/codex wrote the agent loop, the tools, the streaming..it’s working well for the MVP, we’ll see

Comment by lnenad 1 hour ago

Claude Opus really loves this template when building websites. It's very funny how many times I've seen it for recent launches.

Comment by doublerabbit 59 minutes ago

And it lags my desktop every-time, I hate it. It's the default bootstrap theme all over again but instead with SVG's.