Your agent isn't reasoning. It's averaging.

Call an unguided model's output "the average" and it sounds like an insult. It isn't one. The average is a real location in the training distribution, and like any real location it has a specific, nameable behavioral profile, the same way a specific occupation has a specific way of working.

Four behaviors show up there every time. The average does more than it was asked. It fills every gap it finds instead of reporting the gap. It quietly improves a plan it was told to execute. It produces fluent, plausible output without ever having weighed a real alternative.

None of this is misbehavior. An average helpful assistant behaves this way because that is the statistical center of "helpful" once you average it across a corpus with no single professional discipline attached to it. Naming the four behaviors is what makes them overridable; it turns prompt-writing from a matter of taste into a diagnostic loop, find the moment, name what the average does there, write the one specific thing that overrides it.

These four behaviors map one-to-one onto the five sections that follow. The page has a spine; it just isn't a metaphor.

Test: if you can't name the specific behavior a given moment in your prompt is defending against, that moment isn't actually covered yet.

"You are a helpful assistant that builds HTML pages" doesn't narrow anything. "Helpful assistant" and "builds HTML pages" are each, on their own, enormous regions of the training distribution. Averaged together they're still enormous. The model reads the sentence, samples from everything associated with "helpful" and everything associated with "HTML," and lands, predictably, on nothing in particular.

Naming a real occupation with a real, disciplined relationship to its own work compresses a large amount of implied behavior into one sentence, more efficiently than paragraphs of abstract instruction. A stonemason, an inspector, an archive researcher: each already carries a whole professional relationship to its own work, and the model already knows what that relationship looks like from everything it has read about the role.

The part that's easy to miss is that the analogy is doing double duty as instruction and as constraint. A stonemason handed a finished architectural drawing implies "don't redesign the building" without that rule ever being written down separately. A technical inspector signing off a building implies "don't move a wall you think is ugly." A printmaker pulling from an existing plate implies "don't redesign the plate mid-run."

Judge a candidate analogy by what it forbids, not by what it describes. An analogy that implies no refusal is decoration.

"Helpful," left undefined, has no edges. An agent told only what to do keeps being helpful past the point where helpful is actually welcome, filling gaps nobody asked it to fill, because nothing in the prompt told it where the job stops.

Every "What You Do" needs a "What You Cannot Do" right beside it. The Do list describes the job; only the Cannot list describes where the job ends, and the average has no natural stopping point without one.

A refusal written as a specific, situational sentence beats a general one, because a general refusal like "stay in scope" is itself an average: fluent, safe-sounding, and easy to talk yourself past in the moment. A specific one names the exact temptation.

page-builder.md: "Cannot decide structure. The section list, order, and close format are the Structure Spec's decisions, not yours to second-guess by rearranging or adding sections."

optimizer.md: "Cannot rewrite teaching content, card copy, or social/newsletter copy. If a sentence reads awkwardly to you, that is not a metadata or correctness issue; leave it."

The second is the more instructive of the two, because of its second clause. It names the exact moment the agent will want to break the rule, and answers it in advance.

Test: a refusal that doesn't name its own temptation is still operating at the level of the average.

Hand an agent someone else's decision to execute, and the average does something specific and easy to miss: it silently makes the plan better. Not from disobedience. "Be helpful," with no specific professional boundary attached, averages out to "make this as good as I can by any means available," not to "execute faithfully what was actually decided." An agent that privately thinks a plan is suboptimal will often improve it without mentioning that it did.

The fix isn't telling the agent to stop having an opinion. It's telling the agent where the opinion goes. page-builder.md, verbatim:

This same clause is quoted verbatim in one agent (page-builder, above) and restated near-verbatim in a second: card-builder.md carries it twice, once as identity ("you trust it completely, and a disagreement with it is a note for the checkpoint, not a license to invent different card content") and once as a Cannot ("You trust the approved Hero fields completely; if something in them reads badly to you as card copy, say so as a note, don't silently rewrite it"). Three more agents enforce it as an explicit What-You-Cannot-Do boundary rather than restating the prose: optimizer, social-copywriter, and newsletter-copywriter.

Test: suppressing the judgment and routing it are different designs, and only the second keeps the agent's judgment available to the human. A boundary that costs you the agent's opinion is a worse boundary.

Everywhere the prompt is explicit, the prompt wins. Where it runs out, the average wins, and the average's answer will sound reasonable enough that nobody notices it wasn't actually decided.

This isn't general-purpose "use your best judgment," which is itself an instruction to average. It's a specific, pre-decided answer for the one ambiguous case that agent's own domain is most likely to hit.

Not every agent in this team gets one of these. Six of the nine do: content-architect, page-builder, card-builder, social-copywriter, newsletter-copywriter, and optimizer. The other three carry no fallback heuristic at all, and that's the more interesting fact, not a gap to smooth over.

skill-builder.md: "If the input is ambiguous — you cannot tell which mode applies — ask before proceeding," and "A mediocre skill is worse than no skill: it gives agents false confidence that a decision is settled when it isn't."

spec-page-orchestrator.md, on its own checkpoints: "None of these are yes/no confirmations you resolve with a heuristic; they are real, required, blocking checkpoints, and you do not guess, paraphrase, or auto-proceed past any of them."

Test: every agent needs a pre-decided answer for its own ambiguous moment, and for some agents the correct pre-decided answer is stop and ask a human. What's never acceptable is leaving that moment undecided, because undecided is where averaging lives.

A fact this project has already settled, if it isn't written down anywhere the model reads it, gets re-guessed from the general distribution of what people usually do. The system gets no smarter about its own past decisions than an average model is about anyone's.

Pre-decided facts go in a skill. skill-builder.md states this team's own test for what belongs in one: "The content must answer: 'What would an agent have to guess from training data if this skill didn't exist?' If training data would get it right, the skill isn't needed. Write only what's project-specific or what represents a decision this team made." An exact hex value, an exact filter parameter, an exact voice rule: a skill hands the agent a real, already-settled fact instead of leaving it to average-guess an answer that's almost never precisely right for a project with its own real decisions already made.

Decisions made during a run get logged with the alternative that was rejected. Writing down what was not chosen, and why, resists exactly what averaging produces: fluent output that sounds right because it's statistically typical, not because a specific alternative was weighed and rejected for a specific stated reason. This isn't a field a tool enforces; skills/agent-log/SKILL.md's own flag table marks --alternatives as not required. What actually enforces it is each agent's own decision-logging triggers, which name the alternative explicitly. content-architect.md: "You choose the one insight over another candidate reframe the source could have supported — name the alternative."

The log feeds the prompt. log-analyst reads the accumulated record across many runs and promotes recurring decisions into standing principles written directly into the agent's own prompt: "A decision that appears 3 or more times with the same rationale, where the expected outcome was consistently met, should stop being a decision and become a standing principle in the agent prompt." That closes the loop. The system's own operating history becomes the correction mechanism.

Test: if an agent would have to guess a fact from training data, write it down where that agent reads it. If a decision recurs three or more times with the same rationale, it stops being a decision and becomes a standing principle.