Connecting a large model to actual work used to mean walking through a framework's abstractions for a while: define the nodes, describe the tools, wire the transitions. By the time anything ran, half the enthusiasm had been spent on the wiring. The library discussed here takes the opposite position, and its position is the whole point: an agent does not need a framework, it needs a way to act.

smolagents is a small open library, about a thousand lines of core logic, published by the team whose model community most of this ecosystem revolves around. Its central claim is that the model should not learn a special format for calling tools. Let it write code instead, in the language it is already best at, and run that.

Thinking in code rather than filling in a structure

The conventional arrangement asks the model to emit a structured instruction: which tool, which arguments, in a fixed shape the framework can parse. The alternative here is to ask for a runnable fragment of Python, which the library executes and whose output goes back to the model so it can continue reasoning. Code has loops, conditionals and nested calls built in, so a multi-step task that would need three structured round trips often becomes one short script.

The numbers published alongside the approach suggest roughly a third fewer steps and model calls than the structured alternative on comparable tasks. For anything billed per call, that is not a rounding error; it is the difference between an experiment that is affordable to run repeatedly and one that is not. Declaring a capability is equally plain: a normal function, a clear description, and the agent decides when to use it. No glue code, no pre-scripted sequence of calls.

The model is your decision

The library is neutral about models, which is one of its more comfortable properties. A hosted inference service, a commercial provider reached through a routing layer, or a model running locally on your own machine are all the same shape from the agent's point of view, and switching usually means changing one line of initialisation rather than rewriting the logic.

What the model can do sets the ceiling. The better it writes code, the better this style performs, a point the community makes repeatedly and which is worth taking seriously before adopting the pattern: an agent that acts by writing code inherits both the strengths and the weaknesses of its model's coding ability.

What executes, and where

Generating code and then running it raises the obvious question, and the project answers it without hedging. The local executor is for development and debugging; it is not a security boundary. Anything important should run in isolation, and there are several ways to get it: hosted sandboxes, or a container you control yourself, selected by one parameter when the agent is defined.

Two further restraints are sensible. Generated code may only use the language's standard modules by default, and third-party packages must be authorised explicitly, which prevents a casual import of something that reaches the network. If the code fails, the agent reads the error and retries with a correction, and the number of attempts is capped by a step limit that is small by default, so a confused agent cannot spin forever at your expense.

The advantage of being inside an ecosystem

Being produced by the team behind a large model community brings an advantage that is hard to copy: a finished tool or agent can be published to that community and pulled down by somebody else the way a dependency is, and a whole hosted demonstration application can be handed to an agent as a single tool. Beyond that ecosystem, tools from an open protocol and from another popular framework can be attached, and the inputs are not limited to text: images, video and audio are supported.

For anyone learning how agents work, the most valuable property is legibility. A thousand lines is short enough that a problem can be diagnosed by reading the source instead of fighting through layers of abstraction. Transparency at that scale, the efficiency of acting through code, and the freedom to change model and tools at will add up to an unusually good starting point.

Who it suits

Researchers who want to vary one part and hold the rest still, developers who want an agent inside an existing program rather than a new application around it, and anyone who has been irritated by frameworks whose abstractions cost more than they save. It is free and open source, and a thousand lines is small enough to finish in an afternoon.