Adapt Sol 6.1 native multi-agent and workflow compatibility

This commit is contained in:
Kakan committed 2026-10-06 12:38:40 +08:00
1 parent 369384a3eb
commit 28b0bf4535
10 files changed
+81 -2

No files matched your search

+4
View File
@@ -29,6 +29,8 @@ Spawn only P/C work with a concrete output and useful parallel benefit. Prefer u
Choose the execution mechanism before a model: local tools for fixed commands/transforms, host-supported concurrent or async tools for independent I/O, and authorized children for useful independent reasoning or implementation. Waiting on a tool alone is not a reason to create an agent. Prefer a coherent outcome with acceptance over many tiny handoffs; bound ambiguity and ownership rather than prescribing every reasoning step.
GPT-6.1 Sol also supports native Responses Multi-agent beta. Its children share the request model/tools; the tiered route table below applies only where the host actually permits per-child selection. Read [Sol 6.1 adaptation](references/sol61-adaptation.md) before using native Multi-agent or reconciling it with host routing. Neither beta enablement nor this reference authorizes delegation.
For queue states, integration backpressure and proactive expert formations, read [fleet scheduling](references/fleet.md).
## Proactive Luna fleet
@@ -79,6 +81,8 @@ Read [runtime and configuration](references/platforms.md) only for configuration
Read [GPT-6 adaptation](references/gpt6-adaptation.md) when async execution, steering, context recovery or dynamic effort changes affect the workflow. API features are not automatically Desktop/CLI capabilities; use only exposed controls.
For 6.1-specific request compatibility, native tool-result attribution and compaction limits, read [Sol 6.1 adaptation](references/sol61-adaptation.md). Native Multi-agent's automatic compaction is not compatible with standard single-agent dynamic effort updates; choose a supported mode rather than combining every feature.
## Dispatch, observe, accept
Give a compact contract: goal/symptom; baseline and non-goals; read/write/forbidden paths and semantic owner; requested model/effort/working role and real isolation; permitted actions; acceptance; return evidence; escalation. Include a time/checkpoint budget when useful, but do not call it an enforced timeout unless the host supplies one.