delegate_task: optional resultSchema with a parsed typedResult

[shelomo]

delegate_task can require a typed result

Problem

A delegated task's result is a string: the child's last chat message, stored as task.result and returned as summary. When the parent needs values from it, the model re-reads prose and re-types fields. In a controlled rerun on 2026-10-06, Codex parents asked to pass child fields through compactly corrupted escaped strings in 2 of 2 cases (\( became \\(), while the child's own output was byte-exact. The providers already solve this: the Claude Agent SDK takes outputFormat: { type: "json_schema" } and returns structured_output; Codex turn/start takes outputSchema. T3 uses that path today for commit messages and thread titles, but not for delegation.

Proposal

delegate_task accepts an optional resultSchema (JSON Schema). The schema rides on the child thread (delegatedResultSchema), so every adapter reads it from the turn input it already receives. Claude maps it to outputFormat and publishes structured_output as the final assistant message; Codex sets outputSchema on turn/start. At publication the orchestrator parses the child's final answer into resultValue next to the existing result text. task_status and the wait-mode result expose it as typedResult: { value } | null. Adapters that cannot enforce a schema report turns.supportsOutputSchema unset, orchestrator_capabilities shows canEnforceResultSchema: false, and delegate_task fails fast with result_schema_unsupported instead of degrading to prose.

Nothing changes when resultSchema is omitted. No new table, no summarizer, no new tool.

Scope

• Contracts: optional resultSchema on the input and command, optional resultSchema and resultValue on the subagent record, optional delegatedResultSchema on the thread, required typedResult on the MCP result, canEnforceResultSchema on the capability entry, one new failure code, one optional turn capability flag.
• Server: Claude and Codex adapters, the delegated task request and publication paths in the orchestrator, the MCP service, tool descriptions, one sentence in the injected orchestration instructions.
• Tests: contracts, adapter parameter mapping for both providers, parser, child-thread inheritance, and an MCP integration case covering the typed round trip and the unsupported-provider rejection. Server and contracts typecheck clean; scoped lint shows only pre-existing warnings.
• Out of scope, as follow-ups: carrying the value in the completion wake, a ranged task_result read for oversized results, and parent wakes for blocked children.

Questions for maintainers

1. Is resultSchema on delegate_task the right surface, or should it live on target?
2. Should Cursor and OpenCode get a server-side extraction fallback in this PR, or stay result_schema_unsupported until their SDKs expose a native schema option?
3. Any objection to the child thread carrying the schema so follow-up turns on that child stay constrained?

---

Drafted with Claude Fable 5.1 via Claude Code in T3 Code on behalf of the poster. Measurements come from a local controlled rerun on 2026-10-06; the implementation described exists as a local branch and will be pushed as a PR only if the scope is agreed here.