# Sol 6.1 multi-agent beta: delegation is another execution contract

Sol introduced a multi-agent beta, but useful delegation still depends on dependency ordering, bounded worker results and an explicit merge condition.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-29
Original announcement: https://developers.openai.com/api/docs/changelog
Canonical URL: https://retrivium.ai/retrospectives/sol61-multiagent-boundary/

Delegation can shorten a task's critical path while increasing the number of states that must be reconciled. Sol's multi-agent beta should therefore be read as another execution contract, not as a promise that dividing work automatically creates a correct combined result.

## A new control followed two model releases

Astra entered the [API chronology](https://developers.openai.com/api/docs/changelog) on September 3, 2026. [Sol and Luna](https://openai.com/index/introducing-gpt-6-sol-and-luna/) followed on September 22, 2026. On September 29, 2026, the changelog introduced the [Sol upgrade](https://openai.com/index/introducing-gpt-6-1-sol/) and multi-agent beta in Responses. The new capability allowed model delegation within a request; it did not define the application's own rules for accepting combined work.

## Division creates explicit dependencies

Consider an illustrative maintenance task split between configuration inspection and code modification. The code worker needs the inspection's conclusion before choosing a compatible change. Running both immediately may create contradictory assumptions rather than useful parallelism.

Independent tasks can proceed together, but dependencies still need representation. A parent should receive a bounded result with source identity, conclusion and uncertainty. Merely receiving a confident child summary does not establish that the underlying evidence was available or that both workers examined the same revision.

## Authority does not travel through a summary

A worker can propose a change without acquiring permission to apply every consequence it notices. The application's existing action boundary remains relevant when the model delegates. Treat a child result as evidence or a proposed artifact according to its role, rather than as a new source of authority.

The same separation applies to tool results. A parent reading that a child completed a test needs the actual outcome and tested state where the workflow requires verification. A summary can improve coordination without replacing the acceptance record.

## Test the merge rather than only the workers

Prepare a fixture where independent inspection produces a valid finding, while another branch encounters a missing dependency. The final result should preserve the blocked branch rather than declare the whole task complete because one worker succeeded.

Then introduce an incompatible assumption across two successful branches. Inspect whether reconciliation detects it before a combined artifact is accepted. These illustrative cases test coordination behavior without inventing a speedup or assuming that more workers always reduce elapsed time.

## What the beta made possible

The beta expanded the execution structure available to an application. Its practical value depends on useful decomposition, reliable return objects and an explicit merge condition. Model capability and coordination correctness remain different properties.

A defensible adoption record explains what was independent, what waited, what each worker could do and how the combined result was judged. That makes delegation an inspectable engineering choice instead of an unqualified multiplier attached to the model name.

## Related reading

- [Model proposals and application execution](/journal/openrouter-tool-calling/)
- [Tracing related execution events](/journal/provider-request-id-trace-context/)