Two weeks ago the Ollama story was about money. We covered the $65M Series B here as a bet that private inference is a durable infrastructure layer. Since then the team has shown what the money is for: with the v0.32 line, Ollama stops being a plain model runner and becomes an agent that writes code, calls tools, and delegates work on your own machine.
Here is the specific thing that changed since the funding news: typing ollama with no argument no longer drops you into a model prompt, it starts an interactive agent session. For an SMB running local AI to keep data in-house, that is not a cosmetic update. It moves the question from "which model is running" to "what is this agent allowed to do on our machines".
From model runner to agent
Version 0.32.0, released 11 July 2026, changed the default behaviour of the command. Where ollama used to open a model picker, it now launches an agent that can chat, write and run code, search the web, and work through multi-step tasks. The model stays local. What is new is the loop wrapped around it.
The distinction from the earlier ollama launch matters. ollama launch wires an external coding assistant such as Claude Code or Codex to the local OpenAI-compatible API. The new agent lives inside the Ollama process itself. You do not need a second tool to get from a chat reply to an executed action. For small teams with no dedicated platform engineering, that lowers the barrier to entry in a concrete way.
The skills system
The second piece is a skills system. A skill is a reusable capability the agent invokes when it needs it: file operations, git commands, web fetch, running terminal commands. Skills load dynamically and you can define your own. An office that reads invoices from a folder every morning and normalises them into an internal format can register that flow as a skill instead of describing it from scratch each time.
That sounds like pure convenience, but there is a flip side worth naming before you put it into production. An agent allowed to run terminal commands and write files has real effect on the machine. That is exactly the capability that makes an agent useful, and exactly the one a governance plan has to bound: which directories, which commands, which network connections are permitted. Based on our reading, the answer belongs in a written policy, not in a spur-of-the-moment decision at the terminal.
Claude Code channels and the July release train
Ollama did not ship once in July, it shipped in quick succession. v0.32.1 on 16 July handed the agent the current working directory so it operates in the right project context, and added an ollama signin prompt for the agent's web search and fetch. v0.32.3 on 23 July restored the Claude Code channels and fixed the Anthropic thinking streams, alongside tool calling for Laguna 2.1 models and a fix for GLM tool-call generation.
v0.32.4 on 25 July carries the most relevant point for Apple Silicon users: Laguna models now run on the Apple GPU through the MLX engine. It also brings improvements to speculative decoding and, according to the release notes, roughly 4-9 percent faster decoding for Qwen3 MoE models on the M5 Max. The exact figures depend on hardware and model. The direction is unambiguous: the software is pulling more out of silicon people already own.
What this means for on-premise and governance
For a company under GDPR, the interesting property is not the speed, it is that the whole agent loop runs locally. The model reasons locally, the tools act locally, the data never leaves the network. An agent that processes client files or draft contracts without a single token going to an external service sidesteps the entire class of questions around data processing agreements and cross-border transfer.
This does not remove control, it relocates it. If the agent can run code and change files, it needs clear limits: its own account with tight permissions, a defined working directory, no access to production systems without sign-off. How that maps onto GDPR Article 28 processor duties and the EU AI Act's transparency requirements is covered on our data sovereignty page. A local agent is a strong tool, not a free pass.
Which teams should look now
The step pays off mainly where recurring, well-scoped flows exist and the data is sensitive. A law firm structuring pleadings. An accounting office sorting receipts. A development team working on a client's source code that cannot go to the cloud. In all three cases the local agent is not one option among many, it is the only one that keeps the data unambiguously in-house.
Hardware is rarely the bottleneck. A Mac Studio, or a machine with a high-memory GPU, covers the model classes these flows need. The real work is in the scoping: which skills, which permissions, which acceptance criteria. That is where a small, tightly bounded pilot helps more than a big announcement. If you already run local AI, try v0.32 on a test machine first, before the agent touches real folders. Read our overview of local AI for European businesses if you are still weighing whether it fits your setup.
For a year Ollama was the easiest way to start a model locally. With v0.32 it becomes the easiest way to run an agent locally. The upside is real, and so is the duty of care.
Want to work out which of your workflows could be handed to a local agent safely? Our pilot project programme gets you to a working proof of concept in two to four weeks, with clear acceptance criteria.