What changed / requested
Extend Ultracode's experiment loop so it can learn or select the orchestration policy—workflow shape and role/tier assignment—instead of evolving only system-prompt/persona overrides inside a statically selected shape.
At minimum, make the boundary explicit in user-facing diagnostics: report which decisions came from the fixed shape catalog, which were authored by the root model, which came from fleet fitness, and why each worker model/tier was selected.
Why
Problem / observed behavior
In Graff 0.0.233, invoking ultracode injects the fixed shape catalog from src/shapes.zig and tells the root model to pick one shape based on task intent. The root then authors the concrete workflow JSON, and the workflow engine executes it.
The experiment/fleet scoring path fingerprints the system-prompt override and attributes judge fitness to that prompt genome plus niche metadata. Shape slot and provider class help partition scoring, but neither the orchestration graph nor the model/tier policy is the learned genome.
That makes the behavior look more learned than it currently is: Ultracode performs a scored multi-agent experiment, but the high-level topology and model routing are prescribed or inherited rather than selected from measured fitness.
A real v0.0.233 research run showed this distinction:
- Ultracode statically mapped the request to
sweep -> synthesize.
- The root authored four researcher tasks.
- All researchers, judges, and synthesis ran on the inherited
gpt-5.6-sol route.
- The four researchers shared the same prompt fingerprint, and judges scored prompt/persona fitness—not whether Sol, Terra, Luna, or a different workflow shape was the better quality/cost policy.
- An explicit standalone
subagent(model: "gpt-5.6-luna") smoke test succeeded, confirming Luna was available but was not selected by the Ultracode experiment.
The stale worker route observed in that session is separately covered by #371. This issue is about the broader learning boundary, not /model recomputation.
Expected behavior
One of these should be explicit:
- Learned orchestration: treat task class, workflow shape, role, and tier/model policy as experiment dimensions; record quality/cost/latency and allow the fleet to select policies from prior fitness, while retaining safe bootstrap defaults.
- Narrower contract: clearly describe Ultracode as fixed-shape orchestration with learned prompt/persona variants, and trace every static/root-authored/inherited decision so users do not infer that the fleet selected the shape or model.
A useful trace entry would include, per worker:
shape=sweep
role=researcher
tier=mid
resolved_model=gpt-5.6-terra
source=persona | workflow override | learned policy | session default | ladder
policy_or_genome_id=...
Reason for this approach
Prompt fitness alone cannot answer whether a different topology or cheaper model tier would have produced a better result. Keeping shape/tier as contextual niche metadata preserves fair prompt comparisons, but a separate policy layer can learn routing without incorrectly attributing model effects to the prompt genome (the integrity concern raised in #290).
Constraints / trade-offs
- Do not mix prompt and model effects into one fitness value without preserving attribution.
- Quality should be balanced against token cost and latency, or frontier-heavy policies will dominate quality-only judging.
- Sparse shape × role × tier cells need bootstrap defaults and hierarchical fallback.
- Explicit user model/provider pins must always outrank learned policy.
- Cross-provider routing must preserve existing consent boundaries.
Related issues
What changed / requested
Extend Ultracode's experiment loop so it can learn or select the orchestration policy—workflow shape and role/tier assignment—instead of evolving only system-prompt/persona overrides inside a statically selected shape.
At minimum, make the boundary explicit in user-facing diagnostics: report which decisions came from the fixed shape catalog, which were authored by the root model, which came from fleet fitness, and why each worker model/tier was selected.
Why
Problem / observed behavior
In Graff 0.0.233, invoking
ultracodeinjects the fixed shape catalog fromsrc/shapes.zigand tells the root model to pick one shape based on task intent. The root then authors the concreteworkflowJSON, and the workflow engine executes it.The experiment/fleet scoring path fingerprints the system-prompt override and attributes judge fitness to that prompt genome plus niche metadata. Shape slot and provider class help partition scoring, but neither the orchestration graph nor the model/tier policy is the learned genome.
That makes the behavior look more learned than it currently is: Ultracode performs a scored multi-agent experiment, but the high-level topology and model routing are prescribed or inherited rather than selected from measured fitness.
A real v0.0.233 research run showed this distinction:
sweep -> synthesize.gpt-5.6-solroute.subagent(model: "gpt-5.6-luna")smoke test succeeded, confirming Luna was available but was not selected by the Ultracode experiment.The stale worker route observed in that session is separately covered by #371. This issue is about the broader learning boundary, not
/modelrecomputation.Expected behavior
One of these should be explicit:
A useful trace entry would include, per worker:
Reason for this approach
Prompt fitness alone cannot answer whether a different topology or cheaper model tier would have produced a better result. Keeping shape/tier as contextual niche metadata preserves fair prompt comparisons, but a separate policy layer can learn routing without incorrectly attributing model effects to the prompt genome (the integrity concern raised in #290).
Constraints / trade-offs
Related issues
/modelchanges (separate bug)