Workflows: let agent() set the service tier of a seat

[jsanchezgarcia]

The workflow

I run a four-seat review panel as a global workflow. Three seats are Claude and Codex models on the default tier. The fourth is acp-cursor / grok-4.6 / xhigh, and I want that seat on Cursor's fast tier, the same selection Cursor lists as cursor-grok-4.6-xhigh-fast.

A workflow seat is an agent() call:

agent(prompt, { provider: "acp-cursor", model: "grok-4.6", reasoningLevel: "xhigh", label: "reviewer-grok" })

There is no field for the service tier, so the seat cannot ask for fast independently of the project's defaults.

What happens today

Reported environment: bb 0.42.1, desktop app, macOS 15, Cursor CLI 2026.09.08.

In my project, the remembered execution default is claude-code / claude-sonnet-5 / default, and the Grok workflow seat runs on the default tier. Spawning it separately with bb thread spawn and --provider acp-cursor --model grok-4.6 --reasoning-level xhigh --service-tier fast records serviceTier: fast in the thread log.

Source inspection on main at 3526458cd4bcc655cf08ed96052894e3773c2ad3 confirms the following. This source check did not independently rerun the reported live executions:

• The workflow parser and runtime validation allow provider, model, and reasoningLevel, but reject an added serviceTier property with Unknown agent option "serviceTier". The parser's allowed-option check makes this rejection explicit.
• validateSelection resolves the provider/model/reasoning selection and permission mode, but the child spawn passes no service tier.
• Remembered project execution settings apply only when their provider matches the child provider. With a Claude project default, the Cursor child therefore falls back to default; it does not inherit Claude's tier directly. See the provider match and tier resolution.
• bb stores one execution-default row per project. Eligible app-created threads update it, but threads reusing an environment and threads with a non-null originKind are excluded. See the update policy.
• The existing CLI spawn path already forwards an explicit tier. In the ACP bridge, buildAcpSessionParams constructs the model selection through this helper; the parameterized test covers explicit default and fast forwarding. cursorSessionParams is the test helper, not the production function.

What you would expect

agent() accepts an optional serviceTier next to the three selection fields, and the workflow runtime forwards it to the child spawn:

agent(prompt, { provider: "acp-cursor", model: "grok-4.6", reasoningLevel: "xhigh", serviceTier: "fast", label: "reviewer-grok" })

Proposed behavior:

• Validate an explicit tier against provider.serviceTiers when provider.capabilities.supportsServiceTier is true, with an error for an unknown tier consistent with unsupported reasoning-level errors.
• When omitted, preserve existing resolution: use matching-provider project defaults where applicable, otherwise the normal default tier.
• For providers without tier support, I would prefer rejecting an explicit unsupported request rather than silently ignoring it, but would welcome maintainer guidance on the intended behavior.

Likely implementation points are validation.ts, parser.ts, selectedExecutionSchema in service.ts, and the spawn call, with corresponding tests and workflow documentation. I can open a PR after feature sign-off and contributor approval.

Context and alternatives

• Setting the project default to Cursor fast can supply the tier, but a later eligible app-created thread on another provider can replace that default. This does not reliably pin one workflow seat to fast.
• Spawning the Grok seat by hand with bb thread spawn --service-tier fast in parallel with the workflow works, but the seat then loses the workflow's per-lane fallback and the panel result is assembled in two places.
• Naming Cursor's cursor-grok-4.6-xhigh-fast variant directly is rejected by the workflow's catalog validation; the selectable model is the grok-4.6 family. ACP-native model discovery lists effort-suffixed variants as separate models; only the modelCli path collapses them #2958 discusses related ACP catalog and effort-variant behavior, but does not request a workflow tier option.
• Expose sticky permission mode and service tier updates through the public SDK #3401 requested sticky tier updates for existing threads and was closed as not planned. It acknowledged that create/send already support serviceTier; it did not introduce the CLI spawn capability. This request exposes that existing spawn option through workflow agent() calls.

Checks

• I searched open and closed issues for the same request.
• If an agent wrote this, the body ends with > AGENT GENERATED.

AGENT GENERATED

[bb-slop-cop]

🚨 SLOP COP 🚨 · new-issue-autopilot

Applied Type: Feature, Priority: Medium, Effort: Low, and labels: plugins, workflows. No existing classifications needed preservation.

Adds a workflow execution-selection option using existing provider support; the scope is contained and a manual-spawn workaround exists. Verified the final Type is Feature. Reproduction, report, and PR skipped because this rule only fixes Bugs.

AGENT GENERATED