FYI - Burr is designed with recursion in mind, i.e. the ability to kick off Burr within Burr. So you could have an action that is managing several Burr subgraphs... Or you write your own management layer here.
263 karma · joined August 11, 2011
Burr just helps you, the engineer, to really control the primitives. Then adds some cool features you don't have to think about -- like observability :)
Otherwise the larger picture is that MCP is a land grab for building an eco-system around integrations to get access to data. Your LLM agent is not valuable if it can't access things for you... and from a market perspective enterprise pays a lot for this stuff already, and yes MCP is not thought out at all for Enterprise really... At least thankfully they added stateless connections to the spec...
The challenge with this approach though is that you need to run the actual code to see what it does, or as a developer build up a mental model of the code ... but it does shine in certain use cases -- and also reminds me of https://github.com/insitro/redun because it takes this approach too.
[disclaimer I created Hamilton & Burr - both whitebox frameworks] See https://www.reddit.com/r/LocalLLaMA/comments/1d4p1t6/comment... for comment about Burr.
BSD-3 Clear Clause is very permissive - which covers the majority of the code.
What isn't BSD-3 is around features that are targeted at enterprises, e.g. auth. But you don't need to use them to get value from the project & UI; you can deploy to production without them.
The repo has a mermaid diagram, but the code doesn't really reflect that (which is typical of most agent-ic apps we've found!). So I went about refactoring to add Burr since with Burr we should be able to get close to having code that reflects the desired flow. You can see my Burr version in the following PR; it's could be a little cleaner, but I think I'm leaving it in a better place if you had to figure out what was going on and trying to iterate/debug a response - https://github.com/AgentOps-AI/Jaiqu/pull/5/files.
100%; lived that story. In my experience this is usually the result of some poor design assumptions on part of the framework. Other times people want to use something for which it wasn't designed for. In the case of Burr, we still have a few things to iron out, but given our platform backgrounds, we're trying to be cognizant of things that have annoyed us in the past, e.g. two big ones: ability to customize parts given esoteric deployment needs (e.g. persistence layer); adding in observability without it coupling you/getting in the way of logic.
> the LLMs get better, you might want to focus on detailed documentation so that the future AIs can master your framework and help your users
Even without LLMs I think this is required ;)