Strict goal verification, approval hardening, retrieval eval, work limits, sandbox caps (1.38.0)

- Approval: re-prompt unknown answers (max 3), shell-only affirmative guidance recovery; destructive actions stay strict - GoalVerifier subagent with strict JSON verdicts, bounded follow-up rounds, nonzero exit plus open turn on unverified one-shots - Retrieval eval (Hit@K/MRR/nDCG/Context Precision), FTS cascade with title weighting, query/read event logging, --eval-retrieval CLI - Supervisor caps (8 parallel, 64 records) and scheduler hardening (4 fires/tick, per-schedule lease, stated misfire policy) - Sandbox box resource trio: 2g/2.0/256 at create, best-effort update for existing boxes, rm -f recovery pointer - Research archive: 12 subjects, 667 sources, 27 conclusions; suites 979 + 16 green
2026-10-18 12:13:24 +02:00
parent fb72ab8a7f
commit af080fe68e
157 changed files with 8503 additions and 70 deletions
@@ -10,6 +10,7 @@
 *.html
 *.md
 !research/**/*.md
+!uiflow.md

 # Backup files
 *.bak
@@ -9,6 +9,7 @@
 - The in-`tai.py` TUI framework is documented in [tui.md](tui.md) — read it before touching any `Tui*` code.
 - The grr terminal client (`tai.py --tui`, the `Grr*` classes) is specified in [grrtui.md](grrtui.md): read it before touching any `Grr*` code, and keep its screen, key and cap tables in step with the code (`GrrSpecTests` fails when they drift). It is a client of the grr server and shows what the server's `/api/spec` and `/locales.json` say; never copy a string, color or limit of the server into `tai.py`. `tests/grr_tui.py` drives the real binary against a real grr server (sibling `../grr`, `GRR_DIR` to move it) and a real model.
 - The terminal multiplexer (`Mplex*` classes, `tai.py --mplex`, `~/.tai/mplex.toml`) is specified in [mplex.md](mplex.md): read it before touching any `Mplex*` code, and keep its option, command and key tables in step with the code (`MplexSpecTests` fails when they drift).
+- Interactive UI flows (`plexer_show`, `PlexerFlow`, `PlexerController.ask`, the `show`/`result`/`cancel` control commands) are specified in [uiflow.md](uiflow.md): read it before touching any flow code, and keep its contract and cap tables in step with the code (`UiflowDocTests` fails when they drift).

 ## Testing

@@ -89,7 +89,7 @@ A plexer session is a terminal tai can see into and type into, not just read a o
 - **tmux** — if the shell is already inside a tmux pane (`$TMUX_PANE` set), that pane *is* the session. tai drives it with plain `tmux send-keys`/`capture-pane`/`list-panes`; nothing is spawned.
 - **native multiplexer (mplex)**: if nothing already owns the terminal, the plexer-hook/`zsh-plexer-hook`/`fish-plexer-hook` installed above re-execs the fresh interactive shell into `tai.py --plexer-wrap`, which starts (or joins) tai's own tmux-style multiplexer and attaches the terminal to a new session. One detached server per `TAI_HOME` owns every pty, window layout and scrollback; the terminal is a thin client, so detaching leaves everything running and `tai.py --mplex attach` brings it back. Every pane's output is also written to a log under `~/.tai/plexer/`, and the server answers control commands on a Unix socket (`TAI_PLEXER_SOCKET`), with the pane id in `TAI_PLEXER_PANE`, so a separate tai process (the agent the user is actually talking to) can drive the pane it was started in.

-Either way, four tools appear only while a session is actually active (`plexer_send`, `plexer_read`, `plexer_type`, `plexer_status` — hidden otherwise, not just disabled, via `TOOL_ENV_GATES`): `plexer_send` types literal keystrokes (optionally pressing Enter), `plexer_read` reads back the last N lines of real rendered output, `plexer_type` does the same as `send` but one character at a time with a delay for a visible typing effect, and `plexer_status` reports which backend is active and its details (pid/socket/log, or tmux pane id). Which backend answers a given call is autodetected from the environment (`TAI_PLEXER_SOCKET` vs `$TMUX_PANE`), never configured by hand.
+Either way, five tools appear only while a session is actually active (`plexer_send`, `plexer_read`, `plexer_type`, `plexer_status`, `plexer_show`, hidden otherwise, not just disabled, via `TOOL_ENV_GATES`): `plexer_send` types literal keystrokes (optionally pressing Enter), `plexer_read` reads back the last N lines of real rendered output, `plexer_type` does the same as `send` but one character at a time with a delay for a visible typing effect, `plexer_status` reports which backend is active and its details (pid/socket/log, or tmux pane id), and `plexer_show` renders a whole interactive UI flow (dialogs, forms, branching multi-screen apps) from one JSON spec and returns the outcome. Which backend answers a given call is autodetected from the environment (`TAI_PLEXER_SOCKET` vs `$TMUX_PANE`), never configured by hand. The flow contract is [uiflow.md](uiflow.md).

 ### mplex: the multiplexer

