Why the catalogue takes the form it does, what its evidence will and will not support, the one field added to a template thirty years old — and what has had to be corrected.
Rev. 5 — 23 Aug 2026. Punctuation and two habits, under site/STYLE.md; the vocabulary is deliberately left alone. Em dashes fall from 83 to 36, and from 11.3 per thousand words to 4.9; the rest are bibliographic separators, revision notes and figure labels. rather than ran 30 times against 1 of instead of, and is now 20 to 7. squad becomes team in the four places it names OM-002's subject, so this document keeps describing that paper correctly. ⚠️ principal is untouched here, and that is a decision rather than an oversight. The other four papers now say person. This one contains §4.1, the eight shared terms, which argues for principal in as many words: “User” describes someone operating a machine. It cannot express the fact that the agent is acting as someone, on borrowed authority. Renaming the word here would reverse a published claim under cover of a punctuation pass, so it is left standing and flagged instead. Note what the disagreement is and is not: §4.1 argues against user, and so does the ruling that replaced the word elsewhere. What they differ on is the replacement, which is a paragraph to rewrite rather than a term to substitute. No id, name, relation or claim has changed. Asserted virtue is left almost entirely intact for a reason worth recording: this is the argument paper, and eleven of its uses of exactly bound a set or a count while six of actually contrast what a system does with what it claims. That is the exemption doing its job, in the document where the subject is what the evidence supports.
Rev. 4 — 20 Aug 2026. The three sections built on instrumented testing are withdrawn, and their ids are kept. §16 is rewritten as a plain statement of what OM-004 rests on; §17 and §18 are withdrawn in place, each landing on a line saying what was there and why it went. They are not deleted because they were published, and a fragment this site has served is owed forever — /om-005#om-004-the-held-half was a valid citation this morning. §15 keeps its argument for the added field and loses the dated passes it was told through: the lesson is that a null result from a sample too small to contain the case reads exactly like a true negative, and that lesson needs no instrument to state. Sections §§1–13 are untouched.
Rev. 3 — 15 Aug 2026. OM-004’s method notes arrive, as Rev. 1 said they would: §§14–18, and sources becomes §19. They are a different kind of material from §§2–13, which were moved out of papers that had grown them as front matter — these were written for this document, because OM-004 published as a presentation of its entries from the start rather than becoming one. §14 is the one worth reading if you read only one: it is the first time this programme has gone back to a published pattern with measurements from having built it, and two of that pattern’s implementation notes did not survive. §18 collects four corrections, including a firing rate asserted in six places that no measurement had ever produced. Section numbers in the notes below describe the structure at the time each was written.
Rev. 2 — 15 Aug 2026. OM-002’s and OM-003’s arguments arrive, as Rev. 1 said they would: their gap sections, their evidence sections and their Forces that recur (§§8–13). The three papers are now presentations of their entries and nothing else. OM-003’s evidence section was split rather than moved whole — the assessment of how thin the evidence is came here as §12, and the four-source table with its eight open slots stayed in OM-003, because twelve links from within that paper point into those slots and an entry should not have to leave its own document to say what it rests on. The om-00N- prefix set in Rev. 1 did its job: all six sections arrived without a rename, and three of them would have collided on the-evidence and forces without it.
Rev. 1 — 15 Aug 2026. First published. Assembled rather than written: §§2–7 and the preface are OM-001’s, moved here unchanged in the same revision that removed them there. The four numbered papers are becoming plain presentations of their patterns, and everything about how those patterns were arrived at — the gap, the evidence, the form, the corrections — belongs together in one document rather than as front matter on four. OM-002’s and OM-003’s evidence and gap sections follow in Rev. 2; OM-004’s method notes when that paper publishes.
I met these ideas backwards.
Design Patterns was the first book that changed how I saw software rather than what I knew about it, and reading it remains one of the most consequential things that has happened to me in this trade. What it gave me was not twenty-three solutions: I have used perhaps half of them, and argued against several. It was the discovery that a design decision could be a named thing, with a context, a set of forces pulling against each other, a stated cost, and a position among other named things. Before that book, design was taste. After it, design was something you could be wrong about in public.
I came to Christopher Alexander much later, through architecture, for reasons that had nothing to do with code. So I read the adaptation a decade before I read the original, which is a strange way round and an instructive one.
The first thing you notice, arriving at Alexander from software, is how far the Gang of Four carried the form. His patterns are about where the light falls, how high a windowsill sits, where people naturally stop to talk. Ours are about object graphs. That the template survives a journey that long is not luck; it is a claim about what a pattern is: a resolution of competing forces in a context, named, so that people who did not invent it can argue about it.
The second thing you notice is that Alexander did not think the journey had carried the important part. He said so directly, to a room of object-oriented programmers, in his 1996 OOPSLA keynote. He was generous about the format (context, problem, solution) and clear that the format was not the point. What had not come across was that a pattern language is meant to be generative: a sequence you can follow to produce a coherent whole, rather than a catalogue of separable good ideas. And that patterns are finally judged by whether the thing they generate is good for the people who have to live inside it.
I think he was right, and I think that criticism bears on this subject more directly than it did on his audience. The artifact here is not a class hierarchy. It is a surface across which a person hands authority to a machine and then lives with what the machine does. Whether the result is good for that person is not a moral supplement to the engineering. It is the engineering.
So this document says out loud what it stands on. What is inherited is the template; the discipline of stating costs and non-applicability in the same breath as benefits; the insistence that patterns cite one another; and the standard that a pattern must be refusable or it is not a pattern. What is added is one field, and Alexander is the reason for it. A missing pattern here leaves no mark on the artifact; it shows up in someone’s irritation, and in what they blame for it. Failure Signature is where the person living in the thing gets a vote.
Whether any of this is generative in his sense (a sequence you could follow to build a whole surface, rather than fourteen things to check afterwards) I do not know. OM-001 §16 is the closest it comes, and it is a checklist, which is the weaker thing he was warning about.
Debts are not credentials. Naming this one is a way of accepting the standard, not a claim to have met it.
James Andrew Walsh · Organon Mind · 12 August 2026
The other papers present patterns. This one says why there are any, what the evidence behind them is worth, why they are written in a thirty-year-old template with one field added, and where the programme has been wrong in public.
It exists because of a decision made on 15 August 2026 and worth stating plainly: a catalogue is most useful as a plain presentation of its patterns. Until then each paper opened with its own case (the gap it filled, the evidence it rested on, the forces its entries traded off), and a reader wanting a pattern had to walk past an argument to reach it. Those sections were not wrong. They were in the way, and they were saying overlapping things in four places.
So they are here, and the papers are catalogues again. OM-001, OM-002 and OM-003 now open with a short orientation and go straight to their entries. OM-004 never had to be converted — it published in that shape, and its method notes were written directly into this document as §§14–18. Nothing was deleted to achieve that; every section that moved is reproduced here in full. One was split rather than moved: OM-003’s evidence section, whose four-source table and eight open slots are cited twelve times from within that document and stayed there. §12 says so on the page.
Following a citation that landed here
A fragment published against one of those papers still resolves, and each retired id lands on a line naming where its section went. The rule is mechanical: /om-001#the-evidence is /om-005#om-001-the-evidence, and the same for OM-002 and OM-003 when their sections arrive. The prefix exists because all three papers had a section called The evidence and a section called Forces that recur; without it, two of the three would have had to be renamed on arrival, and a published fragment is owed forever.
What this does not do
It does not argue for any individual pattern. Each entry states its own applicability, its costs and its failure signature, in the paper that carries it, and is meant to be refusable there. This document argues only that the vocabulary is worth having and that the form it is written in is the right one — both of which could be true while a given entry is wrong.
The Design Patterns catalogue worked because it named things practitioners were already building badly and inconsistently. Nobody invented the Observer; its authors noticed that four codebases had each grown a different half-solution to the same problem, and gave the shared shape a name so it could be argued about.
Conversational agent interfaces are at exactly that moment. Coding agents, agent modes inside editors, terminal assistants, voice-first agents and a dozen internal tools have each independently grown an approval prompt, a streaming renderer, a tool-activity log, a plan the principal can amend, and a way of saying “are you sure?” The mechanisms have converged. The names have not.
| The mechanism | Names it goes by |
|---|---|
| A point where the agent stops and asks before acting | approval prompt · permission dialog · confirmation · trust prompt · allowlist decision · “are you sure?” |
| A statement of intent issued before the work | plan · steps · todo list · proposal · dry run · preview |
| Output appearing before the answer is finished | streaming · token streaming · incremental rendering · progressive response |
| A record of which tool ran, against what, and what came back | tool call · function call · action log · activity feed · trace · step card |
| A durable output lifted out of the transcript | artifact · canvas · document · file · card |
Every row is one thing. Five names for it is not a naming problem; it is the absence of a vocabulary, and the absence has consequences that this document is about.
The transcript is not the interface. In a tool-using agent, conversation is the control and negotiation layer. Plans, diffs, approvals, tool calls and artifacts are first-class structured objects that the conversation refers to, commands, and takes responsibility for.
That is the claim the whole catalogue follows from, and a system that treats the transcript as the whole interface will reimplement each of these mechanisms badly, as prose.
The catalogue itself, fourteen patterns in full with an index, a map and relations you can navigate, is published at /patterns. It is canonical, and it does not require this document. What follows is the argument for it: why the vocabulary is missing, what its absence costs, what the evidence is, and what form the entries should take.
The gap is not that nothing has been written. Five bodies of work bear on this surface, each strong in its own frame, and none of them lands in the middle.
| Tradition | What it brings | Why it does not close the gap |
|---|---|---|
| Conversation design | A mature, rigorous vocabulary for turn-taking, repair, grounding and sequence. | Grown from voice assistants and customer-service bots. No tools with effects outside the conversation, no borrowed authority, no irreversibility. Its unit is the utterance; here the unit is the delegated task. |
| Agent UX collections | Current, correctly aimed, and the broadest inventory of what shipping systems actually do. | The form is a list of tips. No applicability, no consequences, no stated cost, and therefore nothing that can be refused. “Show tool calls” cannot be argued with, only obeyed or ignored. |
| Human–AI interaction guidelines | Empirically grounded, and excellent as acceptance criteria. | Evaluative rather than generative. A guideline tells you whether a design is good; it does not tell you what to build, or what the thing you build is called. |
| Software design patterns | Exactly the right form, and the discipline of stating consequences rather than only benefits. | The artifact under discussion is code. Structure means class relations, Sample Code means code, and neither survives contact with an exchange. |
| Safety and alignment work | The sharpest thinking on what an agent should be permitted to do at all. | Almost silent on the surface: how permission is asked for, how consent is made specific, how the principal is shown what they authorised. |
What is missing is the middle: a vocabulary with enough rigour to design against, argue with, and refuse. Not a checklist and not a taxonomy: a language, meaning named things with stated relations between them, so that a design decision can be located, not merely defended.
The cost is not that people write imprecise documentation. It is paid four ways, and every one of them is expensive.
Defects present as feelings
A missing design pattern in code announces itself in the artifact: duplication you can point at, a switch statement that grows a case per type. A missing conversational pattern announces itself as an impression: the tool is annoying, the agent is untrustworthy, the thing “doesn’t work”. Impressions get attributed to the model’s intelligence, because that is the only named component in the system. The actual defect is usually structural and usually cheap, and it goes unfixed because nobody has a word for it.
Arguments cannot be had
Two engineers disagreeing about whether to add a confirmation step are really disagreeing about blast radius against attention budget. With no names for either force, the disagreement is about taste, and taste arguments are settled by seniority rather than by evidence. Naming the forces does not resolve the argument; it makes it an argument about something, with a shape that lets one side be shown to be wrong.
Nothing can be refused
A vocabulary that names only good things is marketing. The property that makes a pattern usable is that it states when it does not apply and what it costs, so a team can say “not here, and here is why” and have that be a defensible engineering position rather than laziness. Tips have no such property. This is the single largest difference between a pattern language and a best-practices list, and it is why the form matters as much as the content.
Every team pays the discovery cost again
Absent a shared name, each of these mechanisms is rediscovered by hitting it. That is not hypothetical: four of the fourteen patterns in the catalogue were found exactly that way, on one workstation, in about a week (§5). The cost of rediscovery is not the fix, which is mostly small; it is the hours spent diagnosing a symptom that pointed somewhere else.
Four of the fourteen patterns are not derived from the literature. They were found by hitting them on a single workstation running a voice-first agent: push-to-talk capture, local speech-to-text, local synthesis, a resident agent process with no window of its own, and a physical lighting channel in the room. Each began as a complaint and ended as a structural fix.
| Pattern | How it presented | What it actually was | Measured |
|---|---|---|---|
| Mode Visibility (2) | “the interface is broken” | The binary was started in its headless mode, which has no interface by design. Nothing errored; everything worked. | — |
| Streaming Turn (3) | “she is slow to answer” | Generation and speech synthesis ran strictly in series, because the synthesiser was handed the reply only when the reply was finished. | 11.8 s to first spoken word, decomposing to ~7 s generation and ~4.9 s synthesis. After streaming: first speakable fragment at 1.14 s. |
| Ambient Activity Channel (9) | “is it still going?” | A delegated task has no state channel outside the screen, so delegation costs either attention or a late discovery. | — |
| Honest Gauge (12) | “that one is always red” | A boot service ran a bare swapon, which exits non-zero when swap is already active, so the unit reported failure in its healthy steady state. |
Status surface read failed with 27 GB of swap demonstrably active. |
Two of these have numbers attached and two do not, which is itself worth stating plainly instead of hiding behind uniform prose. Latency is measurable; “is it still going?” is a question someone asked out loud.
What one machine can and cannot establish
This is n = 1. It is not a study, and no claim here rests on frequency. What a single system establishes is existence and cost: that these failure modes are real, that they are cheap to hit, that each presented as something other than what it was, and that the diagnosis in every case ran through a wrong hypothesis first. What it cannot establish is that these are the fourteen most important patterns, that the boundaries are drawn in the right places, or that the names will survive other people’s systems.
The remaining ten come from the literature in §3, from published agent surfaces, and from the structure the four demanded once they were named. They are proposals on the same terms.
The Gang of Four template is the right instrument, for a reason that is easy to miss: it is the only widely-used design form that requires an author to state costs and non-applicability in the same breath as benefits. That is what makes a pattern arguable, and arguable is the whole point.
It needs adapting, because the original assumed the artifact under discussion was code. Here the artifact is an exchange, so two fields change meaning and one is added.
| Gang of Four | Here | Why |
|---|---|---|
| Structure | Structure | turn and authority flow, not class inheritance |
| Participants | Participants | roles in the exchange, not objects |
| Sample Code | Sample Interaction | the artifact is a dialogue |
| — | Failure Signature | added |
Everything else survives intact: Intent, Also Known As, Motivation, Applicability, Collaborations, Consequences, Implementation, Known Uses, Related Patterns. The template is not the contribution. The added field is.
In code, the absence of a pattern is visible in the artifact. Duplication is there in the file; you can point at it, and the diagnosis runs forward from defect to symptom. That is why the original template never needed a field for symptoms: the defect was already the observable.
In an exchange, the artifact is gone the moment it happens, and the only durable observable is what the principal says and does afterwards. The symptom is affective: irritation, distrust, the vague sense that the tool is fighting you. It does not name its own cause, and the natural attribution (the model is not smart enough) is almost always wrong.
Naming the observable symptom does three things a conventional pattern entry does not.
The signatures also compose. Read the fourteen of them end to end and you have a review pass, which is what OM-001 §16 is, and it was assembled by reading them, not written separately.
The last claim the form has to earn is the word language. A list has entries; a language has entries with relations, and the relations are where most of the design argument lives. Two structures carry it.
The first is position. The patterns sit at defined points on the loop a delegated task travels, and most arguments about agent design turn out to be arguments about which arc you are on.
The second is citation. Every entry names the patterns it feeds, loads, governs, cheapens or undermines, with the verb stated. In the printed catalogues that field has been a dead list at the foot of a page since 1994. In the explorer at /patterns it is how you move through the language, which is the difference the word was always claiming.
The strongest evidence that these fourteen belong together is that the same tensions surface in entry after entry, at different points on the loop. They are worth naming because most concrete design arguments are instances of them.
| Force | Pulls toward | Pulls against |
|---|---|---|
| Attention is finite | fewer prompts, peripheral channels, collapsed detail | disclosure, transparency, confirmation |
| Reversibility is purchasable | investing in undo to buy down ceremony | the irreducible set that cannot be undone |
| Prose is expressive, structure is precise | free text for intent | structured objects for selection and review |
| Trust is earned and revocable | widening autonomy with evidence | automatic descent on surprise |
| Latency is felt, not measured | streaming, early partial output | correctness of fragments |
| Memory decays into lies | promoting less, correcting eagerly | the cost of re-explanation |
A team that can name the force it is trading against is having a different conversation from one arguing about whether a dialog box is annoying.
OM-001 closed with a list of what its fourteen patterns did not cover. First on that list: multi-agent choreography — delegation between agents, and what a receipt means when the actor was itself an agent. It was excluded honestly. Nothing had been built, and a pattern with no observed failure is a preference wearing the template.
That changed quickly, and in two places at once. A console was built that spawns agents and renders what they do, which forced a series of measurements about what is actually knowable about a dispatched agent. And a working practice appeared alongside it: propose the units, approve them, dispatch them into isolated workspaces, and come back later to what they left.
Both produced failures. This document names eight of them.
Why these are not patterns 15 to 22
The first fourteen describe one delegated task travelling a loop: orientation, intent, execution, authority, and what survives. Every one of them assumes a single agent, and the vocabulary says so: Turn is defined as “the unit of exchange, and the thing that is held by exactly one party.”
Put twelve agents in flight and there is no turn. There is no single thread of exchange to hold, nothing to interrupt, and no moment at which the principal and the agent are both present. The topology is not a longer cycle. It is a fan-out and a fan-in, and everything difficult lives at the two seams and in the space between them.
So this is a second language rather than an extension of the first. It cites the first constantly, and several of its patterns are the first language's patterns discovering that they do not survive multiplication.
Two sources, of different quality, and the difference is worth stating instead of blending.
Measured, while building a console that watches agents
A console was built whose second front-end spawns an agent over pipes and renders its structured event stream as native elements, not as printed text. Rendering a dispatched agent forced four findings, each of which is a pattern in this document arriving as a bug.
| Finding | What it cost | Pattern |
|---|---|---|
A dispatch card sat on running for eight to sixteen minutes, then produced a wall of text. The events had been arriving the whole time and were being dropped. |
One reading for a range of states that could have been distinguished. | 5 |
| The harness never forwards token-level deltas from a subagent. A step is always a completed burst, and the gaps between bursts are real. | A hard granularity floor. Any surface implying live progress is lying, and the lie is available and tempting. | 5 |
The five lifecycle events key on task_id, not tool_use_id, and two of the five carry no tool_use_id at all. |
Keying on the obvious field drops every status transition while appearing to work. | 5 |
| Depth-2 lifecycle lines were declined and counted, not merged, because a card holds one progress value with nowhere to record a depth. | Merging “would put the grandchild's work in the parent's voice.” | 7 |
Observed, in one morning's practice
The second source is a working session, recorded as it happened:
“This morning I woke up to four such dispatch agents and I gave them that prompt. And then I took all of the replies and pasted them in series back to the agent that dispatched them.”
Working notes, 13 August 2026
Every unit succeeded. Nothing errored. The whole cost of the missing mechanism landed in one person's morning, as clerical work, and that is why it is easy not to notice. Pattern 6 is that sentence, named.
The same session produced the frame the patterns are arranged around:
“A flow state when creating involves doing this very quickly: dispatch an agent, then immediately get back to doing something else and dispatch another agent. And the whole time, you are giving the thing that the agents need, which is the taste and the direction and the choices that make this thing you're building yours.”
Working notes, 13 August 2026
What this establishes, and what it does not
The console findings are measurements: they were made against a real harness, they are reproducible, and three of the four were discovered by a surface being wrong in a way somebody noticed. The practice is one person, over days. It establishes that these failures are real and cheap to hit. It establishes nothing about their frequency, nothing about whether eight is the right number, and nothing about whether the boundaries fall in the right places.
As with OM-001: patterns that survive contact with other people's fleets are worth keeping, and the rest should be argued out.
The tensions that reappear across the eight. They are different from OM-001's, which is itself evidence that this is a second language rather than an extension.
| Force | Pulls toward | Pulls against |
|---|---|---|
| Attention does not divide | unattended work, pre-granted authority | informed consent at the moment of action |
| Isolation costs setup; collision costs correctness | a workspace per unit | the time and disk each one takes |
| You can only see what the channel carries | reporting exactly the granularity you have | the surface that would be nicer to look at |
| Authority granted early is granted blind | scopes an environment enforces | the specificity of per-action consent |
| Synthesis is not concatenation | reconciling, and surfacing disagreement | the cost of reading N reports |
| A finished unit that nobody routed has not finished | return addresses, durable reports | the simplicity of leaving work where it lies |
OM-002 described a team as though it had one shape. A commission is split, units run in isolation, reports come back, a gather reconciles them. That is a real shape and the most common one, but it is a shape (a choice among several), and the document never said so. Reading it back, the eight patterns look like a fixed sequence rather than a set of parts that can be assembled more than one way.
They can be assembled more than one way, and the assemblies are not variations. They are different enough that the same pattern means a different thing inside each one. That is the first half of this document.
The second half is a level up. OM-002's principal ran one team. In practice one person runs four to six areas of a product at once, each with its own dispatcher and its own units, and the difficulties there are not the difficulties of a larger team. They come from a single asymmetry, stated in OM-003 §12 and worth putting early: the recursion fails at the top, because the principal cannot be commissioned. Everything else at that level falls out of it.
What this closes, and what it does not
OM-002 listed six things it did not cover. This document takes up exactly one of them (contention for things that cannot be isolated), and only at the level where it bites hardest, which is the shared trunk rather than the shared port. Depth beyond two, heterogeneous teams, cost, the unit that never reports, and evaluation are all still open, and OM-003 §17 says so again instead of letting them fade.
It also takes up something OM-001 said about itself. That document's preface conceded that its acceptance checklist was “a checklist, which is precisely the weaker thing he was warning about”. OM-003 §1 is the attempt to do better, and OM-003 §11 is where the attempt is scored.
This document has thinner evidence than either of the two before it, and the right response is to say so at the front instead of writing at the same confidence and let the reader assume.
The ladder is worth stating plainly. OM-001: fourteen patterns, four of them drawn from measurements on a running system. OM-002: eight patterns, two of them drawn from four measurements made while building a console, the rest from one person's practice over days. OM-003: six composites and three patterns, none of them newly measured. What is new here is arrangement and topology, and reasoning about topology is argument, not evidence.
The four sources themselves, what each can and cannot establish, and the eight places where an incident belongs and none is on record, stay with the entries that cite them: OM-003 §3. Every entry there names which source it rests on, and twelve links from ten of its sections point at a numbered slot. That table is an instrument the entries use, not part of this case, and separating them was the point of the split.
The tensions that reappear across both levels. The first three are new; the fourth is OM-002's first force arriving at a level where it can no longer be engineered around.
| Force | Pulls toward | Pulls against |
|---|---|---|
| The whole changes the parts | naming arrangements, so a pattern's meaning is read from its position | the simplicity of one pattern, one meaning |
| Duplication buys independence | panels, verifiers, repeated rounds | N times the cost for one answer, and no partition of the work |
| Partition is cheap; ordering is not | splitting work into units that never meet | a single shared trunk through which all of it must land, in some order |
| Attention does not divide, and cannot be scoped | surfaces ordered by what needs a decision | everything else competing for the same person |
| Finished work rots while it waits | landing small and often | the coherence of a release, and the cost of each landing |
| Re-entry costs more than it looks | durable notes maintained for a reader who was absent | a second artifact that can go stale and lie |
OM-004 is not a new language beside OM-001. It is the first paper in this programme that goes back to a pattern already published and reports what building it taught — including the parts of it that were wrong.
Ambient Activity Channel proposes exactly the peripheral channel that has since been built:
Signal the agent's state through a channel the principal perceives without attending to it, so presence and progress cost no screen and no focus.
It even names the palette that was eventually built (violet thinking, cyan tool, warm speaking, amber consent) and states three of the rules OM-004 was going to claim as new: that the channel reports state and never instructions; that the renderer owns presentation and a priority stack; and that it must obey Honest Gauge, because a peripheral signal that lies is worse than a transcript that lies, being trusted without being read.
That is a better thing for a paper to be than a new language, and it is what the evidence actually supports. But the return is not a victory lap. Two of that entry's implementation notes turn out to be insufficient in practice, and saying so is the paper's job.
| Ambient Activity Channel says | What building it showed |
|---|---|
| “Give every state a time-to-live so a lost ‘off’ decays rather than stranding the device.” | A time-to-live decays a stale live cue. It does nothing for a resting state, which is sent once and stays wrong forever. The lamp came up white and no timer would have fixed it. → Standing Assertion |
| “The renderer owns presentation and a priority stack.” | There are two stacks, in two structures of different shape, neither able to see the other, with no test on the composite, and the written composite states its first step backwards. → One Ordering, One Place |
A pattern language that can be corrected by its own practice, in public, with the measurement that did it, is doing the thing this programme says it is for. A language that only ever accreted would be evidence of nothing except that nobody had tried to use it.
Mode Visibility is the second seed, and it was resolved rather than refined. The persistent mode was deleted and replaced by which key you hold. The pattern said make the mode visible at the moment of use; the answer that worked was to remove the mode, so there is nothing to make visible. That is a legitimate outcome for a pattern and the catalogue should be able to record it: the entry stands, because most surfaces cannot delete their modes.
OM-001 adds one field to the Gang of Four form: the seam, which side of the harness/agent boundary a pattern is implemented on. OM-003 adds two: What it changes and Evidence. OM-004 adds one, and it is the strongest of the four:
How you would know this is unnecessary.
Every entry states the condition under which it should be deleted. Not when not to use it, but the condition that would make the pattern pointless, named precisely enough to be checked.
This is not a formatting choice. It recovers Alexander's forces: each answer names the pressure that generates the pattern instead of restating the solution. Four worked examples, all from the first half of OM-004:
And it gives the language something the Gang of Four form has no slot for at all: a pattern that specifies the test that retires it. OM-004's second half ran one. Whether the fast draft pass is still needed was a live question with an answer rather than a matter of taste, and it came back: the draft stays, and what turned out to be doing nothing is something that was never named as a role at all.
The failure mode, which we walked into before publishing
Naming a retirement condition makes it checkable. It does not make the check sound, and the two are easy to confuse: a fact this programme established the expensive way, against itself.
We checked one such condition (does a live transcript ever revise a word from far back in a long utterance?) against a stretch of short ones, saw nothing of the kind, and rescaled the pattern accordingly. The drafting notes then hardened that into does not happen. Shortly afterwards we watched it rewrite the first word of a long one.
A null result from a sample incapable of exhibiting the condition is indistinguishable from a true negative, and it arrives wearing the same authority as a real one. The field's whole value is that it lets a pattern be retired on evidence; that is exactly what makes a false retirement cheap to act on and expensive to notice.
So the field carries an obligation the others do not: state the condition, and state what you would have to have seen to test it. An entry whose retirement condition has been checked should say against what, and whether that could have produced the other answer. This is the strongest of the four template additions across the language, and it is the one that can do harm.
One workstation, one person, one room, over about a fortnight. A lighting channel that was built, broken and repaired several times over, and a speech pipeline dictated into every day. That is the whole of it.
The entries are drawn from watching those two things work and fail. Where something has never actually been observed — a hand on the lamp, an error arriving at 2am — the entry says so on its face instead of leaving a reader to assume otherwise. Those admissions are the most useful thing in the paper and are not to be tidied away.
⚠️ Withdrawn 20 Aug 2026: this section previously set out a position on formal evidence, provenance labels on every claim, and a commitment to publish a reproducible acceptance corpus. That apparatus came out of a period of instrumented testing on one voice pipeline, and it described neither the rest of this catalogue nor how these patterns were actually arrived at. The id is kept because it was published.
OM-004's second set was drafted and then deliberately withheld, because the arrangement it described looked as though it were about to lose a component. It was published once that had been worked out in practice: nothing was removed, and what turned out to be doing no useful work was a mode of operation nobody had named as a role.
⚠️ Withdrawn 20 Aug 2026: this section reported a commissioned measurement over a speech pipeline — replay counts, timings, and the argument they supported. That testing is no longer part of the record. The finding it produced survives where it belongs, in the entries themselves. The id is kept because it was published.
A previous form of OM-004's material was merged into the catalogue as a fifteenth One Agent pattern on 14 Aug 2026 and reverted two minutes later; the live site never carried it for any meaningful interval. It placed an arrangement of six patterns as a single pattern, which is why it was reverted and remains a good reason. The material returned as OM-004, at the level it belongs to.
⚠️ Withdrawn 20 Aug 2026: this section also carried three corrections to figures produced by instrumented testing of a voice pipeline — a revision-depth claim, a configuration described as deployed, and a firing rate. Those figures are no longer in the paper, so the corrections to them have nothing left to correct. The id is kept because it was published.
Directly ancestral
Contemporary collections
Primary material
Patterns 2, 3, 9 and 12 of the One Agent set are drawn from direct observation on a single workstation: a voice-first agent surface with a headless resident agent, local speech-to-text and synthesis, and a physical lighting channel. The measurements quoted are from that system and are set out in §5.
What is claimed, and what is not
This is a proposed language, not a settled one. The value of the Gang of Four form is that it makes a design argument falsifiable: each pattern states when it does not apply and what it costs, and Failure Signature adds a symptom you can go and look for. Patterns that survive contact with other people’s systems are worth keeping; the rest should be argued out of the catalogue, and this document is written to make that easy, not embarrassing.
Corrections and counter-examples: hello@organon.art. A pattern shown not to exist in the wild is a useful result and will be recorded as one.