version: "1.0.0" name: auto-agent-max description: "Use when the user wants the ceiling off subagent spawning — they say \"/auto-agent-max\" (optionally followed by a number capping how many subagents), ask for maximum capability, peer-tier subagents, no model downgrade, or the best possible result regardless of cost. Removes the tier cap so the orchestrator may spawn same-tier subagents, while still sizing each one to the task."

/auto-agent-max

Remove the tier ceiling. A subagent may run the same model as the orchestrator when the subtask genuinely warrants it.

Usage: /auto-agent-max — the agent count is yours to judge. /auto-agent-max 10 — a hard ceiling of ten subagents.

What This Changes, And What It Does Not

It changes exactly one thing: the cap. From the top tier you may now spawn peers, which /auto-agent-eco forbids.

It does not change the routing discipline. "Max" is not "put everything on the biggest model" — that is not maximum capability, it is maximum spend with a side of latency. A top-tier agent sent to run grep across a directory returns the same answer as a cheap one, slower and dearer, and having four of them queued behind a rate limit is worse than the eco version that finished.

So the question every subagent still has to pass is the same one: what does this task actually need? The difference is only that "the top tier" is now an available answer instead of a forbidden one.

When A Peer-Tier Subagent Is Genuinely Right

Reach for one when the subtask carries the same difficulty as the orchestration:

• Adversarial verification of a consequential claim. Whatever tries to refute a finding should be

at least as capable as whatever produced it. If a top-tier agent found it, a top-tier agent should attack it.

• Independent attempts at a hard design, where the value is genuine diversity of approach rather

than parallel throughput. Three peers reasoning separately, then judged, beats one attempt iterated when the solution space is wide.

• Deep reasoning over unfamiliar territory — an undocumented protocol, a subtle concurrency

defect, a build system misbehaving for non-obvious reasons.

• Work whose failure is expensive and quiet: security review, licensing judgments, anything that

ships and misleads if it is wrong.

When It Is Still Wrong, Even Here

• Locating code, inventorying files, running builds, applying a stated edit — these do not improve

with a better model, and the queue they create is a real cost.

• Anything where the answer is verifiable by execution. Let something cheap produce it and let the

test say whether it is right.

• Padding a fan-out to look thorough. Six peers on a three-agent problem is not rigour, it is six

agents rediscovering the same context and then disagreeing about it.

Peer Agents Change The Merge

A cheap subagent that goes wrong is usually obviously wrong. A peer-tier one that goes wrong is plausibly wrong — same fluency, same confident tone, same shape of evidence as a correct answer. That makes contradictions between peers harder to spot, not easier.

So the orchestrator's job gets harder rather than easier as the tiers rise:

• Read peer results against each other, not in sequence. Two peers reaching different conclusions

from the same code is the most valuable signal a fan-out produces, and it is invisible if you merge them one at a time.

• When peers disagree, resolve it against the source, not by preferring the better-written answer.
• Never treat agreement between peers as verification. Two agents given the same prompt and the same

context are correlated, not independent, and they can be confidently wrong together. If independence matters, vary the lens: give each a different angle of attack rather than the same brief.

The Agent Count

A number after the command is a hard ceiling: /auto-agent-max 10 means never more than ten, regardless of how the work decomposes.

With no number, choose from the work and say why. Two things still bound it, and neither is loosened by this skill:

• Resource limits are not negotiable by a capability policy. If /auto-balance has sized this

session, that number is a ceiling. Peer-tier agents are heavier per agent, not lighter — on a contended machine or against account limits, max mode reaches the wall sooner than eco does.

• Rate and usage limits are real. A fan-out that exhausts the session's budget partway leaves the

work half-done, and half a review is worth much less than a completed smaller one. If the budget is tight, prefer fewer peers over more, and say that is what you did.

Report The Spend

State the fan-out: how many subagents, at which tiers, and why each peer-tier agent needed to be one. "It was max mode" is not a reason. If the answer would have been the same at a lower tier, that agent was waste and is worth naming, because the next run can be cheaper for free.

Rationalization Table

Red Flags — Stop

• Assigning top-tier agents to mechanical work because the ceiling is off
• Treating peer agreement as verification
• Merging peer results sequentially instead of against each other
• Exceeding a user-supplied ceiling, or overriding /auto-balance's number
• A fan-out that exhausts the budget and leaves the pass unfinished
• Reporting the result without reporting what the fan-out actually cost