Round 2 — March 2026
Round 1 produced three complementary lenses on a single question: when should an agent pause before implementing? Decision Theory gave a scoring formula (DPS = R×I×S). Cognitive Ethnography gave a cognitive science grounding (RPD, tacit knowledge, Design Stance Protocol). Signal Archaeology (not completed in R1) would presumably mine git history for risk signals.
The steel-man: Round 1 correctly identified that the agent's failure mode is not bad decision-making but non-decision — proceeding through a genuine design fork as if it were an execution step. The DPS formula is honest about being a "decision instrument," not a precise formula. The Design Stance Protocol explicitly names what it is: an externalized substitute for expert anomaly detection. The cognitive ethnography is the strongest piece — it accurately models what tacit expertise actually is (compiled procedural memory, not articulable rules) and why checklists will always be incomplete.
Now the rebuttal.
Where Decision Theory fails: The DPS formula (R×I×S) is a trigger for pausing at individual decisions. But consider what it assumes: that the agent encounters a decision, applies the formula, and then either pauses or proceeds. This is instance-level thinking. It treats every decision as independent. A staff engineer doesn't operate this way. They design architectures where large categories of bad decisions become structurally impossible — the fork doesn't appear in the first place. DPS can score "should I store state in the orchestrator or in the subagents?" But it cannot tell you "design the system so that state ownership is never ambiguous at the protocol level." That's a different level of thinking entirely. The formula addresses symptoms. The staff engineer addresses categories.
Where Cognitive Ethnography fails: The Design Stance Protocol is five steps that mimic what an expert does after their anomaly detector fires. But the document is honest about a deeper problem it then sidesteps: "AI agents, currently, have no persistent episodic memory across sessions. Each session begins at the same baseline." The protocol doesn't solve this — it works around it by providing an explicit procedure to substitute for pattern-matching that doesn't exist. That substitution is useful but it's not the same thing. A protocol that says "name two alternative designs" doesn't know which alternatives are worth naming. An expert names the right two alternatives because they've seen this class of problem fail before. The agent names whatever comes to mind. The gap between those two is the gap between a checklist and a decade of experience, and Round 1 does not close that gap.
The shared failure across all Round 1 approaches: Every one of them is about the trigger — when to pause. None of them address the question Aviad actually asked: how does an agent acquire the equivalent of engineering experience? How does it form and test hypotheses? How does it explore design space efficiently? How does it get better over time? Round 1 built better brakes. The question was: how do you build a driver?
Aviad's clarification reveals this is not a "design pause" problem at all. It is a problem about engineering intelligence as a learnable, accumulating capability.
The actual problem: AI agents currently operate like very capable but permanently junior engineers. They can execute competently within a session. They can reason about designs when prompted. But they don't accumulate experience, don't form and test hypotheses about categories of problems, don't build intuitions that transfer across sessions, and don't develop the architectural instincts that distinguish a staff engineer from a senior engineer. Every session is day one.
The question is: can this be changed? And if so, how?
This is a fundamentally different problem from "when should the agent pause." It has three distinct sub-problems:
Sub-problem A — Experience accumulation: How does an agent build something analogous to a failure library and design pattern library that persists and grows across sessions?
Sub-problem B — Hypothesis formation and testing: When an agent encounters a design question, how does it form architectural hypotheses and validate them before committing — not by gut feel, not by checklist, but by something resembling the scientific method applied to software architecture?
Sub-problem C — Category-level prevention: How does an agent design systems where entire categories of mistakes become impossible, rather than detecting individual instances of those mistakes?
Round 1 addressed none of these. It addressed a fourth problem — instance-level decision triggers — which is useful but downstream of the real problem.
The cognitive ethnography cites Klein's RPD model but draws from it only the trigger mechanism. The fuller model is more useful.
When a staff engineer encounters a new codebase or problem, they don't immediately evaluate design alternatives. They do something prior to that: they build a mental model of the problem's category. Before asking "which design?", they ask "what kind of problem is this?" and "what category does this belong to?" That categorization triggers retrieval from a library of category-specific failure modes, known solutions, and known traps.
The sequence is roughly:
-
Categorize — "This is a distributed state ownership problem. I've seen three variants of this: the write-through pattern, the CRDT pattern, and the saga pattern. Each has a failure topology." The categorization happens fast, often before the agent has even described the problem fully.
-
Load failure topology — Not "what could go wrong?" generically, but "what specifically goes wrong with each known design in this category?" The failure topology is specific to the category. For distributed state ownership: partial write failure, split-brain, read-your-writes violations. These aren't hypothetical — they're patterns extracted from past incidents across many projects.
-
Form hypotheses — "Given this specific context (session-scoped agents, no external queue, crash-recovery requirements), hypothesis: the write-through pattern will fail on mid-session crash. Hypothesis: the saga pattern is overkill for this scale. Hypothesis: agent-local writes with late aggregation violates the read-your-writes requirement in the review workflow." These are falsifiable predictions, not gut feelings.
-
Test hypotheses cheaply — Before building anything: "If I use the orchestrator-batch pattern, what happens when the process dies at step 7 of 10?" Walk the failure path explicitly. This is hypothesis testing — you're running a mental simulation designed to falsify your preferred design.
-
Eliminate dominated options — Options that fail more failure modes than alternatives, without compensating advantages, are eliminated. Not ranked. Eliminated. The design space shrinks fast.
-
Make the residual tradeoff explicit — After elimination, often one or two options remain. The staff engineer makes the tradeoff explicit: "Option A is simpler but loses idempotency. Option B is complex but survives partial failure. Given that this workflow runs once per session and partial failure is the common case, B." This is a decision — but it's a decision between a small residual set after most candidates have been eliminated by hypothesis testing.
Notice what is not in this sequence: a formula. Not a scoring rubric. Not a checklist. What is present: a category library that gets loaded before evaluation starts, a hypothesis formation step that is explicit, and a falsification discipline that eliminates options based on which failure modes they can't survive.
The DPS formula skips to step 6 without doing steps 1-5. That's why it's insufficient.
This is the central distinction Round 1 missed.
Instance-level detection: The DPS formula fires when the agent is about to make a decision that scores high on recurrence, irreversibility, and survival divergence. The agent pauses. It considers alternatives. It makes a better decision. One decision at a time.
Category-level prevention: The agent designs a system where the bad decision cannot arise. Instead of "detect when state ownership is ambiguous and pause," the answer is: "enforce a protocol that makes state ownership structurally unambiguous." If agents are required to register state claims with a coordinator before writing, the orchestrator-batch vs. agent-stores fork never appears — the protocol makes one answer mandatory.
Category-level prevention operates at the architecture layer, not the decision layer. It changes the decision space itself rather than improving decision-making within the current decision space. This is the difference between designing a road with guardrails (category-level) and training better drivers (instance-level).
Concrete examples of the difference:
-
Instance-level (DPS): "When you're about to store state, check if this is session-scoped and if there's a survival divergence between design options."
-
Category-level: "All state that must survive session death is persisted atomically by the writing agent before any coordination signal is sent. This is an invariant, not a decision."
-
Instance-level (Design Stance Protocol): "Before implementing, name two alternative designs."
-
Category-level: "The system uses an append-only event log. All agents append. No agent reads from another's mutable state. The category of 'which agent owns this state' is structurally eliminated."
Category-level prevention is more powerful for two reasons. First, it works when the agent doesn't notice the decision — the architecture makes the bad option impossible, so the agent doesn't need to detect that it's at a decision point. Second, it's O(1) overhead at decision time — the rule applies everywhere without a scoring step.
The cost: category-level prevention requires more upfront thinking. You have to identify the category before you can prevent it. You need the experience to recognize that "state ownership ambiguity" is a category worth preventing, not just a case worth detecting. This is where the experience accumulation problem re-enters.
Aviad explicitly named "how to form and test hypotheses" as a core requirement. Round 1 ignored this entirely. This is the biggest omission.
The scientific method, applied to software architecture, looks like this:
Step 1 — Observation: Identify the phenomenon you're trying to explain or the requirement you're trying to satisfy. "The review workflow must survive mid-session crashes."
Step 2 — Hypothesis: State a falsifiable prediction. "Hypothesis: if each agent persists its findings before signaling completion, the orchestrator can safely crash and restart without data loss." Crucially: this is falsifiable. You can construct a scenario that would prove it wrong.
Step 3 — Experiment design: What is the cheapest way to falsify this hypothesis? Not "build it and see," but "what is the minimal test?" For architecture hypotheses, the cheapest test is usually a failure scenario walkthrough: "assume the orchestrator crashes at point X. What state has been written? What is lost? What can be reconstructed?"
Step 4 — Falsification attempt: Execute the failure scenario. Try to break the hypothesis. If the hypothesis survives — if you cannot find a scenario where it fails — it becomes a design choice with documented failure modes.
Step 5 — Rival hypothesis comparison: If hypothesis A survives falsification, compare it to the best rival hypothesis. "Rival: orchestrator writes findings in a single batch at the end. Falsification: orchestrator crashes before the batch write. Outcome: all data lost." Rival hypothesis is falsified. Original hypothesis survives. Choose original.
This is what Round 1 doesn't describe. The Design Stance Protocol's "failure-first simulation" is in the neighborhood — but it stops short of being a hypothesis-testing methodology. It's a checklist step, not a scientific discipline. The difference: in hypothesis testing, you are explicitly trying to prove yourself wrong. You seek the failure mode that kills your design. If you can't find it despite genuine effort, the design is provisionally validated. The Design Stance Protocol asks you to "name failure modes" — but doesn't require you to construct the minimum scenario that falsifies each design candidate.
The practical mechanism for agents: before any non-trivial design choice, the agent must state at least one falsifiable hypothesis per candidate design, then explicitly attempt to falsify each hypothesis by constructing the simplest possible failure scenario. Only designs that survive falsification attempts are eligible for selection.
This is not expensive. A well-formed falsification attempt takes two to three minutes. It is also fast to recognize when a hypothesis is obviously non-falsifiable (trivially correct) vs. genuinely surviving pressure.
Aviad said: "small issues don't start taking huge resources." Round 1 acknowledges this in the DPS formula's meta-paradox section: "if the agent applies DPS to every sub-decision recursively, the overhead explodes." The proposed fix is to scope DPS to structural decisions only.
But that fix is still instance-level. It reduces the frequency of the overhead, not the nature of it. The DPS formula is a uniform mechanism applied selectively. What's needed is a mechanism that is inherently proportional — where the cost scales with the actual complexity of the decision.
What does proportional look like?
Near-zero cost (simple decisions): Pattern match to a known solution in the category library. "This is a simple state storage problem where the state is bounded and session-local. Known pattern: in-memory dict. No hypothesis testing needed — failure mode is trivial and recovery is trivially cheap." Total overhead: 2 seconds to recognize the category and match the pattern. Proceeds immediately.
Low cost (moderate decisions): Category recognized but multiple viable options exist. "This is a state persistence problem with cross-session requirements. Known patterns: file write, external queue, event log. Run one failure scenario per candidate, eliminate dominated options." Total overhead: 3-5 minutes. One falsification cycle per candidate.
High cost (novel decisions): Category not in library, or multiple categories apply simultaneously, or the failure modes are coupled in non-obvious ways. "This is simultaneously a distributed state problem and a protocol ordering problem. Unknown interaction." Full hypothesis testing with multiple failure scenarios, explicit documentation of the new category for future retrieval. Total overhead: 20-30 minutes — but this is rare by definition, because most decisions fall into known categories as the library grows.
The key insight: the cost scales with how novel the decision is relative to the accumulated category library. The more experience (the richer the category library), the faster the categorization step, and the more decisions fall into the near-zero cost tier. This is exactly how expert engineers get faster over time: not by running faster checklists, but by recognizing categories that previously required explicit analysis.
This is fundamentally different from a formula with a threshold. A formula applies uniform processing to every decision that clears the threshold. A category library gets cheaper to use as it grows, and the cheapest outcomes are the most common outcomes (because familiar problems are common).
Given the critique above, the right mechanism is not a formula, not a checklist, and not a trigger. It is a growing architectural intelligence layer — a system that accumulates experience, improves its own category library, and applies that library proportionally.
The components:
Component 1 — Category Library (persistent, growing): A structured knowledge base of problem categories, each with: (a) recognition features — how to identify this category when you see it, (b) known design patterns — the viable options for this category, (c) failure topology — what goes wrong with each pattern, (d) category-level invariants — architectural rules that prevent entire failure classes, (e) incident links — real kaizen incidents that belong to this category. This is not a checklist. It is a retrieval-augmented reasoning substrate. When the agent encounters a problem, it retrieves the relevant category and loads the failure topology before any evaluation begins.
Component 2 — Hypothesis Formation Protocol (session-specific): Before any non-trivial design commitment, the agent states one falsifiable hypothesis per candidate design, then runs the cheapest possible falsification attempt. Designs that are falsified are eliminated. Designs that survive are compared on their residual tradeoffs. This is one protocol, not a 5-step procedure. "State your hypothesis. Try to break it. If you can't break it, it survives."
Component 3 — Category-Level Architecture Review (upfront, rare): When starting a new system or major component, do a category audit: "What categories of problems does this system create? Which categories are already prevented by the architecture? Which are still open?" This is the staff engineer's "architecture review" translated into the agent's terms. The output is not a design decision — it is a set of invariants: rules that make whole categories structurally impossible. These invariants are added to the system design document and enforced by hooks or conventions.
Component 4 — Incident-to-Category Feedback Loop (after every failure): When a design choice fails, the failure is not just filed as an incident. It is classified into a category. If the category exists in the library, the failure topology is updated. If the category doesn't exist, a new category is created. This is how the library grows. The feedback loop converts incidents into category-level intelligence that benefits all future sessions — not just the one that made the mistake.
Component 5 — Proportional Cost by Category Match (automatic): If the problem matches a category cleanly and one option is clearly non-dominated in that category, proceed immediately with a one-sentence log entry. If the problem matches a category but multiple options survive the failure topology, run a focused falsification cycle (5 minutes). If the problem doesn't match any category, treat it as a novel problem and run full hypothesis testing (20 minutes) and create a new category entry. Cost is proportional to novelty.
This proposal addresses what Round 1 missed:
- It accumulates experience (Category Library grows from incidents).
- It operates at the category level, not the instance level.
- It includes genuine hypothesis testing with falsification.
- It is proportional — familiar problems cost near-zero.
- It gets better over time, because the library grows and more decisions fall into the cheap tier.
- It is adaptive — when a novel failure mode appears, it expands the library rather than failing silently.
The DPS formula can exist inside this as one heuristic for scoping which decisions need a focused falsification cycle. The Design Stance Protocol's steps become the falsification protocol. But both are subordinate to the category-level architecture review that happens upfront and converts instance-level decisions into category-level invariants wherever possible.
Before Round 3 rebuts this, let me name the strongest objection to the proposal above: who builds the category library?
The library starts empty. The first session has nothing to retrieve. The first few incidents create categories, but those categories are only as good as the incident-to-category mapping. And mapping incidents to categories requires the judgment that the agent doesn't yet have. There's a bootstrapping problem: the thing that would make the agent competent requires the competence to build it.
The honest answer: this is a seeded knowledge problem. The initial category library is not built from agent experience. It is built from Aviad's experience — extracted through the critical incident debriefing technique the cognitive ethnography describes. The first version of the library is a compiled artifact of human expertise, structured for machine retrieval. Subsequent sessions grow it from incidents.
This is uncomfortable because it means the quality of the initial library determines the quality of the agent's architectural intelligence for many sessions. But it is not more uncomfortable than the alternative — the DPS formula, which is also seeded from Aviad's experience (the five risk categories), also starts with zero coverage of novel failure modes, and also doesn't improve itself from incidents in any structured way.
The category library at least has a growth mechanism. The DPS formula doesn't.
This document is a second-round contrarian antithesis. It is designed to be wrong in interesting ways. The synthesis is not yet visible. Round 3 should not simply average this with Round 1 — it should find the resolution that neither round reached.
{ "id": "fsi-042", "github_issue": 713, "date": "2026-02-14", "title": "Review findings lost on orchestrator crash", "failure_category": "state-resilience", "surface_trigger_keywords": ["store", "findings", "session", "orchestrator", "flush"], "design_anti_pattern": { "shape": "accumulate-then-flush", "description": "State accumulated in orchestrator memory, written only at task completion", "trap_condition": "session boundary or crash before flush" }, "preferred_pattern": { "shape": "write-through", "description": "Each sub-agent writes its findings immediately on completion" }, "seams_involved": ["orchestrator-subagent-boundary", "session-lifecycle", "review-gate"], "irreversibility": 3, "confirmed_recurrences": 1, "confidence": 0.8, "last_confirmed": "2026-03-10", "status": "active" }