A couple of conversations I was in last week around agentic system design reminding me of Brandon Smith’s excellent write libraries, not frameworks post
A library is a set of building blocks that may share a common theme or work well together, but are largely independent.
A framework is a context in which someone writes their own code. This could take the form of inversion-of-control, a domain-specific language, or just a very opinionated and internally-coupled library.
[…]
So here’s my point: frameworks aren’t always bad, but they are a much bigger risk – for both the creators and the users – than libraries are. If your framework can be a library without losing much, it probably should be
I feel like we have seen this in ML around general-purpose training loops. Everyone training a model needs a training loop, and there are a lot of commonalities (dataloading, checkpointing, observability and so on). It’s very tempting to build a general training loop that many different groups can use. Unfortunately, this is almost inevitably a framework, rather than a library, and inherently hard to compose.
When the needs of the modeler exceed the bounds of the framework they either have to make extensive changes or drop the framework and move to a more bespoke set up. In practice this seems to result in a handful of training frameworks that are somewhat domain specialized: for example, a recsys training framework, an LLM training framework, a multimedia/vision oriented framework and so on.
My sense is the same pattern will happen with agentic loops. A single “one-size-fits-all” agentic framework can feel too broad or rigid, and many teams will carve out domain-specific variants to get the features they truly need. Ideally, we will identify some truly generic components that can be build out library-style, and composed to the domains that we need.