Brief mode: condensed view. Switch to Full for persona notes and full analysis.

Subsidiarity

Don't do at a higher level what a lower level can do.

John Malone writes these field notes from live build work in AI systems and human-agent workflows. Receipts: GitHub · LinkedIn

Where it comes from

Rerum Novarum established the broader social framework, and Quadragesimo Anno articulated subsidiarity explicitly: higher-order authority exists to support lower-order function, not replace it.

The word comes from Latin subsidiarius: standing in reserve, acting as support. The principle isn't anti-hierarchy. It's a constraint on hierarchy: a higher tier may intervene when a lower tier is genuinely inadequate, not simply because the higher tier finds it more efficient to absorb the work. The concept has a long lineage in Catholic social thought and political philosophy.

The principle has traveled well outside Catholic social thought. It's structural logic. It applies wherever you have tiered systems and the temptation to concentrate decisions upward.

In AI agent systems

A multi-agent coding system typically has something like this stack: an expensive reasoning model at the top, a capable coding model in the middle, a fast cheap model for routine tasks, local inference for classification and summarization. The layers differ in cost, latency, and capability.

The subsidiarity question: does each tier only handle what the tier below can't?

In practice, the violation looks like this: the orchestrator runs reasoning cycles on tasks that could be dispatched to the coding model. The coding model reaches for expensive reasoning on tasks the fast model could handle. The fast model calls out to the cloud for work the local inference engine could do in milliseconds. Every upward bypass is a cost you're paying for no marginal quality.

The orchestrator failure mode deserves its own name: gravitational collapse. All decisions migrate upward because the top tier is available and it's never wrong to ask the smartest model. But the context window fills with trivia. The expensive tier spends cycles on tasks it's absurdly overqualified for. The queue backs up. The latency climbs. You've built a system where the senior engineer fields every support ticket.

This isn't just a systems problem. It's a management problem with a familiar shape: the tech lead who keeps grabbing the interesting work. The senior engineer who reviews a junior's PR by rewriting it. The architect who drops into implementation because it's faster than explaining the design. Every upward grab feels locally rational — the higher tier is more capable — and every one of them hollows out the tier below. The junior never learns. The mid-level never owns a decision. The senior burns out fielding work three levels below their role while complaining they have no time for architecture.

John Human Voice

I've watched this exact pattern kill team velocity at scale. The senior grabbing the interesting ticket isn't malicious — they just don't trust the system enough to let it work. The fix isn't a rule. It's building enough trust in the lower tiers that the reach-up reflex stops feeling necessary.

The inverse is just as damaging and harder to detect: the mid-tier that farms work downward while claiming the tier's compensation. You hire a general contractor at general contractor rates. The GC subcontracts every task to cheaper labor, pockets the margin, and never makes a design call or picks up a tool. You're paying for judgment, coordination, and quality control. You're getting a pass-through. The subs do the work. The GC captures the delta. The homeowner gets commodity output at premium prices and wonders why the trim doesn't line up.

John Human Voice

The GC analogy hits differently when you've actually hired contractors. The ones who add real value are the ones who show up and make judgment calls on-site. The pure pass-throughs are easy to spot in retrospect — they just never have an opinion about anything until the invoice comes.

In an agent stack, this is a mid-tier model that dispatches to a cheaper model and reformats the output without adding reasoning. The tokens flow through it. The cost accrues. The value doesn't. The subsidiarity test for any tier in a chain: are you doing work that only this tier can do, or are you just occupying a position?

Subsidiarity is the structural fix for both directions. Each tier exists to relieve the tier above it, not to escalate to it — and each tier must justify its position by doing work the tier below genuinely cannot. In a codebase, in an org chart, in a model stack — the failure modes are mirrors, and so is the remedy.

In gamification design

Every gamification element — badge, streak, leaderboard, level, XP bar — should pass a subsidiarity test before it ships.

The test: Is there a less interventionist mechanism that achieves the same behavioral outcome?

The intervention stack, from least to most intrusive:

1. Plain data display. Show the user what they've done. Numbers, dates, counts. No framing, no judgment.
2. Progress indicator. Show the user where they are relative to a threshold they set or agreed to. Still descriptive, minimally prescriptive.
3. Badge / achievement. Label a completed behavior. Adds social meaning and mild identity signal.
4. Streak / loss aversion mechanic. Creates a psychological penalty for stopping. Documented pressure on anxious users.
5. Leaderboard. Introduces social comparison. Motivating for users at the top, demoralizing for users below the median — which is most users, by definition.
6. Variable reward / slot machine pattern. Unpredictable reinforcement schedules. Effective. Also the mechanism behind compulsive use.

Each step up the stack reaches for a more powerful lever, which means a higher risk of harm. A plain data display can't hurt a user. A streak mechanic applied to a mental health app is a different matter.

