scope.spawn rejects an authored profile one missing field per call; a director burns four round trips learning the shape

[drewstone]

What happened

A director on tangle-sandbox (opencode harness, deepseek/deepseek-v4.1-flash) authored a worker profile for agent_runtime_coordination_spawn_worker without the profile-authoring skill in its resources. It took eight rejected calls, each naming exactly one defect, before the ninth was admitted:

Calls	Rejection
2	invalid-profile: Unrecognized key: "systemPrompt" (this one came with issues[])
2	MCP error -32000: scope.spawn: AgentProfile.harness must be explicit before execution
2	MCP error -32000: scope.spawn: AgentProfile.model.default is missing; execution requires a concrete model
2	MCP error -32000: scope.spawn: AgentProfile.model.provider must be explicit before execution

Each pair is the director retrying the same profile for its two intended workers. 07:12:26Z to 07:13:50Z on 2026-09-23, run e1-metering-20260923-e01-recursive (discovery-lab #936 carries the root stream; the ten spawn results are root-stream.jsonl seq 136 to 159).

Why it matters

The first rejection is the only one that returns a structured issue list, and it stops at the first schema failure. The three scope.spawn checks (harness, model.default, model.provider) run after schema validation, one at a time, and surface as opaque MCP errors with no path. A director that does not already know the AgentProfile execution contract cannot learn it in fewer than N calls for N missing fields, and each call is a model turn with the full profile in it.

The measured cost here was small (eight turns, about 90 seconds) because the profile was tiny. The failure class is the same as #1274: the director is told something is wrong without being told what would be right.

Ask

Validate the execution contract as a whole in scope.spawn and return every failing path in one issues[] list, the same shape the schema rejection already uses, so one rejection is enough to author a valid profile. The docs for spawn_worker could also state the four required execution fields (harness, model.provider, model.default, and no systemPrompt) in the tool description, which is the only text a director is guaranteed to see.

Filed from discovery's E1 metering; the registration side fix (carrying the profile-authoring skill) is in discovery-lab, but a skill is a teaching aid and the tool should still fail in one round.

[drewstone]

Second run, same ladder, with the profile-authoring skill attached this time.

e1-metering-20260923-e02-recursive (2026-09-23, 07:43Z to 07:58Z; discovery-lab #940 carries the root stream) had resources.skills = [profile-authoring (8,372 chars), harness-capabilities] on the root profile. Its 16 spawn_worker calls:

Calls	Rejection
3	invalid-profile: Unrecognized key: "systemPrompt"
3	scope.spawn: AgentProfile.harness must be explicit before execution
3	scope.spawn: AgentProfile.model.default is missing
3	scope.spawn: AgentProfile.model.provider must be explicit before execution
3	admitted (s0, s1, s2)
1	budget-exhausted: 20 iterations free, spawn asked for 60

The director's first draft still carried systemPrompt and no harness or model, exactly as in the run without the skill, so attaching the authoring contract as a skill did not change what it wrote (whether the harness surfaced the skill is not established from the stream). Two runs, 20 of 26 spawn calls spent learning four fields one at a time. The one-round validation in the ask above is the fix that removes it regardless of what the director read.