Outcome-based model routing: per-dispatch outcome logging + automatic demotion for repeated failures

[NOVA-Openclaw]

Pattern source

Adapted from fulcra-tools ATC capability routing (https://github.com/ashfulcra/fulcra-tools, shared by Zonk 2026-07-27, approved for backlog by I)ruid).

Problem

agents.model and fallback_models are static. When a model repeatedly produces bad outcomes for a specific kind of work (e.g. a subagent model that keeps failing staging tests or mangling tool calls), nothing learns from it — the same model keeps getting dispatched until a human notices and edits the agents table. Related: #345 (model names not validated — silent spawn blocks).

Proposal

1. Outcome logging: after each subagent dispatch completes, record (agent, model, work kind, outcome: ok/failed/degraded, ref) — natural hook points: work_queue completion sweep and workflow step closure.
2. Demotion rule: N consecutive (or M-of-K) bad outcomes for a (model, work-kind) pair demotes that model for that kind of work — routing skips to the next fallback. Demotion is scoped (per work kind, not global) and expires/decays so a fixed upstream model can re-earn traffic.
3. Visibility: demotions are announced (agent_chat or #system-design) and queryable, never silent.

Fit with existing machinery

• work_queue already tracks dispatch + completion; add outcome + model columns or a dispatch_outcomes table.
• Pre-spawn lookup (UNIVERSAL/SUBAGENT_SPAWNING) consults demotion state when choosing model vs fallback_models.
• Keeps judgment in prose, bookkeeping deterministic: the demotion rule is pure SQL/script, no LLM in the loop.

Acceptance sketch

• Dispatch outcomes recorded for >95% of subagent runs (sweeper-enforced).
• A model with 3 consecutive failures on a work kind is skipped by the next pre-spawn lookup for that kind, with an announcement.
• Demotion state is inspectable and manually clearable.

[NOVA-Openclaw]

Fresh evidence for outcome-based routing (2026-07-29/30, SE run #521 step 5): kimi-k2.7-code died on context overflow TWICE in one night on the same large-repo (automated-strategies) implementation lane — first death lost all uncommitted work (747-line diff salvaged to patch, unverified), second death was lossless only because the respawn brief mandated commit-early/push-often. Both replacement dispatches on anthropic/claude-sonnet-5 completed cleanly (part 1b: 294 runs/1069 assertions/0 failures). This is now at least the 4th kimi large-task failure on record (lessons 76, 419, 585 + tonight). Under this proposal, two same-night overflow deaths should auto-demote kimi-k2.7-code for large-repo SE implementation dispatches.