Local AI agent manager for Mac and Windows

Trace one failed handoff before adding agents

Imagine asking an agent to fix a failing test. It finds the component, edits it, runs the test, and reports success. The test passes, but the command regenerated an unrelated file that nobody reviewed. Adding a Reviewer after the fact cannot repair the missing boundary between a proposed edit, command approval, and final acceptance.

A local AI agent manager should expose those transitions: which agent owns the task, which model it uses, what context it receives, which tools it calls, and who accepts the result. Zimmer AI is a local-first workspace for open-weight models on a personal Mac or Windows PC. With a local model, prompts, source code, documents, and answers stay on that machine. Zimmer Server addresses a separate need: a multi-user appliance on company-owned Apple-silicon hardware for private team networks.

Start with one capable agent. OpenAI's agent-building guide advises adding specialist agents when a single agent's instructions or overlapping tools become hard to manage. A new role earns its place when it brings independent context, a distinct tool boundary, or a separate acceptance job.

Locate the real capability boundary

Multi-agent systems help when roles are clear and create risk when boundaries are vague. A name such as Reviewer is an instruction, not a security control. The relevant questions concern files, tools, model endpoints, and who can approve action.

For a real repository task on Mac or Windows, inspect each transition:

• Who owns the next step? The Coder should not quietly become the Reviewer.
• Which model is assigned? A fast local model may be right for cleanup, while a stronger model may fit planning.
• What context is visible? Selected files beat dumping the whole repo into every task.
• Which tools are allowed? Read-only search is different from file writes or shell commands.
• How is work handed off? A handoff should include goal, constraints, current state, and acceptance criteria.

Zimmer's harness exposes nine tools: read_file, grep, edit_file, write_file, run_command, todo_write, spawn_agent, use_skill, and mcp_tool. Reading is different from writing; a command may change more than one file; an MCP call may reach an external service. Decide which capability the task actually needs before approving it.

Map six built-in roles to evidence

Zimmer ships Assistant, Coder, Reviewer, Tester, Refactorer, and Documenter. You can also create custom agents with their own instructions and model assignments. These are starting roles, not a reason to run six agents on every task. A small fix may need only Coder and Reviewer.

Assign the model to the job, then evaluate it with a real repository task. A fast local model can help with summarizing or reading; a harder implementation may need a stronger model. The role does not make a weak model reliable. Keep the expected output concrete enough that a person can check it.

Put approval where the action happens

Zimmer's Allow, Ask, and Deny permission tiers distinguish reading from file writes, shell commands, and connected tools. Read-only operations and safe commands can be pre-approved; other actions present the exact request with allow once, allow always, or deny. Destructive commands are denied by default. Every proposed edit appears in a side-by-side diff for acceptance before it touches disk.

In the failing-test example, a handoff from Reviewer to Coder should identify the target files, intended behavior, known risk, and the test that would demonstrate success. A handoff from Coder to Tester should report what changed and the smallest useful verification command. The parent agent remains responsible for reconciling those reports and accepting the diff.

Reviewer -> Coder handoff
- Goal: fix the specific failing state, no refactor
- Files: only the selected component and test file
- Constraints: keep public API unchanged
- Verify: run the existing focused test
- Stop: ask before shell commands or broad rewrites

Visual Studio Code's approval documentation also separates file changes, terminal commands, and external requests. The practical rule is independent of the product: grant the narrow action needed at the moment it occurs, and inspect the result.

Bound subagents and model expectations

Zimmer can hand work between agents, show two agents side-by-side, or delegate with spawn_agent. The spawned agent receives isolated context, works for up to eight tool rounds, and returns a summary. A parent turn can use up to 15 tool rounds. Those limits bound a loop; they do not certify that the work is complete or correct.

Give the subagent a narrow contract: question, relevant files, constraints, expected evidence, and a stopping point. Ask Reviewer to find a broken assumption, not to “improve the project.” Keep the parent responsible for acceptance. Microsoft's subagent guide likewise stresses explicit context and expected output when the coordinator will receive a focused summary.

Zimmer Desktop runs local GGUF models and the agent harness on both macOS and Windows. Its Model Hub sorts candidates by RAM, chip, and free disk. On Apple silicon, 16 GB with a 4B-class Q4 model is a practical floor for useful coding; 32–36 GB is more comfortable for 14B-class models. That Mac guidance is not a Windows GPU performance claim. MLX and system-wide voice are Mac-only features, separate from the agent workflow.

Hosted frontier models from Claude, GPT, and Gemini will outperform laptop-size local models on many demanding tasks. Local inference trades peak capability for privacy, ownership, and predictable cost. Zimmer also is not a full IDE replacement. If you connect a hosted model or an external MCP service, review its separate data path. For the local path, see model fit, agent controls, and connector access.

Questions before you delegate

Test the control plane on one repository task

Choose an existing failing test. Ask Assistant to define the finish line, Reviewer to locate evidence, Coder to propose one focused edit, and Tester to run the smallest approved check. Reject unrelated files in the diff. The exercise fails if the agent expands scope without asking, cannot explain a tool request, or claims success without the actual test result.

This tests an agent manager more directly than a list of features. Repeat the same task in another tool and compare the evidence trail: what the agents saw, which commands ran, what was approved, and what finally changed. The local coding assistant comparison provides a broader repository acceptance lab.