Turn Ollama v0.32 into a Scoped Local Dev Agent for Your Repository

On July 11, 2026, Ollama shipped v0.32.0 and quietly changed what its bare command does. Running ollama with no arguments no longer prints help text: it drops you into an interactive agent that chats, writes code, executes commands, and searches the web, all against a locally served model. The v0.32.1 follow-up on July 16 feeds the agent your current working directory, which turns it from a novelty into a repo tool. In this tutorial you will upgrade to Ollama v0.32.1, pick a model that fits your machine, scope what the agent is allowed to execute, and wire it into a daily dev workflow where your code never leaves the laptop and the token bill stays at zero.

Ollama spent two years as a model runner: ollama run qwen3.5 gave you a chat prompt and nothing else. v0.32 puts an agent loop in the binary itself. The loop can call tools, and the tools it ships with are the consequential part: shell execution, file access, and web search. The same command you have typed since 2024 now has hands.

The design follows the pattern every agent CLI converged on this year: a reasoning model, a tool schema, and a permission prompt between the two. The difference is that with Ollama the reasoning happens on your GPU, which changes both the privacy story and the economics. There is no metered tier to outgrow. (There is also no one to call when it is slow; local trades a bill for a workload.)

An agent with shell access is exactly as dangerous as the shell you give it. Scoping means three concrete decisions: which directory the agent sees, which commands it may run without asking, and which model drives the loop. Ollama v0.32 makes the first decision for you via the working directory. The other two are configuration, and this tutorial treats them as the main event. An unscoped local agent is not safer than a cloud one just because the weights are nearby

Upgrade first. The agent experience needs v0.32.0 or later; the working-directory context needs v0.32.1.

Model choice sets the ceiling on everything that follows. A 4B model triages and drafts; a 14B model refactors credibly. Run both, give them the same task, and keep the smallest one that passes. Local inference is a budget game where the currency is RAM, and spending it on parameters you do not need is how laptops become space heaters.

Launch the agent from the repo root so v0.32.1 hands it the right directory:

Then make the context durable. The agent reads the conversation, but your repo conventions should not live in your typing. Put them in a project file the agent can read on demand:

Now the first instruction in any session is one line: "Read AGENT.md before doing anything." The file is doing the job an onboarding conversation does for a new hire, and like the onboarding conversation, its value shows up the third time it prevents the same mistake.

The agent will propose commands. You decide the standing policy instead of adjudicating every prompt. Keep an allowlist in your shell profile and let the agent see it:

This is policy-as-context: the model reads the rules and follows them the way models follow instructions, which is to say usually. The enforcement backstop is Ollama's own confirmation prompt on execution; the rules exist so that what the agent proposes is already inside the fence, and the prompt becomes a formality instead of a judgment call at 6pm.

Commits stay human on purpose. A local agent that writes code, runs the tests, and then pushes the result has removed the only checkpoint where you actually read the diff.

The payoff is the daily loop. Three tasks the scoped agent does well on a 14B model, all offline:

Notice what all three prompts share: they name the commands, they bound the action, and they end before anything mutates. The agent investigates; you decide. That division holds because the prompts encode it, not because the model knows better.

| | Ollama v0.32 local agent | Cloud agent CLI (Claude Code, Codex) | |---|---|---| | Where code goes | Nowhere | Provider infrastructure | | Marginal cost | $0 | Metered tokens | | Model ceiling | Best open model your RAM fits | Frontier | | Offline | Fully | No | | Long multi-file tasks | Strained on small models | Strong | | Setup honesty | You manage RAM, quantization, updates | Vendor manages everything |

The two columns are not rivals so much as a routing decision. Frontier-hard refactors go to the cloud CLI; everything private, repetitive, or offline goes local. Teams that pick one column for ideological reasons pay for it in the other currency.

- A 4B model does not become senior because you scoped it. Small models confidently propose plausible wrong fixes; the pytest run in the loop is what keeps them honest. - It does not enforce your never-run list cryptographically. It is context plus a confirmation prompt, and a distracted yes at the prompt is still a yes. - It does not index your repository. The agent reads files when told; it has no persistent memory of the codebase between sessions beyond what AGENT.md carries. - It does not do team governance. One laptop, one policy file. Five engineers with five different AGENT.md files is five different agents wearing one name.

A complete session setup, from clean machine to first scoped task:

Save it, chmod +x scoped-agent.sh, and start every session with ./scoped-agent.sh ~/work/billing-service. First message in the session: "Read AGENT.md, then run git status and summarize where this repo stands."

Use the Ollama v0.32 agent when the work is private, the tasks are bounded, and the loop runs many times a day: pre-review, triage, convention sweeps, log spelunking. Skip it when the task needs frontier reasoning across twenty files, and use a cloud CLI with your eyes open about what you are sending. The interesting shift is not that local caught up to hosted, because on raw capability it has not. It is that the runner you already had became an agent while nobody was watching, and the cost of finding out what it is good for is now one command.