Skip to content

v0.8.68 remaining: make AgentProfile canonical for Fleet rosters #4111

Description

@Hmbown

Purpose

Fleet should inherit and configure canonical AgentProfiles, not maintain a parallel Fleet-only route/loadout/profile system. This issue is the durable cutover checklist from the 0.8.68 planning notes.

Reference branch/head at issue creation: work/v0.9.0-cutover @ fb89fc0c6.

Canonical tracker: #4175. Related: #4093, #3965, #4177, #4176.

Product truth

Fleet is where users configure their agent team, but Fleet should save and consume canonical AgentProfile records rather than Fleet-only role/model/loadout structs.

  • AgentProfile = role/persona + instructions + tool posture + provider/model route + thinking + inheritance rules.
  • Fleet = named roster of AgentProfiles (WHO — resolves roles → profiles; not a task runner) (scout, implementer, reviewer, verifier, custom roles).
  • A user should be able to assign, for example, DeepSeek V4 Flash Max Thinking to Scout, GLM 5.2 to Implementer, and DeepSeek V4 Pro to Reviewer, and have those saved as Fleet profile options beyond simply inheriting the main route.

Files to edit

  • crates/config/src/lib.rs
    • FleetProfile currently has slot, role, loadout, model, permissions, delegation, but no explicit provider/thinking route.
  • crates/tui/src/fleet/profile.rs
    • Currently defines an AgentProfile wrapper around FleetProfile plus TOML loader. Promote/enrich this into the canonical agent profile contract or move it to a non-Fleet module.
  • crates/tui/src/fleet/roster.rs
    • Should consume canonical AgentProfiles to assemble a Fleet roster.
  • crates/tui/src/fleet/worker_runtime.rs
    • resolve_fleet_route and related helpers should call the same route/profile resolver as direct agent(profile:) launches.
  • crates/tui/src/tools/subagent/mod.rs
    • Direct agent profile resolution and Fleet profile resolution must share one path.
  • crates/tui/src/tools/workflow.rs
    • Workflow task starts should record resolved profile/provider/model/thinking for receipts.
  • crates/tui/src/tui/views/fleet_setup.rs
    • /fleet setup should edit AgentProfiles: role, model provider, concrete model, thinking tier, tools/posture, and inheritance.
  • crates/tui/locales/en.json and docs
    • Remove user-facing model-class/loadout phrasing where it implies a separate Fleet concept.

Delete/retire list

Delete only after migration and tests pass:

  • Retire the Fleet-only TOML/profile structs inside crates/tui/src/fleet/profile.rs after moving their useful logic into the canonical AgentProfile module. The file may become a thin re-export during transition, but it should not remain a second profile system.
  • Remove user-facing Fleet loadout/model_class_hint framing from setup UI and docs. Keep compatibility parsing only as an internal migration shim if existing configs need it.
  • Do not delete Fleet execution durability: keep crates/tui/src/fleet/manager.rs, ledger.rs, executor.rs, and task_spec.rs.

Remaining checklist

  • Make AgentProfile the canonical saved actor contract.

    • Precedence tiers: explicit task/run args > profile route > role default > operator/session route.
    • One actor-contract type drives both /fleet and agent(profile:).
    • Unit test covers all four precedence tiers.
  • Extend profile schema and /fleet setup to save provider/model/thinking.

    • Add safe non-secret fields for provider, model, and thinking/reasoning_effort to config/TOML loader.
    • Make /fleet setup list models from all configured providers, not only the current provider.
    • Save enough route identity that a profile is unambiguous after restart.
  • Reuse direct agent resolution.

    • Fleet worker launch should reuse resolve_agent_profile_run or equivalent shared resolver and emit the existing AgentWorkerSpec/WorkerRuntimeProfile shape.
    • Receipts should show actual resolved_provider, resolved_model, route_source, and thinking.
  • Update copy and docs.

    • User-facing language: configure agent profile -> assign it to Fleet roster -> inherit or pin route.
    • Avoid model-class/loadout as the primary user concept.

Acceptance

  • A Fleet profile can pin provider + model + thinking independent of the parent session route.
  • Fleet and direct agent(profile:) launches resolve through the same code path.
  • Saved profiles round-trip TOML -> AgentProfile -> resolved route.
  • No parallel Fleet-only route representation remains except documented compatibility shims.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationenhancementNew feature or requestlane-fleetreliabilityReliability, flaky behavior, retries, fallbacks, and robustnesssubagentsSub-agent orchestration, lifecycle, and completion handlingtuiTerminal UI behavior, rendering, or interactionuxUser experience, interaction, or presentation polishv0.8.68Targeting v0.8.68workflow-runtimeWorkflow IR, executor, control flow, and replay runtime

    Projects

    Status
    Done

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions