First, an honest framing. This is not a comparison between two tools we have run side by side for months. smolagents we have tested and understand well. OpenJarvis is still on our bench, notes in progress, and we are not going to pretend otherwise. Where its specifics belong, you will see a bracketed marker. We would rather leave a clear gap than fill it with a guess.
So read this as one solid side and one honest sketch. The point worth keeping either way is the question itself: when do you want an agent framework at all, and which one fits the job?
The category, in plain terms
Agent frameworks are not end-user products. They are libraries you use to build your own agents. That is the line that separates this category from coding agents like Aider or Cline, which are tools 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 in 2026 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.
With that established, the two contenders.
The two contenders, in one line each
- smolagents is HuggingFace’s minimalist, code-execution-based framework: define a function, mark it a tool, give the agent a goal, watch it write Python to call your tools. The framework you reach for when you want an agent without a framework headache.
- OpenJarvis is [CONFIRM: one-line description of what OpenJarvis is and the shape of agent it builds]. This is the side of the comparison we are still finalizing.
What smolagents really is
smolagents 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, or use HuggingFace’s inference API to get going in a few lines.
The trade-offs are real and the Atlas names them. 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. 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.
What OpenJarvis is, as best we have it
This is the part we are still grounding, so we will be brief and explicit.
OpenJarvis is [CONFIRM: what OpenJarvis is at its core, and what kind of agent it is built to produce]. Its execution model is [CONFIRM: code-execution, tool-call schema, graph-based, or something else]. It runs against local models via [CONFIRM: which backend or integration, e.g. Ollama, LiteLLM, or a custom provider]. The setup and difficulty are [CONFIRM: install path and how heavy it is relative to smolagents]. Licensing is [CONFIRM: license].
Until those are confirmed from hands-on testing, treat this side as the studio’s working notes rather than a verdict. We will not stack OpenJarvis up against smolagents on dimensions we have not actually checked.
How they compare, on the axes we can speak to
Philosophy. smolagents is built around minimalism: do less, stay readable, get out of your way. Whether OpenJarvis shares that instinct or leans toward more structure is [CONFIRM: OpenJarvis design philosophy, minimal vs feature-rich].
Execution model. smolagents has the agent write and run Python. OpenJarvis uses [CONFIRM: execution model]. This is the axis that matters most, because it shapes flexibility, debuggability, and how badly a weak model can go wrong.
Local-first fit. smolagents runs local cleanly through LiteLLM and Ollama, which keeps it aligned with how we work. OpenJarvis’s local story is [CONFIRM: how well OpenJarvis supports fully local model backends].
Safety surface. smolagents executes code, so it needs sandboxing for untrusted input. OpenJarvis’s risk profile is [CONFIRM: whether OpenJarvis executes code and what isolation it offers].
Readability. smolagents is small enough to read end to end. OpenJarvis’s footprint is [CONFIRM: codebase size and how auditable it is].
Who should pick what
Pick 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.
Pick OpenJarvis if [CONFIRM: the specific scenario where OpenJarvis is the better fit than smolagents, once tested]. We will write this line properly when the bench notes are done.
Pick neither if a simple LLM 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.
What 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-agent 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.
OpenJarvis sits on the bench. We are testing it deliberately, and when the notes are complete we will update this piece with the same grounding the smolagents side already has. Until then, the honest position is the one we opened with: one tool we can speak to, and one we are still earning the right to compare.
We do not tell you which to use. You watch the work, you make your own call. Curious about these things. You should be too.
Harness your curiosity.
— Stridenote · № 008