Multi Model Delegation

Multi-Model Delegation

Protocol for consulting other models — kimi, glm, gemini, gpt via the PAL MCP gateway (chat, consensus) — on design and judgment work, and for acting on what comes back. The core insight, which inverts the naive approach:

The value is the disagreement, not the union. Two competent models briefed identically converge on the obvious 80% — the part you'd have written anyway. Where they split is a precise pointer at the one decision that is genuinely load-bearing and underdetermined by the prompt. Resolve the split against the codebase — which usually already decided, and which the models structurally cannot see — never by picking the more confident model.

Treat delegated models as idea generators, never as authorities. Taking the majority answer, or the more confident one, launders a coin-flip into a decision that merely looks researched.

You — the orchestrating Claude session — run the whole consult: you dispatch the PAL MCP calls, collect the replies, and do the judgment steps (diff, adjudicate, synthesize) yourself in the main loop.

The Tool Prefix Is Derived, Not Fixed

PAL's tools are reachable as mcp__<server-name>__<tool>, where <server-name> is the key the server is registered under — not the product name, and not the binary. That key can live in any registration scope: a project .mcp.json, a user-scope entry in ~/.claude.json (claude mcp add -s user …, which has no .mcp.json at all), or a local one. So read the registration rather than a file — claude mcp list is authoritative in every scope, and claude mcp get names the scope that owns it:

claude mcp list                 # "pal-mcp-server: pal-mcp-server  - ✔ Connected"
claude mcp get pal-mcp-server   # Scope: Project config (shared via .mcp.json)

With the common registration pal-mcp-server, chat is mcp__pal-mcp-server__chat; a repo that registers the same binary under a different key gets that key in the prefix instead. Every mcp__pal-mcp-server__* name below assumes that registration — substitute the key claude mcp list reports.

If a lookup under the correct prefix still finds nothing, see REFERENCE.md — that message has a second cause.

When to Use This Skill

The Protocol

Execute a multi-model consult in these steps:

Step 1: Resolve model IDs first

Run mcp__pal-mcp-server__listmodels once at the start of the consult whenever a model is named loosely ("kimi2.7", "glm5.2") — registry IDs (kimi-k2.7-code, glm-5.2) and their aliases (kimi, glm) rarely match what anyone types from memory.

Step 2: Brief every model with the same prompt

Send the identical brief, verbatim, to each model — one mcp__pal-mcp-server__chat call per model — and collect every reply before judging any of them. Different prompts produce divergences that are artifacts of the framing, not of the problem — and afterward you cannot tell a real design tension from a wording accident. Pass code via the absolute_file_paths parameter rather than pasting it into the prompt: it is what the parameter is for, and the pasted copy risks truncation. Attachments carry a per-model token budget that a multi-file set routinely exceeds — when it does, build one curated excerpt bundle rather than trimming per model (see below).

Step 3: Keep round one independent

Withhold model A's answer from model B. You want independent draws, not an echo. Cross-critique is a deliberate later round, never the first one.

Step 4: Diff the answers for the split

With every reply collected, compare them point by point:

• Convergence → the safe default; adopt it and move on.
• Divergence → this is the actual decision, and it is now yours — not theirs. Don't ask "which answer do I take?" Ask "what did they disagree about, and what in my codebase already decides it?"

Step 5: Adjudicate against the code, not taste

Go read the thing the decision turns on. Very often the codebase has already decided, and the models couldn't know because they can't see it. This is the step that makes the whole exercise worth its tokens.

Step 6: Graft, never adopt wholesale

Even the winning proposal carries ideas that are wrong for your repo. Graft the good parts from the runner-up; reject what doesn't fit and say why.

Canonical case (gh-board priority grading, 2026-07): kimi-k2.7-code and glm-5.2, identical briefs. They converged on the module shape and config-first weights, and both independently proposed a contribution ledger — the one idea not already in hand, and the one convergent idea worth keeping. They split on exactly one question: does the triage bucket feed the priority score, or sit above it? One minute in src/app/filter.rs settled it — build_rows already groups into bucket sections after sorting, so a bucket baseline would double-count the grouping. Both models also proposed an A–F letter grade; both were overruled — grade bands stack a second set of magic thresholds on the weights and quantize away the fine ordering the score exists to produce. The models produced the question; the repo produced the answer.

Step 7: When a claim is refuted, ask the second question

Step 5 adjudicates "is this claim true?" against the code. When the answer is no, the instinct is to discard the claim and move on. Don't — ask the second question first:

"Why couldn't the test suite answer this?"

That question survives a wrong claim. A confident, specific, false finding usually points at something real — not the defect it names, but the absence of a gate that would have settled it in seconds. The claim dies; the gap it exposed does not.

The move: add the gate that decides the question, then kill-test it by swapping in the reviewer's proposed value. If the reviewer was right, the gate goes red and you have found a real bug. If they were wrong, it goes red on their version and green on yours — converting an argument into a permanent, mechanical answer, so neither the next reviewer nor the next session can re-litigate it.

Canonical case (loractl verbosity review, 2026-07): kimi-k2.7-code claimed flag_directives emitted a loractl= tracing target matching nothing — because the package is loractl-cli — which would make the entire -v ladder inert. It was wrong: [[bin]] name = "loractl", so module_path! roots at loractl, and a live -v run had already printed INFO lines. But the claim was unfalsifiable from the suite, because the unit test asserted the directive string and never that the filter matched a real event. Fix: a spawned-binary test pair (-v must show INFO, default must not), then a kill-test swapping in the reviewer's loractl_cli= — which fails it. Wrong claim, real gap, permanent gate.

The generalization beyond model reviews: a test that asserts the shape of a value rather than the behaviour it produces cannot settle a question about that behaviour — it passes whether the wiring works or not. Those are exactly the tests an outside reviewer's wrong guess will find for you.

When It's Worth the Tokens

PAL Mechanics That Bite

When PAL's MCP server is not connected, the same models are reachable directly over the OpenCode Go gateway — see REFERENCE.md for that route's three failure modes.

The Curated Excerpt Bundle

When the load-bearing code spans more than the smallest model's attachment budget allows, do not trim per model — that silently un-identicals the briefs. Build one file and attach it to every model:

1. Write it inside the workspace: <repo>/tmp/<consult>/context-excerpts.md.
2. Include verbatim excerpts of exactly the load-bearing regions — no paraphrase; the whole point is that the models read the real code.
3. Number the sections (§1…§N), each titled with its real file path + line range, so a cited §7 resolves back to source.
4. The smallest model's budget bounds the bundle. Size the whole file under it, then attach that one path to every model.
5. Reference sections from the brief by number ("weigh §3 against §9").

Canonical case (loractl #132, 2026-07): a 7-file, ~84K-token attachment set bounced on both gpt-5.3-codex and kimi-k2.7-code. An 11-section bundle at ~21K tokens fit all three budgets, kept the briefs byte-identical, and the models cited sections accurately.

Agentic Optimizations

Related

• parallel-agent-dispatch — delegating work to Claude subagents: those are delegates producing output; this skill's models are second opinions producing judgment
• agent-teams — implicit-team / SendMessage mechanics for Claude teammates
• adversarial-review — inverted-objective second pass on a finished artifact, by an isolated Claude reviewer
• verify-before-plan — the same adjudicate-against-reality instinct, applied to orchestrator premises before a dispatch

For the second cause of an empty deferred-tool lookup and the direct OpenCode Go gateway route (model enumeration, streaming, reasoning-budget exhaustion), see REFERENCE.md.