Skip to content

[Feature]: Reconcile native sub-agent host attempts and skips with LoopX Turns #5051

Description

@huangruiteng

Problem / 问题

A Goal can enable multi_subagent, set a model preference, and configure max_children, but the native Codex child entry point is still controlled by the host/model. agent-context projects guidance and a configured ceiling; it does not observe live slots. After a Turn, LoopX cannot reliably tell whether a native child was started, deliberately skipped, rejected by host capacity, or never attempted. This makes a configured team look like an execution promise and leaves “why were so few children used?” unanswerable from authoritative receipts.

Current main at 41ba6f4d97ba2219f4e7d7e24f164cd34f85051c exposes the boundary: agent_context.py returns read_only: true and host_receipts_observed: false. Its optional --native-child-operation/outcome/count arguments add an observation to that one response, not a durable host receipt. subagent_context.ts defaults live_availability to not_observed and receipt_observation to not_supplied unless data is passed in. This is a host-boundary hypothesis, not a claim that LoopX should automatically launch up to the configured maximum.

中文:配置允许最多几个子 Agent,不代表当轮有几个空槽,也不代表应该启动几个。原生宿主调用未形成持久的“尝试/跳过/失败/结果”回执,导致用户和管理 Agent 无法区分合理的不派工与漏执行。

Minimal public reproduction / 最小复现

  1. In a synthetic Goal, enable multi_subagent with max_children: 3 and a native Codex model preference.
  2. Read agent-context --phase before_plan and --phase before_delegate for its coordinator.
  3. In the Codex host, start one native read-only child, or decide that no independent question warrants a child; read agent-context --phase after_delegate_result and the Goal Turn/history.
  4. The configured limit and guidance are visible, but no durable Turn-bound native attempt/skip/result record distinguishes these two cases. Supplying --native-child-operation spawn --native-child-outcome succeeded changes the read-only response only.

Observed against public source and LoopX CLI 1.2.0; no private Goal state or raw host logs are needed.

Desired outcome / 期望行为

Record a small, typed host-observed native-child decision for an admitted Turn: stable Turn/operation identity, entry point, attempted operation and actual outcome (including capacity rejection), or a bounded skip reason when a child was considered but not useful/possible. Project configured maximum separately from observed capacity and actual launched count. Parent review should reference the child outcome before calling its evidence adopted. Readback should be available through the existing shared projection; a missing host observation must remain unknown, never be inferred from configuration, prose, or a successful agent-context read.

Do not force max_children launches, create another scheduler/task database, expose prompts/results/local paths, or conflate native children with bound loopx delegation or peer activation. Ordinary monitor/no-parallel-work Turns should not get irrelevant child detail. Host failures should preserve useful parent work and apply a typed same-Turn retry rule.

Acceptance / 验收

  • Synthetic fixture covers: successful native spawn and parent adoption; deliberate no-spawn with a concrete reason; agent_thread_limit_reached with no same-Turn retry; missing host observation remaining unknown; disabled/unconfigured feature producing no unrelated packet.
  • Records survive Turn readback/restart and are idempotent by operation identity; duplicate reporting cannot inflate child counts or quota. No raw child content is persisted.
  • Existing CLI/managed Turn, frontend and Lark views consume the same typed projection where they display team activity; verify affected controls/readback and explain any unchanged entry point.
  • Preserve max_children as an upper bound and require independent, useful child work. Do not use a child count as an alpha or progress metric.

Related but distinct: #4339 tracks broad manager semantic handoff. This issue is the narrow native host observation boundary for temporary children.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions