#2749 No first-class workflow primitive for spawning a permission-scoped agent session

Problem Statement

Workflow steps support four task types today: model_method, workflow, manual_approval, assert. None of these represent "spawn an agent worker session under an explicit tool-permission policy for this step."

When building a supervisor/worker agent pipeline (e.g. driving Claude Code non-interactively per lifecycle state, gating what tools/commands each state may use), the only available approach today is to hand-construct a raw shell command inside a command/shell model, e.g.:

claude -p "Implement ${{ inputs.workItemId }} per the design."
--settings policies/claude/implement.settings.json
--permission-mode dontAsk --permission-prompts none

This works, but has no schema support:

• swamp workflow validate can't confirm the referenced settings file exists or is well-formed.
• The effective per-step capability/permission set isn't queryable or surfaced anywhere the way guard/dependsOn surface control flow — it's buried inside an opaque shell string.
• Nothing distinguishes a permission-relevant flag from arbitrary shell text, so tooling (linting, workflow evaluate, reports) can't reason about it.

Proposed Solution

A step task type such as agent_session (alongside model_method / manual_approval) with structured fields, e.g.:

task: type: agent_session agent: claude settingsFile: policies/claude/implement.settings.json prompt: "Implement ${{ inputs.workItemId }} per the design."

swamp workflow validate could then confirm settingsFile exists and parses, and workflow evaluate/reports could surface the resolved capability set per step for audit, the same way step inputs are surfaced today.

Alternatives Considered

A community/official model type wrapping the agent CLI (e.g. @community/claude-session) with typed arguments for settingsFile and prompt would at least give schema validation on the settings file and prompt without requiring a new step task type — more achievable near-term if a new task type is out of scope, though it doesn't solve the "surface the resolved capability set" half of the problem.

Context

Ran into this building a supervisor/worker lifecycle workflow (design -> reproduce -> implement -> test -> review -> merge) where each state should run a Claude worker constrained to that state's permitted tools/commands.