agent-teams: spawn_teammate cannot select a model/provider

[ripley-xl]

Summary. spawn_teammate (Agent Teams) has no way to choose the member's LLM route. The child always inherits the Lead's latest request header, so one team cannot mix models — for example a cheap Flash worker next to a stronger Lead.

Why it happens (0.2.2-rc.1).

• SpawnTeammateRequest is { name, description, prompt, context, provider, signal }. provider is the subagent backend (spawn / fork), not an LLM route, and there is no agentOptions or model field.
• dsh-experimental-tool-agent-team passes that request through unchanged; its Config only has interrupt, freshProvider, forkProvider.
• ctx.subagents.startActivation then calls resolveChildAgentOptions(parent, request.agentOptions, depth), which starts from the parent's latest request header. With no agentOptions, the child inherits the Lead's provider/model.

Contrast. dsh-tool-subagent (the legacy subagent / subagent_fork tools) already supports this: modelSelection: true exposes provider / model / reasoning_effort, and its agentOptions config sets child defaults. The team tool never got the same treatment.

Impact. Teams are the place where heterogeneous models matter most (cheap parallel workers, a strong reviewer). Today the only workarounds are switching the Lead's model before spawning, or having a third-party plugin patch the registered spawn_teammate definition in place.

Proposed change. Add optional model selection to the team creation path, mirroring tool-subagent:

• extend SpawnTeammateRequest with optional agentOptions: { provider, model, reasoningEffort?, maxTokens? };
• add modelSelection / agentOptions config to dsh-experimental-tool-agent-team, or always expose optional provider / model / reasoning_effort parameters on spawn_teammate;
• pass them through to startActivation, and validate explicit routes against the Session's subagentModelSelectionPolicy the way assertAllowedModelSelection does.

Note that a route change on a context: "fork" member breaks provider-side prefix reuse, so it should stay opt-in.

Environment. DSH 0.2.2-rc.1 (Desktop), macOS. Happy to test a patch.

[XuShan0425]

Independent confirmation on Windows Desktop 0.2.2-rc.1 — same root cause, and the seam below the two hops already works.

Where the route is dropped (2 hops, not 3):

1. dsh-experimental-tool-agent-team — spawn_teammate exposes name / description / prompt / context only; execute forwards { name, description, prompt, context, provider, signal } to the roster.
2. dsh-experimental-agent-team — spawnAdmitted() calls ctx.subagents.startActivation({ delivery: "parent", childId, provider, label, request: { prompt, parent } }). No agentOptions on the request.
3. dsh-subagent / dsh-subagent-spawn-in-process — already fine: capabilities = { agentOptions: true, agentPreset: true, outputSchema: true, depthLimit: true }, documented as "agentOptions (merged over the parent route)", and the activation path already resolves child options from request.agentOptions before falling back to the parent header.

So no new durability or route-resolution machinery is needed — hops 1–2 just need to carry the field.

Minimal backward-compatible shape:

• tool: one optional model (optionally reasoningEffort), omitted ⇒ inherit the Lead route exactly as today;
• roster: SpawnTeammateRequest gains optional agentOptions, forwarded verbatim into startActivation's request;
• gate explicit routes through the same assertAllowedModelSelection / subagentModelSelectionPolicy used by tool-subagent, so one session switch governs both surfaces;
• memberView() already reports live.options.model when present, so list_agents and the roster row show the real route with no UI work.

Two smaller notes from this install:

• context: "fork" on a different route defeats provider-side prefix reuse, so the route should stay a creation-time, opt-in field — as you say.
• If model becomes a member identity field, decide whether a cold-resumed member must still match the recorded route; otherwise a persisted roster row can be resumed onto a different model silently. Implicit inheritance sidesteps the question, but then the roster cannot promise a route.

Worth converging with the complete implementation already offered in #8324 (feat/agent-team-teammate-model-selection, 4 commits, unit tests + docs, live-verified on deepseek-flash + glm-5.3-flash). If that lands, this report is just the 0.2.2-rc.1 reproduction record.

Happy to test a patch on Windows Desktop 0.2.2-rc.1.

[Sicaduj]

That third-party plugin workaround now exists: https://github.com/Sicaduj/dsh-agent-soul

spawn_teammate gains an optional agent_type, and each teammate's Markdown Agent Soul can declare model / provider / reasoning-effort (validated against the live provider catalog, applied to the child, and recorded in a durable binding so cold resume keeps the route). Omit model and it inherits the Lead exactly as today. It also adds per-soul personas, enforced tool matrices, slash commands, a Settings → Agent Soul editor, and an optional /orchestrate mode.

It's a stopgap that replaces the tool-agent-team row — the two-hop carry through SpawnTeammateRequest/startActivation is still the right native fix. Needs the Agent Teams bundle and Node >= 24.9; install notes: https://github.com/Sicaduj/dsh-agent-soul#requirements-and-install

[Sadrak2017]

Optional model selection also needs an observable dispatch record. If a requested route becomes unavailable after a provider-catalog change, silently inheriting the Lead would change the teammate's cost and evaluation conditions. In our work on Sinaps Studio at SinapsData, model comparison makes that distinction important. Could each attempt record the requested route, actual route and any fallback reason, with an unavailable explicit selection failing visibly unless fallback was separately authorized?