chore(multishot): delete the loop core when gtm and tax land on runGraph (extracted from agent-runtime#694)

[drewstone]

Extracted from tangle-network/agent-runtime#694 (final ledger there). The ./multishot loop core (runMultishot + the loop inside runMultishotMatrix) is ruled subsumed by runGraph with the production caller brain. Deletion is gated on consumer migration, and the gate is measured, not assumed.

Aliveness census (2026-08-16, deletion scope = zero)

surface	evidence
gtm-agent origin/master	5 files import @tangle-network/agent-eval/multishot; runMultishot at eval/matrix/multishot.ts:9; runMultishotMatrix at eval/matrix/matrix.ts:30 (called in runMatrixPass)
tax-agent origin/main	3 files; runMultishot called at tests/eval/multishot.ts:286
npm dependents (tarball-grep dist)	agent-runtime 0.135.0 + 0.135.2, agent-app 0.45.60, sandbox-ui 0.103.1, agent-knowledge 8.0.1 — 0 hits for agent-eval/multishot

The gate — all three must land first

1. tangle-network/gtm-agent#897 — both gtm loop call sites onto runGraph (built, parity 4/4 deep-equal vs runMultishot, sound-with-nits audit; held on the runtime 0.135.3 keystone, agent-runtime#873).
2. tangle-network/tax-agent#486 — the tax migration (open).
3. The gtm runMultishotMatrix follow-up — by #897's own scope the matrix path stays loop-backed after it merges.

Execution rules when the gate opens

• Re-run the census above (default-branch greps + tarball-grep of every npm dependent) before removing any export.
• Eval-layer parts (judges, matrix composites, types, router helpers) relocate with import specifiers preserved; only the loop core deletes.
• MultishotDriverEmptyError becomes an edge-ledger empty event per the #694 ruling.
• Full suite + verify:package; changelog; release; watch npm and PyPI.

[drewstone]

Census re-run 2026-08-15 — gate still closed, deletion scope stays zero

Gate check: gtm#897 is OPEN (draft), gtm#899 has not started, and only tax#486 has merged.
The runtime 0.135.3 keystone (tangle-network/agent-runtime#873) is unpublished — npm latest is agent-runtime 0.135.2 and agent-app 0.45.60.

surface	loop imports (value)	eval-layer-only imports
gtm-agent origin/master	3 sites: runMultishot at eval/matrix/multishot.ts:9 and eval/monitoring/live-soak.ts:5; runMultishotMatrix at eval/matrix/matrix.ts:30	eval/scoring/multishot-judges.ts (renderJsonFooter, JudgeConfig, ArtifactJudgeInput, ConversationJudgeInput); eval/matrix/matrix.test.ts (vi.mock)
tax-agent origin/main	1 site: runMultishot at tests/eval/lib/graph-multishot.test.ts:12 (parity reference vs runGraphMultishot; plus MultishotDriverEmptyError, MultishotFatalToolError)	tests/eval/lib/graph-multishot.ts (8 types); tests/eval/multishot.ts (judge + shape types); tests/eval/lib/multishot-transcript.test.ts (2 types)
npm dependents (tarball-grep dist)	agent-runtime 0.135.0 + 0.135.2, agent-app 0.45.60, sandbox-ui 0.103.1, agent-knowledge 8.0.1 — 0 hits	—

Measured remainder: 4 value import sites of the loop core across 2 default branches (gtm 3, tax 1).
The dead subset of the loop core is empty — runMultishot and runMultishotMatrix are both live.
No export deletes today; partial-and-honest beats total-and-wrong.

Finding for the gate design: tax#486 merged but kept runMultishot as the parity reference engine in graph-multishot.test.ts.
When the gate opens, that test must drop the loop reference (or pin it to a vendored copy), or the tax census stays non-zero permanently.

Order that opens the gate: agent-runtime#873 publishes 0.135.3 → gtm#897 merges → gtm#899 (matrix path) merges → re-run this census.

[drewstone]

Loop-importer census — measured 2026-08-16, from every canonical repo's origin default branch

Method: for each repo in ~/code whose .git is a directory (worktree clones excluded), git grep -l "@tangle-network/agent-eval/multishot" <origin default> -- '*.ts', then each hit classified by whether it imports the loop core as a VALUE (runMultishot / runMultishotMatrix) or only types and primitives (MultishotMessage, JudgeConfig, runJudge, routerCompletion, …). Comment-only mentions are excluded.

Value imports of the loop core — these break when the core is deleted

repo	branch	file:line	symbol	state
gtm-agent	origin/master	eval/matrix/multishot.ts:9	runMultishot	migrated on gtm#897 (runMultishotGraph)
gtm-agent	origin/master	eval/monitoring/live-soak.ts:5	runMultishot	migrated on gtm#897 (runMultishotGraph)
gtm-agent	origin/master	eval/matrix/matrix.ts:27	runMultishotMatrix	migrated on gtm#900 (runMultishotMatrixGraph)
gtm-agent	origin/master	eval/matrix/matrix.test.ts:7	runMultishotMatrix (vi.mock double)	follows matrix.ts on gtm#900
tax-agent	origin/main	tests/eval/lib/graph-multishot.test.ts:12	runMultishot	KEPT — reference oracle, see below
agent-runtime	origin/main	examples/p1-parity/arms.ts:36	runMultishot	NOT migrated — arm A of the loop-vs-graph parity benchmark
agent-runtime	origin/main	examples/self-improving-loop/self-improving-loop.ts:31	runMultishot	NOT migrated

Type / primitive imports only — unaffected by deleting the core

repo	branch	file
agent-runtime	origin/main	examples/p1-parity/offline.ts:22, examples/p1-parity/run-parity.ts:39
gtm-agent	origin/master	eval/scoring/multishot-judges.ts
tax-agent	origin/main	tests/eval/multishot.ts, tests/eval/lib/multishot-transcript.test.ts
tuner-agent	origin/main	src/lib/benchmark-registry.ts, src/lib/eval-adversary.ts, src/lib/eval-judge.ts, src/lib/eval-tools.ts

Flag: the loop survives as a reference oracle in two places, and where it should LIVE is an open decision

tax-agent's parity suite (tests/eval/lib/graph-multishot.test.ts, merged as tax#486) keeps runMultishot deliberately: it is the reference implementation the graph runner is proven byte-equal against — deep-equal transcript, artifacts, tool-call count, cost, plus the three fail-loud paths. gtm#900's new eval/lib/multishot-matrix-graph.test.ts does the same for the matrix path. agent-runtime's examples/p1-parity/arms.ts uses it the same way, as arm A of a benchmark whose entire purpose is loop-versus-graph.

So "delete the loop core" and "keep a loop reference to prove the graph" are in direct tension, and three repos now depend on the oracle. Where the oracle should live is not decided here — the options on the table are: keep runMultishot published as-is; move it to a @tangle-network/agent-eval/testing (or similar) reference-only subpath; vendor a frozen copy into each parity suite; or delete it and retire the byte-equality proofs. This census only records that the decision now has three dependents, not two.

Gate state at the time of this census (2026-08-16T07:05Z)

gate	state
tax#486	MERGED — production path on runGraphMultishot, loop kept only as the parity oracle
gtm#897	pushed, out of draft at 2ec62ef (interface-0.53 cohort + the two direct call sites), audit running
gtm#900 (issue #899)	open, draft, stacked on #897 at 4fcea77 — matrix path migrated, parity test green
agent-runtime examples	NOT started — 2 value imports remain

Deletion scope stays zero until gtm#897 and gtm#900 merge AND the agent-runtime examples are answered. The examples are the item this census adds that earlier ones missed: examples/p1-parity/arms.ts and examples/self-improving-loop/self-improving-loop.ts import the loop core as a value from agent-runtime's own tree, so deleting it breaks agent-runtime's examples typecheck, not just a product repo.

[drewstone]

Gate update — 2026-08-16T07:17Z:

• gtm#897 MERGED at 07:15:36Z as 5db467a (genuine value-audit verdict 🟡 sound-with-nits on the pushed head 2ec62efc). The two direct loop call sites — eval/matrix/multishot.ts and eval/monitoring/live-soak.ts — are now on runMultishotGraph on master.
• gtm#900 (issue #899, the runMultishotMatrix path) is out of draft at f2dadc9, rebased onto the merged master, audit running. Its diff is six files; pnpm test 3728 passed / 0 failed, tsc -p eval/tsconfig.json exit 0.

Deletion scope stays zero until #900 merges AND the two agent-runtime examples (examples/p1-parity/arms.ts:36, examples/self-improving-loop/self-improving-loop.ts:31) are answered. Those two are the item this census added.

[drewstone]

Loop-importer census — measured after gtm#900 merged (cab9cd5, 2026-08-16T07:35:32Z; issue #899 auto-closed 07:35:33Z).

Answer: the loop core has zero production callers anywhere in the fleet. All 4 production call sites are migrated. What remains is 3 test-only parity oracles and 2 unpublished examples. Of 10 npm packages that depend on @tangle-network/agent-eval, 0 reference the /multishot subpath at all.

Deletion scope is still not zero-risk, and the reason is now a single named thing: the parity oracle. Framed below, not decided.

Method

Three independent sweeps. Every number is from a remote-tracking ref, never a local HEAD — several local checkouts are stale and give the wrong answer.

1. git grep for loop-core value symbols — runMultishot, runMultishotMatrix, excluding the *Graph twins — on gtm origin/master (post-merge) and tax origin/main.
2. The same grep across every canonical repo in ~/code, each on its own remote default branch.
3. Tarball-grep: read the latest manifest of all 41 published @tangle-network/* packages, keep the 10 declaring any dependency on agent-eval, download the published tarball, grep for agent-eval/multishot|runMultishotMatrix|runMultishot.

Result 1 — production call sites: 4 of 4 migrated, 0 remain

Repo	Site	Was	Now	Landed by
tax	tests/eval/multishot.ts:286	runMultishot	runGraphMultishot	#486
gtm	eval/matrix/multishot.ts:64	runMultishot	runMultishotGraph	#897
gtm	eval/monitoring/live-soak.ts:155	runMultishot	runMultishotGraph	#897
gtm	eval/matrix/matrix.ts:187	runMultishotMatrix	runMultishotMatrixGraph	#900

Result 2 — every remaining loop-core value reference

Repo / branch	File:line	Symbol	Role	Published?
gtm origin/master	eval/lib/multishot-graph.test.ts:13 + 8 call sites	runMultishot	shot-level parity oracle	test only
gtm origin/master	eval/lib/multishot-matrix-graph.test.ts:19,272	runMultishotMatrix	matrix-level parity oracle (added by #900)	test only
tax origin/main	tests/eval/lib/graph-multishot.test.ts:12,223	runMultishot	shot-level parity oracle	test only
agent-runtime origin/main	examples/p1-parity/arms.ts:36,334	runMultishot	A/B arm baseline in the parity example	no — examples/ is not in the tarball
agent-runtime origin/main	examples/self-improving-loop/self-improving-loop.ts:31,202	runMultishot	offline demo	no — examples/ is not in the tarball
agent-eval origin/main	src/multishot/multishot.ts:73, src/multishot/matrix.ts:183,204, tests/multishot/matrix-transport.test.ts	both	the package's own core and its own tests	n/a — the thing itself

One non-importer worth naming so it is not miscounted later: tests/eval-surface.test.ts:46 in gtm contains the string runMultishotMatrix< inside expect(matrix).not.toContain(...). It is a regression guard asserting the loop is absent from matrix.ts. It matches a naive grep and is the opposite of a caller.

Result 3 — npm dependents at current latest (tarball-grep)

Package	Version	agent-eval range	/multishot refs	subpaths actually imported
traces	0.11.5	dep 0.143.0	0	analyst, contract, hosted, pipelines, supervisor-run, trace-attributes, traces
agent-runtime	0.135.3	peer >=0.145.15 <0.146.0	0	analyst, campaign, contract, pipelines
agent-app	0.45.61	peer >=0.145.15	0	campaign, contract
sandbox-cli	0.8.6	dep 0.145.11	0	root only
agent-knowledge	8.0.2	peer >=0.145.16 <0.146.0	0	campaign, experiment, rl
starter-foundry	0.13.5	dev 0.135.1	0	campaign, contract, src, traces
run-capsule	0.4.1	dep 0.134.1	0	storyboard
browser-agent-driver	0.36.0	dev ^0.23.0	0	root only
agent-provider-tangle	0.11.3	dev 0.145.3	0	root only
agent-bench	0.8.10	dep 0.145.11	0	analyst, campaign, contract, rl, rollout, supervisor-run

Negative control for the zero. The identical grep over the identical tarballs finds 1–71 files per package referencing @tangle-network/agent-eval (traces 8, agent-runtime 57, agent-app 20, sandbox-cli 1, agent-knowledge 16, starter-foundry 71, run-capsule 8, browser-agent-driver 1, agent-provider-tangle 1, agent-bench 56), across 12 distinct non-multishot subpaths. The grep fires; the /multishot zero is a real zero, not a broken pattern.

What deleting the loop core does NOT buy you

The /multishot subpath stays. 9 gtm files and 4 tax files import it; only 3 of those 13 touch the loop core (the oracles above), so the other 10 import only non-loop members: routerCompletion, runJudge, renderJsonFooter, estimateRouterCost, defaultShapeFromProfile, computeCellComposite, renderDimensions, the Multishot* error classes, and ~15 exported types. Those are judge, transport, and shape primitives with live production callers. They are unrelated to the orchestration loop and are not in scope for this deletion.

Threats to validity

• ~/code/tax-agent-capstable shows a runMultishot production call at tests/eval/multishot.ts:286. It is a stale clone of the same repo (tangle-network/tax-agent); its origin/main ref a782779 (Aug 4) is a proven ancestor of the real origin/main 763fa6a. Excluded — not a real importer.
• agent-runtime's tarball ships only dist, package.json, README.md, skills. Its examples/ loop imports are repo-only, which is exactly why sweep 3 reports 0 for a repo that sweep 2 shows does import the loop. The two sweeps disagreeing here is correct, not a contradiction.
• Sweep 3 covers the 41 published @tangle-network/* packages returned by registry search. A private consumer or a non-org package would not appear.
• Sweeps 1 and 2 cover default branches only. An unmerged branch could add an importer.

The open decision: what to do with the parity oracle

The 3 oracles are now the only reason the loop core stays published. Each runs the loop and its graph twin on identical scripted transports and asserts deep equality — transcript rows, typed artifacts, tool-call count, cost arithmetic. The loop is the reference. Deleting it deletes the proof that the graph engine is equivalent to the thing it replaced.

Three options, each with its real cost. Not choosing here.

1. Keep the loop published as a test-only oracle.
Cost: agent-eval carries a second full orchestration engine with no production caller, indefinitely. Every substrate change must keep a dead path compiling and behaviourally correct, and #617 never closes.
Benefit: parity stays continuously proven at zero migration cost — and it is the only option that keeps proving it against future graph-engine changes, not just today's.

2. Move the oracle inside agent-eval as a fixture.
The loop becomes internal (non-exported) and the parity proof becomes a substrate fixture.
Cost: consumers lose the ability to prove their own twins equal. gtm's and tax's twins are not the substrate's twin — they are product-specific graph wirings — so a substrate-internal fixture proves a strictly different claim than the three consumer tests prove today. The migration is not mechanical.
Benefit: public API surface shrinks; the loop stops being something external code can call.

3. Retire the oracle — declare parity settled.
Delete the loop core and the three parity tests together.
Cost: equivalence becomes a historical assertion rather than a continuously checked one. A future regression in the graph engine's transcript, cost, or artifact shape lands with nothing watching for it.
Benefit: the largest deletion, and the only option that actually closes #617.

The same tension, seen from #897 and #900

#897's value audit raised a medium concern that #900's audit repeated and sharpened: gtm now carries two orchestration twins — eval/lib/multishot-graph.ts and eval/lib/multishot-matrix-graph.ts — the latter roughly 160–170 lines of frozen copy of the substrate's own matrix cell body, diverging at exactly one call.

That copy exists because agent-eval hardwires runMultishot inside runMultishotMatrix (src/multishot/matrix.ts:204) and exposes only wire-level transport seams, which cannot express an orchestration swap. The substrate alternative both audits named is a runShot seam in agent-eval: add a shot (or runCell) option to RunMultishotMatrixOptions, and both frozen twins in gtm collapse into a call.

#900's audit added a second, related nit: gtm's CellOutput is declared as a local "structural twin" because agent-eval does not export the per-cell output type, so additive substrate drift is invisible to TypeScript and caught only at runtime by the parity test.

This is the same tension as the oracle decision, not a separate one. A shot seam is also what makes option 2 tractable — with injection, the consumer's product-specific wiring becomes an argument rather than a fork, so an in-substrate fixture could prove the consumer's claim too. Without it, options 1 and 3 are the only honest choices.

Deletion scope stays zero until this is decided.

[drewstone]

The shot seam exists — agent-eval 0.145.19

The substrate change both audits named is shipped. RunMultishotMatrixOptions.runShot selects the per-cell conversation engine and defaults to runMultishot (agent-eval#621, released 0.145.19 on npm and PyPI).

Reporting it here because this census framed the oracle decision, and one of the three options moves.

What landed

runShot?: MultishotShot<TPersona>	the per-cell conversation engine; defaults to runMultishot
MultishotShot<TPersona>	exported — (opts: RunMultishotOptions<TPersona>) => Promise<MultishotResult>, the default engine's own signature
MultishotCellOutput	exported — the former private CellOutput; RunMultishotMatrixResult.matrix is now MatrixResult<MultishotCellOutput>
assertMultishotShotResult + MultishotShotResultError	every shot result is validated; a malformed one fails the cell with no fallback to the default engine

The matrix keeps cell fan-out, concurrency, the cost ceiling, the three judge slots, the cell composite, the per-cell writers and the run summary. Only the conversation is swappable.

The measurement that motivated it, closed

gtm's eval/lib/multishot-matrix-graph.ts is 223 lines that differ from the substrate cell body at one call. With the seam it is 12 lines of code:

export function runMultishotMatrixGraph<TPersona extends MultishotPersona>(
  opts: RunMultishotMatrixOptions<TPersona>,
): Promise<RunMultishotMatrixResult> {
  return runMultishotMatrix({ ...opts, runShot: runMultishotGraph })
}

Compiled, not asserted: gtm's runMultishotGraph signature was copied verbatim from eval/lib/multishot-graph.ts on gtm origin/master into a declaration file, and the collapsed module type-checked against the released dist/multishot/index.d.ts at exit 0. Renaming the option to runShotTypo makes the same check fail with TS2353, so the check is real.

The second nit this census recorded is closed by the same change: gtm's CellOutput "structural twin" becomes import type { MultishotCellOutput }, so additive substrate drift is a compile error rather than a runtime surprise.

gtm is unchanged. The collapse is the argument for the seam, not part of it. Migrating gtm is a separate change against the released version.

What this changes about the oracle decision — and what it does not

Option 2 (move the oracle into agent-eval as a fixture) becomes tractable. This census stated the blocker precisely:

Cost: consumers lose the ability to prove their own twins equal. gtm's and tax's twins are not the substrate's twin — they are product-specific graph wirings — so a substrate-internal fixture proves a strictly different claim than the three consumer tests prove today. The migration is not mechanical.

The seam removes that asymmetry for the matrix-level oracle. A consumer's product-specific wiring is now expressible as a MultishotShot — an argument, not a fork — so a substrate fixture can be parameterised by the engine under test and prove the consumer's claim rather than a different one. The census's own words: "A shot seam is also what makes option 2 tractable — with injection, the consumer's product-specific wiring becomes an argument rather than a fork."

Options 1 and 3 are unchanged. The seam does not make the loop core dead, does not settle whether parity should keep being checked, and does not remove the cost named for either option.

Two limits, so the tractability claim is not read wider than it is.

1. The seam is matrix-level. Of the three surviving oracles, the two that compare shots rather than matrices — gtm eval/lib/multishot-graph.test.ts and tax tests/eval/lib/graph-multishot.test.ts — call runMultishot directly and are unaffected. Only gtm eval/lib/multishot-matrix-graph.test.ts sits behind the new seam. A shot-level fixture would need runMultishot itself to stay reachable in some form, which is exactly the option-1-versus-option-3 question.
2. "Tractable" is not "built". Nobody has written the parameterised fixture, and its migration cost is unmeasured.

Deletion scope stays zero. Not taking the decision here.

Census delta

No importer counts change. This adds one substrate capability to the record, and the census's own conditional — "without it, options 1 and 3 are the only honest choices" — no longer holds for the matrix oracle.

[drewstone]

Census re-run 2026-08-16 — the deletion premise is contradicted. Stopping before the delete.

The gate said: confirm the only remaining value imports are the three parity oracles, then delete. Re-ran the census. There are five, not three. Two live in agent-runtime and are not oracles.

Value imports of the loop, default branches + npm

surface	runMultishot / runMultishotMatrix as a VALUE	verdict
gtm-agent origin/master	eval/lib/multishot-graph.test.ts, eval/lib/multishot-matrix-graph.test.ts	parity oracles — migrated in tangle-network/gtm-agent#902
tax-agent origin/main	tests/eval/lib/graph-multishot.test.ts	parity oracle — migrated in tangle-network/tax-agent#488
agent-runtime origin/main	examples/p1-parity/arms.ts:36 — imported and called at line 334	NOT an oracle. Arm A of the P1 parity experiment IS the loop. Its own validity test asserts the real asymmetries between the two engines ("the graph settles at the first passing shot while runMultishot burns its whole budget"). Golden records cannot replace it: its purpose is to run the loop live against a real provider, not to compare against a recording.
agent-runtime origin/main	examples/self-improving-loop/self-improving-loop.ts:32	NOT an oracle. A demo that runs runMultishot over N personas.
tuner-agent origin/main	none — runJudge and types only	unaffected; those exports stay
npm, all 16 published @tangle-network/* at latest	zero hits for agent-eval/multishot, zero for runMultishot	4 of the 16 depend on agent-eval (agent-app 0.45.62, agent-knowledge 8.0.5, agent-runtime 0.137.0, sandbox-cli 0.8.7); examples/ is not in agent-runtime's files, which is why the tarball grep is clean and the source grep is not

tax-agent-capstable is a second checkout of tangle-network/tax-agent at the same commit, not a distinct consumer.

Why this blocks

agent-runtime's package.json runs typecheck as tsc --noEmit && pnpm run typecheck:examples, and tsconfig.examples.json includes examples. Deleting runMultishot turns agent-runtime's main typecheck red and removes arm A of a live experiment last touched in agent-runtime#868.

What shipped instead

The oracle is frozen and the consumers are migrated, which is the whole prerequisite:

• agent-eval#627 — @tangle-network/agent-eval/multishot/golden, 13 shot + 1 matrix scenario, mutation-proven load-bearing. Nothing deleted; runMultishot and runMultishotMatrix are untouched.
• gtm#902 and tax#488 move the three oracles onto the records. Both are draft until 0.146.0 publishes.

Migrating those oracles found four real accounting defects in the production graph engines that the old comparison could not see — missing costProvenance, no cell spend declared on a throw, driver retries billed at zero, and in tax a maxTurns <= 0 hang. Details in the two PRs.

To unblock the delete

One of:

1. Migrate examples/p1-parity/arms.ts arm A and examples/self-improving-loop onto a graph engine, or
2. Rule the P1 parity experiment closed and retire both examples.

(1) changes what the experiment measures — arm A exists to be the loop. That is a call for whoever owns the P1 result, not a mechanical migration.

[drewstone]

Census re-run, 2026-08-17 — five value imports stand. Deletion scope stays zero.

Answer first: the loop core still has 5 value imports on first-party default branches and 0 in any published package. Three are parity oracles with open migration PRs. Two are in agent-runtime/examples, are not oracles, and no PR migrates them. The golden records shipped in 0.146.0 retire the oracles. They do not retire the other two.

Method

Same mechanical derivation as the driver census, so the two are comparable.

1. Every directory under ~/code whose .git is a directory — 106 checkouts, 98 distinct repositories after collapsing by remote URL. A worktree clone's .git is a file, so worktrees drop out by structure.
2. Each is grepped on refs/remotes/origin/HEAD, never a local branch. Every repository with a hit was fetched first.
3. The grep is runMultishot\b and runMultishotMatrix\b with runMultishotGraph, runMultishotMatrixGraph and runGraphMultishot excluded — those are the replacement engines, not the core.
4. Each hit is opened and classified by whether the import binds a value or only types and primitives.
5. npm search @tangle-network returned 250 published packages. 10 declare a dependency on this one. All 10 latest tarballs were downloaded and grepped for agent-eval/multishot, runMultishot and runMultishotMatrix.

Result — value imports of the loop core

Repo	Branch	Site	Symbol	Class
gtm-agent	origin/master	eval/lib/multishot-graph.test.ts:19	runMultishot	parity oracle — gtm-agent#902 OPEN, CLEAN
gtm-agent	origin/master	eval/lib/multishot-matrix-graph.test.ts:27	runMultishotMatrix	parity oracle — gtm-agent#902 OPEN, CLEAN
tax-agent	origin/main	tests/eval/lib/graph-multishot.test.ts:18	runMultishot	parity oracle — tax-agent#488 OPEN, CLEAN
agent-runtime	origin/main	examples/p1-parity/arms.ts:36	runMultishot	not an oracle — arm A of the P1 parity experiment
agent-runtime	origin/main	examples/self-improving-loop/self-improving-loop.ts:32	runMultishot	not an oracle — a demo that runs the loop over N personas

Result — everything else that imports the subpath is unaffected

These bind types, judges and router helpers, never the loop core. None of them blocks a deletion of the core.

Repo	Sites	What they bind
gtm-agent	eval/lib/multishot-graph.ts:45, eval/lib/multishot-matrix-graph.ts:31, eval/matrix/matrix.ts:31, eval/matrix/multishot.ts:11, eval/monitoring/live-soak.ts:8, eval/scoring/multishot-judges.ts:7-8	runJudge, computeCellComposite, routerCompletion, requireRouterApiKey, estimateRouterCost, renderJsonFooter, MultishotDriverEmptyError, MultishotFatalToolError, types
tax-agent	tests/eval/lib/graph-multishot.ts:31, tests/eval/multishot.ts:22, tests/eval/lib/multishot-transcript.test.ts:9-10	routerCompletion, renderDimensions, renderJsonFooter, error classes, types
tuner-agent	src/lib/eval-adversary.ts:27, src/lib/eval-judge.ts:15, src/lib/eval-tools.ts:28	runJudge, JudgeConfig, JudgeDimension, tool types
agent-runtime	examples/p1-parity/offline.ts:22, examples/p1-parity/run-parity.ts:39	MultishotTransport, MultishotTransportRequest — types only

Result — published packages

0 of 10 reference the /multishot subpath or either loop symbol.

agent-app@0.45.62, agent-bench@0.8.12, agent-knowledge@8.0.8, agent-provider-tangle@0.12.3, agent-runtime@0.140.0, browser-agent-driver@0.36.0, run-capsule@0.4.1, sandbox-cli@0.8.10, starter-foundry@0.13.5, traces@0.11.6.

agent-runtime's tarball reads 0 because examples/ is not published. The tarball is the wrong instrument for this caller; the default-branch grep is the right one. That asymmetry is why both sweeps run.

What the golden records replace, and what they do not

0.146.0 (#627) shipped @tangle-network/agent-eval/multishot/golden — 13 conversation scenarios and 1 matrix scenario, verified present in the published 0.147.0 tarball. Each record freezes every transport request the reference engine's legs received and the value the run resolved or threw with, on a deterministic transport.

They replace the parity oracle. An oracle imports runMultishot, runs it beside the graph engine and diffs the two. With the records, a consumer asserts its own engine against the recording and imports no engine at all. That is exactly what gtm-agent#902 and tax-agent#488 do — both are titled "check the graph engine against the multishot golden records". When those two merge, the three oracle imports go to zero.

They do not replace examples/p1-parity/arms.ts. Arm A of that experiment is the loop, running live against a real provider under a conserved token pool. Its purpose is measurement, not regression detection. A recording cannot stand in for a live arm: the experiment exists to observe what the two engines do with real model output, and its own validity test asserts the real asymmetry between them — the graph settles at the first passing shot while runMultishot burns its whole budget. Replacing arm A with a recording would delete the measurement, not port it.

They do not replace examples/self-improving-loop. That is a runnable demo of the loop.

What blocks deletion

One thing, stated plainly: agent-runtime type-checks its examples. Its typecheck script is tsc --noEmit && pnpm run typecheck:examples, and tsconfig.examples.json covers examples/. Deleting runMultishot therefore turns agent-runtime's typecheck red at its next bump of this package. This is not a soft coupling that a lint rule could waive.

So the blocker is not the three oracles. Those are already solved and are waiting on two open PRs. The blocker is that the P1 parity experiment holds a live dependency on the loop, and the experiment is a research artifact whose value is that it runs the real thing.

The decision that would unblock it

The choice is about the P1 parity experiment, and it is not this repository's to make alone. Three options, ranked by what each costs:

1. Retire the P1 parity experiment. If the loop-versus-graph comparison has produced its result and is not going to be re-run, arm A and the demo both delete, the count goes to zero, and the core is removed in the next minor. Cheapest, and irreversible for that measurement.
2. Move the loop into agent-runtime's example. The example vendors the ~300 lines it needs and this package deletes its copy. The experiment keeps running live. The cost is a frozen fork of the engine inside an example directory, which drifts from whatever the graph engine becomes.
3. Keep the core and mark it experiment-only. No deletion. The core stays exported for the one live consumer, documented as such, and the deletion issue closes as "will not do while P1 runs".

Recommendation, stated as a recommendation and not a decision: option 1 if the P1 result is final, option 3 otherwise. Option 2 buys the least — it keeps the code alive in a place with less test coverage and no release discipline.

Until that is decided, deletion scope stays zero. The two open oracle PRs should still merge; they cut the blocker from five imports to two and make the remaining question a single clean one.