Skip to content

Ultracode: learn orchestration and tier policy, not only prompt variants #372

Description

@justrach

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:

  1. 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.
  2. 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions