I’m often asked when advocating Agentic AI, “Why do none of your tutorials ever mention AutoGen, LangGraph, SmolAgents, or any other popular Agentic AI framework?” or “Which framework should I pick as a beginner to Agentic AI?” In this article, I want to explain why, during this special period of rapid development in Agentic AI, the specific framework you use doesn’t really matter—and why you should even avoid starting your Agentic AI journey with a framework.
Why We Need Technical Frameworks/Libraries
Before diving into the main question, we should first understand why frameworks (or libraries) are needed in other software engineering fields. There are three main benefits they bring, at different levels.
The most fundamental benefit is that they provide library functions that save us a lot of effort. Take C’s math library as an example. It provides a sqrt function, so we don’t have to implement the Newton iteration method ourselves just to compute square roots.
Once we can use library functions to achieve increasingly high-level functionality, the second benefit of a framework becomes clear: it offers appropriate abstractions. This allows us to think from angles that better match human intuition and business logic. For example, many GUI libraries provide a “dialog box” class. When we use such a class in our code, we don’t need to worry about how the message loop inside that dialog box is handled, or how the operating system redraws different buttons. Instead, we can concentrate on the business logic—where to place a button, what content to display when a drop-down list is clicked, and so on. This higher-level abstraction means we can focus on bigger ideas while avoiding many sources of error.
On top of that, the third and higher-level benefit is that frameworks often introduce a way of thinking or a design philosophy. This encourages and guides us to adopt best practices in a field. If you have used Xcode to write Objective-C or Swift programs, you’ll notice that the default template is configured using the MVC design pattern. There is no hard rule forcing developers to stick to MVC, but by initializing an iOS app project in this structure, Apple gently nudges beginners into a design pattern that’s been proven effective in engineering practice. As a result, their programs are less likely to suffer from unmaintainable code, and are easier to understand as the project grows.
These three benefits build on one another and even correspond to three ways (or levels) of using a framework. When you just treat a framework as a set of library functions, you retain the greatest flexibility—because you’re not constrained by the framework’s specific worldview or design patterns. But you also gain the fewest benefits. Using the framework at a higher level brings more advantages, but also more constraints—specifically, that you must see your entire project through the eyes of the framework’s author. For instance, if you really dislike the MVC pattern, using Xcode’s default template for Swift programs may be painful, unless you wipe out the project structure and adopt your own design pattern. In that case, it devolves from the third level back to the second.
What Choosing a Framework Means in Agentic AI
What makes Agentic AI special is that it’s so new, and everyone has a different perspective on how it should work. By choosing a particular framework, you effectively lock yourself into that framework’s perspective on Agentic AI. Take a few examples:
- AutoGen is built on the idea that an LLM can handle everything through asynchronous collaboration among multiple agents exchanging messages to tackle highly complex tasks.
- LangGraph is built on the idea that the agentic workflow can be represented as a graph. To address the challenge of a static graph structure, it introduces conditional edges, persistence, events, asynchrony, and other complex elements.
- SmolAgents is built on the idea (or assumption) that agents shouldn’t be invoked simply as tools. Instead, code should serve as a key intermediate medium, since it is clearer and more concrete.
You can see that these are more than just libraries offering a set of functions. They each have a strong, sometimes heavy, design philosophy—almost a “worldview.” Such an approach can greatly benefit your Agentic AI development, but it can also limit you. If you deeply understand and agree with their viewpoint, you’ll be productive and comfortable. But if, over time, you develop or discover a different way of thinking—either through your own experience or changes in the field—sticking with that framework can become extremely painful. Switching later can be difficult. Imagine migrating from SmolAgents to LangGraph—since their foundational ideas aren’t compatible, such a move would be complex, maybe more complicated than starting from scratch.
Looking farther ahead, choosing a framework now isn’t just a matter of picking the tool itself, but embracing its underlying worldview. Given how fast Agentic AI is changing, any revolutionary leap in understanding may happen at any moment. Whether we can respond to such breakthroughs in time could hinge on which worldview we have locked ourselves into. The flourishing diversity of Agentic AI frameworks is evidence that our understanding of the field is still akin to the story of blind men feeling different parts of an elephant. The likelihood that any given worldview is incomplete—or outright wrong—is high. Just look at the massive changes (essentially a full rewrite) AutoGen made from v0.3 to v0.4. Locking yourself in too soon doesn’t just risk incurring technical debt that may come due at any moment; it also limits your ability to see the field comprehensively.
So far, I’ve mainly focused on the opportunity cost. From the perspective of short-term benefits, existing frameworks also don’t provide that much value. The main reason is that Agentic AI is still in its early stages, so building a complete system isn’t that complicated yet. As discussed in previous articles, Agentic AI basically boils down to an LLM that can call tools, a tool protocol, plus a multi-round orchestrator. You can build a prototype in five minutes. These frameworks aren’t really saving you all that much effort. For newcomers to Agentic AI, I don’t recommend starting with a framework. You can begin by understanding the fundamental concepts and, with the help of an Agentic AI programming tool like Cursor, build your own system step by step. It might not even be slower than starting from an existing framework—and it could be more rewarding.
Some More Detailed Pitfalls
If you have actually tried any of these Agentic AI frameworks to build real apps, you might have seen some additional pitfalls.
First, while many of them claim to be low-level or lightweight, they often adopt high-level design patterns that require quite a bit of prerequisite knowledge just to get a working app. LangGraph, for example, requires you to learn how to define a graph via code and get it compiled without errors, which can be nontrivial. In SmolAgents, if you want to create a custom tool, you must figure out the interface for that specific library. It can take a fair amount of trial and error to finally write something that doesn’t crash. In other words, using these frameworks doesn’t necessarily help you get a working system up and running any faster. This is contrary to our intuitive expectation for a framework.
A natural question follows: why not use Agentic AI itself to solve this problem? Why should a human have to write so much code just to use an Agentic AI library? But somewhat ironically, none of these popular Agentic AI frameworks—AutoGen, LangGraph, or SmolAgents—provides prompt documentation specifically designed for AI. In other words, there is still no popular framework that is AI-native or even AI-friendly, something that would allow tools like Cursor to quickly and autonomously write running code against these frameworks. This is one of the reasons I find these libraries disappointing.
The second pitfall is their tendency toward over-abstraction. LangGraph is a spin-off of LangChain, which is notoriously known for this. If you only want to run the simplest toy demo, you can just use its existing classes and get up and running. But as soon as you try to connect any preexisting interfaces or do any custom work (common in enterprise environments), you inevitably need to write custom classes or modify the underlying implementation. That’s when the nightmare begins. You find yourself tracing through internal class definitions, diving down eight levels of abstract interfaces, all to find the spot you need to change. Then you have to modify code layer by layer or pass in your own implementations to achieve your custom needs.
This is a classic failure pattern in frameworks for fields that are evolving rapidly. MVC works well for iOS development because the fundamentals of GUI interfaces have been refined over decades, and are more or less settled. Agentic AI, on the other hand, is still in flux at the conceptual level. Any mid- to high-level abstraction is bound to be fragile. Over-abstraction by a framework replaces the builder’s intuition with the architect’s assumptions. This is less a solution and more a problem in and of itself. In many cases, bridging to real-world systems requires patch upon patch, until you finally decide to scrap everything and start over.
Conclusion
So, in short, existing Agentic AI frameworks often bind your technology choices to a particular worldview. At a moment of rapid growth in this field, that binding brings limited benefits but poses significant risks, both for integration with current systems and for future course changes. That’s why I don’t usually discuss specific Agentic AI frameworks or recommend that beginners start out with them. They come with such pronounced perspectives that they shape our thinking before we have the chance to independently form our own. Instead, we should keep a builder’s mindset, work from first principles, and master the fundamentals. Then, based on our specific needs, we can flexibly build the system that fits us best.
Do keep in mind, though, that this is only a temporary phenomenon. As Agentic AI’s components settle and converge—similar to how web standards emerged—we will eventually have frameworks and libraries of genuine, widespread value. That time just hasn’t arrived yet.
Comments