Live data from Hacker News

Apache Burr: Build reliable AI agents and applications

burr.apache.org

31–40 of 125 posts

Re: Apache Burr: Build reliable AI agents and applications

#31

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.

After trying a few I like NanoBot more than Pi. Also popular, pretty clean code, I found fewer bugs than I did in Pi.

Re: Apache Burr: Build reliable AI agents and applications

#33
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…

Agents are a way to de-bloat the context. The way LLMs function, you absolutely need to find the sweet spot for a given task, and if the primary LLM has to go through a bunch of failures to find a working function, those failures are better contained in an agent and disposed of.

Obviously, you could have a different LLM like a "angel" that prunes a primary agent of the context it doesn't need, but I think the realistic KV cache problem is will determine the optimal structure: you want the work do be done in the most efficience KV cache (context-reuse) as much as possible.

There's definitely more to it than just spawning agents.

Re: Apache Burr: Build reliable AI agents and applications

#34
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…

Take a simple workflow. You have a query it goes to a classifier. The classifier determines what workflow it should route the request to.

Then you have a general workflow that has a set of skills (prompts) and tools. And that could be recursive.

So if you do something like "rename this file" you have to build up a workflow like:

[classifier]

what's the workflow -> rename

[rename workflow]

list files (tool call)

figure out relevant predicate (LLM)

convert predicate into a filter query give the context of the files (LLM)

figure out what you want the new name to be (LLM)

create the request body and hit the tool

approval workflow

formatting

It's a lot to manage and orchestrate and that's just one simple example. You'd like want to use the same building blocks to delete a file or move it. Even to know the right concepts is difficult as we're a bit deluded on whats going on in the background of these modern AI apps like Claude and GPT that do a lot of this stuff for you

Re: Apache Burr: Build reliable AI agents and applications

#38

Earlier quoted context omitted.

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.

Have a look at pi.

Whst about pi do you like?
Post reply on HN