L E D G E / A D VA N C E D C O U R S E Designing and Operating — Advanced Course Multi-Agent Systems 7 Lectures — From the organizational theory of text files to the engineering of learning and operations
of the 7 Lectures Lecture Theme Goal of this lecture L1 Overview — The Organizational Theory of Text Files Explain your whole team of agents as a single architecture diagram L2 The Design of Team Composition Predict a team’s output habits just by looking at its member list L3 Principles of Interaction Design Read and build any discussion pattern as a combination of 5 levers L4 Pattern Catalog by Purpose Instantly assemble composition + discussion pattern from "what I want to raise right now" L5 The Engineering of Learning Loops Explain the difference between "records piling up" and "getting smarter," and design the latter L6 The Engineering of Organizational Operations Design a system that stays healthy 3 months later, not just right after launch L7 Tips Compendium & Capstone Sweep through field-level techniques and integrate every lecture in a capstone project
A R C H I T E C T U R E Overview — The Organizational Theory of Text Files Goal of this lecture: be able to explain your whole team of agents as a single architecture diagram
R C H I T E C T U R E What you're really running is "a company made of documents" Command layer CLAUDE.md Read automatically every session. Persona, principles, prohibitions Procedure layer .claude/skills/.../SKILL.md Read in full only when invoked by a /command. A process sheet Fact layer data/ memory/ logs/ Read only when the AI goes looking. Accumulated records, standards, learning Persona layer .claude/agents/*.md A sub-agent's job description (judgment criteria, viewpoint) These 4 layers differ in when they get read Lecture 1 — Overview: The Organizational Theory of Text Files
R C H I T E C T U R E Which layer to write in isn't about content — it's decided by when you want it read Layer When it gets read So what to put there If misplaced Command Every time, unconditionally Short principles, persona, prohibitions A long procedure here gets skimmed past in a long conversation Procedure Only when invoked, in full Steps that must never be skipped A principle here gets ignored in sessions that never invoke it Fact Only when referenced What you grow (standards, records) A command here has no guarantee of being read Persona When a sub-agent is invoked Judgment criteria, viewpoint, what not to do A procedure here fuses persona and process, killing reusability Lecture 1 — Overview: The Organizational Theory of Text Files
R C H I T E C T U R E The 4 layers in practice — inside an investment team Layer Real example (excerpt) Why that layer Command CLAUDE.md: "Always look up held-stock prices yourself, every time. Don’t defer to the user." A principle to enforce every time, in chat or scheduled tasks alike Procedure /review skill: "① required reading → ② market check → ③ save report → ④ log lessons" A process sheet only needed weekly. No need to read it every time Fact portfolio.csv (holdings), investment-philosophy.md (investing philosophy) Changes weekly. Something to grow Persona Expert agent: "Speak from the perspective of scouting growth companies on the ground" A judgment axis summoned only for discussions Lecture 1 — Overview: The Organizational Theory of Text Files Put "check the stock price yourself" in the procedure layer, and it's ignored on any day the skill isn't invoked
R C H I T E C T U R E The economics of context — "what gets read" is a finite resource What you let the AI read is an allocation problem, just like a budget 1 Always-loaded content is a luxury Keep CLAUDE.md down to only the principles that would cause an accident if missing 2 Lazy-load by default Put only a pointer (one reference line) in the command layer; keep the content in the fact layer. Specify the reading order too 3 Watch parent-folder inheritance A parent shared by multiple teams should be a thin file with only a 'map'. A leftover old instruction file contaminates every team's persona Lecture 1 — Overview: The Organizational Theory of Text Files
R C H I T E C T U R E Core thesis — Don't grow the agent, grow the data Fact layerhigh frequency, low risk > Procedure layer > Command layer > Persona layerlow frequency, high risk — 90% of improvements are just "add one line to the fact layer." The diff is clear, and if it breaks you just delete the one line — Rewriting the persona (prompt) is a last resort — it shifts overall behavior in ways you can no longer trace — Side benefit: your team's intelligence becomes a visible asset — explainable to others, portable to new teams Lecture 1 — Overview: The Organizational Theory of Text Files
R C H I T E C T U R E The org-wide architecture — hub and spoke Shared notes (the hub) Personal status (updated weekly) / values / cross-cutting lessons / team roster Team A Team B Team C Team D Each team only "reads" the hub. Cross-team links stay thin — one team fetching a specific file from another No dependencies, only references If the hub disappears, each team still works. Coordination is reference-only One source of truth Never let two teams hold the same information. Declare "the finance team owns finances, everyone else just reads" Lecture 1 — Overview: The Organizational Theory of Text Files
R C H I T E C T U R E This course's "full map of design variables" Design area Variables Covered in Composition (who to place) Splitting principles, headcount, personas, reviewer, synthesizer L2 Interaction (how to make them talk) Visibility, order, repetition, feedback, framing L3–4 Learning (how to get smarter) Closing the loop, scoring, promotion L5 Operations (how to keep it running) Schedule, definition of done, detection automation L6 Lecture 1 — Overview: The Organizational Theory of Text Files The goal of this course: turn a "vaguely good team" into "a bundle of adjustable variables"
1 5 M I N Exercise 1 — Audit an existing team into the 4 layers 1 Classify Sort the team's files into command / procedure / fact / persona 2 Find the mistakes Typical case: a long procedure inside CLAUDE.md, or a critical rule with no guarantee it gets read 3 Move one thing 'Procedure → turn into a skill' should be the most common fix before CLAUDE.md has a 10-line process written directly inside it Skimmed past in long conversations after The process moves to a /weekly-review skill CLAUDE.md keeps only a 1-line reference Lecture 1 — Overview: The Organizational Theory of Text Files — — — —
U M M A R Y Lecture 1 summary 1 The 4 layers (command, procedure, fact, persona) differ in when they get read. Where you write something is decided by when you want it read 2 What gets read is a finite resource. Always-loading is a luxury; lazy-loading (pointer style) is the default 3 Improve starting from the fact layer. Holding intelligence as data makes it visible, reversible, and portable Lecture 1 — Overview: The Organizational Theory of Text Files
T E A M C O M P O S I T I O N The Design of Team Composition — Who, How Many, How to Place Them Goal of this lecture: predict a team's output habits just by looking at its member list
E A M C O M P O S I T I O N The 3 principles of splitting — there are only 3 reasons to split agents apart 1 Clashing judgment axes Split when two standards can't coexist in one mind — a writer and an editor. The clash itself is the value of division 2 Information separation Split when you want to change what each side sees. 'Independent review' and 'role-based information blocking' both require a split to design 3 Authority separation Split when you want to change what's allowed. 'The reviewer only reads' / 'only the recorder writes logs'. Prevents accidents Test: a new-member proposal that fits none of the 3 principles just adds a "job title." Don't create it Lecture 2 — The Design of Team Composition
E A M C O M P O S I T I O N A persona isn't verbal decoration — it's the strategic core Observation — Repeated Prisoner's Dilemma experiment — An "Inamori Kazuo" persona held to cooperation through 5 straight rounds of betrayal. Philosophy became strategy directly — A "Machiavelli" persona spontaneously produced a multi- move plan: fake cooperation to build trust, then exploit it on the final round — Every choice each made, every round, traced back to that persona's own philosophical vocabulary Interpretation A persona's value isn't tone of voice — it's giving choices a consistent rationale "Macro-economics lead" alone returns a textbook average. Write "thinks in terms of big cycles, like Ray Dalio" and judgment gains an axis and a bias. Role × person is the standard formula Lecture 2 — The Design of Team Composition
E A M C O M P O S I T I O N Composition and interaction are two independent levers Compositionwho to place × Interactionhow to make them talk = Character of the output — Observation: with the same discussion pattern, swapping 3 editor personas for 3 designer personas swapped the whole output — from "essay drafts" to "system-design proposals" — Elaborate discussion patterns don't matter if the composition is homogeneous — the output stays homogeneous Lecture 2 — The Design of Team Composition
E A M C O M P O S I T I O N A composition template — 5 basic positions Position Role What it changes Example Viewpoint holder (2–3) The core bodies, each thinking on its own judgment axis Viewpoint distance decides diversity 3-investor panel Reviewer A dedicated role for rejecting proposals Filters out mediocrity, raises the quality floor Instantly rejects "the existing app is enough," with a quota Synthesizer Integrates the discussion, translates into the user’s own words Turns discussion into a readable report — watch for manufactured consensus Investment advisor Researcher Gathers facts/material and distributes to everyone Grounds the discussion in fact — keep separate from viewpoint holders Market researcher Recorder Captures process insights as learning data Gives the team a learning loop (L5) reflector Lecture 2 — The Design of Team Composition You don't need all five — pick per purpose
E A M C O M P O S I T I O N The reviewer — separating generation from review sharpens both Generatormakes 5 proposals Reviewermust reject 2–3 Approved proposalsquality floor rises — Observation: adding a "reviewer with a rejection quota" visibly raised the bar of what got through — Letting the generator self-review turns lenient — a "waste-not" bias sets in — Generation and review clash on judgment axis (principle ①). That's why they're split Lecture 2 — The Design of Team Composition
E A M C O M P O S I T I O N Designing "distance" between viewpoints — not too close, not too far, chosen by purpose Close (3 senior peers in the same field) Output: practical, coherent Risk: 3 rewordings of the same conclusion Best for: refining an execution plan Far (investor × poet × biologist) Output: surprising, metaphorical, hard to connect Risk: discussion never converges, scatters Best for: originality, emergence — Observation: colliding geology × translation theory × dramaturgy produced the metaphor "the geology of conversation" — something no single field would generate. Distant pairings are a high-risk, high-return lever that pays off only when the connection succeeds When unsure, start with "2 close, 1 far" — 2 close voices for practicality, 1 far voice to shake things up Lecture 2 — The Design of Team Composition
E A M C O M P O S I T I O N The economics of headcount — most discussions are best at 3 Count Character Use case 1 person Fastest, cheapest. No discussion happens Everyday routine work (don’t add more if 1 suffices) 2 people One axis of conflict. Ideal for back-and-forth Critique cycles, game-style formats 3 people Three axes of conflict — triangulation, not a majority vote Best fit for most discussions 4+ people Each voice thins out. Works if split into phases A serial split like 3 diverging + 1 shaping Lecture 2 — The Design of Team Composition Instead of 4+ people arguing at once, split into phases (3 diverge, then 1 shapes it up, in series)
E A M C O M P O S I T I O N The team lifecycle — composition isn't static 1 Founding Start minimal (one 'constitution' file), grow only when a case matches one of the 3 splitting principles 2 Growth Healthy growth means the data (standards, records) grows — not the headcount 3 Dormancy Fine to leave it idle when unused. But distinguish this from 'active but records have stopped' (unrecorded) 4 Disband / cross- cut Don't make a standing team for a time-boxed big task — spin up a temporary 'project' and fold it when done Lecture 2 — The Design of Team Composition
2 0 M I N Exercise 2 — Design a "composition table" for your own problem Item Worked example (a team weighing a side hustle) Purpose Build the judgment material for whether — and if so, which — side hustle to start Viewpoint holders (2–3), axis & distance ① A realist mentor (balance & stamina / close) ② A solo-business veteran (revenue realities / close) ③ A life-design coach (the self 5 years out / far) Reviewer, rejection criteria & quota "Reject anything needing over 10hrs/month" / "Reject anything with no relevant experience." At least 2 of 5 proposals must be rejected Synthesizer’s translation target Translate into "3 lines I could explain to my spouse" Mapping to the 3 splitting principles ①⇄② is a clash of judgment axes (current stability vs. revenue reality). ③ is information separation (speak from the ideal, without seeing the realistic data) Lecture 2 — The Design of Team Composition Check: cut any member who fits none of the 3 principles. If everyone is "close," consider adding one "far" voice
U M M A R Y Lecture 2 summary 1 Only 3 reasons to split: clashing judgment axes, information separation, authority separation. Don't add headcount otherwise 2 Persona is the strategic core — write role × person. Composition and interaction are independent levers 3 A reviewer (with a rejection quota) raises the quality floor. Start viewpoint distance at "2 close, 1 far" Lecture 2 — The Design of Team Composition
I N T E R A C T I O N P R I N C I P L E S Principles of Interaction Design — The Five Levers That Determine Discussion Quality Goal of this lecture: read and build any discussion pattern as a combination of 5 levers
N T E R A C T I O N P R I N C I P L E S Premise — read "observation" and "interpretation" separately This lecture draws on a set of experiments varying discussion setups 25 ways, plus toy-model trials. But it's n=1 (a single theme), evaluated mostly by the AI itself, without rigorous controls. So the two are presented separately. Observation Facts actually left in the experiment log What did or didn’t appear Interpretation An explanation the author built from the observations Doesn’t inherit the original experiment report’s conclusions The interpretations aren't verdicts — they're hypotheses for you to test in your own context — a map for replication Lecture 3 — Principles of Interaction Design — — — —
N T E R A C T I O N P R I N C I P L E S Starting observation — simply lining agents up does nothing Throwing the same question at 3 agents at once Nothing beyond "three opinions side by side" occurred Feeding the prior reply into the next input Positions got revised, concepts synthesized, and rebuttals emerged along the way Agents don't know about each other's existence. "Discussion" is nothing but designing the flow of information — editing the last output into the next input Lecture 3 — Principles of Interaction Design
N T E R A C T I O N P R I N C I P L E S The 5 levers of interaction design 1 Visibility Whose words get shown to whom 2 Order Parallel, serial, or back-and-forth 3 Repetition How many rounds to run 4 Pressure Push for agreement, or preserve conflict 5 Frame What shape the question is handed over in Describe the flow of information with these 5 variables, and any discussion pattern reduces to a blueprint Lecture 3 — Principles of Interaction Design
N T E R A C T I O N P R I N C I P L E S What does "making them discuss" actually involve? Method How it works Good for Manual relay You act as the messenger. "Answer as A" → check output → "Now rebut this as B" and hand it over First trials, testing a format. No tooling needed, start today Written procedure (skill) The steps live in a procedure doc. "① A’s conclusion → ② hand to B to rebut → ③ ..." → one /command runs the same discussion every time Once the format is settled Job-description agents Call named members defined in .claude/agents/. "Review this as the critic" Standing team operations Lecture 3 — Principles of Interaction Design It's not magic conversation — you (or a written procedure) decide how the handoff happens
E V E R 1 Lever 1: Visibility — how much you show decides diversity Setting Effect Side effect Show everything (open) Resonance and mutual correction occur. Fast convergence Anchoring: everyone gets pulled toward the first statement Show nothing (independent) Diversity maximized. Differences in viewpoint become genuine Integration work is needed afterward Show only the last one (relay) A chain of transformation — a different light hits it each step No one is checking quality For decisions that matter, don't show anything at first (add an independent phase) Lecture 3 — Principles of Interaction Design AI anchors more strongly than humans do — it tries hard to stay faithful to prior context
E V E R 2 Lever 2: Order — parallel, serial, and back-and-forth are different tools Parallel (everyone at once) Q → A / B / C → merge Gather broadly Serial (relay) Q → A → B → C Transform the prior output — polish or skip ahead Back-and-forth (critique cycle) Q → A ⇄ B (×n rounds) Dig deep through proposal and critique — Observation: dialectical back-and-forth dominated on "conceptual depth" but produced the fewest outputs. Serial relay never dug deep, but stood out for sharpness of titles and phrasing — Order is a choice between breadth, depth, or sharpness. No single pattern buys all three — switch by purpose, or chain them by phase Lecture 3 — Principles of Interaction Design
E V E R 3 Lever 3: Repetition — rounds open up "new dimensions," on one condition Observation — repeated game A persona that made only simple choices in a one-shot round spontaneously produced, over 5 repeated rounds, a strategy dimension that doesn't exist in a single round: build trust with fake cooperation, then betray on the final round Observation — the flip side The theoretically expected "tit-for-tat" strategy never emerged. Because the opponent never once retaliated, no learning signal ever formed that betrayal gets punished — Repetition only pays off when "the outcome of one round can change behavior in the next." It only works paired with levers 4 and 5 — Deepening mostly happens in round 2; round 3 tends toward tidying up. In practice, stop once it plateaus at 2–3 rounds Lecture 3 — Principles of Interaction Design
E V E R 4 Lever 4: Pressure — consensus is manufactured by default — Observation: without any instruction, agents overwhelmingly praised each other and reached smooth agreement. Only rounds explicitly told "don't aim for consensus" left conflicting points in the final output — A discussion's value isn't consensus — it's the surviving conflict, marking the exact spot a human needs to judge Design principle for pressure Separate convergence out as the synthesizer's job; explicitly permit — even require — non-agreement from the viewpoint holders. The synthesizer's output isn't a "conclusion" — it's "points of agreement + points of conflict + why the conflict remains" Write: "Don't aim for consensus. State the one point you won't concede" Give the reviewer a rejection quota Standard test: "Does this still hold with the person's name removed?" Lecture 3 — Principles of Interaction Design
E V E R 5 Lever 5: Frame — how you hand over the question is the hidden strongest lever Even with the same prompt — "come up with a new team idea" — changing only the frame produces: "What does my current life phase need?" → integrated, realistic proposals "Work backward from my ideal self in 3–5 years" → development-plan-style proposals "Install expertise nobody's ever asked an AI for" → pragmatics, phenomenology, anthropology — proposals absent from every other round "First design the worst possible team, then invert it" → proposals that face failure and stagnation head-on, absent elsewhere Changing the frame replaces the entire search space. It can reshape the terrain more than levers 1–4 combined Lecture 3 — Principles of Interaction Design
N T E R A C T I O N P R I N C I P L E S Practice: "reading" existing patterns with the 5 levers Pattern ① Visibility ② Order ③ Reps ④ Pressure ⑤ Frame 4-phase format Hidden first half, open second half Parallel → back- and-forth → merge 2 rounds Non-agreement required Plain One-stroke relay Only the last one Serial 1 round No pressure "Recast it in your own view" Dialectical battle Open Back-and-forth 2–3 rounds Critique required Plain Anti-pattern inversion Open Parallel → merge 1 round None Inverted war-game Open Turn-based back- and-forth 3+ rounds Adversarial (win condition) "Go all-out to break it" Lecture 3 — Principles of Interaction Design Goal: go from symptom to lever — "too shallow, add repetition," "too generic, invert the frame"
2 0 M I N Exercise 3 — Diagnose a recent "discussion with AI" using the 5 levers 1 Write it out Map that discussion onto the 5-lever table. Most will be 'open, parallel, 1 round, no pressure, plain frame' 2 Name one complaint Too shallow / too generic / just long, etc. 3 Move one lever Shallow → add ③ repetition + ④ mandatory critique. Generic → invert ⑤ frame or add ① isolation. Just long → require the synthesizer to give 3 agreement lines + 3 conflict lines Worked example: "Discussing where to move" = open, parallel, 1 round, no pressure, plain frame → complaint: "only safe options come up" → invert lever 5: "First list the conditions that would make a neighborhood absolutely unlivable for me. Work backward from that to find what I'm overlooking" Lecture 3 — Principles of Interaction Design
U M M A R Y Lecture 3 summary 1 Discussion is designing the flow of information. Every pattern decomposes into 5 levers: visibility, order, repetition, pressure, frame 2 Consensus is manufactured by default. Separate convergence into the synthesizer role; require non-agreement from viewpoint holders 3 The hidden strongest lever is the frame. Question how the question is handed over before you touch the structure Lecture 3 — Principles of Interaction Design
PAT T E R N C ATA L O G A Catalog of Patterns by Purpose — Practical Designs for Composition × Interaction Goal of this lecture: instantly assemble composition and discussion pattern from "what I want to raise right now"
T E R N C ATA L O G How to use the catalog — first narrow it to one purpose Most failures come from being greedy — "deep, original, and practical all at once." One discussion buys one property. So pull from the catalog by purpose. Your symptom Goal Matching patterns Answers feel shallow, crumble under pushback A. Deepen Critique cycle / 4-phase / round robin Not enough proposals or breadth B. Diverge Independent parallel / relay / constraint spiral Only proposals I’ve seen before C. Originality Inversion / cross-domain collision / transplant / role reversal Have a proposal, want weaknesses & blind spots D. Validate war-game / jury / premortem A good proposal isn’t landing as execution E. Execute Two-stage rocket Lecture 4 — Pattern Catalog by Purpose
A P 1 Map 1: the 6 basic flow shapes — any pattern is built from these 1 Parallel (fan) Q → A / B / C → merge Gather broadly 2 Serial (relay) Q → A → B → C Transform, polish, or skip ahead 3 Back-and-forth (ping-pong) Q → A ⇄ B (n rounds) Dig deep through proposal and critique 4 Gate (funnel) many proposals →| review |→ few Rejection raises the quality floor 5 Turn-based (game) A —attack→ B / A ←defend— B + judge Adversarial pressure exposes weaknesses 6 Staged (rocket) [divergence block] → [shaping block] Different composition per phase, keeps purposes from mixing Lecture 4 — Pattern Catalog by Purpose Same as the 5 levers: parallel=visibility, serial/back-forth=order, n rounds=repetition, gate=pressure. Any shape can carry a "frame"
A P 2 Map 2: a position map of roles — think of it as a river's flow Recorderreflector Side channel — doesn't join the discussion, observes and feeds learning data Supplierdistributes facts / material Upstream Viewpoint A ⇄ B ⇄ C Peer clash / adversarial role = asymmetric, has a win condition Center stage Reviewerholds a rejection quota Gate Shaper / synthesizertranslates into an executable, reportable form Downstream Lecture 4 — Pattern Catalog by Purpose
A P 2 Center stage has only 4 kinds of "relationship" Relationship Description Examples Peer clash Equal-status viewpoint holders collide on different judgment axes Investor panel, critique cycle Asymmetric adversary One side is given a win condition (crush it, reject it, fail it) war-game, reviewer, jury Serial transformation Recasts the prior output in a different light (no critique) Relay, shaper Observation Doesn’t join the discussion — records it and feeds learning reflector Lecture 4 — Pattern Catalog by Purpose
O A L A — D E E P E N A-1 Critique cycle (dialectic) — raises conceptual resolution and defensibility Coordinates: flow = back-and-forth / relationship = peer clash (2 people) / frame = plain Proposer Critichunts for counterexamples Propose → critique → revise …… ×2–3 rounds Composition 1 proposer + 1 critic (2 people whose judgment axes clash). A synthesizer is optional Steps ① propose → ② critique (no praise — at least 3 specific issues) → ③ revised proposal → ④ round 2 covers only new weaknesses → ⑤ present the final form alongside its "remaining weaknesses" Observed Top-rated across all patterns on "conceptual depth." But produces the fewest outputs Failure mode The critic turns polite and holds back (→ write "restraint is dereliction of duty"). Round 3+ turns ritualistic (→ cap it at 2 rounds) Lecture 4 — Pattern Catalog / Goal A: Deepen
O A L A — D E E P E N A-2 Independent → mutual challenge → synthesis (4-phase) — the standard rig for big decisions Coordinates: flow = parallel → back-and-forth → merge / relationship = peer clash (3 people) / frame = plain 1 Distribute material The researcher hands facts to everyone 2 Independent review 3 viewpoint holders conclude without seeing each other (visibility OFF) 3 Mutual challenge 2 rounds of questions/rebuttals. No consensus allowed, and non- agreement required 4 Synthesis The synthesizer gives 'agreements / conflicts / translation.' Convergence stays separate Composition Full lineup: 3 viewpoint holders (2 close + 1 far recommended) + researcher + synthesizer. In Phase 3 round 2, each states what they won't concede vs. what they'll grant Observed Used monthly by a live investment team. Reliably delivers multi-angle perspective and "honesty" (reports that don't force a false consensus) Failure mode Skipping Phase 2 straight into open discussion (→ anchoring collapses 3 voices into 1). Synthesizer smoothing over conflict (→ define the output as a "conflict-point list") Lecture 4 — Pattern Catalog / Goal A: Deepen
O A L A — D E E P E N A-3 Round-robin debate — a moderator advances the topic one point at a time Coordinates: flow = back-and-forth + moderator / relationship = peer clash (2 people) / frame = moderator resets the question every round Moderatorresets the question Debater A ⇄ Debater B Advance one point per round The key The moderator resets "this round's question" every time. Left alone, it repeats the same claims Observed Repetition behaves as in Lever 3 — round 2 deepens, round 3 tidies up Lecture 4 — Pattern Catalog / Goal A: Deepen
O A L B — D I V E R G E B-1 Fully independent parallel (hidden parallel) — maximizes volume and breadth Coordinates: flow = parallel (visibility OFF) / relationship = no clash (isolated) / frame = plain Same question → viewpoint A (isolated) → 5 proposals → viewpoint B (isolated) → 5 proposals → viewpoint C (isolated) → 5 proposals → dedupe and list Composition 2–4 viewpoint holders. Keep them at a distance — close pairs converge even in isolation Observed Rounds with an independent phase showed markedly less proposal overlap than open-parallel rounds Failure mode The synthesizer picks a "top 5" unilaterally at merge time. For divergence, let the human select — the selection criterion itself becomes your preference data (L5) Lecture 4 — Pattern Catalog / Goal B: Diverge
O A L B — D I V E R G E B-2 One-stroke relay (chain of transformation) Coordinates: flow = serial / relationship = serial transformation / frame = "recast it in your own view" Afirst draft Brecasts it in their own aesthetic Cturns it into a story Each person only sees the immediately prior output. No critique — transform only Composition 3 people with distant judgment axes. No reviewer (validation happens later, separately) Observed Dominates on diversity and sharpness of titles. Neologistic phrasing appeared only in this format — but with no quality check and the widest variance Failure mode "Transform" turns into "summarize" (→ instruction: "recast in your own view," explicitly ban summarizing) Lecture 4 — Pattern Catalog / Goal B: Diverge
O A L B — D I V E R G E B-3 Constraint spiral — narrow while polishing Coordinates: flow = back-and-forth (self-questioning) / frame = constraints added in stages 1 Brainstorm freely Round 1, no constraints. Surface the raw material 2 Add one constraint Rebuild the same idea under that constraint 3 Add another e.g. 'only things doable tomorrow morning' Observed A "cute idea" turned into a "razor-sharp idea" round by round. Constraints acted as a polishing tool, not a filter Interpretation A format that runs divergence and convergence back-and-forth in the same discussion — a gradual tightening of the frame lever Failure mode Loading every constraint from the start — with no freedom in round 1, there's no raw material to polish Lecture 4 — Pattern Catalog / Goal B: Diverge
O A L C — O R I G I N A L I T Y C-1 Anti-pattern inversion — construct "novel" through structure Premise: asking for originality doesn't produce it ("think originally" is one of the weakest instructions). Lever ⑤ Frame changes the search space itself 1 Design the worst case Everyone seriously designs 'the worst possible answer, never to be made' 2 Analyze its structure Articulate exactly what structure makes it so bad 3 Invert point by point Flip the structure and rebuild a good answer Observed Proposals that face "failure, stagnation, doing nothing" head-on appeared only in this format. The record notes: "the moment you drop the nice words, the inversion emerges" Interpretation A device that shines a light on territory everyone unconsciously avoids (negative, taboo, inefficient). Lifting the pressure to "produce a good idea," even once, widens the search space Failure mode Step 1 turns into a joke session (→ state: "design the worst case seriously too — a lazy worst case gives you nothing to invert") Lecture 4 — Pattern Catalog / Goal C: Originality
O A L C — O R I G I N A L I T Y C-2 Cross-domain collision / emergence lab — cross-breeding distant personas Coordinates: flow = parallel → back-and-forth / relationship = peer clash (distant) / frame = "explain it again using your own field's concepts" Geologist Translator Director Point of intersectioncoin a new name here Composition Maximize viewpoint distance. A connector role (synthesizer) is essential Observed The metaphor "conversation that doesn't click is a geological fault" arose only in this format — no single field would have produced it. Several other runs failed to connect and scattered Interpretation High risk, high return. Prone to producing originality in the form of metaphor and redefinition — buys "distance when it lands" over hit rate Failure mode The 3 fields just restate the same thing in their own jargon (→ require them to "coin a new name at the intersection") Lecture 4 — Pattern Catalog / Goal C: Originality
O A L C — O R I G I N A L I T Y C-3 Expertise transplant (installation) Coordinates: flow = parallel or solo / frame = transplant (name a distant discipline) "Redesign this everyday problem using the concepts of [discipline]" (pragmatics, phenomenology, behavioral economics, anthropology, ecology... deliberately pick something distant) Observed A whole cluster of proposals (e.g. pragmatics × everyday conversation) appeared that showed up in no other round. Naming "territory nobody ever asked an AI about" was the effective ingredient Interpretation Originality is often just an untried multiplication of two known things. This format forces one side of that multiplication Failure mode It ends as an academic explainer without landing on the actual problem (→ make "translate into one action for tomorrow" a mandatory final step) Lecture 4 — Pattern Catalog / Goal C: Originality
O A L C — O R I G I N A L I T Y C-4 Role reversal / death and rebirth — self-destructive "pattern breakers" Coordinates: flow = back-and-forth / relationship = peer (swapped axes) / frame = self-destruction (weak viewpoint, kill the proposal) Role reversal Everyone first brainstorms from "the viewpoint they're worst at" → then critiques each other from their real viewpoint. Unfamiliarity breaks the usual pattern Death and rebirth (Phoenix) Everyone thoroughly "kills" one proposal, then rebuilds an entirely different one from the wreckage. Structurally cuts attachment to the original Observed Both produced mediocre results in some rounds — not a stable format. But the proportion of proposals breaking from "the user's usual pattern" was high When to use Occasionally, as a "pattern breaker," when you feel you've fallen into a rut Lecture 4 — Pattern Catalog / Goal C: Originality
O A L D — VA L I D AT E D-1 War-game (adversarial simulation) — expose weaknesses and blind spots Coordinates: flow = turn-based / relationship = asymmetric adversary + judge / frame = win condition assigned Your proposal Adversarygiven a win condition Judgerules every turn 3 rounds, turn-based Composition 2–3 adversaries (each with a different line of attack) + 1 judge. Give the adversary the objective of "winning" — sharper attacks than "please critique this" Judge's questions Standard tests: "Could a big player copy this in six months?" "Is this a fight you can actually win?" Failure mode The adversary stays polite (→ bind it with a win condition: "your goal is to push them out of the market") Lecture 4 — Pattern Catalog / Goal D: Validate
O A L D — VA L I D AT E D-2 Jury — a verdict from the target reader or user Coordinates: flow = gate / relationship = asymmetric (verdict) / frame = "would I actually use / read this?" Have 3 personas from different walks of life vote on "would I really use / read this." Only unanimous approval passes Observed Proposals that looked good from the creator's viewpoint got voted down by the jury — the mechanism worked Tip Cast the jury as "busy strangers with no particular interest," not "kind friends" Lecture 4 — Pattern Catalog / Goal D: Validate
O A L D — VA L I D AT E D-3 Time-travel validation — the year-later oracle premortem Coordinates: flow = solo to parallel / frame = future perfect tense (assume it already failed) Have it write, in advance: "This plan had failed a year later. What happened?" Observed Produced designs with clear reasons-to-exist and failure conditions from the start Interpretation Future-perfect framing surfaces more concrete failures than present-tense "list the risks" (likely because psychological distance drops). An AI version of the classic human premortem technique Lecture 4 — Pattern Catalog / Goal D: Validate
O A L E — E X E C U T E E Two-stage rocket — the standard formula for landing on execution Coordinates: flow = staged / relationship = stage 1 = clash, stage 2 = transformation / frame = separately defined per stage Stage 1: diverge & review 3 viewpoint holders + a reviewer (guards quantity and quality) Output: "proposals" Stage 2: shaping 1 shaper (translates into steps, cadence, first move) Output: "tomorrow's action" Observed Running divergence and implementation design in the same discussion left both half-baked. Splitting into 2 stages — "3-person diverge+review" then "1 shaper turns approved proposals into an execution design" — stabilized it The rule Run emergent discussion and execution design in separate phases, with separate compositions Lecture 4 — Pattern Catalog / Goal E: Execute
H E AT S H E E T Cheat sheet — pull a recipe from your situation Situation Recommended recipe Everyday advice No pattern needed. Ask solo (always mind the cost) Weekly planning A-1 Critique cycle, just 1 round Monthly / money-related decisions A-2 Full 4-phase format Out of ideas, stuck B-1 Independent parallel → next day, C-1 inversion to dig a different direction "I’ve seen this all before" syndrome C-2 Cross-domain collision or C-3 expertise transplant (aim for distance) The night before a big decision D-3 Premortem → D-1 war-game Have the idea, can’t move Run only stage 2 of E: have the shaper translate it Lecture 4 — Pattern Catalog by Purpose
U L L D E M O Full demo — running "should I start a side hustle?" through the 4-phase format (manual relay, ready-to-paste prompts) Phase 1: distribute material "As material for a side-hustle decision, summarize: available time (1hr weekday evenings, Saturday mornings), my employer's moonlighting policy, and past records of 'work I enjoyed / lost track of time doing.' Pull the latter from my records folder." Phase 2: independent review (run 3 separate times; don't show each other's answers) "You're a realist mentor. Judging only by the material above, on the axis of balancing my job and stamina, reach a conclusion on whether I should start. Don't worry yet about what the other members think." (Repeat separately for "solo-business veteran" and "life-design coach") Phase 3: mutual challenge (paste in all 3 conclusions) "Here are all 3 conclusions. Each of you rebut the other two. Don't aim for consensus. Each of you state the one point you won't concede, to the end." Phase 4: synthesis "As synthesizer, give me — in words I could explain to my spouse — 3 lines each on: ① where the 3 agreed, ② where it stayed split, ③ why it stayed split. Don't reach a conclusion. I'll decide." The levers are all just ordinary language. "Don't worry yet" = visibility OFF. "Don't aim for consensus" = pressure. "I'll decide" = separating the judgment Lecture 4 — Pattern Catalog by Purpose
T E R N C ATA L O G The catalog's limits, and your own lab notebook The "observations" here are records from n=1 experiments and live use. Your theme, your composition, may give different results. So the right way to use this catalog is — 1 Pick by purpose Pull the pattern by purpose 2 Compare to no pattern Same prompt, compared (basic experimental method) 3 Log one observation Note the result and insight in your own lab notebook 4 Grow your own Promote it into your own cheat sheet Patterns aren't rules — they're vocabulary. Every design starts from "what do I want to raise right now?" Lecture 4 — Pattern Catalog by Purpose
2 5 M I N Exercise 4 — Pick a real case and design it end-to-end 1 Pick one purpose A deepen / B diverge / C originality / D validate / E execute 2 Write the tables Choose a pattern, write the 5-lever table (L3) and composition table (L2) 3 5-line procedure Write the steps as a 5- line procedure (skill) 4 Run and record Compare against 'no pattern,' log one observation Lecture 4 — Pattern Catalog by Purpose
U M M A R Y Lecture 4 summary 1 One discussion buys one property. Work backward from purpose (deepen / diverge / originality / validate / execute) 2 Originality isn't produced by asking — it's produced by manipulating the frame (inversion, cross-domain collision, transplant). Validation gives adversaries a win condition 3 Separate emergence from execution with a two-stage rocket. The catalog is vocabulary — your own lab notebook is the final authority Lecture 4 — Pattern Catalog by Purpose
L E A R N I N G L O O P The Engineering of Learning Loops — Turning Records into Intelligence Goal of this lecture: explain the difference between "records piling up" and "getting smarter" — and design the latter
E A R N I N G L O O P "Records piling up" and "getting smarter" are different things The common case — a log warehouse Daily records keep piling into logs/. But CLAUDE.md hasn\u2019t changed in a year. Judgment is still exactly as precise as a year ago The target — a learning loop Standards get extracted from records and folded back into the fact layer. Judgments impossible six months ago are possible now The difference isn\u2019t "recording" — it\u2019s whether there\u2019s a mechanism to re-read records, abstract them, and feed them back to where they get used Lecture 5 — Engineering of Learning Loops
E A R N I N G L O O P The 4 stages of a learning loop — it's only a loop once it closes ① Recordcapture action and result ② Extractfind the common pattern ③ Promotewrite it as a standard in the fact layer ④ Applyactually referenced in the next decision The result of ④ feeds back into ① — only once this closes is it a "loop". Most teams stop at ① (② through ④ don't exist) Lecture 5 — Engineering of Learning Loops
E A R N I N G L O O P The recorder (reflector) — a dedicated observer who doesn't join the discussion Viewpoint A Viewpoint B Recorderwatches the discussion, writes the lessons — Viewpoint holders are too busy defending their own point to survey the whole discussion. Being a party to it blocks learning (this is exactly L2's splitting principle ② — information separation) — The recorder's question: "what judgment criterion from today's discussion is worth reusing next time?" "Is there a failure pattern that keeps repeating?" — The output isn't a reflection essay — it's a 1–3 line candidate addition to the fact layer, in the form "when X, do Y" Lecture 5 — Engineering of Learning Loops
E A R N I N G L O O P The discipline of extraction — not one failure, but wait for "3 times the same" Bad extraction (overreacting) One mistake triggers a hard "never do X" rule added to CLAUDE.md → rules pile up into a wall of text that\u2019s exhausting just to read Good extraction (pattern confirmation) Wait until the same kind of failure shows up 3 times in the record, then generalize the common condition into a one- line standard added to the fact layer Distinguish a one-off mistake from a structural weakness. The recorder's job also includes saying "not yet a standard, let's wait and see" Lecture 5 — Engineering of Learning Loops
E A R N I N G L O O P Promotion — where to write it follows the 4 layers from L1 Promotion target Example Fact layer Add "reduce positions crossing an earnings date" to investment-philosophy.md (the most common case) Procedure layer The same gap keeps happening in a process → add a check step directly into the skill’s procedure Command layer Rare. Only "breaking this is catastrophic"-level lessons get promoted as a single line in CLAUDE.md Lecture 5 — Engineering of Learning Loops The learning loop is L1's "grow the fact layer" made concrete as a mechanism that runs on a time axis
E A R N I N G L O O P The most important thing to learn is "your own selection criteria" B-1 (independent parallel) produces 5 proposals, and you pick one. How you picked it is data — "your preference" — that isn't written down anywhere yet. Just recording the reason becomes a standard the next reviewer or synthesizer can use Just picking and moving on Pick 1 of 5 proposals to adopt The reason lives only in your head Next time, you’re back to choosing from scratch among the same 5 Recording the reason Note: "Picked B — low upfront cost, easy to exit" The fact layer grows a standard: "prioritize ease of exit" Next time, the reviewer can pre-filter using that standard Lecture 5 — Engineering of Learning Loops — — — — — —
E A R N I N G L O O P The overfitting trap — standards degrade if you only ever add — Past N standards, mutually contradictory ones start mixing in and the AI struggles to decide what to prioritize. There's a tipping point where "getting smarter" flips into "losing coherence" Periodic audit Once a month, re-read the standards list and ask "is this still valid?" Retire ones invalidated by changing circumstances Consolidate into a higher-level principle Merge 3 similar standards into 1 general principle, cutting the count. An application of L1's "what gets read is a finite resource" Lecture 5 — Engineering of Learning Loops
2 0 M I N Exercise 5 — Implement one learning loop in your own team 1 Appoint a recorder Make it a dedicated role that doesn't join the discussion (no double- hatting with an existing member) 2 Set extraction frequency Every session, or weekly? Write down the 'wait for 3' rule 3 Choose the promotion target Which file in the fact layer gets the addition 4 Book an audit date Put a date on the calendar, one month out, to re-read the standards list Lecture 5 — Engineering of Learning Loops
U M M A R Y Lecture 5 summary 1 Records aren't learning. It only becomes a loop once "record → extract → promote → apply" closes 2 Make the recorder a dedicated role that doesn't join the discussion. Wait for "3 times the same" before generalizing 3 The most important learning target is your own selection criteria. Audit standards monthly, don't let them multiply endlessly Lecture 5 — Engineering of Learning Loops
O P E R AT I O N S The Engineering of Organizational Operations — Building Systems That Stay Healthy 3 Months Later Goal of this lecture: design a system that's healthy 3 months on, not just right after launch
P E R AT I O N S Observation — vibrant right after launch, quietly dead 3 months later Right after standing up multiple teams, you use them. But 3 months in, before you notice, half of them haven't been called in weeks. Nothing broke — they were simply forgotten. No error surfaces, so discovery comes late Right after launch Summoned almost daily Standards are fresh, judgment is fast The user is engaged too 3 months later Pushed aside by other priorities, stops being called Since it isn’t called, the learning loop also stalls No errors. It just quietly falls out of use Lecture 6 — Engineering of Organizational Operations — — — — — —
P E R AT I O N S The 3 causes a team gets forgotten Cause of death What it is Fix Ad-hoc triggers Designed to be called "whenever I feel like it." Busy periods are exactly when it isn’t Schedule (Fix ①) No definition of done A project-type team with no ending condition overstays indefinitely Definition of done (Fix ②) Manual detection Checking "is it working" is itself a chore, so even the checking gets forgotten Automated detection (Fix ③) Lecture 6 — Engineering of Organizational Operations
P E R AT I O N S Fix ①: Schedule — kill "whenever I feel like it" with a mechanism Frequency Example Design tip Daily Routine sounding-board sessions, daily priority checks Keep it light only — a heavy discussion every day won’t last Weekly Weekly review (e.g. 4-phase discussion) Fix the day and time. Nail it down to "Sunday, 8pm" Monthly Standards audit, overall team health check Bundle the L5/L6 checks together into this one session Event-driven Before earnings releases, big decisions Write "whenever this happens, always run it" explicitly into the procedure Lecture 6 — Engineering of Organizational Operations Write the schedule itself into the procedure layer (a skill) — design in "run /weekly-review every Sunday at 8pm" as part of it
P E R AT I O N S Fix ②: definition of done — write the ending first Unlike standing teams, a time-boxed project team (L2's "disband / cross-cut") will overstay forever without a criterion for finishing. Write "what needs to happen for this to wrap up" at creation time Bad example "A team to explore new business ideas" — exploration can continue forever. There's no condition to fold it Good example "Disband once 3 options are compiled into a comparison report." "If no conclusion by end of August, disband anyway and keep only the material in the fact layer" Lecture 6 — Engineering of Organizational Operations
P E R AT I O N S Fix ③: automate detection — don't check "is it working" by hand Shared notesthe hub (L1) Note last-updated dateone line per team Monthly audit sees the listspot the stalled rows Just having each team log a line in the shared note (L1's hub) like "Team A: last active 6/2" makes stalled teams visible at a glance during the monthly audit (L5). A concrete way to distinguish "dormant" from "unrecorded" (L2's lifecycle) Lecture 6 — Engineering of Organizational Operations
1 5 M I N Exercise 6 — Audit all your teams from a "3 months later" lens 1 List them all Write out every team / project you currently have 2 Diagnose with the 3 causes Check whether it relies on ad-hoc triggers, lacks a done-definition, or needs manual checking 3 Apply one fix Set a schedule, or add one completion condition Lecture 6 — Engineering of Organizational Operations
U M M A R Y Lecture 6 summary 1 Teams get quietly forgotten with no error thrown. The 3 causes of death: ad-hoc triggers, no definition of done, manual detection 2 Put the schedule in the procedure layer, and make invocation mechanical. Project teams write their fold-up condition up front 3 Just logging one "last updated" line in the shared note enables a monthly audit Lecture 6 — Engineering of Organizational Operations
T I P S & C A P S T O N E Tips Compendium & Capstone Project Goal of this lecture: sweep through field-level techniques and integrate every lecture in a capstone project
I P S Tip ① — Phrasing that works Phrase Lever / effect "Don’t worry yet about what the other members think" Turns off Lever ① visibility — use for building an independent phase "Don’t aim for consensus. State the one point you won’t concede" Releases Lever ④ pressure — explicitly permits preserving conflict "Recast it in your own view (no summarizing)" The core of B-2 relay — forces a distinction between transforming and summarizing "Rejection quota: at least 2 of 5 proposals must be rejected" A quantified instruction that guarantees reviewer quality "Would this still hold with the person’s name removed?" A standard test for whether agreement is substantive or just politeness "Assume it had failed a year later — what happened?" D-3’s frame — future-perfect tense draws out concrete risk Lecture 7 — Tips Compendium & Capstone
I P S Tip ② — Common failures and fixes: pitfalls from every lecture Symptom Typical cause Fix Principles don’t hold in long conversations A long procedure is written directly into CLAUDE.md Move the procedure into a skill (L1) Discussions always converge on the same conclusion No non-agreement instruction — pressure applies by default Separate the synthesizer, require non- agreement (L3–4) The same mistake keeps repeating No recorder — extraction and promotion never happen Appoint a dedicated recorder (L5) Nobody’s calling the team anymore, and nobody noticed The trigger was "whenever I feel like it" Pin the schedule into a skill (L6) No original ideas come out at all Just asking to "be original" without changing the frame Inversion, cross-domain collision, transplant (L4, group C) Lecture 7 — Tips Compendium & Capstone
I P S Tip ③ — Decision flow for when you're unsure, on one page Q1 "Do I want this read every single time?" \u2192 Yes: command layer / No: procedure, fact, or persona layer (L1) Q2 "Do I need a new member?" \u2192 Check whether it fits one of the 3 splitting principles: judgment axis, information, authority (L2) Q3 "What do I want to raise right now?" \u2192 Pick one of deepen / diverge / originality / validate / execute, pull from the catalog (L4) Q4 "Am I having the same discussion over and over?" \u2192 Add a recorder, close the learning loop (L5) Q5 "Would this survive 3 months of not being called?" \u2192 No: write a schedule and a definition of done (L6) Lecture 7 — Tips Compendium & Capstone
E C A P Recap — the 4 design areas connect together \u2460 Overview4-layer text org \u2461 Compositionwho to place \u2462\u2463 Discussion design5 levers, patterns \u2464 Learningrecords to intelligence \u2465 Operationsa mechanism that keeps running Composition and interaction (L2\u2013L4) determine "discussion quality." Learning and operations (L5\u2013L6) guarantee that quality doesn\u2019t decay over time. Everything is grounded in L1\u2019s 4-layer structure Lecture 7 — Tips Compendium & Capstone
0 M I N Capstone — redesign your own team across all 7 lectures Step Task 1 Pick a current team (or one you want to build) 2 L1: audit existing files into the 4 layers, fix one misplacement 3 L2: write a composition table (3 splitting principles, personas, viewpoint distance, headcount) 4 L3–4: pick one purpose, design a 5-lever table and a pattern 5 L5: implement a recorder and a learning loop (record → extract → promote → apply) 6 L6: write a schedule, a definition of done, and a detection mechanism to guarantee it 3 months out Lecture 7 — Tips Compendium & Capstone Deliverables: a 4-layer audit table, composition table, pattern design, learning loop, and operations schedule — 5 items total
M A R Y Advanced course — full summary 1 Text files have 4 layers (command, procedure, fact, persona). Where you write it is decided by when it should be read 2 There are only 3 reasons to split. Composition and interaction are independent levers 3 Discussion decomposes into 5 levers (visibility, order, repetition, pressure, frame). Preserve conflict, don't force consensus 4 One discussion buys one property. Work backward from purpose to pattern 5 Records aren't learning. It's a loop only once extraction and promotion close it 6 Teams get quietly forgotten. Prevent it with a schedule, a definition of done, and automated detection Advanced Course — Designing and Operating Multi-Agent Systems
forest8810
flux
navitimejapan
bokurano_compass
konifar
yda
hirokiyamamoto14
macloud
gatechnologies
3dc_inc
gw_recruit
m_coder
mkitahara01985
eileencodes
lauravandoore
nikkihalliwell
inesmontani
addyosmani
philnash
aleyda
michielstock
lara
speakerdeck
szymonslowik
