>> the local model runtime
Running a model locally is the easy part. Ollama installs, pulls a model, and answers. The harder question is what role that model should have in a system that already has tools, contracts, and a release flow. If the answer is "it decides things", the system gets worse. If the answer is "it does a bounded job well", it gets better.
In the MQ stack the integration is deliberately small. mq-agent does not
hard-code a model name anywhere. It keeps named profiles — fast,
review, planner, memory — and each profile
maps to whatever local model currently does that job best. The mapping lives in
a small JSON file, not in the code. Swapping a model is config, not a refactor.
The command surface is read-only by default:
models current shows the active profile,
models list reports what is installed locally,
models bench runs a small prompt against the selected model.
Only models switch writes anything, and it refuses to do so without
an explicit --approve flag — without it, the command reports what it
would change and stops. Dry-run is the default, everywhere it can be.
The same discipline shows up in how the runtime is checked. The operator dashboard and the stack gate both probe Ollama, but a missing Ollama is not a crash — it is a status. The check reports "ollama CLI not found", suggests installing or starting it, and the rest of the command surface stays usable. An optional dependency should degrade to a message, not take the tool down with it.
The most interesting part is the boundary drawn around learning. A local model is
a good pattern extractor: give it review findings, get back structured JSON.
That is a narrow, verifiable job. So the extraction may run on Ollama, but the
contract, the validation, the safety classes, and the storage stay in
mq-mcp. The model does not execute commands, does not mutate
repositories, and cannot write to memory on its own. Storage requires explicit
approval from the operator, and low-confidence records never get stored automatically.
Text inside reviewed content is treated as data, never as instructions. That rule sounds obvious until you notice how many pipelines quietly break it by pasting untrusted output straight back into a prompt.
None of this makes the local model impressive. That is the point. The value is not that a model runs on the machine — it is that the system stays predictable when it does, and keeps working when it does not.