onegw PR #110: verdict-driven combo reorder for agentloop tier routing

[linhdmn]

Context

todo.md was converted to issues (2026-09-20). Cross-repo dependency from agentloop's M2.x TypeSafe routing.

Open item

internal/router/router.go on feat/systemone-provider has the verdict-driven combo reorder (commit 9390e2b) but it is NOT on onegw master. Without this, onegw has a systemone provider but no leg for agentloop's tier selection to route to.

Refs: onegw PR #110, agentloop internal/experiments Route()

[linhdmn]

Update 2026-09-21

Verdict-driven combo reorder remains the onegw blocker. Framing update only:

• The verdict can come from System One (Jev or Laya) — UC-4 in docs/JEV-INTEGRATION.md (intent / complexity Choice+Score before spending planning tier).
• onegw still owns the combo table and leg pick; agentloop only sends tier + optional verdict metadata once the contract is agreed.
• Local Laya is the right default for this pre-route call (must stay cheap/fast).

[linhdmn]

The blocker was misattributed — the real gap was in agentloop and it is now fixed (#35).

This issue said onegw PR #110 is what stands between this project and tier routing. Reading the code, that is not the gap: the loop computed a tier per step and never sent it. took no model parameter and the client was constructed with a single combo, so CurrentTier was a field on a run record and nothing else.

Two further facts, both of which make #110 a second step rather than the first:

1. tierCombo emitted planning/execution/tiny, and this portfolio's onegw ships exactly one combo (dev). So two of the three tier names were combos upstream does not have — #110 could not have fixed anything while the names were fiction.
2. #110 is a verdict-driven reorder: it decides which leg answers given a combo. That is an optimisation of the leg, not the missing tier→combo hop. The hop is what was missing.

#35 lands the hop: ChatTier(ctx, tier, …), WithTiers tier→combo mapping, and tiers renamed to planning/execution/synthesis. Verified against a stub gateway — three calls to exec-combo, one to synth-combo.

Still open here, and this is the honest remainder: the 40–70% figure in §13.1 move 3 is unproven. It needs §11.4's paired parity suite (the same cases run both ways, paired per case). Until that runs, routing is a mechanism, not a measured saving. And #110 remains worth doing for the leg choice behind whatever combo is configured — but it is no longer blocking tier routing, and the issue should be re-scoped to that.

[linhdmn]

The blocker was misattributed — the real gap was in agentloop and it is now fixed (#35).

This issue said onegw PR #110 is what stands between this project and tier routing. Reading the code, that is not the gap: the loop computed a tier per step and never sent it. onegw.Client.Chat took no model parameter and the client was constructed with a single combo, so CurrentTier was a field on a run record and nothing else.

Two further facts, both of which make #110 a second step rather than the first:

1. tierCombo emitted planning/execution/tiny, and this portfolio's onegw ships exactly one combo (dev). Two of the three tier names were combos upstream does not have, so #110 could not have fixed anything while the names were fiction.
2. #110 is a verdict-driven reorder: it decides which leg answers given a combo. That is an optimisation of the leg, not the missing tier→combo hop. The hop is what was missing.

#35 lands the hop: ChatTier(ctx, tier, …), WithTiers tier→combo mapping, and tiers renamed to planning/execution/synthesis. Verified against a stub gateway — three calls to exec-combo, one to synth-combo.

Still open here, and this is the honest remainder: the 40–70% figure in §13.1 move 3 is unproven. It needs §11.4's paired parity suite (the same cases run both ways, paired per case). Until that runs, routing is a mechanism, not a measured saving. #110 remains worth doing for the leg choice behind whatever combo is configured, but it is no longer blocking tier routing, and this issue should be re-scoped to that.