Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apache Burr: Build reliable AI agents and applications

burr.apache.org

Post reply on HN
Print view View original

61–70 of 125 posts

Re: Apache Burr: Build reliable AI agents and applications

#61

Post by chuckadams »

peterbell_nyc wrote: post #54
tomrod wrote: post #38

Earlier quoted context omitted.

Whst about pi do you like?

Pi is a nice multi-agent wrapper. I use it to wrap my OpenAI max plan calls and my API calls. It takes care of some of the agent plumbing - still need sandbox, orchestrator, compounding, context, evals, etc but it's a nice component.

Any particular plugins you'd recommend? For orchestration I gave pi-subagents a try, and didn't care for it, ended up with hung agents sticking around forever and I wasn't even doing anything terribly fancy. Claude's subagent control is annoying and clumsy, but it works.

Re: Apache Burr: Build reliable AI agents and applications

#62

Post by chuckadams »

pianopatrick wrote: post #30
brotchie wrote: 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…

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.

The most interesting evolution of my agent workflow over the past year is that I've dropped all the language gimmicks: I used to use particular emoji to mark parts of code as hints to the AI, I structured planning docs in very rigid language for different types of instructions, and generally optimizing my language for machine consumption. That's all gone now: all my comments, directives, plans and so on are just plain and clear English, nothing more. They're direct and unceremonious, but no longer bullet points that were nearly caveman-speak. It just works better that way.

Re: Apache Burr: Build reliable AI agents and applications

#63

Post by enragedcacti »

pramodbiligiri wrote: post #42
vanuatu wrote: post #11

vibe coded landing page reddit user testimonial framework is for state machines why man..

How does one know that a website is "vibe coded"? Any good indicators?

https://vorpus.github.io/performativeUI/

so far I'm seeing: GradientText, Animated button, EyebrowPill, Aurora background, MockIDE, LogoRow, SlippyWords, StatCounter, CommunityBadge

also: "No DSL, no YAML — just Python functions and decorators."

'It's not X, its Y' but with an added em dash is crazy work.

Re: Apache Burr: Build reliable AI agents and applications

#64

Post by brotchie »

agentdev001 wrote: post #60
peterbell_nyc wrote: post #55

Earlier quoted context omitted.

This this this! Anyone have something they genuinely like for all of this? For now I'm rolling my own, but I can't believe I won't find a better OSS alternative soon...

Nvidia Openshell solves most of the hard problems I've run into while building stuff in this space. Observability is, for my purposes, solved by a given framework supporting OpenTelemetry. Guardrails is where I've gotten the most value of openshell being a neat package. Agent workload scope is written as policy in openshell, and capability is backed by openshell handling all execution. Monitoring/deployment/versionin…

We need the equivalent of the MEAN / LAMP stackronym for agents.

Re: Apache Burr: Build reliable AI agents and applications

#66

Post by fxwin »

brotchie wrote: 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…

The advantage of frameworks isn't that they make it easier to write the actual agent, it's tooling + observability + ... Even Langchain, for all the (deserved) criticism it gets made this very clear very early: It might be easy/easier to write your own chatbot from the ground up, but what happens if you have to add observability/tracing? Being able to just add one environment variable and instantly have a UI where i can nicely go through all of my traces with basically 0 additional effort is something a hand rolled solution just can't really compete with

Re: Apache Burr: Build reliable AI agents and applications

#67

Post by freakynit »

brotchie wrote: 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…

Yep.. same. I build my own agents... all use-case specific. Keeps the code super minimal, and avoid unnecessary complexity. I have tried a few of these, but nop.. no help.. only more work (and issues).

Re: Apache Burr: Build reliable AI agents and applications

#68

Post by freakynit »

fxwin wrote: post #66
brotchie wrote: 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…

The advantage of frameworks isn't that they make it easier to write the actual agent, it's tooling + observability + ... Even Langchain, for all the (deserved) criticism it gets made this very clear very early: It might be easy/easier to write your own chatbot from the ground up, but what happens if you have to add observability/tracing? Being able to just add one environment variable and instantly have a UI where i…

This only becomes relevant if your execution graph is complex/big enough. Otherwise, all it takes is less than 30 minutes to add telemetry to all needed points. Doing manually also gives you better control on what you really want to track (to save costs).

Re: Apache Burr: Build reliable AI agents and applications

#70

Post by sdesol »

peterbell_nyc wrote: post #53
brotchie wrote: 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…

For me the heart of an agentic system is NOT using agents (except when you really have to). Components of a working system include: - Pipelines/recipes to describe multi-step flows (deterministic, agentic and HiTL steps), loops, conditionals, exit-on's for max loop iteractions, etc - The logistics to actually run the model and HiTL steps reliably across multiple agent worker pools - Management and delivery (and secur…

Can you comment more on

> Context management so the right agents have the right context for the right sessions at the right time

I'm going to do a show HN tomorrow that explains how you can give your agents years of experience. The basic idea is, you would commit in your repo or download manifests (JSON files) that can be converted to "Brains" (SQLite databases). Each brain can have its own properties.

For example, I provide a "code intent" analyzer (instructions for AI) that says when analyzing a file, extract this metadata. For the code intent analyzer, I have the AI extract a single sentence purpose for the file. So if you execute:

gsc rg cache --db code-intent --fields purpose

you get all matches for 'cache' plus the matching file's purpose like "Modify file to update caching strategy". This is how the agent can tell if the file is talking about cache vs. whether this file is what you should change if you want to update the caching strategy.

So for what you described, you can have a brain for different stages of a task. It can be as simple as, in the planning stage, make sure you do this if you need to touch this file.

I am working on a rust-blast-radius brain that uses `syn` + AI generated metadata to help you understand "what if I changed this file, what would be affected". With the rust-blast-radius brain, the AI can summarize the types of files that will be affected without having to open the file based on what has been changed or discussed.

So you can have a rule like, if I make changes to a Rust file, make sure to do a blast radius analysis so we don't forget to consider something.

Does this align with what you are looking for?

Post reply on HN