Stop playing the game — design it, so self-interest produces the outcome you want.
Without scrolling back: your BATNA is…
Lessons 1 through 10 took the rules as given: a payoff matrix appeared, strategies were fixed, and your job was to predict what rational players would do. That's the forward problem. Mechanism design is the reverse: you choose the rules first.
You don't ask "given this game, what happens?" You ask "what outcome do I want, and what game — what rules, what incentives, what information flow — produces that outcome when everyone plays selfishly?"
Sometimes called reverse game theory, mechanism design is what you do when you have the power to set the structure: you're the platform, the market maker, the employer, the doctor designing the referral network, the engineer setting the reward function for your AI agents. The players respond strategically — and that's fine, because you've anticipated it.
You become the architect, not a player. That shift in perspective is the most powerful move in the entire arc.
The field is formalised in Hurwicz, Maskin, and Myerson's work — see SEP — Game Theory for a rigorous treatment. Dixit & Nalebuff, The Art of Strategy (Norton, 2008) gives the practitioner's view.
The central property of a well-designed mechanism is incentive compatibility: the rules are set up so that the behavior you want is also what each player wants to do for themselves. You don't need to police them. You don't need to catch cheaters. Self-interest does the work.
This is the dream: the equilibrium of the game you've designed is the outcome you wanted. If you engineered it right, every rational player following their own incentive lands exactly where you needed them.
An incentive-compatible mechanism makes honest or desired behavior each player's dominant strategy — they can't do better by gaming it, regardless of what others do.
Think of the concepts from earlier lessons: dominance (Lesson 1), Nash equilibrium (Lessons 4–5), backward induction (Lesson 7). Mechanism design is engineering those tools on purpose. You're not just finding the equilibrium — you're selecting the equilibrium you want by choosing the rules that produce it.
The practical question: can a player benefit by lying, hiding their true preferences, or gaming your system? If yes — the mechanism is broken, not the player. Fix the mechanism.
Open Yale ECON 159 (Polak), later lectures; SEP — Game Theory.
Here's the workhorse example — elegant, proven, and the logic behind the ad auctions you bid in every day.
Rules of a second-price (Vickrey) auction: all bidders submit sealed bids. The highest bidder wins — but pays the second-highest bid, not their own.
Remarkable result: bidding your true value is a dominant strategy. No matter what anyone else bids, you can never do better than bidding exactly what the item is worth to you.
Here's the intuition — plain, no algebra:
Contrast this with a first-price sealed-bid auction, where you pay your own bid. Now shading makes sense — you want to win but not overpay — so you have to guess what others will bid. Truth-telling is gone; strategy becomes a guessing game, and the mechanism is NOT incentive-compatible.
Why this matters for your ad auctions: Google's ad auction is a generalised second-price design. The intent is that honest bids (your true value-per-click) are the equilibrium. Understanding this tells you what the "right" bid actually is — and when the mechanism deviates from the textbook, where the gaming opportunity appears.
William Vickrey (1961), second-price auctions — Nobel-winning mechanism design result. Named Vickrey auction in his honour.
Some markets have no prices. You can't let the kidney go to the highest bidder. You can't let hospitals simply outbid each other for residents. So instead of prices, you match people to people — and the mechanism has to do the work that prices normally do.
The Gale-Shapley deferred-acceptance algorithm (1962) solves this. Participants submit preference rankings. The algorithm runs iterative "proposals" — players propose, others tentatively accept or reject, and the process continues until no one wants to switch. The result is a stable matching: no unmatched pair would both prefer each other to their current assignment. The algorithm can be designed so that telling the truth about your preferences is safe — you cannot gain by misreporting.
No two agents would both rather abandon their assignment for each other. Truth-telling is safe by design.
Kidney exchange (Alvin Roth) is the landmark real-world success. A patient with a willing but incompatible donor can't simply receive that kidney — blood types don't match. Roth's mechanism chains incompatible pairs together: your incompatible donor gives to a stranger whose incompatible donor gives to you. The mechanism solves a problem that prices literally cannot solve (selling organs is illegal), and it saves lives by making cooperation each pair's dominant strategy.
This is mechanism design at its most vivid: the market didn't exist until someone designed the rules that made it work. As a neurosurgeon, the logic is direct — you've seen what it means when matching mechanisms fail (cases lost to inappropriate triage, referrals going to the wrong specialist). A well-designed referral mechanism fixes this not by asking people to be altruistic, but by making the right referral the self-interested one.
Gale & Shapley (1962), stable matching — the foundational algorithm. Alvin Roth, kidney exchange — Nobel Prize 2012, mechanism design applied to market design. SEP — Game Theory.
Everything above assumes you hold the pen. Most days you don't — you're a participant inside mechanisms someone else built (the payer's fee schedule, the hospital's OR block system, the ad platform's auction rules). Know which seat you're in before you reach for this toolkit.
Diagnosing which seat you're in — designer or player — is itself the first design question. Get that wrong and you'll waste effort re-engineering rules you were never going to be allowed to change.
Every system you run is a mechanism. The question is whether you designed it, or whether it designed itself — badly.
Referral programs. You pay referrers R$X per booked consultation. If referrers game it by sending unqualified leads, the mechanism is wrong. Fix: pay on consultation-completed, not on lead. Now their incentive (getting paid) aligns with your goal (filled, quality appointments). Incentive-compatible.
AI agent coordination. Each agent in your fleet optimises its own local objective. If those local objectives conflict with the global goal — agents hoarding context, duplicating work, routing around each other — the reward function is the bug. Mechanism design for agent orchestration: define each agent's payoff so the fleet's Nash equilibrium is the outcome you want. The agents don't need to cooperate; they need to be pointed right.
The diagnostic question for any system you run:
The recap of the entire arc:
Your rep — the capstone, and it has to be real. Open DECISIONS.md and design one of two structural rows for real: D5 — the referral incentive scheme that rewards referrers without cheapening the relationship, or D8 — the verify/refute rules for your AI agent fleets so honest output is the self-interested output.
Copy learning-records/REP-TEMPLATE.md and fill Phase 1, adapted for a mechanism instead of a matrix: ① what outcome do you want the mechanism to produce · ② what do the players (referrers, or your agents) privately know or want that you don't · ③ what rule makes the desired behaviour their own best move · ④ can they game it — if yes, where does it leak · ⑤ your predicted equilibrium once the rule is live · ⑥ the one design choice you're least sure of · ⑦ the contraindication check — do you actually control these rules, or are you a player here too?
Then bring the drafted mechanism back to me and I'll pressure-test whether it's actually incentive-compatible — or just a matrix wearing a mechanism's clothes.
REP-*.md exists for D5 or D8 with Phase 1 filled by a real mechanism — not a worked example, not a matrix, an actual rule you could hand a referrer or an agent tomorrow. Delivered ≠ learned.Primary sources: SEP — Game Theory · Open Yale ECON 159 (Polak). William Vickrey (1961); Gale & Shapley (1962); Alvin Roth, kidney exchange. Dixit & Nalebuff, The Art of Strategy (Norton, 2008).
The four design questions: