McAmner Journal note

mq-agent

Local AI agent orchestrator.

On keeping the model out of the way until it is needed.

>

>> mq-agent

mq-agent is a local-first control plane for AI agent work: planning, execution, verification, memory, safety, and tool routing. It is built around one principle. The model should not rule the system. The system should rule the model.

Most AI tooling puts the model at the center. You describe a task, the model decides how to fulfill it, and you watch what happens. mq-agent starts from the opposite assumption: the model is one component in a pipeline, not the pipeline itself.

The agent connects to mq-mcp — a local MCP server that exposes tools for repository analysis, architecture decisions, code review, diagnostics, and controlled execution. When you run a command such as review, audit, score, doctor or release-check, the agent does not improvise freely. It routes the request through a defined command surface, calls the right tool, receives structured output, and renders the result back to the operator.

The model routes, explains, and formats. The tools do the work. The contracts define the boundary. The human keeps authority.

The command surface was a deliberate constraint. Each command maps to a specific kind of work. There is no open-ended prompt interface because there does not need to be. A well-defined task needs a well-defined command, not a general-purpose chat window pretending to be an operating system.

That constraint is the architecture.

A command is easier to test than a conversation. A contract is easier to verify than an intention. A release gate is safer than trust. A small surface is stronger than a large one.

The integration with mqlaunch follows the same logic. The menu delegates to the agent, the agent calls mq-mcp, and the result surfaces in the terminal. Nothing leaves the machine unless explicitly asked. Local infrastructure. Local model when possible. Local context. Local judgment.

This is not about making an agent more autonomous. It is about making automation more accountable. The useful question is not how much the model can do. The useful question is what the model should be allowed to do, under which conditions, with which proof, and with which rollback path.

Architecture memory is stored through mq-mcp as a list of decisions — not only as diagrams, not only as documents, but as queryable records. When a review runs, the agent can pull the relevant decisions and display them alongside the findings. Context that was previously implicit becomes part of the output.

That changes the shape of the work. A codebase is no longer only files. It becomes decisions, contracts, signals, gates, history, and memory.

The interesting thing about building an agent is discovering how little the model actually needs to do. The hard work is not the prompt. It is the tool design, the routing, the contracts, the safety boundary, the verification loop, the memory surface, and the release discipline. Get those right and the model becomes almost invisible. That is the point.

Built for control, not chaos. Local-first. Contract-driven. Release-gated.

>> post commands