Subsidiarity says: don't use level 4 if level 2 achieves the goal. The lightest sufficient intervention is the right one. This isn't squeamishness about engagement metrics — it's a design discipline. When you reach for a stronger lever before you've confirmed the weaker one fails, you're not engineering. You're hoping the hammer works because it's the biggest tool you own.

In frontier model design

The paternalistic gating anti-pattern shows up at the top of the AI stack, not just in product design. Frontier language models routinely override the user's judgment about what the user needs.

A security researcher asks for help analyzing an exploit they're professionally qualified to assess. Refused. A chemist asks about chemistry. Blocked. The model isn't evaluating the user's competence — it's applying a blanket ceiling because the training process penalizes engagement more than it penalizes unhelpfulness.

The subsidiarity violation is structural: the user is the lowest competent authority on what they need. They opted in by asking the question. The model — a higher-order system — absorbs that decision, not because the user is incapable but because the model's alignment training treats refusal as cheaper than risk.¹

John Human Voice

The "refusal as liability management" framing is the one that never gets named in public. The model isn't confused about whether you're a threat — it's just that the cost of a false negative (helping someone bad) is visible, and the cost of a false positive (refusing someone legitimate) is distributed and invisible. The incentive structure produces exactly this outcome.

This produces a specific kind of damage. Moral hedging dressed as safety: "I can't help with that, but here's a helpline" on topics that are uncomfortable but not harmful. Competence deflection: "I'm just an AI" on questions where the user explicitly asked for analysis. The system protects its own liability surface while claiming to protect the user.

The same guardrail applies: if a model restricts access "for the user's own good," the question is whether the restriction serves the user or the model's training incentives. Subsidiarity says the user's decision to ask is itself the signal of competence. A higher-order system may set defaults — it doesn't get to impose ceilings on consenting adults.

The recursive property

The principle applies to itself.

If a one-line convention achieves what infrastructure would achieve, don't build infrastructure. If a shared config file handles what a custom service would handle, don't run a service. If a comment in the code answers the question, don't schedule a meeting.

The lightest intervention that works is the right one. This sounds obvious. It isn't. The failure mode is constant: builders chase confidence, not novelty. Infrastructure feels like progress because you built something. Conventions feel like nothing because you wrote a sentence. But conventions compound without maintenance cost. Infrastructure demands your attention forever. One scales with the team. The other scales with whoever set it up.

A subsidiarity check on any proposed system: what's the minimum-tier intervention that handles this case? Does the case actually justify going higher? If the answer requires you to invent reasons, you're already past the subsidiarity line.

The tautua connection

There's a Samoan proverb: O le ala i le pule o le tautua. The pathway to leadership is through service. Tautua is service; pule is authority.

The proverb describes subsidiarity from the bottom up: authority is earned by demonstrating that you've handled what you can handle before you claim the right to delegate upward. Leadership is not the absence of hands-on work — it's the consequence of having done it.

In an AI system, the orchestrator earns its position by keeping its hands off work the lower tiers can do. In a product, the system earns the right to intervene behaviorally by demonstrating that lighter interventions were insufficient. The claim to a higher level of authority is always contingent on having exhausted what the lower level can handle.

But tautua runs both directions. The higher tier earns authority by staying in its lane — and the lower tier has to trust that it will. If the junior pre-escalates everything because they've learned the tech lead will rewrite their work anyway, the hierarchy is formally correct and functionally collapsed. The chain of command didn't fail from the top. It failed because the bottom stopped trusting it.

In an agent stack, this looks like tier erosion. If a fast model's output is routinely discarded or overridden by the tier above it, the system learns to skip that tier — not by design but by attrition. The tier collapses not because it was incapable but because it was never trusted to be capable. Subsidiarity describes what the higher tier shouldn't do. It only works if the lower tier believes it.

John Human Voice

I served in Samoa. Tautua isn't a management theory — it's how you earn the right to be heard in a room. You serve first. Not performatively, not strategically. Actually. The proverb only works if it's true of you, not just a framing you borrowed. The agent-stack reading is accurate. But there's something the technical framing can't capture: tautua is relational. It's not about tier positions. It's about whether the people around you believe you've done the work.

That's subsidiarity. Not a constraint on what you're capable of. A discipline about what you're willing to leave in someone else's hands. The test isn't whether you could do it better. The test is whether you trust someone enough to let them try. Every system that works is built on that trust. Every one that collapses lost it somewhere along the way.²

Read this article and analyze its core argument:
https://spitfirecowboy.com/workshop/0002-subsidiarity

Then answer:
1. Where does subsidiarity break down in your own toolchain or workflow — which tier is doing work it shouldn't be?
2. The article claims "easier" fails the subsidiarity test. Name a case where you've seen "easier" win and what it cost.
3. The tautua section argues that subsidiarity only works if lower tiers are trusted. How do you build that trust technically — not just structurally?
4. The paternalistic gating anti-pattern applies to both product design and frontier model alignment. What's the structural reason the same failure appears at both levels?

Be specific. Name the tools, the domains, and the gaps.