Agent frameworks are having a moment, and most of the noise is selling you something you do not need. So before comparing any of them, the more useful question is the one the category avoids: do you need an agent framework at all? Most of the time, the honest answer is no.
This piece is about when that answer flips to yes, and about the one framework we actually reach for when it does: smolagents. We keep an eye on alternatives like OpenJarvis, but we will not stack a tool we have not run in real work against one we have. One solid side beats two shaky ones.
What is an agent framework, and do you need one?
Agent frameworks are not end-user products. They are libraries you use to build your own agents, which is the line that separates them from coding agents like Aider or Cline that you simply use. A framework is for when you are constructing a multi-step workflow of your own: research a topic, weigh options, take an action, report back.
Here is the part the field rarely says out loud. Most of the time, you do not need a framework. A well-prompted model in a loop with a couple of function tools beats a framework-based solution for typical work. The honest take is that this category is hype-heavy and substance-light for most studio use. Reach for a framework only when a plain loop genuinely breaks down: many tools, branching logic, code-execution-driven steps.
What is smolagents?
smolagents is HuggingFace’s minimalist, code-execution-based framework: you define a function, mark it as a tool, give the agent a goal, and watch it write Python to call your tools. It is the framework you reach for when you want an agent without a framework headache.
It is small on purpose. The framework is roughly a thousand lines of Python, which means you can read the source rather than trust a black box. Its defining choice is the execution model: instead of picking from a menu of rigid tool-call schemas, the agent writes actual Python code to call your tools. You define a tool as a plain function with a docstring, the agent reads that docstring to understand it, and it composes code to get the job done.
That code-first approach is more flexible than menu-style tool calling, and it is the reason smolagents feels less like a framework and more like a thin, honest layer over the model. It runs against local models through the LiteLLM integration, so you can point it at Ollama and keep everything on your machine.
A concrete example makes it click. Say you want an agent that takes a topic, searches a few sources, and writes a short brief. You write three small Python functions, search, fetch, and summarize, each with a clear docstring, hand the agent the goal, and it writes the glue code that calls them in order, inspects the results, and decides whether it needs to search again. You did not configure a graph or learn a domain-specific language. You wrote functions and described the job.
What are the risks of a code-writing agent?
The trade-offs are real. Code execution is powerful and dangerous in equal measure: the agent writes Python that runs on your machine, so sandboxing with something like E2B or Docker is essential for anything untrusted. An agent that can run code is an agent that can run the wrong code, and the boundary you put around it is your responsibility.
And because the agent writes code, a weaker model fails more visibly, producing broken Python rather than quietly malformed tool calls. The fix is the same as everywhere in local AI: use a strong model. A code-based agent makes model weakness obvious, which is uncomfortable but honest; a schema-based one can hide the same weakness behind a valid-looking call.
When should you actually reach for smolagents?
Reach for smolagents if you write Python, you have outgrown a plain LLM-in-a-loop, and you want a code-first agent without ceremony. It is the right step up when direct calls with structured outputs stop being enough: multiple tools, branching logic, code-driven workflows. It is also the framework to reach for first precisely because it is the easiest to abandon when you discover you did not need a framework after all.
Reach for nothing if a simple model call and a Python loop would do the job. That is genuinely the right answer more often than the category’s marketing admits. Do not adopt a framework to solve a problem a loop already solves.
The progression is worth internalising: one prompt, then a prompt plus a tool, then a small loop, and only then a framework. Each step is cheap to try and cheap to undo. Skipping straight to a framework is how a one-afternoon problem quietly becomes a one-week dependency.
What do we run, and why?
We use a framework rarely, and when we do, it is smolagents. For most studio work, a direct model call with structured outputs and a small hand-written loop is enough, and it is easier to reason about than anything a framework gives us. smolagents earns its place only when that approach breaks down, and its minimalism is exactly why we trust it there: when we outgrow it, we have usually overengineered the problem and the framework tells us so.
For our actual coding work, refactors and repo edits, we do not use a framework at all. We use end-user products like Aider and Cline. smolagents is for building a custom agent that does something specific, not for general coding. Alternatives like OpenJarvis stay on the bench until we have run them in real work; when that is done, we will say so here rather than guess now.
The takeaway is smaller and more useful than a framework shootout. Start with a loop. Add smolagents only when the loop visibly breaks. And treat any framework that cannot survive you reading its source in an afternoon with suspicion. You watch the work, you decide.