@@ -101,6 +101,10 @@ renderer of the chat scene (headings, bold, inline and fenced code, lists, quote
 than 30 minutes passed, `NEW` marks what you have not read. Under the newest bot message, and under any message you
 select, sit copy, good, bad and try again; steps fold open with Enter.

+A pending approval is also asked at once as a dialog (Deny, Allow once, Always allow for the browser tool) the moment it arrives or the chat opens, without blocking anything: Esc leaves the card, a decision made elsewhere closes the dialog.
+
+A running command that goes quiet on a prompt-like last row (a password, a `?`, `[y/N]`) opens its terminal by itself, so the prompt reaches the user and the answer is typed into the command; Esc leaves it.
+
 Cards: approvals (Allow once, Deny, Always allow in browser for the browser tool, then the state), questions (lettered
 options and Skip), files (Enter opens the viewer: text with line numbers, anything else is saved and opened by the
 desktop), several files, templates (publish, copy link, details), and live process cards. A running command's card
@@ -184,6 +188,9 @@ Every limit is a constant in `tai.py`.
 | `GRR_COMPOSER_MAX_ROWS` | 6 | rows the composer grows to |
 | `GRR_VIEWER_MAX_BYTES` | 2097152 | bytes the file viewer reads |
 | `GRR_DRAFT_KEEP` | 64 | chats with a kept draft |
+| `GRR_PROMPT_QUIET` | 0.8 | seconds of silence on a prompt-like last row before a running command opens its terminal |
+| `GRR_PROMPT_ASKS` | 20 | times one process card opens its terminal by itself |
+| `GRR_PROMPT_MAX` | 8 | pending approvals asked at once as dialogs in one chat |
 | `GRR_LIST_MORE` | 12 | rows Show more adds |
 | `GRR_MENU_MAX_H` | 14 | rows of a menu before it scrolls |
 | `GRR_CONTROL_JOBS` | 64 | control jobs kept (finished ones drop oldest first) |
@@ -74,6 +74,19 @@ The same socket serves `NativePlexerController` (the agent tools). One request l
 error. `read` returns the tail of the pane's raw byte log. A malformed request returns `{"ok": false, "error": ...}`
 and never disturbs the server.

+Three more commands render one UI screen for the `plexer_show` agent tool (the
+full flow contract is [uiflow.md](uiflow.md)): `{"cmd": "show", "screen": {...},
+"timeout": 60}` draws the screen on the first attached client of the pane's
+session and returns `{"id": N}`; `{"cmd": "result", "id": N}` polls it
+(`{"done": false}` until the user answers, then `{"done": true, "status":
+"ok"/"cancelled"/"timeout"/"detached", "value": ...}`, collected once);
+`{"cmd": "cancel", "id": N}` drops it. Kind `choice`/`message` renders as a
+centered overlay dialog, kind `text` as a status-row prompt. `show` is refused
+loudly when the screen is malformed, the client is busy with another prompt or
+overlay, the session has no attached client, or `MPLEX_FLOW_MAX` flows are
+already pending. Records whose driver died are reclaimed after
+`MPLEX_FLOW_KEEP` seconds, on every show and every server tick.
+
 ### Hard caps

 | Constant | Value | Limits |
@@ -93,6 +106,7 @@ and never disturbs the server.
 | `MPLEX_PASTE_MAX` | 4 MiB | one paste buffer |
 | `MPLEX_RENDER_INTERVAL` | 12 ms | minimum time between frames for a client |
 | `MPLEX_REAP_KILL_AFTER` | 2 s | SIGHUP is escalated to SIGKILL for a pane process that ignored it |
+| `MPLEX_FLOW_MAX` / `MPLEX_FLOW_KEEP` | 16 / 300 s | pending UI flows per server, grace before a dead driver's record is reclaimed |

 ## Keys

@@ -102,7 +116,7 @@ Key names use tmux notation: `a`, `C-a`, `M-a`, `C-M-a`, `S-Up`, `Space`, `Enter

 Lookup order for every key from an attached client:

-1. an open prompt, then an open overlay (`display-panes`), take the key;
+1. an open prompt, then an open overlay (`display-panes`, a UI flow dialog), take the key;
 2. in the `root` table: a binding runs;
 3. the prefix key or `prefix2` switches the client to the `prefix` table; the next key is looked up there (an unbound key is dropped);
 4. otherwise the top mode of the pane takes it (copy mode uses `copy-mode` or `copy-mode-vi` according to `mode-keys`; a
@@ -6,19 +6,19 @@

 | Metric | Value |
 |---|---|
-| Subjects | 8 |
-| Total source documents | 531 |
-| — Tier 1 (Source Dossier, independently analyzed) | 158 |
-| — Tier 2 (Source Citation Card, listed only) | 373 |
-| Total conclusion documents | 16 |
+| Subjects | 12 |
+| Total source documents | 667 |
+| — Tier 1 (Source Dossier, independently analyzed) | 193 |
+| — Tier 2 (Source Citation Card, listed only) | 474 |
+| Total conclusion documents | 27 |
 | Archive opened | 2026-10-09 |
-| Last updated | 2026-10-12 |
+| Last updated | 2026-10-18 |

 ## Subjects

 | Subject | Sources (T1 / T2) | Conclusions | Opened | Last updated | Driving task |
 |---|---|---|---|---|---|
-| [`sqlite-rag-hybrid-search`](sqlite-rag-hybrid-search/) | 32 (10 / 22) | 1 | 2026-10-09 | 2026-10-09 | Designing tmux-log export + chunked retrieval; settled on BM25-only, no vector DB |
+| [`sqlite-rag-hybrid-search`](sqlite-rag-hybrid-search/) | 60 (17 / 43) | 3 | 2026-10-09 | 2026-10-18 | Designing tmux-log export + chunked retrieval; settled on BM25-only, no vector DB; extended 2026-10-18 with retrieval-quality measurement and a gated lexical tuning roadmap |
 | [`agent-memory-recency-tracking`](agent-memory-recency-tracking/) | 63 (16 / 47) | 1 | 2026-10-09 | 2026-10-09 | Designing an LRU-style last-used/use-count tracker for vault records and chunks |
 | [`async-pty-process-testing`](async-pty-process-testing/) | 59 (20 / 39) | 1 | 2026-10-09 | 2026-10-09 | Designing tai_test.py (pty vs. pipes, non-blocking stdin, process-group cleanup, test-framework shape) — backfilled after it was initially skipped, see activity log |
 | [`shell-multiplexer-auto-attach`](shell-multiplexer-auto-attach/) | 139 (49 / 90) | 3 | 2026-10-09 | 2026-10-12 | Designing a tai-managed terminal multiplexer + bashrc auto-attach: tmux-as-substrate recommendation, interactive-vs-automation shell detection; extended 2026-10-10 to cover zsh/fish hook syntax; extended 2026-10-12 with the tmux 3.6 key table, option and command dumps (installed binary) and the conclusion to build a native tmux-parity multiplexer configured by ~/.tai/mplex.toml |
@@ -26,6 +26,10 @@
 | [`agentic-tool-loop-design`](agentic-tool-loop-design/) | 74 (7 / 67) | 2 | 2026-10-11 | 2026-10-11 | Fixing stop-after-narration on prompt-JSON CLI backends without intent regexes; decided structural loop control plus exactly-once JSON-contract repair plus prompt contract, implemented in tai.py the same session (suite 357/357 + 16/16 green); approval tiers judged already industry-standard, no change |
 | [`muse-responses-openai-transpiler`](muse-responses-openai-transpiler/) | 66 (3 / 63) | 2 | 2026-10-11 | 2026-10-11 | Documenting Meta muse Responses wire format vs classic Chat Completions; decided bidirectional transpile is feasible with a fixed loss table and system guidance has three channels; scratch transpiler tested, nothing merged |
 | [`free-model-discovery`](free-model-discovery/) | 4 (4 / 0) | 1 | 2026-10-12 | 2026-10-12 | Bringing tai's free model lists up to date from live endpoints (zen, openrouter, devplace, pollinations); live discovery replaces hard-coded lists |
+| [`agent-goal-verification`](agent-goal-verification/) | 43 (11 / 32) | 3 | 2026-10-18 | 2026-10-18 | Validating whether the GoalVerifier subagent plus strict JSON verdicts plus approval hardening scales and is solid; kept all three as shipped with stated conditions |
+| [`prompt-context-scaling`](prompt-context-scaling/) | 34 (10 / 24) | 3 | 2026-10-18 | 2026-10-18 | Scaling prompts past the context window and reusing RAG/graph for more; tai already matches the converged arsenal, giant prompts should spill to retrievable records (specified, not built), full GraphRAG and memory vendors rejected |
+| [`background-work-limits`](background-work-limits/) | 10 (4 / 6) | 2 | 2026-10-18 | 2026-10-18 | Bounding parallel subagents and hardening the scheduler; parallel cap 8 with reject-loud, per-tick fires 4, one live run per schedule via lease, stated misfire policy; implemented same day |
+| [`sandbox-resource-caps`](sandbox-resource-caps/) | 21 (3 / 18) | 1 | 2026-10-18 | 2026-10-18 | Capping the agent sandbox box CPU/memory/pids after the coverage audit found it uncapped; static trio 2g/2.0/256 at create, best-effort update for existing boxes, pids via recreation; implemented same day |

 ## Recent activity log

@@ -48,6 +52,11 @@
 | 2026-10-11 | `tui-framework-design` | Extended with 16 more sources (all Tier 1, no Tier 2 — every consulted source body was fetched by the researching agents) + 2 conclusions (`conclusions/telegram-chat-grammar-adoption.md`, `conclusions/telegram-theme-roles-mapping.md`): 10 dossiers on Telegram chat look-and-feel (tdesktop day/night theme files, lang.strings copy sheet, Android DialogCell/ChatMessageCell, FAQ check semantics, chat-themes blog, third-party checkmarks explainer, Bot API keyboards/commands, bot features onboarding) and 6 on Mini App theming (official WebApps ThemeParams/events/design rules; SDK docs for main/back, settings, viewport, theming; third-party iOS teardown). Decisions: adopt Telegram's metadata grammar as rows (clock/checks/blue-checks/eye, no delivered state), 8-hue peer palette, service/date pills, literal status/composer/bot copy, and reply-vs-inline keyboard grammar, rejecting bubbles, gradient themes, and pixel geometry; map the 15 ThemeParams keys onto tai's 12 roles with Desktop-file plus dark-sample defaults and a never-hardcode/re-read-on-switch discipline. A same-session internal tai.py inventory (chat scene present but plain: no ticks/dividers/header/rich rows/composer buttons; 6 of 12 roles used, hardcoded borders) informed both conclusions with per-item patch targets but produced no source documents (internal code, not external research). Nothing built yet — both conclusions are specified-not-shipped. Carried gaps: iOS/Web hexes unverified (Desktop day/night only); bubble radii/paddings/spacing/tail geometry, header icon inventory, chat-list time/date formatting and truncation, send-vs-voice swap and media-bubble time overlay unknown; no official typography/spacing spec (teardown values only); light defaults for section_*/subtitle/destructive unpublished; WebViewColors diagram uninspected; back-button SDK page yielded no captured evidence. Subject total now 94 sources (49 Tier 1 / 45 Tier 2), 5 conclusions. Counts verified directly against the written files via `research/audit.py` (PASS). |
 | 2026-10-11 | `muse-responses-openai-transpiler` | New subject: 66 sources (3 Tier 1 / 63 Tier 2) + 2 conclusions, covering the Meta muse Responses wire format vs classic Chat Completions (official migration guide, Responses reference, Chat reference fetched and synthesized; 63 search listings logged as seen-not-analyzed). Decisions: bidirectional transpile is feasible with a fixed warn-on-drop loss table, and system guidance has three channels (instructions preferred, developer/system Items otherwise). Backed by a scratch stdlib transpiler (`/tmp/openai_transpile.py`, self-test green, real-capture round trip verified); nothing merged into tai.py. Counts verified directly against the written files via `research/audit.py` (PASS). |
 | 2026-10-12 | `shell-multiplexer-auto-attach` | Extended with 1 source (Tier 1: output of the installed tmux 3.6, `list-keys`, `list-keys -N`, `show-options`, `list-commands`) + 1 conclusion (`conclusions/tmux-parity-native-multiplexer.md`): the native multiplexer gets tmux's default key tables, command and option names, configured by `~/.tai/mplex.toml`; the earlier "build on tmux" recommendation stays for the tmux controller and detection rules. Behavior was also compared command by command against the same binary (layouts, windows, copy mode), see `mplex.md`. |
+| 2026-10-18 | `agent-goal-verification` | New subject: 43 sources (11 Tier 1 / 32 Tier 2) + 3 conclusions, covering LLM-judge reliability and biases, test-time verification scaling, evaluator-optimizer and reflection patterns, test-based verification, structured-output reliability tiers, and approval-UX practice (2 gather subagents plus first-hand fetches of all Tier 1 pages). Decisions: keep the verifier-subagent architecture with bounded rounds, keep prompt-only JSON with strict parse and retry, keep re-prompt plus shell-only exact-match affirm recovery. Counts verified directly against the written files via `research/audit.py` (PASS). |
+| 2026-10-18 | `prompt-context-scaling` | New subject: 34 sources (10 Tier 1 / 24 Tier 2) + 3 conclusions, covering context-window management (compaction, just-in-time retrieval, notes, subagent isolation), long-context limits, map-reduce over long inputs, GraphRAG scope and cost, and memory layers (2 gather subagents plus first-hand fetches of all Tier 1 pages). Decisions: tai's arsenal already matches the converged set; oversized prompts should spill to records and answer via retrieval (specified, not built); full GraphRAG and memory vendors rejected in favor of growing the vault graph. Counts verified directly against the written files via `research/audit.py` (PASS). |
+| 2026-10-18 | `sqlite-rag-hybrid-search` | Extended with 28 sources (7 Tier 1 / 21 Tier 2) + 2 conclusions (`conclusions/standing-retrieval-eval.md`, `conclusions/lexical-tuning-roadmap.md`), closing the original conclusion's open risk on unmeasured retrieval quality: rank metrics (Hit@K/MRR/nDCG/Context Precision), goldens generalized from the fingerprint method, implicit search-then-read preferences, query logging gap, and an ordered tuning backlog (column weights, OR-fallback, prefix) with HyDE/RM3/embeddings rejected. Counts verified directly against the written files via `research/audit.py` (PASS). |
+| 2026-10-18 | `background-work-limits` | New subject: 10 sources (4 Tier 1 / 6 Tier 2) + 2 conclusions, covering supervisor bounds (OTP intensity, semaphore reject-loud) and scheduler policies (APScheduler max_instances/coalesce, Temporal Skip, cron) after a feature-coverage audit found orchestration and scheduling unresearched. Decisions implemented same day: AGENTS_MAX_PARALLEL 8 with AgentsFull refusal, 64-record retention with oldest-collected purge, 4 fires per tick, one live run per schedule via last_status lease, stated misfire policy, no auto-retry. Counts verified directly against the written files via `research/audit.py` (PASS). |
+| 2026-10-18 | `sandbox-resource-caps` | New subject: 21 sources (3 Tier 1 / 18 Tier 2) + 1 conclusion, covering container resource caps (Docker limits reference, podman-run flag parity, podman-update create-only pids gap) plus snippet corroboration of the memory/cpus/pids trio after the coverage audit found the sandbox box fully uncapped. Decision implemented same day: static `--memory=2g --cpus=2.0 --pids-limit=256` at box create for both engines, one best-effort `update` (memory plus cpus) per process for existing boxes, concrete `rm -f` recovery pointer on failure. Counts verified directly against the written files via `research/audit.py` (PASS). |

 ## How to use this index

@@ -0,0 +1,28 @@
+# Agent tech stack survey: approval primitives
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Agent tech stack survey: approval primitives |
+| Source URL | https://github.com/12bitsd/agent4novel/blob/HEAD/docs/research/agent-tech-stack.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the Agents SDK approval search; the snippet tabulates the SDK's needs_approval to interruptions to approve/reject/resume chain. Consistent with the first-hand docs; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Human in the Loop AI: Best Approval Setup for Agents (2026)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Human in the Loop AI: Best Approval Setup for Agents (2026) |
+| Source URL | https://ai-agents-pitstop.com/human-in-the-loop.html |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the Agents SDK approval search; the snippet summarizes the SDK interruption flow (needsApproval stops the run, approve or reject then continue). A secondary summary of a source read first-hand; stayed a card.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# AI Agent Frameworks Compared: A 2026 Guide
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | AI Agent Frameworks Compared: A 2026 Guide |
+| Source URL | https://www.aitoolsvault.site/blog/ai-agent-frameworks-compared |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the Agents SDK approval search; the snippet maps one approval-gated support agent across the SDK and LangGraph primitives. Low-value aggregator-style comparison; logged for completeness, not relied on.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,54 @@
+# Building effective agents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Building effective agents |
+| Source URL | https://www.anthropic.com/research/building-effective-agents |
+| Source publisher / author | Anthropic |
+| Source type | blog post |
+| Source date (published) | 2024-12-19 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | direct page fetch |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+Anthropic's agent patterns essay names the evaluator-optimizer loop (one LLM call generates, another evaluates in a loop) as a core workflow, requires ground truth from the environment at each step, demands stopping conditions, and warns that agentic systems trade latency and cost for performance with compounding-error risk.
+
+## Key findings
+
+- "In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop."
+- Fit criteria: "particularly effective when we have clear evaluation criteria, and when iterative refinement provides measurable value".
+- "During execution, it's crucial for the agents to gain 'ground truth' from the environment at each step (such as tool call results or code execution) to assess its progress."
+- "The task often terminates upon completion, but it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control."
+- "Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense."
+- "The autonomous nature of agents means higher costs, and the potential for compounding errors. We recommend extensive testing in sandboxed environments, along with the appropriate guardrails."
+- The page carries a note that tooling described has changed since December 2024 and points to newer Managed Agents material.
+
+## Pros / strengths
+
+- Distilled from production deployments across industries; the evaluator-optimizer description matches tai's GoalVerifier loop nearly verbatim.
+- The ground-truth and stopping-condition requirements give independent backing to the verifier's tool access and the VERIFY_* caps.
+
+## Cons / limitations / caveats
+
+- A patterns essay, not a controlled study; no numbers on judge accuracy or cost curves.
+- Dated December 2024 with an explicit pointer to newer material; the core patterns read as stable, but the tooling advice has moved on.
+
+## Relevance to tai
+
+The single strongest external validation of the verifier-subagent architecture: separate evaluator, evidence from the environment (not claims), bounded iterations, and an explicit cost/latency tradeoff accepted per task. tai's one-shot verification is evaluator-optimizer with a JSON verdict contract and a two-round cap.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Training Verifiers to Solve Math Word Problems
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Training Verifiers to Solve Math Word Problems |
+| Source URL | https://arxiv.org/abs/2110.14168 |
+| Source type | paper |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scholarship gather worker; the classic result that trained verifiers ranking many candidates (best-of-N) beat fine-tuning and scale better with data. Corroborates the test-time scaling dossier from the trained-verifier side; not first-hand read.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Reflexion: Language Agents with Verbal Reinforcement Learning
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Reflexion: Language Agents with Verbal Reinforcement Learning |
+| Source URL | https://arxiv.org/abs/2303.11366 |
+| Source type | paper |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scholarship gather worker; reported to reach 91% pass@1 on HumanEval by reflecting on task feedback into episodic memory. Supports critique-plus-retry loops grounded in feedback signals; not first-hand read.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Self-Refine: Iterative Refinement with Self-Feedback
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Self-Refine: Iterative Refinement with Self-Feedback |
+| Source URL | https://arxiv.org/abs/2303.17651 |
+| Source type | paper |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scholarship gather worker; reported gains of about 20 absolute points from iterative self-feedback. Stands in tension with the Tier 1 cannot-self-correct dossier (which attributes such gains to smuggled-in external feedback); not first-hand read, so recorded here as the contradicting side.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,53 @@
+# Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena |
+| Source URL | https://arxiv.org/abs/2306.05685 |
+| Source publisher / author | Lianmin Zheng et al. (NeurIPS 2023 Datasets and Benchmarks Track) |
+| Source type | paper |
+| Source date (published) | 2023-06-09 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+The founding LLM-as-judge paper: strong LLM judges reach over 80% agreement with human preferences (human-human level), but exhibit position, verbosity, and self-enhancement biases plus limited reasoning ability. The authors conclude LLM judging is a scalable, explainable approximation of expensive human preference labels.
+
+## Key findings
+
+- "Strong LLM judges like GPT-4 can match both controlled and crowdsourced human preferences well, achieving over 80% agreement, the same level of agreement between humans."
+- "We examine the usage and limitations of LLM-as-a-judge, including position, verbosity, and self-enhancement biases, as well as limited reasoning ability, and propose solutions to mitigate some of them."
+- "LLM-as-a-judge is a scalable and explainable way to approximate human preferences, which are otherwise very expensive to obtain."
+- Evidence base: MT-bench multi-turn set plus Chatbot Arena crowdsourced battles, with 3K expert votes and 30K human-preference conversations released.
+
+## Pros / strengths
+
+- Peer-reviewed at a top venue with large-scale human agreement data; the bias taxonomy (position, verbosity, self-enhancement) is the reference every later judge paper builds on.
+- Directly answers the "does it scale" half of the question: judging scales where human labeling cannot.
+
+## Cons / limitations / caveats
+
+- Judges chat response preference, not agentic task completion; agreement rates do not transfer directly to a verifier grading shell transcripts.
+- Uses strong judges (GPT-4 class); tai's verifier runs on free rotating backends where judge quality is lower and more variable.
+- Single-judge verdicts inherit that judge's biases; the paper's mitigations (position swapping, few-shot) are not implemented in tai's verifier.
+- Scope note: findings above are from the abstract and paper metadata read first-hand; the full PDF was not read.
+
+## Relevance to tai
+
+Sets the ceiling and the caveats for the GoalVerifier: judge verdicts are useful and cheap but biased and approximate, so tai is right to treat a pass as evidence rather than proof, to require tool-grounded checks in the verifier prompt, and to keep the verdict advisory to bounded follow-up rounds instead of an unbounded retry loop.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,51 @@
+# Large Language Models Cannot Self-Correct Reasoning Yet
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Large Language Models Cannot Self-Correct Reasoning Yet |
+| Source URL | https://arxiv.org/abs/2310.01798 |
+| Source publisher / author | Jie Huang et al. (ICLR 2024) |
+| Source type | paper |
+| Source date (published) | 2023-10-03 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+The key counterpoint in this subject: intrinsic self-correction, where an LLM corrects its own response using only its inherent capabilities without external feedback, fails on reasoning tasks and sometimes degrades performance. Gains reported by self-correction methods come from the external or simulated feedback they include, not from introspection alone.
+
+## Key findings
+
+- "Central to our investigation is the notion of intrinsic self-correction, whereby an LLM attempts to correct its initial responses based solely on its inherent capabilities, without the crutch of external feedback."
+- "In the context of reasoning, our research indicates that LLMs struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction."
+- Published at ICLR 2024 after a March 2024 revision, so the claim survived peer review.
+
+## Pros / strengths
+
+- Draws the exact line that matters for tai: same-model introspection versus separate verification with external grounding.
+- Explains the apparent contradiction with Self-Refine style results: those methods smuggle in feedback (tools, tests, simulated critics), and that feedback does the work.
+
+## Cons / limitations / caveats
+
+- Scoped to reasoning tasks and intrinsic correction; it does not claim a separate verifier agent with tool access fails. That distinction is the whole design question, and this paper lands on tai's side of it.
+- 2023-era models; stronger reasoners may shift the boundary, though the external-feedback requirement has held up in later work.
+- Scope note: findings above are from the abstract and paper metadata read first-hand; the full PDF was not read.
+
+## Relevance to tai
+
+Validates the two load-bearing choices in the GoalVerifier: the verifier is a separate subagent rather than the same turn second-guessing itself, and its prompt demands evidence from tool results and machine state rather than judgment from prose alone. A same-model "are you sure?" loop is what this paper says fails; tai does not build that loop.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | SWE-bench: Can Language Models Resolve Real-World GitHub Issues? |
+| Source URL | https://arxiv.org/abs/2310.06770 |
+| Source type | paper |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the industry gather worker alongside the Tier 1 evaluation-guide dossier; the paper behind test-based agent verification over 2,294 real GitHub issues. The guide itself was read first-hand, the paper was not.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# JudgeLM: Fine-tuned Large Language Models are Scalable Judges
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | JudgeLM: Fine-tuned Large Language Models are Scalable Judges |
+| Source URL | https://arxiv.org/abs/2310.17631 |
+| Source type | paper |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scholarship gather worker via arXiv API search on judge bias; reported to taxonomize position, knowledge, and format biases and to claim over 90% agreement with a GPT-4 teacher judge. Corroborates the bias direction of the Tier 1 MT-Bench dossier but was not first-hand read, so it stays Tier 2.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,52 @@
+# Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters |
+| Source URL | https://arxiv.org/abs/2408.03314 |
+| Source publisher / author | Charlie Snell et al. |
+| Source type | paper |
+| Source date (published) | 2024-08-06 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+Studies the two mechanisms for scaling test-time compute, verifier-based search and adaptive response revision, and finds effectiveness varies by prompt difficulty. A compute-optimal allocation beats best-of-N by over 4x in efficiency, and on suitable problems lets a smaller model outperform a 14x larger one at matched FLOPs.
+
+## Key findings
+
+- The two mechanisms studied: "(1) searching against dense, process-based verifier reward models; and (2) updating the model's distribution over a response adaptively, given the prompt at test time."
+- "Using this compute-optimal strategy, we can improve the efficiency of test-time compute scaling by more than 4x compared to a best-of-N baseline."
+- "On problems where a smaller base model attains somewhat non-trivial success rates, test-time compute can be used to outperform a 14x larger model" in a FLOPs-matched evaluation.
+- Framing: test-time compute is "a critical step towards building generally self-improving agents that can operate on open-ended natural language".
+
+## Pros / strengths
+
+- Directly measures the scaling question: verification plus revision spend converts to performance, with a quantified efficiency edge over naive best-of-N.
+- The difficulty-dependent effectiveness finding supports spending verification budget adaptively rather than uniformly.
+
+## Cons / limitations / caveats
+
+- Preprint (unvetted at research time); results are on reasoning benchmarks with verifier reward models, not on end-to-end agent tasks with an LLM-judge verdict.
+- tai's verifier is a prompted generalist judge, not a trained process-based reward model, so the 4x figure does not transfer as a number, only as a direction.
+- Scope note: findings above are from the abstract and paper metadata read first-hand; the full PDF was not read.
+
+## Relevance to tai
+
+The theoretical backbone for spending extra model calls on verification: tai's verify loop (judge the turn, revise on failure, bounded rounds) is exactly the verifier-plus-revision pattern this paper validates. It also suggests a future improvement: skip or shorten verification for trivial turns instead of always paying one full verifier call.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Can We Trust This Evaluation? Instance-Level Reliability of LLM-as-a-Judge
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Can We Trust This Evaluation? Instance-Level Reliability of LLM-as-a-Judge |
+| Source URL | https://arxiv.org/abs/2610.14029 |
+| Source type | paper |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scholarship gather worker; reported to show majority-vote judge panels can be confidently wrong on individual items, so aggregate agreement does not guarantee per-verdict reliability. This is the sharpest caveat against trusting any single verifier pass, but it rests on the worker's abstract read alone.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# A CaLLM Judge is a Better Judge: Mitigating Bias in LLM-as-a-judge
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | A CaLLM Judge is a Better Judge: Mitigating Bias in LLM-as-a-judge |
+| Source URL | https://arxiv.org/abs/2610.18108 |
+| Source type | paper |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scholarship gather worker via arXiv API search; reported to propose multicalibration (CaLLM) bounding many judge biases at once, including undocumented ones. Relevant as a future debiasing direction for the verifier, but not first-hand read.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,52 @@
+# Confirmation Fatigue and the Protocol Gap in Agentic AI Oversight
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Confirmation Fatigue and the Protocol Gap in Agentic AI Oversight |
+| Source URL | https://raw.githubusercontent.com/changkun/blog/HEAD/content/ideas/2026-02-18-human-in-the-loop-agents.md |
+| Source publisher / author | Changkun (personal research blog) |
+| Source type | blog post |
+| Source date (published) | 2026-02-18 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | direct page fetch |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+A heavily sourced essay arguing per-tool-call human approval is solved in theory but unsolved in practice: confirmation fatigue is a security vulnerability and the main obstacle to oversight at scale. It documents the threat (Rippling T10, SOC alert statistics), the MCP protocol gap (consent mandated but unenforceable), and the field's convergence on risk-tiered, reversibility-based oversight.
+
+## Key findings
+
+- "Per-tool-call human approval in agentic AI is solved in theory, unsolved in practice. Confirmation fatigue is not a UX annoyance but a security vulnerability and the primary obstacle to effective human oversight at scale."
+- "Risk-tiered oversight is the dominant paradigm. Classify tool calls by risk, auto-approve the safe majority, focus human attention on the dangerous few."
+- "The highest-leverage pattern: classify by reversibility, not abstract risk", citing a decision-theoretic study where intermediate confirmation at irreversibility boundaries cut task time by 13.54%.
+- The MCP spec "states: 'Hosts MUST obtain explicit user consent before invoking any tool'", then concedes it "cannot enforce these security principles at the protocol level".
+- SOC parallel: teams average "4,484 alerts/day" with 67% ignored from false-positive fatigue; risk-proportional filtering beats blanket approval.
+
+## Pros / strengths
+
+- Synthesizes threat models, protocol analysis, and academic citations (autonomy levels, CHI trust calibration) into one coherent argument with primary references attached to each claim.
+- The reversibility criterion gives tai a principled line for which approvals stay strict: irreversible actions keep hard gates, recoverable ones can be more forgiving.
+
+## Cons / limitations / caveats
+
+- Single-author essay, not peer-reviewed; second-hand statistics (SOC numbers, the 13.54% study) are quoted, not verified here.
+- MCP-focused; tai is not an MCP client, so the protocol-gap half is context rather than directly applicable.
+
+## Relevance to tai
+
+Validates tai's approval tiers (safe-command allowlist, yolo mode, per-command gates) as the converged industry shape, and supports the shell-only affirm recovery: running a user-requested shell command is recoverable and user-initiated, while deletes and secret shares are irreversible or sensitive and correctly stay strict. Also warns that every added approval prompt has a fatigue cost, which argues for keeping the re-prompt cap small.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,51 @@
+# Conclusion: Approval input hardening (re-prompt plus shell-only affirm recovery)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Conclusion |
+| Tier | N/A |
+| Date decided | 2026-10-18 |
+| Decided by | retoor, advised by tai (agent, Muse Spark) |
+| Status | Active |
+| Confidence | Medium |
+
+## Question / problem statement
+
+The incident that started this work: a mistyped approval answer ("A", not among y/Y/n) silently counted as deny, and follow-up praise ("it was perfect") became new instructions that ended the run. The question was how to harden approval input without weakening gates: re-prompt on unknown input, and let unambiguous affirmation after a denial count as approval for the shell case.
+
+## Conclusion
+
+Keep the shipped hardening: unknown allow answers re-prompt up to three times before falling through to deny, and exact-match affirmative guidance ("it was perfect", "everything was fine" and the rest of the allowlist) approves the denied shell command only. Deletes, secrets, schedules, and releases stay strict on any denial. The affirm set stays exact-match; nothing fuzzy ever approves.
+
+## Supporting sources
+
+- [openai-agents-python-human-in-the-loop](../openai-agents-python-human-in-the-loop.md): fail-closed approval rules and denial text fed back into the run; tai's strict-by-default with narrow recovery follows the same shape.
+- [changkun-human-in-the-loop-agents](../changkun-human-in-the-loop-agents.md): risk-tiered oversight is the dominant paradigm; reversibility is the highest-leverage classifier, which justifies recovering user-initiated shell runs while keeping irreversible actions strict.
+- [pmq9-human-in-the-loop-workflows-skill](../pmq9-human-in-the-loop-workflows-skill.md) (Tier 2): show the action itself, not the agent's summary; tai shows the raw command.
+- [lukemurraynz-hitl-changelog-tiered-chain](../lukemurraynz-hitl-changelog-tiered-chain.md) (Tier 2): classifiers may never approve irreversible actions; denials feed back as corrective context.
+
+## Alternatives considered and rejected
+
+- Fuzzy or substring affirm matching ("yes..." anywhere approves): rejected, "yes, but do X instead" must stay guidance; exact-match is the auditable line.
+- Uniform affirm recovery for all approval types: rejected, approving a delete or secret share from praise text would be a fail-open surprise; the reversibility criterion keeps it shell-only.
+- Accepting "A"/"all" as always-allow: rejected implicitly by the re-prompt design; unknown input asks again instead of guessing intent, which covers typos without inventing new meanings.
+
+## Risks / open questions
+
+- No source found directly studies typo re-prompts or affirm-after-deny at a CLI; this conclusion rests on the fail-closed and risk-tiered principles, not on a direct study. Confidence is Medium for that reason.
+- A user who means "continue without it" but types a bare affirm word will run the command; the recovery print ("taking ... as approval") makes the interpretation visible at the moment it happens.
+- Revisit if: users report surprise approvals, or the allowlist needs a phrase (additions stay exact-match, one per line, with a test).
+
+## Action taken
+
+Shipped as `Approval.parse_allow` / `Approval.is_affirmative`, the re-prompt loop in `Agent.ask_approval`, and the shell-only recovery in `Tools.run_shell`, with 6 unit tests including the negative case that deletes stay strict.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial conclusion recorded. |
@@ -0,0 +1,51 @@
+# Conclusion: Prompt-only JSON with strict parse and retry for verdicts
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Conclusion |
+| Tier | N/A |
+| Date decided | 2026-10-18 |
+| Decided by | retoor, advised by tai (agent, Muse Spark) |
+| Status | Active |
+| Confidence | High |
+
+## Question / problem statement
+
+The verifier's verdict must arrive as a strict success-plus-failures object. The question was whether prompt-only JSON (schema pasted in the prompt, forgiving extraction, strict validation, retry via follow-up rounds) is solid enough across tai's heterogeneous backends, or whether verdicts require constrained decoding to be trustworthy.
+
+## Conclusion
+
+Keep prompt-only JSON with strict parse and retry: paste the schema into the verifier prompt, extract forgivingly (fences, first object), validate strictly (success must be bool, failures a list of complete item/reason/proposal dicts, contradictions fail), and treat any malformed verdict as a failed check that consumes a round. Adopt provider-enforced structured outputs only if a constrained-decoding backend becomes tai's standard path.
+
+## Supporting sources
+
+- [openai-structured-outputs](../openai-structured-outputs.md): without Structured Outputs, "you should use a validation library and potentially retries"; applications "must detect and handle" incomplete-JSON edge cases. tai implements exactly this fallback.
+- [tkarim45-structured-output-eval](../tkarim45-structured-output-eval.md): measured 100% schema adherence for schema-in-prompt on a small schema, tying constrained decoding; the real failure mode is shape, not syntax.
+- [devto-mattbusel-json-repetition-setting](../devto-mattbusel-json-repetition-setting.md) (Tier 2): independent practitioner confirmation of the schema-in-prompt plus forgiving-parse-ladder practice.
+- [yinsongxu-llm2jev-request-to-model](../yinsongxu-llm2jev-request-to-model.md) (Tier 2): a schema in the prompt cannot establish judgment correctness, which is why the verdict stays advisory to bounded rounds rather than proof.
+
+## Alternatives considered and rejected
+
+- Constrained decoding now: rejected, tai's backends (CLI harnesses, free tiers) do not offer it uniformly; single-backend enforcement would split the verdict path in two for no measured gain on this small schema.
+- JSON mode if available: rejected as insufficient on its own (valid JSON without schema adherence); the strict validator covers what JSON mode does not.
+- Lenient parsing (accept partial verdicts): rejected, a half-parsed verdict is exactly how "success" gets misread; fail-closed keeps the strictness guarantee.
+
+## Risks / open questions
+
+- Weaker free-tier models likely score below the 100% schema-in-prompt figure measured on Claude Haiku; malformed verdicts cost rounds instead of answers, which is correct but slower.
+- Valid JSON with wrong content (confident misjudgment) passes the parser by design; content risk is carried by the architecture conclusion (evidence rules, bounded rounds), not by parsing.
+- Revisit if: malformed-verdict rounds dominate verification cost, or one constrained backend becomes standard.
+
+## Action taken
+
+Shipped as `GoalVerifier.extract_json` (forgiving) plus `GoalVerdict.from_text` (strict) with unit tests covering fences, contradictions, missing fields, bare failures, garbage input, and over-long payloads read from the full worker result.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial conclusion recorded. |
@@ -0,0 +1,57 @@
+# Conclusion: Verifier-subagent architecture for one-shot goals
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Conclusion |
+| Tier | N/A |
+| Date decided | 2026-10-18 |
+| Decided by | retoor, advised by tai (agent, Muse Spark) |
+| Status | Active |
+| Confidence | High |
+
+## Question / problem statement
+
+tai's one-shot mode used to quit after a single turn even when the goal was undelivered (a denied download plus a misread "it was perfect" ended the run with exit 0). The question was whether gating the quit on a separate verifier subagent, with bounded follow-up rounds, is a sound pattern that scales, or an overbuilt control that burns model calls for little gain.
+
+## Conclusion
+
+Keep the GoalVerifier design as shipped: a separate worker subagent judges goal delivery from transcript plus tool-grounded evidence, failures feed bounded follow-up turns, and unverified outcomes exit nonzero with the turn left open. This is the industry-standard evaluator-optimizer loop with a strict verdict contract, and both literature and production practice support it under the caps already in place.
+
+## Supporting sources
+
+- [anthropic-building-effective-agents](../anthropic-building-effective-agents.md): evaluator-optimizer loop, ground truth from the environment each step, stopping conditions, accepted cost/latency tradeoff.
+- [langchain-reflection-agents](../langchain-reflection-agents.md): independent second source for the generator/critic loop with fixed rounds and tool observations as grounding.
+- [arxiv-2408-03314-test-time-compute-scaling](../arxiv-2408-03314-test-time-compute-scaling.md): verifier-plus-revision spend converts to performance (4x over best-of-N); smaller models can beat larger ones with test-time compute.
+- [arxiv-2306-05685-judging-llm-as-a-judge](../arxiv-2306-05685-judging-llm-as-a-judge.md): judge verdicts reach human-level agreement but carry known biases, so the verdict stays evidence plus bounded rounds, never blind trust.
+- [arxiv-2310-01798-cannot-self-correct](../arxiv-2310-01798-cannot-self-correct.md): intrinsic same-model self-correction fails without external feedback, which is why the verifier is a separate subagent with tool access.
+- [swebench-evaluation-guide](../swebench-evaluation-guide.md): executable checks are the gold standard; the verifier prompt's tools-first ordering follows from this.
+- [openai-evaluation-best-practices](../openai-evaluation-best-practices.md): judge quality varies by context, so keep the verify log events and calibrate the rubric from real outcomes.
+- [arxiv-2303-17651-self-refine](../arxiv-2303-17651-self-refine.md) (Tier 2): the contradicting side on self-correction gains, resolved in favor of external feedback per the ICLR paper above.
+
+## Alternatives considered and rejected
+
+- Same-turn self-check ("are you sure?"): rejected, the cannot-self-correct paper says intrinsic correction without external feedback fails and can degrade results.
+- Unbounded retry until verified: rejected, Anthropic requires stopping conditions and warns of compounding errors and cost; two extra rounds is the shipped bound.
+- No verification, trust the final answer: rejected, this was the incident that started the work (silent quit on an undelivered goal).
+- Test-based verification only (SWE-bench style): rejected as the sole mechanism because most one-shot goals have no pre-written checks; kept as the preferred evidence source inside the verifier prompt instead.
+
+## Risks / open questions
+
+- False-negative verdicts burn up to two extra turns and can make the agent redo finished work; watch the false-fail rate in the verify log events.
+- Instance-level judge reliability is weaker than aggregate agreement suggests (see the Tier 2 instance-reliability card); a wrong pass is still possible, so the exit code means "verifier satisfied", not "proven".
+- Verifier quality depends on the free rotating backends; a weak-backend verdict is weaker evidence, unmeasured so far.
+- Revisit if: false-fail rounds become the common case, or a constrained-decoding backend becomes the standard path (see the JSON fallback conclusion).
+
+## Action taken
+
+Shipped in tai.py the same sessions as the research: `GoalVerifier` / `GoalVerdict` / `GoalFailure`, `Agent.verify_loop` with `VERIFY_MAX_ROUNDS = 2`, one-shot exit 0/1 wiring, open turn state on unverified outcomes, 14 unit tests, suite 959 green plus live probes of both the pass and fail paths.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial conclusion recorded. |
@@ -0,0 +1,28 @@
+# AI agent approval queues need runtime authority
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | AI agent approval queues need runtime authority |
+| Source URL | https://github.com/runcycles/cycles-docs/blob/HEAD/blog/ai-agent-approval-queues-need-runtime-authority.md |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the Agents SDK approval search; the snippet compares LangChain HITL middleware (pause, persist, resume with approve/edit/reject/respond) against the SDK flow. Confirms cross-framework convergence on pause-resume approvals; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Deepy system audit modes design
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Deepy system audit modes design |
+| Source URL | https://github.com/kirineko/deepy/blob/HEAD/openspec/changes/archive/2026-05-28-add-system-audit-modes/design.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the Agents SDK approval search; the snippet describes adopting the SDK's native approval primitives for a deep audit mode. Evidence that independent projects converge on the same approval shape; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# LLM JSON output: one setting dropped valid JSON from 75% to 4%
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | LLM JSON output: one setting dropped valid JSON from 75% to 4% |
+| Source URL | http://dev.to/mattbusel/llm-json-output-one-setting-dropped-valid-json-from-75-to-4-1o12 |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the structured-output reliability search; the snippet recommends schema-in-prompt plus a forgiving parse ladder (strip fences, cut first object, repair slips) before schema validation. That ladder is what tai's extractor implements; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# JSON Mode and Structured Outputs study notes
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | JSON Mode and Structured Outputs study notes |
+| Source URL | https://github.com/dhyanendrasinghsikarwar/learning_notes/blob/HEAD/2.2%20Structured%20&%20reliable%20output/2.2.1_JSON_Mode_Structured_Outputs.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the structured-output reliability search; the snippet lists four reliability levels from prompt-only to grammar-constrained decoding. Same ladder as the Tier 1 sources; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# User-in-the-Loop Interfaces study notes
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | User-in-the-Loop Interfaces study notes |
+| Source URL | https://github.com/emrekuruu/nvidia-ncp-aai-study-notes/blob/HEAD/Human-AI%20Interaction%20and%20Oversight/User-in-the-Loop%20Interfaces.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the approval-UX search; the snippet frames too little control as ambush and too much as fatigue plus a scalability bottleneck. States the calibration tai's tiers aim at; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Approval evidence sources log
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Approval evidence sources log |
+| Source URL | https://github.com/fny666/northstar-agent-os/blob/HEAD/research/nextgen-continuity-2026-09/a-line-evidence-window/A-LINE-APPROVAL-EVIDENCE-20260921T190354Z/sources.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the Agents SDK approval search; the snippet records the official SDK HITL page (tools declare needs_approval, interruptions surface pending items, RunState resumes). A pointer to a source read first-hand instead; logged for the trail.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Defense patterns: human-in-the-loop gates
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Defense patterns: human-in-the-loop gates |
+| Source URL | https://github.com/hardw00t/ai-security-arsenal/blob/HEAD/skills/llm-security/references/defense_patterns_2026.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the approval-UX search; the snippet lists HITL failure modes (approval fatigue rubber-stamping, dialogs hiding full arguments, agent text tricking users into approving). Supports showing the raw command and keeping prompts scannable; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Human-in-the-loop design skill
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Human-in-the-loop design skill |
+| Source URL | https://github.com/justshipai/pm-skills-lab/blob/HEAD/skills/ai-product/human-in-the-loop-design/SKILL.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the approval-UX search; the snippet rejects one global approval setting and confirmation prompts without evidence, reserving approval for high-stakes actions. Matches tai's risk tiers; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# call-me-maybe: function calling with constrained decoding on Qwen3-0.6B
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | call-me-maybe: function calling with constrained decoding on Qwen3-0.6B |
+| Source URL | https://github.com/kheldin/call-me-maybe |
+| Source type | repository |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the structured-output reliability search; the snippet claims constrained decoding lifts a 0.6B model from about 30% prompting-only accuracy to near-perfect schema-compliant calls. Relevant as the small-model end of the enforcement argument; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,51 @@
+# Reflection Agents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Reflection Agents |
+| Source URL | https://www.langchain.com/blog/reflection-agents |
+| Source publisher / author | LangChain (Ankush Gola) |
+| Source type | blog post |
+| Source date (published) | 2024-02-21 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+LangChain's reflection pattern composes a generator LLM with a reflector LLM that critiques as a teacher, looping a fixed number of times, optionally folding in tool observations as external information. It also flags reward-score sensitivity in reflection/search hybrids as a known reliability failure mode.
+
+## Key findings
+
+- "This simple example composes two LLM calls: a generator and a reflector. The generator tries to respond directly to the user's requests. The reflector is prompted to role play as a teacher and offer constructive criticism for the initial response."
+- "The loop proceeds a fixed number of times, and the final generated output is returned."
+- "Reflection is a prompting strategy used to improve the quality and success rate of agents and similar AI systems. It involves prompting an LLM to reflect on and critique its past actions, sometimes incorporating additional external information such as tool observations."
+- On LATS hybrids: "While it can be sensitive to the reward scores, the general algorithm can be flexibly applied to a variety of tasks."
+
+## Pros / strengths
+
+- Second independent industry source (with Anthropic) for the generator/critic loop with a fixed iteration cap, which is tai's verify loop shape.
+- Explicitly blesses tool observations as the external grounding for critique, matching tai's evidence-strict verifier prompt.
+
+## Cons / limitations / caveats
+
+- Vendor blog with linked example notebooks; states the pattern, not measured accuracy or cost data.
+- The reward-sensitivity warning applies to score-driven search hybrids more than to tai's boolean-plus-failures verdict, but it still cautions against trusting any single model-graded signal too far.
+
+## Relevance to tai
+
+Independent confirmation that a separate critic call over the transcript plus tool evidence, bounded to a fixed number of rounds, is standard practice rather than an exotic control. tai's stricter verdict contract (boolean plus itemized failures with proposals) is a compatible tightening of the same loop.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# HITL design patterns changelog: tiered decision chain
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | HITL design patterns changelog: tiered decision chain |
+| Source URL | https://github.com/lukemurraynz/hve-agent-skills/blob/HEAD/skills/hitl-design-patterns/CHANGELOG.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the approval-UX search; the snippet describes a rules-first tiered chain where a classifier may never approve irreversible actions and denials feed back as corrective context. Both rules match tai's design; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# HITL design patterns skill
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | HITL design patterns skill |
+| Source URL | https://github.com/lukemurraynz/hve-agent-skills/blob/HEAD/skills/hitl-design-patterns/SKILL.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the approval-UX search; the snippet advises against gating safe actions (fatigue training) and suggests re-gating after about 60 seconds without new human instruction. The no-gate-on-safe part matches tai's allowlist; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,52 @@
+# Human-in-the-loop - OpenAI Agents SDK
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Human-in-the-loop - OpenAI Agents SDK |
+| Source URL | https://openai.github.io/openai-agents-python/human_in_the_loop/ |
+| Source publisher / author | OpenAI |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (living documentation page) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | direct page fetch |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+The official Agents SDK guide describes the industry-standard approval loop: tools declare `needs_approval`, the run pauses with pending items in `interruptions`, the app approves or rejects (optionally with a custom rejection message fed back into the run), and the same run resumes from serialized state.
+
+## Key findings
+
+- "Set `needs_approval` to `True` to always require approval or provide an async function that decides per call."
+- "Callable approval rules fail closed when the SDK cannot safely inspect the arguments. If the arguments are missing, empty, contain only whitespace, are malformed JSON... the callable is not invoked and the call requires manual approval."
+- "By default, a rejected tool call returns the SDK's standard rejection text back into the run" with per-call `rejection_message` override taking precedence over the run-wide formatter.
+- "Convert the result to a `RunState` with `result.to_state()`, call `state.approve(...)` or `state.reject(...)`, and then resume", and the resumed run continues where it left off.
+- Per-call approvals are scoped to the call ID; `always_approve` / `always_reject` persist the decision for the tool identity.
+
+## Pros / strengths
+
+- First-party specification of the dominant approval pattern, including the fail-closed rule and the denial-feedback mechanism.
+- The pause / serialize / resume shape matches tai's turn-state plus `--resume` design almost exactly.
+
+## Cons / limitations / caveats
+
+- SDK-specific mechanics (RunState, interruptions) that tai reimplements in its own vocabulary; no guidance on free-text approval prompts or typo handling at a CLI.
+- No discussion of approval fatigue or input validation; those come from practitioner sources, not this page.
+
+## Relevance to tai
+
+Confirms three tai design choices as industry-standard: per-command approval with an always-allow escape hatch, denial text fed back into the run as corrective context (tai's `Denied` guidance), and resumable paused runs (tai's open turn state plus `--resume`). The fail-closed rule supports keeping destructive approvals strict while recovering only the shell case on unambiguous affirmation.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Building Mia AI: Making AI-Agent Execution Visible, Reliable, and Safe
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Building Mia AI: Making AI-Agent Execution Visible, Reliable, and Safe |
+| Source URL | https://community.openai.com/t/building-mia-ai-making-ai-agent-execution-visible-reliable-and-safe/1404516 |
+| Source type | forum thread |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the Agents SDK approval search; the snippet argues approvals should be a runtime pause rather than something the model says in text. Matches tai's out-of-band prompt design; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,51 @@
+# Evaluation best practices
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Evaluation best practices |
+| Source URL | https://developers.openai.com/api/docs/guides/evaluation-best-practices |
+| Source publisher / author | OpenAI |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (living documentation page) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+OpenAI's eval guide states the core tradeoff plainly: LLM-as-judge quality varies by problem context while expert human labels are expensive and slow. It prescribes eval-driven development, clear rubrics, logging everything for future eval cases, and calibrating automated scoring against human judgment.
+
+## Key findings
+
+- "No strategy is perfect. The quality of LLM-as-Judge varies depending on problem context while using expert human annotators to provide ground-truth labels is expensive and time-consuming."
+- "Ensure eval rubrics are clear and detailed" (adjacent guidance on the same page).
+- Eval-driven development: "Evaluate early and often. Write scoped tests at every stage", "Log everything: Log as you develop so you can mine your logs for good eval cases", "Maintain agreement: Use human feedback to calibrate automated scoring."
+- Anti-patterns include "Vibe-based evals" and "Ignoring human feedback: Not calibrating your automated metrics against human evals."
+
+## Pros / strengths
+
+- Vendor-neutral advice despite the source: it openly bounds its own recommended technique (judge quality varies) instead of overselling it.
+- The log-and-calibrate discipline maps directly onto tai's verify log events, which are mineable the same way.
+
+## Cons / limitations / caveats
+
+- Guidance for offline eval suites, not for an inline runtime acceptance gate; tai applies the same judge machinery live, where a wrong verdict costs follow-up rounds instead of just a noisy metric.
+- No numbers on judge accuracy; pairs with the MT-Bench paper for quantities.
+
+## Relevance to tai
+
+Justifies shipping the strict verifier now while treating calibration as ongoing work: keep the `verify` log events, watch the false-pass and false-fail rates in real use, and tighten the rubric (the verifier prompt) from that log. Also supports the decision to exit nonzero with a report rather than silently passing.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,52 @@
+# Structured model outputs
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Structured model outputs |
+| Source URL | https://developers.openai.com/api/docs/guides/structured-outputs |
+| Source publisher / author | OpenAI |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (living documentation page) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | direct page fetch |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+OpenAI's official guide draws a hard line between JSON mode (valid JSON guaranteed, schema adherence not guaranteed) and Structured Outputs (schema adherence enforced at generation time). For callers that cannot use Structured Outputs, the guide prescribes exactly the fallback tai uses: validate the output and retry.
+
+## Key findings
+
+- "Structured Outputs is the evolution of JSON mode. While both ensure valid JSON is produced, only Structured Outputs ensure schema adherence."
+- "JSON mode will not guarantee the output matches any specific schema, only that it is valid and parses without errors. You should use Structured Outputs to ensure it matches your schema, or if that is not possible, you should use a validation library and potentially retries to ensure that the output matches your desired schema."
+- Benefits claimed for Structured Outputs: "Reliable type-safety: No need to validate or retry incorrectly formatted responses", explicit refusals, simpler prompting.
+- The comparison table states JSON Mode outputs valid JSON: Yes; adheres to schema: No.
+- When using JSON mode, the model must be explicitly instructed to produce JSON (the API errors if the string "JSON" does not appear in context), and applications "must detect and handle the edge cases that can result in the model output not being a complete JSON object".
+
+## Pros / strengths
+
+- Authoritative statement of the two-tier guarantee ladder from the vendor that defines both tiers.
+- Gives an explicit sanctioned fallback (validate plus retries) for callers without schema enforcement, which is tai's exact situation on multi-backend free tiers.
+
+## Cons / limitations / caveats
+
+- Vendor documentation for OpenAI's own API; says nothing about other providers' JSON modes or their adherence rates.
+- No numbers on how often prompt-only JSON fails; quantitative failure rates come from community evals, not this page.
+
+## Relevance to tai
+
+Directly load-bearing for the GoalVerifier design: tai cannot use constrained decoding across its heterogeneous backends (CLI harnesses, free tiers), so prompt-only JSON plus strict schema validation plus verification rounds is the vendor-recommended fallback, not a hack. The "detect and handle edge cases" line justifies the forgiving extract plus strict parse split in `GoalVerifier.extract_json` / `GoalVerdict.from_text`.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Human-in-the-loop workflows skill
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Human-in-the-loop workflows skill |
+| Source URL | https://github.com/pmq9/agent-skills/blob/HEAD/.claude/skills/engineering/ai/human-in-the-loop-workflows/SKILL.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the approval-UX search; the snippet names the biggest HITL design failure as showing the AI's summary of the action instead of the action itself. tai shows the raw command, which is the recommended side; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Human-in-the-loop governance pattern
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Human-in-the-loop governance pattern |
+| Source URL | https://github.com/prajwalamte/ai-engineering-patterns/blob/HEAD/content/patterns/governance/human-in-the-loop.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the approval-UX search; the snippet defines the gate as pausing before consequential actions by category until explicit consent. The standard definition tai implements; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Human-in-the-Loop AI Agents: Approval Workflows and Best Practices
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Human-in-the-Loop AI Agents: Approval Workflows and Best Practices |
+| Source URL | https://promptessor.com/blog/human-in-the-loop-ai-agents |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by two approval-UX searches (logged once); the snippets describe run-level approval patterns and OpenAI's guardrails-versus-human-review split. The underlying SDK docs were read first-hand instead, so this stayed a card.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Prompt engineering notes: JSON reliability levels
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Prompt engineering notes: JSON reliability levels |
+| Source URL | https://github.com/rajsekharalluri/devthread.in/blob/HEAD/content/genai-engineer/prompt-engineering.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the structured-output reliability search; the snippet states the prompt-only / JSON-mode / schema-enforced ladder. Consistent with the Tier 1 vendor docs; a study-notes page seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Structured output reliability skill
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Structured output reliability skill |
+| Source URL | https://github.com/sayem7456/opencode-engineering-skills/blob/HEAD/skills/structured-output-reliability/SKILL.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the structured-output reliability search; the snippet insists every structured-output pipeline must validate before use and notes no provider guarantees perfect output. Matches tai's strict-parse stance; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# OpenAI Agents SDK production notes: approvals
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | OpenAI Agents SDK production notes: approvals |
+| Source URL | https://github.com/sheikh-mohammad/agent-factory-claude-skills/blob/HEAD/.claude/skills/openai-agents-sdk/references/production.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the Agents SDK approval search; the snippet restates the built-in HITL flow (run pauses, pending items in interruptions). Redundant with the first-hand SDK docs; stayed a card.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# The AI Agent Approval Workflow for Unreal: Human-in-the-Loop That Isn't a Rubber Stamp
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | The AI Agent Approval Workflow for Unreal: Human-in-the-Loop That Isn't a Rubber Stamp |
+| Source URL | https://www.strayspark.studio/blog/approve-ai-agent-changes-unreal-editor-from-phone |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the approval-UX search; the snippet warns that showing the agent's explanation means grading its essay rather than its action, and that every-change gates train reflexive approval. Reinforces raw-action display; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Structured Outputs and Constrained Decoding in Agentic AI
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Structured Outputs and Constrained Decoding in Agentic AI |
+| Source URL | https://github.com/sumansingh226/python-to-ai-ml-journey/blob/HEAD/src/Ai/topis/%23%20Structured%20Outputs%20&%20Constrained%20Decoding%20in%20Agentic%20AI.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the structured-output reliability search; the listing snippet claims top models fail JSON schema adherence 5-15% of the time without enforcement. Directionally consistent with stronger sources, but a personal study-notes repo, seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,50 @@
+# SWE-bench Evaluation Guide
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | SWE-bench Evaluation Guide |
+| Source URL | https://raw.githubusercontent.com/SWE-bench/SWE-bench/main/docs/guides/evaluation.md |
+| Source publisher / author | SWE-bench (Princeton NLP) |
+| Source type | repository |
+| Source date (published) | Unknown — not stated (living project docs) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+The reference implementation of test-based agent verification: candidate patches are applied to real repositories and the repositories' own tests decide whether the issue is resolved, all inside Docker for reproducibility. No LLM judges the outcome; execution is the judge.
+
+## Key findings
+
+- "SWE-bench evaluates models by applying their generated patches to real-world repositories and running the repository's tests to verify if the issue is resolved. The evaluation is performed in a containerized Docker environment to ensure consistent results across different platforms."
+- The harness entry point is `swebench.harness.run_evaluation` with worker parallelism, instance selection, Docker cache levels, and result caching by run id.
+- Predictions are JSONL rows of instance id, model name, and patch text; cloud execution via Modal or sb-cli is supported.
+
+## Pros / strengths
+
+- Ground truth by construction: the verdict is a test run, immune to judge bias, verbosity effects, and sycophancy.
+- Reproducible and automatable at scale, which is why it became the standard coding-agent benchmark.
+
+## Cons / limitations / caveats
+
+- Only works where executable checks exist (tests, builds, scripts). Most tai one-shot goals ("upgrade python", "research X") have no pre-written test suite, so pure SWE-bench-style verification is unavailable.
+- Heavyweight per check (containers, repos, dependency installs); overkill for judging a chat-length turn.
+
+## Relevance to tai
+
+Sets the gold standard tai's verifier approximates: prefer checking machine state with tools over grading prose. tai's verifier prompt already instructs read-only tool inspection first and transcript judgment second; this source says that ordering is right and that any goal with an executable check should get one rather than relying on the judge alone.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,51 @@
+# Structured-Output Reliability Eval
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Structured-Output Reliability Eval |
+| Source URL | https://github.com/tkarim45/structured-output-eval |
+| Source publisher / author | tkarim45 |
+| Source type | repository |
+| Source date (published) | Unknown — not stated |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | direct page fetch |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+A runnable benchmark comparing four JSON strategies (plain prompt, schema-in-prompt, native constrained decoding, strict tool) on valid-JSON rate, schema adherence, and field accuracy, including adversarial inputs. On Claude Haiku 4.5, plain prompting hit only 25% schema adherence (33% adversarial) while schema-in-prompt hit 100%, tying constrained decoding on this task set.
+
+## Key findings
+
+- Measured table (Claude Haiku 4.5 on Bedrock, 8 tasks): plain schema adherence 0.250 (adversarial 0.333); schema_in_prompt, native, and strict_tool all 1.000 on every column.
+- "Malformed JSON was never the failure mode. Claude Haiku returned valid JSON 100% of the time on every strategy, plain included... The real failure is schema adherence."
+- "Just putting the schema in the prompt fixed it, no constrained decoding required... constrained decoding's real value is the guarantee at scale and on harder schemas, not a measured lift over schema-in-prompt on this set."
+- "Valid JSON is not equal to correct" (Valid ≠ correct): braces parse, shape wrong.
+
+## Pros / strengths
+
+- Real measured numbers on a real model with a reproducible harness, not vendor marketing; distinguishes the two failure modes (syntax vs schema) that most advice smears together.
+- Directly supports tai's position: for a small fixed schema like the verdict object, schema-in-prompt plus validation is empirically sufficient.
+
+## Cons / limitations / caveats
+
+- One model family (Claude Haiku), 8 tasks, one operator; tai's verifier runs on weaker free-tier models where plain-prompt adherence is likely worse than 25%.
+- Community repo, no peer review; the mock path ships deliberately different numbers as a teaching fixture, which a careless reader could quote instead of the real table.
+
+## Relevance to tai
+
+Quantitative backing for the verdict contract: paste the schema into the verifier prompt (tai does), validate strictly on receipt (tai does), and treat constrained decoding as a future guarantee rather than a current requirement. Also warns that tai's weaker verifier backends need the strict-parse-plus-retry path more than Claude-class models do.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Structured Output From an LLM Can Be Perfect JSON and Completely Wrong
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Structured Output From an LLM Can Be Perfect JSON and Completely Wrong |
+| Source URL | https://pub.towardsai.net/structured-output-from-an-llm-can-be-perfect-json-and-completely-wrong-cbd630be2306 |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the structured-output reliability search (also seen mirrored on Medium under the same title by Syed Ali; both listings describe one article, logged once). The snippet draws the JSON-mode versus native-structured-output line and the valid-not-equal-correct point. Same claims verified first-hand in stronger sources, so this stayed a card.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# llm2jev request-to-model: schema limits
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | agent-goal-verification |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | llm2jev request-to-model: schema limits |
+| Source URL | https://github.com/yinsongxu/llm2jev/blob/HEAD/docs/request-to-model.md |
+| Source type | repository |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the structured-output reliability search; the snippet notes a schema in the system prompt is still just a text instruction and cannot establish judgment correctness. Supports the valid-not-equal-correct caveat; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,51 @@
+# APScheduler User Guide
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | APScheduler User Guide |
+| Source URL | https://apscheduler.readthedocs.io/en/3.x/userguide.html |
+| Source publisher / author | APScheduler |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (living documentation page) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+The APScheduler guide supplies tai's scheduler policy vocabulary: max_instances defaults to 1 (a new fire while the previous run lives counts as a misfire), coalescing rolls queued missed executions into one trigger, and misfire_grace_time decides whether a late execution still runs (which can fire several runs in succession).
+
+## Key findings
+
+- "By default, only one instance of each job is allowed to be run at the same time. This means that if the job is about to be run but the previous run hasn't finished yet, then the latest run is considered a misfire."
+- "It is possible to set the maximum number of instances for a particular job that the scheduler will let run concurrently, by using the `max_instances` keyword argument when adding the job."
+- "If coalescing is enabled for the job and the scheduler sees one or more queued executions for the job, it will only trigger it once. No misfire events will be sent for the 'bypassed' runs."
+- Late execution against `misfire_grace_time` "can lead into the job being executed several times in succession."
+
+## Pros / strengths
+
+- Three orthogonal knobs (overlap, coalescing, grace) that decompose tai's scheduler decisions cleanly: tai takes max_instances 1 plus always-coalesce and skips grace windows as unneeded complexity.
+- Documents the failure mode each knob prevents, so tai's simpler choices stay explicit rather than accidental.
+
+## Cons / limitations / caveats
+
+- Single-process scheduler semantics; tai's compare-and-swap claim across processes goes beyond what this page covers.
+- No per-tick firing cap concept; tai's burst bound comes from the supervisor side (global parallel cap), not from here.
+
+## Relevance to tai
+
+Direct template for the scheduler half: one live run per repeating schedule (lease-checked, Temporal-Skip style), missed intervals coalesced into one fire (already tai's behavior, now specified), and no auto-retry of failed runs (loud `last_status` instead).
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Periodic Tasks
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Periodic Tasks |
+| Source URL | https://docs.celeryq.dev/en/stable/userguide/periodic-tasks.html |
+| Source type | vendor docs |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scheduler gather worker; reported the single-scheduler rule against duplicate tasks and user-side locking for overlap. tai's compare-and-swap claim already covers the duplication half cross-process; the locking half is superseded by the lease design.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,52 @@
+# Conclusion: One live run per schedule, capped fires, stated misfire policy
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Conclusion |
+| Tier | N/A |
+| Date decided | 2026-10-18 |
+| Decided by | retoor, advised by tai (agent, Muse Spark) |
+| Status | Active |
+| Confidence | High |
+
+## Question / problem statement
+
+The scheduler fired every due row with no per-tick bound and no overlap protection: 1000 due rows meant 1000 spawns, and a repeating schedule fired again while its previous run was still going. The question was which production policies to adopt (overlap, burst caps, misfire handling) without growing new infrastructure.
+
+## Conclusion
+
+Three rules, no schema migration: (1) at most `SCHEDULER_MAX_FIRES = 4` spawns per tick, half the global pool, with the backlog draining on later ticks; (2) max one live run per repeating schedule (APScheduler default, Temporal-Skip), enforced by a lease: a claim sets `last_status` to running, and a new fire is skipped while the claim is younger than the run timeout plus margin, so crashed schedulers self-heal instead of sticking rows; (3) the misfire policy is stated, not accidental: repeating schedules coalesce missed intervals into one fire (APScheduler-coalesce, cron-like), one-shot schedules fire late however late (Temporal-catchup-like), and failed runs never auto-retry (their loud `last_status` is the record).
+
+## Supporting sources
+
+- [apscheduler-user-guide](../apscheduler-user-guide.md): max_instances default 1 with overlap counting as misfire, plus coalescing of queued executions into one trigger.
+- [temporal-schedule](../temporal-schedule.md): Skip as the default overlap policy (a new start while one runs simply does not start), with concurrency only under the policy that names it.
+- [celery-periodic-tasks](../celery-periodic-tasks.md) (Tier 2): the single-scheduler rule tai's compare-and-swap claim already implements cross-process.
+- [cron-manpage](../cron-manpage.md) (Tier 2): current-minute-only evaluation as the simplest coalescing precedent for repeats.
+
+## Alternatives considered and rejected
+
+- A `running` agent-id column: rejected, agent ids are per-process so the column would lie across processes; the timestamp lease in existing columns is cross-process honest.
+- Grace windows for late one-shots: rejected, a personal agent should fire the late reminder rather than drop it; the 60s minimum interval plus 30s tick keeps staleness visible.
+- Buffers and cancellation (Temporal Buffer/Cancel): rejected as unneeded complexity; skip plus loud status covers the observed cases.
+- Auto-retry of failed scheduled runs: rejected, same as workers; the schedules list shows the failure and the next fire proceeds normally.
+
+## Risks / open questions
+
+- The lease approximates liveness by time, not by process state; a run finishing just past its timeout overlaps the next fire by design (the watcher waits timeout plus margin, matching the lease).
+- Skipped-overlap fires leave no per-row trace beyond the still-running status; the tick prints a count, and the row visibly stays running.
+- Revisit if: per-tick backlog grows faster than it drains (raise the burst cap with evidence), or overlap skips hide real stalls (add an age alarm on running rows).
+
+## Action taken
+
+Implemented the same day: per-tick fire cap with skip counts, `last_status = running` at claim with lease-checked skip, and unit tests for the cap, overlap skip and stale-lease recovery, and one-shot late firing.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial conclusion recorded. |
@@ -0,0 +1,52 @@
+# Conclusion: Cap live subagents with reject-loud semantics
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Conclusion |
+| Tier | N/A |
+| Date decided | 2026-10-18 |
+| Decided by | retoor, advised by tai (agent, Muse Spark) |
+| Status | Active |
+| Confidence | High |
+
+## Question / problem statement
+
+`spawn_agent` had no breadth bound: depth was capped at 2 but a turn could fork any number of workers, each holding a thread and an LLM conversation. The base rule requires a hard cap on everything unbounded. The question was where to set it and what a full pool should do: block (backpressure) or refuse (reject-loud).
+
+## Conclusion
+
+Cap live subagents at `AGENTS_MAX_PARALLEL = 8` with semaphore-TryAcquire semantics: `spawn_agent` raises past the cap instead of queueing, and each caller translates the refusal into its own loud message (fork tool tells the agent to poll existing workers first, the scheduler leaves the row for the next tick with a printed count, verification reports a failed check). The number is arithmetic, not magic: a scheduler burst of 4 plus interactive forks plus one verifier, single machine, free-tier friendly. Past `AGENTS_MAX_RECORDS = 64` total records, spawning purges oldest collected finished records first, so delivered results stay inspectable but never accumulate without bound.
+
+## Supporting sources
+
+- [go-semaphore](../go-semaphore.md): worker-pool-via-semaphore plus the explicit block-versus-TryAcquire fork; tai takes the refuse side.
+- [erlang-otp-supervisor](../erlang-otp-supervisor.md): bounding must be structural (a counter with a tripwire), which the live-count check is.
+- [python-concurrent-futures-deadlock](../python-concurrent-futures-deadlock.md) (Tier 2): blocking waits between workers are a documented deadlock shape, which rules out queueing the spawn.
+- [vorpus-structured-concurrency](../vorpus-structured-concurrency.md) (Tier 2): unstructured background work drops errors silently, which is why every refusal and drop is loud by construction.
+
+## Alternatives considered and rejected
+
+- Blocking acquire (wait for a slot): rejected, a stalled fork burns the spawning turn's step budget and risks the documented wait deadlock; polling plus retry is the honest loop.
+- Higher cap (16+) or per-profile caps: rejected for now, 8 already exceeds any legitimate burst observed (scheduler 4 plus a few forks); raise on measured need, not speculation.
+- Purging uncollected finished records: rejected, that would lose undelivered results; only collected finished records are purged, which loses nothing.
+- Auto-retry of failed workers (Temporal-style): rejected, failures surface as loud results instead; retry belongs to the caller that understands the task.
+
+## Risks / open questions
+
+- A pathological turn could still fork-poll-fork in a loop within the cap; step budgets, not the pool cap, bound that, and they already exist.
+- Uncollected finished records still accumulate in very long sessions; watch record counts if sessions run for days.
+- Revisit if: legitimate bursts hit the cap (raise with evidence), or free-tier rate limits argue for lowering it.
+
+## Action taken
+
+Implemented the same day: `AgentsFull` exception, cap check in `spawn_agent`, loud handling in the fork tool, scheduler pre-check, purge of collected finished records, and unit tests pinning refusal plus recovery (collect, then spawn succeeds).
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial conclusion recorded. |
@@ -0,0 +1,28 @@
+# cron(8)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | cron(8) |
+| Source URL | https://manpages.ubuntu.com/manpages/noble/man8/cron.8.html |
+| Source type | vendor docs |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scheduler gather worker; reported current-minute-only evaluation (missed minutes never catch up). The simplest misfire policy on record; tai's repeating schedules behave this way, one-shots deliberately do not.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,51 @@
+# Supervisor Behaviour
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Supervisor Behaviour |
+| Source URL | https://www.erlang.org/doc/design_principles/sup_princ.html |
+| Source publisher / author | Erlang/OTP System Documentation v29.1.2 |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (living documentation page) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+The OTP supervisor reference: children restart by strategy, but restarts are bounded by a maximum intensity (MaxR restarts in MaxT seconds, default 1 in 5), past which the supervisor terminates everything and escalates. Bounding must be structural (a counter with a tripwire), not advisory.
+
+## Key findings
+
+- "The supervisors have a built-in mechanism to limit the number of restarts which can occur in a given time interval", specified by `intensity` (MaxR) and `period` (MaxT).
+- "If more than `MaxR` number of restarts occur in the last `MaxT` seconds, the supervisor terminates all the child processes and then itself."
+- "The intention of the restart mechanism is to prevent a situation where a process repeatedly dies for the same reason, only to be restarted again."
+- Defaults are `1` and `5` when not given; escalation goes to the next higher-level supervisor.
+
+## Pros / strengths
+
+- Four decades of production supervision distilled into one mechanism; the intensity-plus-period shape is directly portable to any retry or respawn loop.
+- The escalation rule (trip, terminate, let the parent decide) matches tai's loud-failure style better than silent infinite retry.
+
+## Cons / limitations / caveats
+
+- Erlang process semantics (cheap processes, real kills) do not transfer to Python threads, which cannot be killed; tai can refuse and abandon but never terminate a stuck worker.
+- No notion of a parallel-worker cap; OTP bounds restarts, not breadth, so the fan-out half comes from the semaphore source instead.
+
+## Relevance to tai
+
+Justifies the two bounds tai adopts: a parallel-live cap (breadth) plus no-blind-retry (tai workers and schedules never auto-restart; failures surface as loud results). If tai ever adds worker retry, this source prescribes intensity-plus-period as its shape.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,50 @@
+# semaphore package
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | semaphore package |
+| Source URL | https://pkg.go.dev/golang.org/x/sync/semaphore |
+| Source publisher / author | Go project (golang.org/x/sync) |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (living documentation page) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+The Go semaphore reference gives tai both halves of the fan-out decision: cap parallel workers with a counting semaphore, and choose explicitly between blocking acquire (backpressure) and TryAcquire (reject-loud). tai takes the reject side: a full pool refuses new spawns with a loud error instead of stalling the caller.
+
+## Key findings
+
+- "Example_workerPool demonstrates how to use a semaphore to limit the number of goroutines working on parallel tasks."
+- "This use of a semaphore mimics a typical 'worker pool' pattern, but without the need to explicitly shut down idle workers when the work is done."
+- "TryAcquire acquires the semaphore with a non-negative weight of n without blocking. On success, returns true. On failure, returns false and leaves the semaphore unchanged."
+
+## Pros / strengths
+
+- Names the exact fork in the road (block versus refuse) with reference semantics for both, so tai's choice is deliberate rather than accidental.
+- Worker-pool-via-semaphore matches tai's shape (threads come and go; only the live count is bounded).
+
+## Cons / limitations / caveats
+
+- Go-side primitive with contexts and goroutines; tai reimplements the policy (count live under a lock, refuse past the cap), not the mechanism.
+- No guidance on sizing the cap; tai's number comes from its own arithmetic (scheduler burst plus interactive forks plus verifier headroom).
+
+## Relevance to tai
+
+Direct backing for `AGENTS_MAX_PARALLEL` with reject-loud semantics: `spawn_agent` raises past the cap instead of queueing, because a queued fork would stall the spawning turn's step budget (and blocking waits between workers are a documented deadlock shape). Callers translate the refusal into their own loud message.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# concurrent.futures
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | concurrent.futures |
+| Source URL | https://docs.python.org/3/library/concurrent.futures.html |
+| Source type | vendor docs |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the supervision gather worker; reported the deadlock warning for tasks waiting on each other's futures. Supports the reject-instead-of-block choice (a blocked spawn could stall a turn holding budget); not opened first-hand.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,51 @@
+# Schedule
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Schedule |
+| Source URL | https://docs.temporal.io/schedule |
+| Source publisher / author | Temporal |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (living documentation page) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+Temporal's schedule reference enumerates six overlap policies with Skip as the default (a new start while one runs simply does not start) and AllowAll as the only policy permitting concurrency. It frames overlap as a per-schedule policy choice with a safe default, which is exactly what tai adopts.
+
+## Key findings
+
+- "The Overlap Policy controls what happens when it is time to start a Workflow Execution but a previously started Workflow Execution is still running."
+- "`Skip`: Default. Nothing happens; the Workflow Execution is not started."
+- "`AllowAll` Starts any number of concurrent Workflow Executions. With this policy (and only this policy), more than one Workflow Execution, started by the Schedule, can run simultaneously."
+- Buffer variants (BufferOne, BufferAll) plus CancelOther and TerminateOther complete the six; a paused execution still counts as running for overlap evaluation.
+
+## Pros / strengths
+
+- Shows the full policy space, which lets tai pick Skip deliberately while knowing what it is not building (buffers, cancellation).
+- The safe-default framing (concurrency only under the one policy that names it) matches tai's fail-closed style.
+
+## Cons / limitations / caveats
+
+- Distributed-system machinery (catchup windows, buffers) far beyond a single-file agent; tai takes the overlap default and the misfire vocabulary, nothing else.
+- No per-tick burst cap concept; same as APScheduler, the global bound lives elsewhere.
+
+## Relevance to tai
+
+Names tai's overlap behavior: Temporal-Skip by default (previous run live means this fire does not start), with the lease check as the liveness test. Buffers and cancellation stay explicitly unbuilt.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Workflow Activity
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Workflow Activity |
+| Source URL | https://docs.temporal.io/workflow-activity |
+| Source type | vendor docs |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the supervision gather worker; reported mandatory activity timeouts with retry-plus-backoff by default. tai takes the timeout half (every spawn already carries one) and rejects the auto-retry half as unneeded complexity; stayed a card.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Trio's core functionality
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Trio's core functionality |
+| Source URL | https://trio.readthedocs.io/en/stable/reference-core.html |
+| Source type | vendor docs |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the supervision gather worker; reported nursery cancel-all on child error with grouped re-raise. The cancel-and-group half of structured concurrency, not applicable to tai's kill-less threads; stayed a card.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Notes on structured concurrency, or: Go statement considered harmful
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | background-work-limits |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Notes on structured concurrency, or: Go statement considered harmful |
+| Source URL | https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the supervision gather worker; reported the nursery rule (a block cannot exit until its children do) and the dropped-background-error failure mode of unstructured tasks. Shapes tai's join-before-quit discipline; not opened first-hand.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Agent Memory Architecture Wars 2026
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Agent Memory Architecture Wars 2026 |
+| Source URL | https://agentmarketcap.ai/blog/2026/04/08/agent-memory-architecture-wars-letta-mem0-zep-native-provider |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the memory-layer search; the snippet characterizes Mem0 as compression-first (extraction pipeline into dense memories, optional graph variant). Supports the build-vs-adopt framing; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Agentic framework landscape: memory layer entry
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Agentic framework landscape: memory layer entry |
+| Source URL | https://github.com/agentpatterns-ai/website/blob/HEAD/frameworks/agentic-framework-landscape.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the memory-layer search; the snippet restates Mem0 as a layer composing over any harness with multi-signal retrieval numbers. Redundant with the first-hand README dossier; stayed a card.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# GraphRAG vs RAG: The Ultimate Guide to Building Reasoning AI Search in 2026
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | GraphRAG vs RAG: The Ultimate Guide to Building Reasoning AI Search in 2026 |
+| Source URL | https://aithinkerlab.com/graphrag-vs-rag-the-ultimate-guide-to-building-reasoning-ai-search-in-2026/ |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the GraphRAG comparison search; the snippet repeats the higher build cost and latency framing with a pro-graph verdict. Low-value aggregator-style guide; logged for completeness, not relied on.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,53 @@
+# Effective context engineering for AI agents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Effective context engineering for AI agents |
+| Source URL | https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents |
+| Source publisher / author | Anthropic |
+| Source type | blog post |
+| Source date (published) | 2025-09-29 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | direct page fetch |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+Anthropic's context-engineering essay is the reference statement of the converged arsenal: context is finite with diminishing returns (context rot), so agents should compact near-full conversations into summaries, retrieve just-in-time via lightweight identifiers instead of stuffing, persist notes outside the window, and delegate deep work to subagents. Bigger windows do not remove the need for any of this.
+
+## Key findings
+
+- "As the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases" (context rot, observed across all models).
+- "Compaction is the practice of taking a conversation nearing the context window limit, summarizing its contents, and reinitiating a new context window with the summary", preserving decisions, bugs, and implementation details while discarding redundant tool outputs.
+- "Rather than pre-processing all relevant data up front, agents built with the 'just in time' approach maintain lightweight identifiers (file paths, stored queries, web links, etc.) and use these references to dynamically load data into context at runtime using tools."
+- Long-horizon techniques listed: "compaction, structured note-taking, and multi-agent architectures".
+- "Waiting for larger context windows might seem like an obvious tactic. But it's likely that for the foreseeable future, context windows of all sizes will be subject to context pollution and information relevance concerns."
+- Hybrid model endorsed: drop stable context up front, navigate the rest just-in-time with search primitives (their example: glob and grep over files).
+
+## Pros / strengths
+
+- Names every technique tai already implements (compaction, spill identifiers plus record_read, notes as records, fork subagents) as the recommended set, from the vendor operating the largest coding agent.
+- The just-in-time plus lightweight-identifier framing is exactly tai's mem:<hash> spill design, independently derived.
+
+## Cons / limitations / caveats
+
+- Vendor engineering essay, no controlled numbers; the compaction-recall tradeoff is stated qualitatively ("distills... in a high-fidelity manner") without a loss metric.
+- Assumes frontier-model summarization quality; tai compacts with whatever backend is active, including weak free tiers, where summary fidelity is lower.
+
+## Relevance to tai
+
+The master checklist against which tai's context handling was audited: compaction (have it), just-in-time retrieval via identifiers (have it: spill ids plus search), notes outside the window (have it: records), subagent delegation (have it: fork/poll). The gap it exposes is oversized single inputs: Anthropic's techniques all assume the unit of work fits or can be fetched piecemeal, and tai has no path for one giant user prompt except holding it whole.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# GraphRAG vs. Vector RAG: When to Use Knowledge Graphs for Better AI Answers
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | GraphRAG vs. Vector RAG: When to Use Knowledge Graphs for Better AI Answers |
+| Source URL | https://www.archyde.com/graphrag-vs-vector-rag-when-to-use-knowledge-graphs-for-better-ai-answers/ |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the GraphRAG comparison search; the snippet claims up to 20 percentage points multi-hop retrieval gain with substantial overhead. Unverified magnitude; directionally consistent with the paper's sensemaking win.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks |
+| Source URL | https://arxiv.org/abs/2005.11401 |
+| Source type | paper |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scholarship gather worker as the founding RAG paper (parametric memory plus dense-vector index, SOTA on open-domain QA). Foundational but predates and adds nothing beyond tai's settled BM25-chunked retrieval conclusion; not first-hand read.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,51 @@
+# Recursively Summarizing Books with Human Feedback
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Recursively Summarizing Books with Human Feedback |
+| Source URL | https://arxiv.org/abs/2109.10862 |
+| Source publisher / author | Jeff Wu et al. (OpenAI) |
+| Source type | paper |
+| Source date (published) | 2021-09-22 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+The canonical map-reduce pattern for over-window inputs: summarize small sections, then recursively summarize the summaries, reaching state of the art on book-length summarization (BookSum) and book QA (NarrativeQA via zero-shot QA over the summaries). The inference-time decomposition needs no special training to reuse as a pattern.
+
+## Key findings
+
+- "At inference time, the model first summarizes small sections of the book and then recursively summarizes these summaries to produce a summary of the entire book."
+- "We achieve state-of-the-art results on the recent BookSum dataset for book-length summarization."
+- "A zero-shot question-answering model using these summaries achieves state-of-the-art results on the challenging NarrativeQA benchmark."
+
+## Pros / strengths
+
+- Proves decomposition scales past the window for both summarization and QA-shaped goals, which covers tai's massive-prompt cases (paste a huge log, ask questions over it).
+- Single-source in this subject for the pattern's measured wins, hence Medium confidence; corroborated in shape (not numbers) by GraphRAG's map-reduce-over-summaries answering step.
+
+## Cons / limitations / caveats
+
+- 2021 GPT-3-era work with heavy human-feedback training behind the headline numbers; tai would reuse only the inference pattern with off-the-shelf models.
+- Recursive summarization compounds summary error at each level; retrieval-first with summarization as fallback loses less.
+- Scope note: findings above are from the abstract and paper metadata read first-hand; the full PDF was not read.
+
+## Relevance to tai
+
+Backs the second half of the giant-prompt proposal: after spilling an oversized prompt to chunks, answer questions over it either by retrieving slices (preferred, lossless) or by map-reducing chunk summaries through subagents (for global questions). tai already owns every primitive this needs: chunker, FTS index, fork/poll workers.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,50 @@
+# Lost in the Middle: How Language Models Use Long Contexts
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Lost in the Middle: How Language Models Use Long Contexts |
+| Source URL | https://arxiv.org/abs/2307.03172 |
+| Source publisher / author | Nelson F. Liu et al. (TACL 2023) |
+| Source type | paper |
+| Source date (published) | 2023-07-06 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+The paper behind the "bigger window is not enough" argument: on multi-document QA and key-value retrieval, model accuracy is highest when relevant information sits at the start or end of context and degrades significantly in the middle, even for explicitly long-context models.
+
+## Key findings
+
+- "Performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models."
+- "Current language models do not robustly make use of information in long input contexts."
+- Tested on multi-document question answering and key-value retrieval; published in TACL 2023.
+
+## Pros / strengths
+
+- Peer-reviewed, replicated finding that directly bounds the "just stuff the prompt" strategy: position effects punish exactly the giant-middle-blob input shape.
+- Explains why retrieval (small, relevant, front-loaded context) beats stuffing even when stuffing fits.
+
+## Cons / limitations / caveats
+
+- 2023-era models; newer long-context models degrade more gracefully, but the follow-up RULER dossier shows the gap persists in kind.
+- Scope note: findings above are from the abstract and paper metadata read first-hand; the full PDF was not read.
+
+## Relevance to tai
+
+Justifies keeping the 32k working cap with aggressive curation instead of chasing bigger windows: stuffing a massive prompt whole is measurably worse than retrieving its relevant slices. Directly supports the spill-and-retrieve proposal for oversized prompts.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models |
+| Source URL | https://arxiv.org/abs/2310.05736 |
+| Source type | paper |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scholarship gather worker; reported up to 20x prompt compression with little performance loss via a trained budget controller plus token-level compression. The compression alternative tai rejects (needs a trained compressor, lossy, dependency-hostile); single-source and not first-hand read.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,50 @@
+# RULER: What's the Real Context Size of Your Long-Context Language Models?
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | RULER: What's the Real Context Size of Your Long-Context Language Models? |
+| Source URL | https://arxiv.org/abs/2404.06654 |
+| Source publisher / author | Cheng-Ping Hsieh et al. (COLM 2024) |
+| Source type | paper |
+| Source date (published) | 2024-04-09 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+RULER shows vanilla needle-in-a-haystack drastically overstates usable context: across 17 long-context models and harder retrieval, tracing, and aggregation tasks, nearly all models drop sharply with length, and only half the models claiming 32k+ tokens hold satisfactory performance at 32k.
+
+## Key findings
+
+- "Despite achieving nearly perfect accuracy in the vanilla NIAH test, almost all models exhibit large performance drops as the context length increases."
+- "While these models all claim context sizes of 32K tokens or greater, only half of them can maintain satisfactory performance at the length of 32K."
+- The benchmark adds multi-hop tracing and aggregation beyond needle search, plus varied needle counts and types.
+
+## Pros / strengths
+
+- Turns "claimed context" into "usable context" with a reproducible open benchmark; the 32k figure lands exactly on tai's working cap.
+- COLM 2024 peer review plus 17-model breadth makes the direction robust even as individual models improve.
+
+## Cons / limitations / caveats
+
+- Synthetic tasks; real agent workloads mix easier and harder patterns, so the numbers bound rather than predict tai's case.
+- Scope note: findings above are from the abstract and paper metadata read first-hand; the full PDF was not read.
+
+## Relevance to tai
+
+Validates the conservative 32k cap: on the free rotating backends tai actually uses, usable context is certainly below claimed context, so compacting early and retrieving slices is safer than trusting the window. Kills the "wait for bigger windows" alternative for tai's backend tier.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,50 @@
+# From Local to Global: A Graph RAG Approach to Query-Focused Summarization
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | From Local to Global: A Graph RAG Approach to Query-Focused Summarization |
+| Source URL | https://arxiv.org/abs/2404.16130 |
+| Source publisher / author | Darren Edge et al. (Microsoft Research) |
+| Source type | paper |
+| Source date (published) | 2024-04-24 |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+The GraphRAG paper: conventional RAG fails on global sensemaking questions over a corpus, so build an LLM-extracted entity graph, pregenerate community summaries, and answer by map-reducing over them. On 1M-token datasets it substantially beats plain RAG on comprehensiveness and diversity for that question class.
+
+## Key findings
+
+- "RAG fails on global questions directed at an entire text corpus, such as 'What are the main themes in the dataset?', since this is inherently a query-focused summarization task, rather than an explicit retrieval task."
+- Method: "uses an LLM to build a graph index in two stages: first, to derive an entity knowledge graph from the source documents, then to pregenerate community summaries for all groups of closely related entities", then per-community partial responses fused into a final answer.
+- "For a class of global sensemaking questions over datasets in the 1 million token range, we show that GraphRAG leads to substantial improvements over a conventional RAG baseline for both the comprehensiveness and diversity of generated answers."
+
+## Pros / strengths
+
+- Precisely scopes its own win: global sensemaking over large corpora, not lookup. That scoping is what makes it inapplicable to tai rather than merely expensive.
+- The map-reduce-over-summaries answering pattern is reusable independently of the graph machinery.
+
+## Cons / limitations / caveats
+
+- Every indexed document pays LLM extraction plus community summarization; costs scale with corpus size before any query is ever asked.
+- Scope note: findings above are from the abstract and paper metadata read first-hand; the full PDF was not read.
+
+## Relevance to tai
+
+Confirms the graph verdict in both directions: tai should not build entity extraction plus community summaries (wrong query shape, high indexing cost, maintenance-mode upstream), but should keep and grow its cheap structural graph (tags, record links, one-hop expand) for the lookup-plus-context workload it actually serves.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory |
+| Source URL | https://arxiv.org/abs/2504.19413 |
+| Source type | paper |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the scholarship gather worker; reported 91% lower p95 latency and over 90% token savings versus full-context and RAG baselines on LOCOMO. The Mem0 README was read first-hand instead, so the paper stayed a card.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,52 @@
+# Conclusion: tai already implements the converged context arsenal
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Conclusion |
+| Tier | N/A |
+| Date decided | 2026-10-18 |
+| Decided by | retoor, advised by tai (agent, Muse Spark) |
+| Status | Active |
+| Confidence | High |
+
+## Question / problem statement
+
+An internal inventory found tai already compacts conversations, spills oversized tool outputs to retrievable records, chunks and BM25-indexes content, links records in a tag graph, and delegates context-heavy work to subagents. The question was whether this set matches what the industry converged on, or whether tai is missing a standard piece.
+
+## Conclusion
+
+tai's context handling already matches the converged industry arsenal piece for piece: threshold compaction (Anthropic, OpenAI, LangChain, Cursor), just-in-time retrieval via lightweight identifiers instead of stuffing (Anthropic, LangChain offload), notes persisted outside the window (Anthropic notes, tai records), subagent context isolation (Cursor, LangChain), and call-count cost guardrails (LangChain limits, tai step caps). No standard mechanism is missing; the remaining work is extending the existing machinery to new input shapes, not adopting new machinery.
+
+## Supporting sources
+
+- [anthropic-effective-context-engineering](../anthropic-effective-context-engineering.md): the master checklist (compaction, JIT identifiers, notes, multi-agent) tai was audited against.
+- [openai-compaction-guide](../openai-compaction-guide.md): threshold compaction balancing quality, cost, and latency.
+- [langchain-prebuilt-middleware](../langchain-prebuilt-middleware.md): the parts list (summarization, context editing, filesystem offload, subagents, limits) tai mirrors.
+- [cursor-subagents](../cursor-subagents.md): delegation for context isolation with cheaper models for bulk work.
+- [cursor-prompting-agents](../cursor-prompting-agents.md) (Tier 2): fourth-vendor corroboration of auto-compaction near the window limit.
+
+## Alternatives considered and rejected
+
+- Adopting a memory framework (Mem0/Letta) for conversation context: rejected, decided in the companion conclusion; the existing compaction plus retrieval covers the same needs without new dependencies.
+- Chasing bigger context windows instead of curating: rejected per the RULER and lost-in-the-middle dossiers (claimed context exceeds usable context; middle-position recall degrades).
+- Adding explicit context editing (dropping old tool outputs without full compaction): considered and deferred, not rejected; it is the one LangChain piece tai lacks, and a candidate follow-up if compaction costs annoy.
+
+## Risks / open questions
+
+- tai compacts with whatever backend is active, including weak free tiers; summary fidelity there is unmeasured and likely below the frontier-model results vendors report.
+- The audit is mechanism-level; retrieval quality (are the right slices found?) has no Hit@K-style measurement in tai, a gap already recorded in the RAG subject.
+- Revisit if: a vendor ships a genuinely new mechanism outside this set, or compaction summaries prove lossy enough to hurt in practice.
+
+## Action taken
+
+Nothing built: this conclusion records that the shipped machinery (compact_messages, spill_or_truncate, chunk_lines, FTS5 index, graph edges, fork/poll) is the right set. Follow-up decisions live in the two companion conclusions.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial conclusion recorded. |
@@ -0,0 +1,54 @@
+# Conclusion: No full GraphRAG and no memory vendor; grow the vault graph instead
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Conclusion |
+| Tier | N/A |
+| Date decided | 2026-10-18 |
+| Decided by | retoor, advised by tai (agent, Muse Spark) |
+| Status | Active |
+| Confidence | High |
+
+## Question / problem statement
+
+tai owns a BM25 chunk index plus a small structural graph (tags, record links, one-hop search expansion). The question was whether to go further: adopt full GraphRAG entity extraction plus community summaries, or adopt a memory layer (Mem0/Letta), to get more mileage out of the vault for retrieval and context.
+
+## Conclusion
+
+Do neither. Do not build LLM entity extraction plus community summaries (wrong query shape for tai's lookup workload, 5-10x indexing cost, reference implementation in maintenance mode), and do not adopt a memory vendor (embeddings plus extraction dependencies violate stdlib-only; neither product obsoletes ordinary retrieval anyway). Instead grow what the vault already has: more edge types from existing structure (same-tag, same-session, parent-child already flow), entity-ish linking from literal identifiers (paths, hashes, error codes need no LLM to extract), and BM25-plus-graph fusion at retrieval time.
+
+## Supporting sources
+
+- [arxiv-2404-16130-graphrag-paper](../arxiv-2404-16130-graphrag-paper.md): scopes its own win to global sensemaking over large corpora, not lookup.
+- [microsoft-graphrag-readme](../microsoft-graphrag-readme.md): maintenance mode plus expensive-indexing warning, from the vendor itself.
+- [landedjobs-advanced-rag-graphrag](../landedjobs-advanced-rag-graphrag.md) (Tier 2): 5-10x indexing cost; vector plus rerank beats GraphRAG on lookups; route by query shape.
+- [pg-raggraph-ordering](../pg-raggraph-ordering.md) (Tier 2): RAG first, graph traversal only to rerank or expand weak retrieval, which is tai's search-plus-expand shape.
+- [mem0ai-mem0-readme](../mem0ai-mem0-readme.md): the transferable ideas (ADD-only accumulation, entity linking, BM25-plus-entity fusion) without the dependency.
+- [medium-mem0-vs-letta](../medium-mem0-vs-letta.md) (Tier 2): neither memory product makes ordinary retrieval obsolete.
+- [jplevi-graphrag-vs-rag](../jplevi-graphrag-vs-rag.md) (Tier 2): commonly-built GraphRAG underperforms vanilla RAG on real-world lookup workloads.
+
+## Alternatives considered and rejected
+
+- Full GraphRAG pipeline: rejected for the three independent reasons above (query shape, cost, maintenance mode).
+- Mem0 or Letta adoption: rejected on dependencies (embeddings, extraction calls, runtime) and on redundancy (vault plus compaction already cover the needs).
+- Graph removal (chunks only): rejected, one-hop expansion over literal structure is nearly free and the enhancer pattern is well supported; the graph stays as enhancer, never as the primary path.
+
+## Risks / open questions
+
+- One disagreeing datapoint: the Tier 2 hackathon benchmark claims GraphRAG beats basic RAG on every metric including tokens; most plausibly a global-question mix effect, but a genuine head-to-head on tai-shaped content would settle it.
+- Literal-identifier linking is proposed, not measured; if tag-plus-identifier expansion adds noise rather than recall, narrow it back to tags.
+- Revisit if: tai's workload shifts toward global sensemaking questions over the vault, or a dependency-free graph win is demonstrated on tai-shaped content.
+
+## Action taken
+
+Nothing built: this conclusion is a standing no-go with a positive program (edge types, identifier linking, fusion scoring) specified for future sessions.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial conclusion recorded. |
@@ -0,0 +1,53 @@
+# Conclusion: Spill oversized prompts to records and answer via retrieval
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Conclusion |
+| Tier | N/A |
+| Date decided | 2026-10-18 |
+| Decided by | retoor, advised by tai (agent, Muse Spark) |
+| Status | Active |
+| Confidence | High |
+
+## Question / problem statement
+
+Every tai context mechanism handles tool outputs, history, and stored content, but a single giant user prompt has no path except sitting whole in the window: compaction keeps recent messages intact, so a 100k-character paste stays a 100k-character middle blob with measurably degraded recall. The question was how to scale prompt size without a ceiling.
+
+## Conclusion
+
+Extend the existing spill machinery to oversized user prompts: past a size cap, save the prompt body as a vault record with kind `transcript`, chunk and index it like any other content, replace the in-context message with a short pointer plus the user's actual question, and let the turn proceed via search over the chunks (lossless, preferred) or map-reduce summarization through subagents for global questions. No new infrastructure is needed; all primitives exist.
+
+## Supporting sources
+
+- [arxiv-2307-03172-lost-in-the-middle](../arxiv-2307-03172-lost-in-the-middle.md): middle-position recall degrades sharply, which is exactly what a giant whole prompt creates.
+- [arxiv-2404-06654-ruler](../arxiv-2404-06654-ruler.md): usable context trails claimed context, so stuffing is unsafe precisely on tai's weaker backends.
+- [arxiv-2109-10862-recursive-summarization](../arxiv-2109-10862-recursive-summarization.md): chunk-then-summarize scales past the window for both summaries and QA over long inputs (single-source for the measured wins).
+- [anthropic-effective-context-engineering](../anthropic-effective-context-engineering.md): just-in-time retrieval via lightweight identifiers instead of stuffing up front.
+- [langchain-prebuilt-middleware](../langchain-prebuilt-middleware.md): filesystem offload plus subagent isolation as the production shape for bulky content.
+
+## Alternatives considered and rejected
+
+- Stuffing the whole prompt and trusting the window: rejected, the lost-in-the-middle and RULER evidence says recall degrades exactly in that shape.
+- Prompt compression (LLMLingua-style, 20x claimed): rejected, needs a trained compressor model (dependency-hostile), is lossy by construction, and single-sourced here (see the Tier 2 card).
+- Truncating oversized prompts: rejected, silent information loss is worse than any retrieval miss; spill-then-retrieve loses nothing.
+- Routing giant prompts to a long-context model: rejected for now, RULER shows claimed size overstates usable size and tai cannot assume a strong backend is configured.
+
+## Risks / open questions
+
+- Retrieval over prompt chunks can miss the relevant slice (lexical gap, accepted in the RAG subject); the pointer message must tell the model the full text is searchable so it actually searches instead of answering from the stub.
+- Map-reduce over chunks compounds summary error per level; retrieval-first ordering in the prompt text mitigates this.
+- Revisit if: prompt-spill retrieval misses become a reported problem, or a strong long-context backend becomes the reliable default.
+
+## Action taken
+
+Nothing built yet: this conclusion specifies the design (spill cap, `transcript` record kind, pointer stub, retrieval-first answering, subagent map-reduce fallback) for a future implementation session.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial conclusion recorded. |
@@ -0,0 +1,28 @@
+# Prompting agents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Prompting agents |
+| Source URL | https://cursor.com/docs/agent/prompting |
+| Source type | vendor docs |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the industry gather worker alongside the first-hand subagents page; reported to say Cursor auto-compresses older conversation into a summary as the fixed window fills. Corroborates threshold compaction from a fourth vendor; not opened first-hand.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,52 @@
+# Subagents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Subagents |
+| Source URL | https://cursor.com/docs/subagents |
+| Source publisher / author | Cursor |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (living documentation page) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+Cursor's subagent docs describe context isolation as the primary motive for delegation: each subagent gets a clean window, noisy intermediate output never touches the main conversation, and purpose-built Explore/Browser subagents run on faster, cheaper models. The built-in subagents were designed from analysis of conversations where context limits were actually hit.
+
+## Key findings
+
+- "Each subagent operates in its own context window" and "Long research or exploration tasks don't consume space in your main conversation."
+- "Intermediate output stays in the subagent. The parent only sees the final summary."
+- "The explore subagent uses a faster model by default. This enables running 10 parallel searches in the time a single main-agent search would take."
+- "Faster models cost less. Isolating token-heavy work in subagents with appropriate model choices reduces overall cost."
+- "These subagents were designed based on analysis of agent conversations where context window limits were hit."
+
+## Pros / strengths
+
+- Production evidence from the most-used coding agent that delegation-for-isolation plus cheaper-models-for-bulk-work is the economical shape.
+- The foreground/background mode split matches tai's fork/poll split (collect now versus later).
+
+## Cons / limitations / caveats
+
+- Product docs for a managed agent; no failure rates or quality comparisons between main-model and fast-model subagent output.
+- Cursor-specific built-ins (Explore, Browser); the pattern transfers, the implementations do not.
+
+## Relevance to tai
+
+Validates tai's fork guidance ("fork background subagents for independent, long, or context-heavy work") as the same architecture Cursor ships. Suggests one refinement worth pricing later: letting context-heavy workers run on a cheaper pinned model instead of the session default.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# GraphRAG hackathon benchmark: accuracy and token use
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | GraphRAG hackathon benchmark: accuracy and token use |
+| Source URL | https://github.com/dejokz/graphrag_hackathon |
+| Source type | repository |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the GraphRAG comparison search; the snippet claims GraphRAG beats basic RAG on every metric including 34% fewer tokens. Contradicts the lookup-side consensus, likely a query-mix effect (global questions favor graphs, per the paper itself); recorded as the disagreeing datapoint.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# I benchmarked AI agent memory in 2026
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | I benchmarked AI agent memory in 2026 |
+| Source URL | https://dev.to/everest_an/-i-benchmarked-ai-agent-memory-in-2026-and-the-numbers-tell-a-different-story-than-the-marketing-2ae4 |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the memory-layer search; the snippet argues benchmarks miss production realities (Mem0 needs manual add/search calls, Letta demands its runtime). Useful skepticism about memory marketing; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# The GraphRAG Paradox: Scaling Knowledge Retrieval Without Token Collapse
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | The GraphRAG Paradox: Scaling Knowledge Retrieval Without Token Collapse |
+| Source URL | http://dev.to/asifmiqbal/the-graphrag-paradox-scaling-knowledge-retrieval-without-token-collapse-28m5 |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the GraphRAG comparison search; the snippet tabulates vector RAG at 180ms and $18 per 10k queries against naive chained-LLM GraphRAG at 16.4s and $222, with a deterministic-graph hybrid in between. Unverified numbers, but the cost ordering matches every stronger source.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# GraphRAG vs vector RAG: when the knowledge graph pays for itself
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | GraphRAG vs vector RAG: when the knowledge graph pays for itself |
+| Source URL | https://dev.to/saurabh_naik_b213f3bbeafe/graphrag-vs-vector-rag-when-the-knowledge-graph-pays-for-itself-3386 |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the GraphRAG comparison search; the snippet describes the map-reduce-over-summaries mechanism and Microsoft's own cheaper LazyGraphRAG follow-up. Cost-side corroboration; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# GraphRAG vs RAG: When Vector Search Isn't Enough
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | GraphRAG vs RAG: When Vector Search Isn't Enough |
+| Source URL | https://jplevi.com/blog/graphrag-vs-rag-when-vector-search-isnt-enough |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the GraphRAG comparison search; the snippet concedes commonly-built GraphRAG underperforms vanilla RAG in real-world scenarios with added latency, proposing adaptive per-question routing. The routing conclusion tai adopts; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Advanced RAG interview notes: GraphRAG cost and routing
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Advanced RAG interview notes: GraphRAG cost and routing |
+| Source URL | https://github.com/landedjobs/rag-engineer-interview-questions/blob/HEAD/content/06-advanced-rag.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the GraphRAG comparison search; the snippet puts graph-construction indexing at 5-10x the cost of embedding chunks, says vector plus rerank beats GraphRAG on lookups, and calls unqualified "GraphRAG is strictly better" a red-flag answer. Directly supports routing by query shape.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Retrieval Augmented Generation with Deep Agents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Retrieval Augmented Generation with Deep Agents |
+| Source URL | https://docs.langchain.com/oss/python/langchain/rag |
+| Source type | vendor docs |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the industry gather worker; reported as retrieve-then-offload-and-delegate (chunks go to a filesystem backend, not the orchestrator context). Same direction as the first-hand middleware dossier; the page itself was not opened.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,53 @@
+# Prebuilt middleware
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Prebuilt middleware |
+| Source URL | https://docs.langchain.com/oss/python/langchain/middleware/built-in |
+| Source publisher / author | LangChain |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (living documentation page) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+LangChain's production middleware catalog decomposes context management into composable pieces tai mirrors one by one: auto-summarization near token limits, context editing that clears old tool outputs, a filesystem for offloading bulky results, glob/grep file search, subagent spawning for isolation, and call-count limits as cost guardrails.
+
+## Key findings
+
+- Summarization: "Automatically summarize conversation history when approaching token limits, preserving recent messages while compressing older context."
+- Context editing: "Manage conversation context by clearing older tool call outputs when token limits are reached, while preserving recent results."
+- Filesystem: "Provide agents with a filesystem for storing context and long-term memories."
+- Subagent: "Handing off tasks to subagents isolates context, keeping the main (supervisor) agent's context window clean while still going deep on a task."
+- File search: "Provide Glob and Grep search tools over filesystem files."
+- Cost guardrails ship alongside: model-call and tool-call limits "to prevent excessive costs".
+
+## Pros / strengths
+
+- The closest thing to a parts list for the converged architecture; every item maps to a tai mechanism (compaction, spill, vault records, fork/poll, MAX_STEPS).
+- Shows context editing (dropping old tool outputs) as distinct from summarization, which tai currently only does implicitly via compaction.
+
+## Cons / limitations / caveats
+
+- Framework catalog, not a study; no numbers on how much each piece saves or what breaks when old tool outputs are dropped.
+- Assumes the LangChain runtime; tai would reimplement any missing piece natively.
+
+## Relevance to tai
+
+Confirms tai's decomposition is complete at the mechanism level, and surfaces the one missing piece worth considering: explicit context editing that drops or collapses old tool outputs without a full compaction pass. Everything else on the list tai already has under its own names.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# Mem0 vs Letta in Production: Two Ways to Build Agent Memory
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Mem0 vs Letta in Production: Two Ways to Build Agent Memory |
+| Source URL | https://medium.com/data-science-collective/mem0-vs-letta-choosing-the-right-ai-agent-memory-layer-4458712d22a6 |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the memory-layer search; the snippet frames Mem0 as a callable layer versus Letta as a stateful runtime, noting neither makes ordinary retrieval obsolete. The key line for tai's build-vs-adopt call; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Agent memory frameworks showdown: Cognee vs Mem0 vs Zep vs Letta
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Agent memory frameworks showdown: Cognee vs Mem0 vs Zep vs Letta |
+| Source URL | https://medium.com/data-science-collective/agent-memory-frameworks-showdown-cognee-vs-mem0-vs-zep-vs-letta-0f439b56f282 |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the memory-layer search; the snippet positions Mem0 as fastest to ship (bolt-on) and Letta as more control with more infrastructure, both production-proven at scale. Adoption-context only; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Mem0 Raises $24M Series A to Build Memory Layer for AI Agents
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Mem0 Raises $24M Series A to Build Memory Layer for AI Agents |
+| Source URL | https://www.vcaonline.com/news/2025102807/mem0-raises-24m-series-a-to-build-memory-layer-for-ai-agents/ |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the memory-layer search (same press release also seen on wcia.com; both listings describe one announcement, logged once with 41k stars, 14M downloads, 35M to 186M quarterly API calls). Traction signal only, not technical evidence.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,53 @@
+# Mem0 README
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Mem0 README |
+| Source URL | https://raw.githubusercontent.com/mem0ai/mem0/main/README.md |
+| Source publisher / author | Mem0 (mem0ai) |
+| Source type | repository |
+| Source date (published) | Unknown — not stated (living repository file) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | direct page fetch |
+| Confidence | Medium |
+| Status | Active |
+
+## Summary
+
+Mem0 is a drop-in memory layer (add/search/update/delete over user, session, and agent scopes) whose April 2026 algorithm uses single-pass extraction, entity linking, and multi-signal retrieval fusing semantic, BM25 keyword, and entity matching. It reports 92.5 on LoCoMo and 94.4 on LongMemEval at about 7k tokens per query, with the caveat that managed-platform numbers include proprietary optimizations.
+
+## Key findings
+
+- "Multi-Level Memory: Seamlessly retains User, Session, and Agent state with adaptive personalization."
+- Retrieval fuses "semantic, BM25 keyword, and entity matching scored in parallel and fused".
+- Reported table: LoCoMo 92.5 at 7.0k tokens, LongMemEval 94.4 at 6.8k tokens, BEAM 1M at 64.1, BEAM 10M at 48.6.
+- "Scores reflect Mem0's managed platform, which includes proprietary optimizations not available in the open-source SDK; open-source users should expect directionally similar gains but not identical numbers."
+- Extraction is "Single-pass ADD-only", one LLM call with no update or delete passes; "Memories accumulate; nothing is overwritten."
+
+## Pros / strengths
+
+- Shows the production memory-layer shape concretely: extraction pipeline plus fused retrieval behind a small CRUD API, composable over any agent loop.
+- The BM25-plus-entity fusion corroborates tai's lexical-plus-graph direction from an independent production system.
+
+## Cons / limitations / caveats
+
+- Vendor benchmarks on vendor-chosen suites; the managed-versus-OSS gap is disclosed but unquantified.
+- Requires embeddings infrastructure plus an extraction LLM call per write; incompatible with tai's stdlib-only, no-embeddings constraints as a dependency.
+- BEAM scores visibly decay with corpus size (64.1 at 1M to 48.6 at 10M), so "unlimited" still degrades.
+
+## Relevance to tai
+
+Mem0 is the thing tai will not adopt but should learn from: the ideas that transfer dependency-free are ADD-only accumulation, entity linking across memories, and fusing BM25 with entity/tag signals at retrieval. tai's vault (records plus tags plus graph edges) is already halfway to that shape without any new dependency.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,50 @@
+# GraphRAG README
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | GraphRAG README |
+| Source URL | https://raw.githubusercontent.com/microsoft/graphrag/main/README.md |
+| Source publisher / author | Microsoft |
+| Source type | repository |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | direct page fetch |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+Microsoft's GraphRAG repository, the reference implementation of graph-based retrieval, now carries a maintenance-mode warning (no new PRs or features) and a cost warning on indexing. It describes itself as a research demonstration for extracting structured data from unstructured text with LLMs, not a supported offering.
+
+## Key findings
+
+- "This project is largely in maintenance mode, and won't be accepting new PRs or implementing new features", because "the capabilities of frontier models have changed dramatically" since the July 2024 release.
+- "Warning: GraphRAG indexing can be an expensive operation, please read all of the documentation to understand the process and costs involved, and start small."
+- "The provided code serves as a demonstration and is not an officially supported Microsoft offering."
+- The pipeline "is designed to extract meaningful, structured data from unstructured text using the power of LLMs."
+
+## Pros / strengths
+
+- First-party statement of the project's status and cost profile; settles the adopt-or-not question from the vendor's own mouth.
+- The maintenance rationale (frontier models changed the tradeoff) is itself evidence about where the field moved.
+
+## Cons / limitations / caveats
+
+- Says nothing about the technique's merits, only the implementation's status; the paper dossier carries the method claims.
+- A research code drop was never the right adoption target anyway; serious adopters reimplement the pipeline.
+
+## Relevance to tai
+
+Decisive against adopting full GraphRAG extraction: expensive LLM indexing, a maintenance-mode reference, and tai's content is lookup-shaped (commands, logs, errors) where the technique underperforms flat retrieval (see the interview and practice cards). tai's existing tag/edge graph plus one-hop expand keeps the cheap half of the idea without the extraction pipeline.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,52 @@
+# Compaction
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Dossier |
+| Tier | 1 |
+| Source title | Compaction |
+| Source URL | https://developers.openai.com/api/docs/guides/compaction |
+| Source publisher / author | OpenAI |
+| Source type | vendor docs |
+| Source date (published) | Unknown — not stated (living documentation page) |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | both |
+| Confidence | High |
+| Status | Active |
+
+## Summary
+
+OpenAI's server-side compaction guide confirms threshold-triggered summarization as a first-class platform feature: past a configured token threshold the server emits a compaction item carrying prior state forward, and clients drop everything before it. The stated purpose is balancing quality, cost, and latency as conversations grow.
+
+## Key findings
+
+- "Compaction helps you balance quality, cost, and latency as conversations grow."
+- "When the rendered token count crosses the configured threshold, the server runs server-side compaction", emitting a compaction item in-stream and pruning context before continuing inference.
+- "The returned compaction item carries forward key prior state and reasoning into the next run using fewer tokens."
+- "You can drop items that came before the most recent compaction item to keep requests smaller and reduce long-tail latency."
+- The example threshold in the guide is 200,000 tokens.
+
+## Pros / strengths
+
+- Independent vendor confirmation that threshold-triggered compaction is the standard mechanism, with the same trigger/prune/carry shape as tai's client-side version.
+- Makes the cost/latency motive explicit: compaction is as much about bills and tail latency as about fitting the window.
+
+## Cons / limitations / caveats
+
+- Server-side and opaque ("not intended to be human-interpretable"); tai's summary is client-side and inspectable, which is better for audit but costs a visible extra model call.
+- No guidance on what to preserve versus discard; the compaction-item content policy is OpenAI-internal.
+
+## Relevance to tai
+
+Validates tai's `compact_messages` trigger design (ratio of a cap, summarize middle, keep recent) as the industry shape. tai's 32k cap with 0.8 trigger is far smaller than the guide's 200k example, which is correct for its weaker backends: the RULER dossier shows claimed context far exceeds usable context on small models.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Initial dossier created. |
@@ -0,0 +1,28 @@
+# pg-raggraph: RAG first, graph second
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | pg-raggraph: RAG first, graph second |
+| Source URL | https://github.com/yonk-labs/pg-raggraph |
+| Source type | repository |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the GraphRAG comparison search; the snippet states the graph as enhancer design (vector plus BM25 first, one-hop traversal only to rerank or expand weak retrieval). That ordering is what tai's search-plus-expand already does; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Deus research notes: GraphRAG comparison
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Deus research notes: GraphRAG comparison |
+| Source URL | https://github.com/sliamh11/deus/blob/HEAD/docs/research/graphrag-comparison.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the GraphRAG comparison search; the snippet scopes LightRAG's "6000x cheaper" claim to retrieval orchestration tokens and notes graph traversal starts paying off around a thousand nodes. Useful cost-scope discipline; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Graph RAG study notes: when it is overkill
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Graph RAG study notes: when it is overkill |
+| Source URL | https://github.com/sudhir13s/ai-ml-learning-resources/blob/HEAD/llms-applications-and-agents/rag-and-knowledge-systems/graph-rag/graph-rag.md |
+| Source type | other |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the GraphRAG comparison search; the snippet argues single-factoid lookups answered from one chunk gain nothing from the extraction plus community machinery and can get worse through bad extraction. Matches tai's lookup-shaped workload verdict.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Agent Memory Architectures Compared (2026)
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Agent Memory Architectures Compared (2026) |
+| Source URL | https://sureprompts.com/blog/agent-memory-architectures-compared-2026 |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the memory-layer search; the snippet describes the mem0-style CRUD layer (add after a turn, search before a turn, layer handles extraction and dedup) and warns Letta is heavier than plain fact memory needs. Relevant layer-shape comparison; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
@@ -0,0 +1,28 @@
+# Agent memory: episodic versus semantic representations
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| Institute | Molodetz Institute — Research & Retrieval Division |
+| Subject | prompt-context-scaling |
+| Document type | Source Citation Card |
+| Tier | 2 |
+| Source title | Agent memory: episodic versus semantic representations |
+| Source URL | https://github.com/metabuilder-labs/tokenjam-website/blob/HEAD/src/content/blog/2026-05-13-agent-memory.mdx |
+| Source type | blog post |
+| Date researched | 2026-10-18 |
+| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
+| Research method | Search aggregator result listing (not independently opened or quoted) |
+| Confidence | Not independently verified |
+| Status | Active |
+
+## Why it's here
+
+Surfaced by the memory-layer search; the snippet notes production systems blend episodic and semantic memory with vector plus graph representations. tai's events-plus-records split mirrors this without vectors; seen only as a snippet.
+
+## Changelog
+
+| Date | Change |
+|---|---|
+| 2026-10-18 | Logged as consulted-but-not-analyzed. |
--- a/Show More
+++ b/Show More