“Agentic” is one of those words that gets stretched until it stops meaning anything. So let us pin it down with one plain distinction, and build everything else on top of that.
A model that answers takes your text and gives you text back. You ask, it responds, the exchange ends. An agent does something different: it works in a loop. It reads files, edits them, runs commands, looks at the result, and decides what to do next, repeating until the goal is met or it gets stuck. The model is no longer the whole product. It is the decision-maker inside a loop that can touch the real world.
That single shift, from answering to doing, is the thing “agentic” actually names. And for local AI specifically, it changed what the category is for.
The loop, made concrete
It is easier to see this in a real tool than in the abstract. The Atlas describes opencode as a coding agent that ships as a native desktop app: you point it at a folder and type a prompt, and it reads files, proposes edits, runs commands, and shows you the work. The demo in the note is small but it captures the whole idea. You say “add a function to utils.py that takes a list and returns the sum, add a test for it,” and the agent reads the relevant files, proposes the edit, asks permission, and applies it. That is the loop: read, decide, act, check, repeat.
smolagents shows the same pattern from a builder’s angle. The Atlas frames it as a minimalist framework where you define a function, mark it as a tool, give the agent a goal, and watch it write Python to call your tools. The agent writes code, executes it, sees the result as a variable it can use, and decides the next step. Different shape, same engine: a model running in a loop with the ability to take actions, not just describe them.
What it changed for local setups
Here is why this matters more for local AI than for cloud. Before agents, a local model was a chat partner. It could draft and summarize and answer, but the actual work, opening the file, making the edit, running the test, still landed on you. Useful, but bounded.
The agentic loop removes that boundary. A local model can now do real work, not just talk about it. The Atlas note on opencode is direct that wiring the app to a local Ollama model and a capable open model keeps the local-first thesis intact: the agent reads your files, edits your code, runs your commands, and none of it leaves the laptop. That is a meaningful change. The privacy story used to come with a tax, which was that you did everything by hand. Now the loop runs locally too, so you keep the privacy and the model still does the work.
The same is true for the build-it-yourself path. smolagents pointed at a local Ollama model means you can stand up a custom agent, a research helper, a data analyst, a workflow runner, that takes real actions on your machine with nothing going to a third party. The category quietly went from “private chat” to “private worker.”
What it now demands
A model that can act is more useful and more dangerous, and the second half is not optional to think about.
- Permissioning. When a tool can edit files and run commands, “approve each step” stops being a nicety and becomes the safety model. opencode’s flow is built around exactly this: the agent proposes an action and you approve it before it happens. Treat that approval step as load-bearing, not as a speed bump to click through.
- A sandbox for anything untrusted. smolagents makes this sharp. The Atlas is repeated and blunt: code execution is dangerous by default, because the agent writes Python that runs on your machine. The note insists on sandboxing (E2B or Docker) before running untrusted prompts. 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.
- A capable enough model. This is the constraint that runs through both notes. An agentic loop exposes a weak model more harshly than a chat box ever did. The Atlas says it plainly for opencode: model quality is still the ceiling, and a weak model is still a weak agent. smolagents puts it in even starker terms: code-based agents make model weakness obvious, producing broken Python and wrong logic, so you use strong models. A chat model can hedge a thin answer. An agent that acts on a thin decision breaks something.
The position: a smaller, more honest claim
Strip the hype away and “agentic” is not magic. It is a model in a loop with the ability to act, and that is enough to be genuinely new. For local AI it changed the ceiling of what a private setup can do, from answering questions to completing tasks, while keeping the data on your machine. That is the upside, and it is real.
But the same step that makes a local model useful as a worker is what makes permissioning, sandboxing, and model quality non-negotiable. You do not get the “does real work” benefit without taking on the “can do real damage” obligation. The studios and individuals who get value from agentic local AI are the ones who treat the approval prompt as a control, isolate anything that runs untrusted code, and run a model strong enough to make decisions worth acting on.
What we run, and how we think about it
In the studio opencode is in production for coding work, pointed at a local model, which is the agentic loop running fully on-machine. When we build something custom rather than use a finished product, smolagents is the framework we reach for, and the Atlas guidance we follow is its own: most of the time you do not need a framework at all, a direct call and a simple loop is enough, and you step up to an agent only when the task genuinely needs tools, branching, and a real loop.
That is the calm version of “agentic.” Not a revolution to chase, but a capability to use deliberately, with the guardrails it requires. A model that answers became a model that does, and the only question worth asking each time is whether this particular job needs one that does. We will not decide that for you. You watch the work, you decide.
Curious about these things. You should be too.
Harness your curiosity.
— Stridenote · № 011