Name the five loop architectures.	ReAct/TAO · Plan-then-Execute · Graph-based (LangGraph) · Dumb Loop · Conversation-driven (AutoGen).	harness-engineering::m1::recall
"ReAct is an acronym for what? State the cycle."	ReAct = Reasoning + Acting. Cycle: Thought → Action → Observation, repeated until stop. (Yao et al. 2022, arXiv:2210.03629.)	harness-engineering::m1::recall
"Plan-then-Execute is ~X× faster than ReAct on complex tasks. State X and the source."	X = 3.6× (LLMCompiler data). Caveat: holds on complex, decomposable tasks WHERE THE PLAN IS CORRECT. Inverts when the plan is wrong.	harness-engineering::m1::recall
"ReAct vs Plan-then-Execute: which can recover from a wrong mid-task step, and why?"	ReAct can recover (it interleaves planning and execution, re-reasons each turn). Plan-then-Execute cannot (commits upfront; every step inherits the plan's error, no mid-execution recovery).	harness-engineering::m1::analysis
"For a CI/CD pipeline task, which architecture — ReAct or Plan-then-Execute — and why?"	Plan-then-Execute. Steps are predictable/known; the 3.6× speed applies; the brittleness doesn't matter because the plan is reliably correct. ReAct's recovery ability is wasted on predictable tasks.	harness-engineering::m1::application
"For a debugging task, which architecture and why?"	ReAct. Debugging is unpredictable — you discover as you go; cannot plan upfront. Plan-then-Execute would commit to a wrong plan and inherit the error through every step.	harness-engineering::m1::application
"What is the 'dumb loop' philosophy?"	Delegate ALL reasoning to the model; harness handles only stable transition logic (call model, parse tool calls, execute, append). No plan validation, no explicit state machine. Anthropic's bet, realized in Pi.	harness-engineering::m1::recall
"State the future-proof test."	"When the underlying model upgrades, does agent performance improve? If yes, harness isn't constraining the model. If no, harness has become the constraint." Most over-engineered harnesses fail.	harness-engineering::m1::recall
"A senior engineer adds a sophisticated LangGraph state machine 'for control'. What's the risk?"	The graph fights model capability growth. A rigid graph encoding yesterday's best practice becomes tomorrow's constraint. If the model could handle a transition naturally, the forced path is overhead.	harness-engineering::m1::analysis
"Graph-based (LangGraph) is right when the ___ is the product; wrong when you want the model to ___."	Right when the PROCESS is the product (regulated workflow, compliance). Wrong when you want the model to figure out the process (exploration, creative).	harness-engineering::m1::application
"Conversation-driven (AutoGen) is right for ___ and wrong for ___."	Right for brainstorming/debate (emergent interaction is the point). Wrong for execution (non-deterministic, hard to audit, can loop).	harness-engineering::m1::application
Name the five stop conditions.	Token budget · no-tool-call (end_turn) · max iterations · error threshold (N consecutive) · human interrupt.	harness-engineering::m1::recall
"Why must the token budget be cumulative across the session, not per-call max_tokens?"	Per-call max_tokens limits ONE completion. A session budget limits cumulative spend across ALL calls in the run. Without it, a runaway session = five-figure bill.	harness-engineering::m1::analysis
"What is the infinite loop problem, and what are its three causes?"	"No stop condition triggers → model keeps calling tools, each costs money, no exit. Causes: (1) model hallucinates ongoing work; (2) tool keeps failing, model retries; (3) context fills with noise, model loses the task."	harness-engineering::m1::recall
"Same tool + same input + same error, repeatedly. Which stop condition catches this, and what's the pattern called?"	Error threshold (N consecutive errors → halt). The pattern is a STUCK LOOP (Module 7.2 builds a detector).	harness-engineering::m1::application
"A loop with no stop condition is a ___."	Production defect. The infinite loop problem. Every production loop needs all five conditions.	harness-engineering::m1::recall
Name the four subagent patterns.	Agents-as-tools · Handoffs · Fork · Worktree.	harness-engineering::m1::recall
"Which subagent pattern keeps the parent in control? Which loses visibility?"	Agents-as-tools keeps control (sync, structured result returns). Handoffs lose visibility (terminal, one-way). Fork loses it (isolated). Worktree keeps it (mergeable).	harness-engineering::m1::analysis
"A subagent returns its full context to the parent. What's wrong, and what's the cure?"	Pollutes parent's window + re-bills tokens. Cure: bound returns to 1-2k tokens; summary-only by default; full output via JIT retrieval. (Same as Fleet F02 orchestrator-context-trap.)	harness-engineering::m1::analysis
"oh-my-opencode's Prometheus → Atlas → Junior hierarchy uses which two subagent patterns?"	Prometheus → Atlas = agents-as-tools (Atlas returns structured summary). Atlas → Junior = worktree (parallel execution with merge). Real systems MIX patterns.	harness-engineering::m1::application
"True or false: there is one correct subagent pattern; choose it."	False. Real systems mix patterns based on the control/visibility tradeoff. The rubric (Module 10) scores the MIX, not the choice of a single pattern.	harness-engineering::m1::analysis
Name the 8 fields of the per-turn observability payload.	trace_id · turn_number · tool_name · input_hash · output_hash · latency_ms · token_delta · stop_reason.	harness-engineering::m1::recall
"Why hashes (input_hash, output_hash) instead of full content in the per-turn payload?"	Tool outputs are 67.6% of context (Module 0.3) and may contain secrets. Hashes dedup, detect stuck loops (same input+output = no progress), enable selective replay. Full content → separate access-controlled store.	harness-engineering::m1::analysis
"Same input_hash + same output_hash across consecutive turns. What does this signal?"	A STUCK LOOP — no progress. The model is calling the same tool with the same input and getting the same result. Triggers stuck-loop detection (Module 7.2).	harness-engineering::m1::application
"How do you add observability to a loop WITHOUT modifying its core?"	Wrap callModel and executeTool with a withObservability higher-order function that records start time, calls through, emits the structured payload. Same pattern for permission gates (M6) and security checks (M11). The loop's interface is the extension point.	harness-engineering::m1::application
"Pi logs minimally; Claude Code logs extensively. Which is correct?"	Both. Observability is a thickness-spectrum decision. BUT there is a FLOOR: a loop emitting nothing is un-debuggable. Pi is above the floor; no-logging is below it. There's no excuse to ship a loop with no per-turn payload.	harness-engineering::m1::analysis
"The loop's callModel/executeTool interface is described as what?"	The extension point. Observability, permissions, security, rate limiting, cost enforcement all plug in around it via wrappers. Learn the wrapper pattern once; reuse for all cross-cutting concerns.	harness-engineering::m1::recall
"Name the four loop anti-patterns from Module 1."	(1) Infinite retry (cure: error-threshold + taxonomy). (2) Graph that fights the model (cure: dumb-loop philosophy). (3) Un-observable loop (cure: wrapper). (4) Unbounded subagent return (cure: 1-2k token bound).	harness-engineering::m1::recall
"LangGraph's interrupt() serializes state and waits indefinitely. What is this the foundation of?"	Human-in-the-loop design (Module 6.2). The approval stop condition.	harness-engineering::m1::application
"You're choosing an architecture for a compliance-governed multi-approval agent. Which, and why?"	Graph-based (LangGraph). The process IS the product — explicit, testable state machine; native checkpointing; interrupt() for HITL at approval nodes. Wrong choice = wanting the model to figure out the process.	harness-engineering::m1::application