Repository navigation
feat(managed-agent): H4e child teams and detach to an independent durable owner #13745
Description
Note
Update 2026-10-10 — E1 is delivered by #13811 (H4e-a); E3 moves to H4e-b and E2 to the Detach follow-up.
- E1 is done. feat(managed-agent): H4e-a team record contract #13811 (merged as
6b7564606d) lands the record half of this slice as H4e-a: theteam_state,team_task,team_messageandteam_planbodies, validated in TypeScript and Java against the sharedmanaged-team-record/1fixtures, with commit-time rules that bind every team record to its lead Session. All four domains stay disabled for submission. Design: English · 简体中文. - E3 moves to H4e-b, the runtime half, together with the rest of what the H4a delivery map gives H4e: the seven team tools on the managed path, the managed Agent tool's
namefor teammate routing (H4b decision 11), the mailbox relay and member-side delivery, plan resolution through D6 actions,requestMemberShutdown, legacy team import, and enablement after a physical acceptance pass. The design's open questions 1–4 list what H4e-b still has to decide. - E2 is not H4e. Detach stays the separate "Detach" row of the H4a delivery map, as the H4b and H4c designs already say, and the detach-owner question (a tenant-level retention policy or the root Session authority) moves with it. The H4 design's open question 4 now points there instead of H4c. The Detach follow-up has no issue yet.
- The triage's three questions are answered in that design: the detach owner goes with the Detach follow-up; teammate routing is H4e-b's; and the team domains are the durable form of the Legacy team model, not a parallel one.
- This issue stays open for H4e-b.
2026-10-10 更新 —— E1 已由 #13811（H4e-a）交付；E3 移到 H4e-b，E2 移到 Detach 后续工作。
- E1 已完成。 feat(managed-agent): H4e-a team record contract #13811（合入为
6b7564606d）以 H4e-a 的形式落地本片的记录那一半：team_state、team_task、team_message与team_plan四个记录体，在 TypeScript 与 Java 中按共享的managed-team-record/1fixture 校验，并带有把每条团队记录绑定到其 lead Session 的提交时规则。四个 domain 均保持不开放提交。设计：English · 简体中文。 - E3 移到 H4e-b，即运行时那一半，连同 H4a 交付地图分给 H4e 的其余内容：managed 路径上的七个团队工具、用于 teammate 路由的 managed Agent 工具
name（H4b 决策 11）、mailbox 中继与成员一侧的投递、经由 D6 action 的计划裁决、requestMemberShutdown、旧团队导入，以及经过实机验收后的启用。设计中的开放问题 1–4 列出了 H4e-b 仍需决定的事项。 - E2 不属于 H4e。 detach 仍是 H4a 交付地图中单列的 "Detach" 一行，H4b 与 H4c 的设计也都这样写；detach 后的所有者问题（租户级保留策略，或 root Session authority）随之移走。H4 设计的开放问题 4 已改为指向那里，而不再指向 H4c。Detach 后续工作目前还没有 issue。
- 分诊留下的三个问题已在该设计中回答： detach 所有者随 Detach 后续工作走；teammate 路由归 H4e-b；团队 domain 是 Legacy 团队模型的持久形态，而不是并列的另一套。
- 本 issue 保持打开，继续跟踪 H4e-b。
Note
Update 2026-10-10 — the mailbox moved here from #13744, and the child_run kind dispatch was refactored.
- E1 now covers the mailbox as well as the team domains. The maintainer's 2026-10-09 scoping of H4d moved feat(managed-agent): H4d durable peer messages between child and parent Sessions #13744's D3 (the mailbox) into this slice, which is what the child-agents design implied by pairing "team domains and mailbox" in one later slice. feat(managed-agent): H4d durable peer messages between child and parent Sessions #13744 keeps only
continueChildRunand durable delivery, and its delivery depends on the mailbox living here. The boundary question this issue raised — mailbox in H4d or H4e — is settled: H4e. - Read E2's detach work against the refactored kind dispatch. refactor(managed-agent): classify child Session run kinds by name #13779 (
refactor(managed-agent): classify child Session run kinds by name, merged 2026-10-10) changed the shape this issue described:parseChildRunnow routesshelltoparseChildShellRecordand bothchild_agentandworkflowto one sharedparseChildSessionRun(value, kind), atpackages/core/src/managed-runtime/managed-child-run-record.ts:345-352. The substance of E2 is unchanged —detachstill has no occurrence in that file or inmanaged-child-operations.ts— but a detach implementation now has one shared session-run parser to extend rather than a per-kind one. - Re-checked at
main=9ec44d45c4(Flyway V57, contract v1.38.0):MANAGED_SESSION_ENABLED_DOMAINSholds 13 domains,MANAGED_EXTENSION_RECORD_BODIES12 bodies, and thechild_runkind allowlist is still['child_agent'].
2026-10-10 更新 —— mailbox 从 #13744 移到本片，且 child_run 的 kind 分发已被重构。
- E1 现在同时覆盖 mailbox 与 team 记录域。 维护者 2026-10-09 对 H4d 的定范围把 feat(managed-agent): H4d durable peer messages between child and parent Sessions #13744 的 D3（mailbox）移进了本片，这正是 child-agents 设计把「team domains and mailbox」并列为同一个后续切片所隐含的归属。feat(managed-agent): H4d durable peer messages between child and parent Sessions #13744 只保留
continueChildRun与持久投递，而其投递依赖 mailbox 落在这里。本 issue 提出的边界问题 —— mailbox 归 H4d 还是 H4e —— 已裁定：H4e。 - E2 的 detach 工作要对着重构后的 kind 分发来做。 refactor(managed-agent): classify child Session run kinds by name #13779（
refactor(managed-agent): classify child Session run kinds by name，2026-10-10 合入）改变了本 issue 描述的形状：parseChildRun现在把shell路由到parseChildShellRecord，而把child_agent与workflow两者都路由到一个共享的parseChildSessionRun(value, kind)，位置在packages/core/src/managed-runtime/managed-child-run-record.ts:345-352。E2 的实质未变 ——detach在该文件与managed-child-operations.ts里仍然零命中 —— 但一个 detach 实现现在要扩展的是一个共享的 session-run parser，而不是逐 kind 的 parser。 - 已在
main=9ec44d45c4（Flyway V57、契约 v1.38.0）复核：MANAGED_SESSION_ENABLED_DOMAINS有 13 个域、MANAGED_EXTENSION_RECORD_BODIES有 12 个记录体，child_run的 kind 白名单仍是['child_agent']。
What would you like to be added?
Slice H4e of the Stage H4 delivery map: child teams, and detach to an independent durable owner.
#13505 defines the map as six slices — "H4a record contract, H4b child Session runtime, H4c workflow kind, H4d durable peer messages, H4e teams, and H4f public task cancel (shared with H5)". H4a and H4b are merged; H4e has no issue and no PR.
| Item | Deliverable | Exit check |
|---|---|---|
| E1 — team domains | The team record domains the child-agents design names, on the same extension-record pipeline H4a/H4b use, with their own bodies, validators and transition witnesses in the shared fixture corpus. | TypeScript and Java produce and refuse identical team chains from the shared fixtures; a team domain stays out of MANAGED_SESSION_ENABLED_DOMAINS until its own slice enables it, following the deployment-order rule H0c established (the server gains the bodies before any writer commits). |
| E2 — detach to an independent durable owner | A child can be detached from its parent into an independent durable owner, so that it outlives the parent's Session and its result is still accountable. | A detached child survives its parent's close and is still observable and cancellable; a detach request with no independent durable owner available is refused, not silently downgraded to a still-parented child. |
| E3 — close cascade under teams | The close cascade H4b built for parent→children extends to team membership: closing a team's owner settles its members by the same rules (cancel by default, detach where E2 allows, orphaned results recorded and never fed to a model). | Closing an owner cancels its non-detached members, never resurrects for an orphaned result, and leaves each member's terminal fact separately observable. |
E2 is the item #13550 explicitly deferred: its out-of-scope list names "detach to an independent durable owner". The child-agents design already states the rule this slice has to satisfy — "detaching without an independent durable owner is refused" — so the refusal semantics are designed; what is missing is an owner to detach to.
Why is this needed?
Detach is zero-implementation today, not partial. detach has no occurrence in either packages/core/src/managed-runtime/managed-child-run-record.ts or managed-child-operations.ts, so neither the operation nor its refusal exists yet.
The consequence is that a child's lifetime is strictly bounded by its parent's. H4b already commits the close cascade in one direction — "Closing a parent cancels its non-terminal children through the ordinary close pipeline before the Harness closes, and a result that reaches a closing or closed parent is marked orphaned — recorded, never fed to a model, never reviving the parent" — which is the correct conservative behaviour, but it means any long-running child dies with its parent. Teams and detach are what let work outlive the Session that started it, which is the property Stage H exists to provide (per #12827, on the Managed path the Runtime can be reclaimed and the Harness replaced, so lifetime cannot rest on a process).
Teams also carry the same recovery discipline the rest of Stage H demands, and inherit it cheaply if built on the H4a bodies: each membership fact separately committed, separately killable and replay-safe, with every failure resolving to a proven classification rather than a guessed success.
Additional context
Part of #12380, Stage H under #12827. Related: #13505 (H4a, the two record bodies and the six-slice map), #13550 (H4b, the runtime, the close cascade and the deferred detach), the H4d peer-messages issue filed alongside this one (its mailbox may be the delivery mechanism team messages use — the two slices should agree on it rather than each inventing one), #13265 (H3, whose shell kind gate stays closed), #12827 (Stage H tracker).
Out of scope: the workflow kind, isolation policies and child quotas (H4c, filed alongside); the continueChildRun/queryChildRun operations (H4d, filed alongside); public task cancel and the children's task-event/output-cursor streams (H4f, filed alongside); cross-workspace children, which the child-agents design lists as a later H4 slice separate from teams; custom subagent_type definitions, which #13550 assigns to D8b/D8c; anything on public or files-profile surfaces.
Verification note: the absence of detach in managed-child-run-record.ts and managed-child-operations.ts was checked at main = 55ee50d34e (Flyway V54, contract v1.33.0). The team domains named here come from docs/design/2026-10-04-managed-child-agents.md, which lists "team domains and mailbox" among the later H4 slices it does not schedule; that document gives no team body shape, so E1 needs a design pass before implementation. Re-check both at the current head before starting.
中文
希望增加什么？
阶段 H4 交付图里的 H4e 切片：child teams，以及 detach 到一个独立的持久所有者。
#13505 把交付图定义为六片 ——「H4a record contract, H4b child Session runtime, H4c workflow kind, H4d durable peer messages, H4e teams, and H4f public task cancel (shared with H5)」。H4a 与 H4b 已合入；H4e 既无 issue 也无 PR。
| 项 | 交付内容 | 验收 |
|---|---|---|
| E1 — team 记录域 | child-agents 设计点名的 team 记录域，走 H4a/H4b 使用的同一条 extension-record 流水线，有自己的记录体、校验器与迁移见证，并进入共享 fixture 语料。 | TypeScript 与 Java 从同一份共享 fixture 产出并拒绝完全相同的 team 链；team 域在它自己的切片启用之前不进入 MANAGED_SESSION_ENABLED_DOMAINS，遵循 H0c 确立的部署顺序规则（server 先于任何 writer 获得记录体）。 |
| E2 — detach 到独立持久所有者 | 一个 child 可以从其父 detach 到一个独立的持久所有者，使其在父 Session 之后仍然存活，且其结果仍可问责。 | 已 detach 的 child 能在其父关闭后存活，并且仍可观察、仍可取消；在没有可用独立持久所有者时，detach 请求被拒绝，而不是被静默降级为一个仍依附于父的 child。 |
| E3 — teams 下的关闭级联 | H4b 为父→children 建立的关闭级联扩展到 team 成员关系：关闭一个 team 的所有者按同一套规则结算其成员（默认取消、在 E2 允许处 detach、孤儿结果被登记且绝不喂给模型）。 | 关闭所有者会取消其未 detach 的成员，绝不因孤儿结果而复活，并让每个成员的终态事实可分别观察。 |
E2 是 #13550 明确推迟的那一项：它的 out-of-scope 清单点名了「detach to an independent durable owner」。child-agents 设计已经写下了本片必须满足的规则 ——「detaching without an independent durable owner is refused」—— 所以拒绝语义是设计好的；缺的是一个可以 detach 过去的所有者。
为什么需要？
detach 今天是零实现，不是部分实现。detach 在 packages/core/src/managed-runtime/managed-child-run-record.ts 与 managed-child-operations.ts 里都没有出现，所以这个操作和它的拒绝都还不存在。
后果是一个 child 的寿命被其父严格限定。H4b 已经在一个方向上提交了关闭级联 ——「Closing a parent cancels its non-terminal children through the ordinary close pipeline before the Harness closes, and a result that reaches a closing or closed parent is marked orphaned — recorded, never fed to a model, never reviving the parent」—— 这是正确的保守行为，但它意味着任何长时间运行的 child 都会随其父一起死亡。teams 与 detach 才是让工作活得比启动它的 Session 更久的东西，而这正是 H 阶段存在的理由（按 #12827，在 Managed 路径上 Runtime 可被回收、Harness 可被替换，所以寿命不能建立在进程上）。
teams 还带着 H 阶段其余部分要求的同一套恢复纪律，而且如果建在 H4a 的记录体上就能廉价地继承它：每个成员关系事实分别提交、分别可杀、可重放安全，每种失败都解析为一个被证明的分类，而不是一次猜测的成功。
补充信息
属于 #12380，阶段 H 在 #12827 下跟踪。相关：#13505（H4a，两个记录体与六片图）、#13550（H4b，运行时、关闭级联与被推迟的 detach）、与本 issue 同时提交的 H4d peer 消息 issue（它的 mailbox 可能正是 team 消息使用的投递机制 —— 两片应当就它达成一致，而不是各自发明一个）、#13265（H3，其 shell kind 门禁仍关闭）、#12827（阶段 H 跟踪）。
不在范围内：workflow kind、隔离策略与 child 配额（H4c，同时提交）；continueChildRun/queryChildRun 操作（H4d，同时提交）；公开任务取消与 children 的 task-event/output-cursor 流（H4f，同时提交）；child-agents 设计列为独立于 teams 的 H4 后续切片 cross-workspace children；#13550 划给 D8b/D8c 的自定义 subagent_type 定义；任何公开面或 files-profile 面上的改动。
核实说明：detach 在 managed-child-run-record.ts 与 managed-child-operations.ts 中的缺失已在 main = 55ee50d34e（Flyway V54、契约 v1.33.0）上核实。这里点名的 team 域来自 docs/design/2026-10-04-managed-child-agents.md，它把「team domains and mailbox」列在自己未排期的 H4 后续切片中；该文档没有给出 team 记录体的形状，所以 E1 在实现前需要一轮设计。开工前请把两者都在当前 head 上再核一次。
Activity
qwen-code-review-bot commentedon Oct 9, 2026
✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.
✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。
qwen-code-review-bot commentedon Oct 9, 2026
Triage
type/feature-request,category/core,scope/core,scope/session-management,roadmap/multi-agent,priority/P2,daemon,need-discussion,status/ready-for-human中文说明
type/feature-request,category/core,scope/core,scope/session-management,roadmap/multi-agent,priority/P2,daemon,need-discussion,status/ready-for-humanAnalysis
Every factual claim in the issue re-checked at
main=669b2f0fThe issue was verified at
55ee50d34e; main has moved since, so all of it was re-checked. Nothing drifted.detachstill has no occurrence in eithermanaged-child-run-record.tsormanaged-child-operations.ts. The operation surface there is launch / dispatch / attach / settle-completed / fail / stop-requested / cancel / delivery / acceptance / acceptance-consumed — no detach, and no team bodies. Confirmed: zero implementation, not partial.V54__managed_child_lineage_relay.sql; the OpenAPI contract is still 1.33.0. The author's baseline markers still hold at head.team_state,team_task,team_message,team_planare registered in the closedMANAGED_SESSION_DOMAINSindex and absent fromMANAGED_SESSION_ENABLED_DOMAINS— E1's exit check describes the current state accurately.Direction: aligned
This is planned work on an accepted staged delivery (#12380 → #12827 → the six-slice map in merged #13505), the capability gap is evidenced rather than theoretical, and the out-of-scope list is unusually disciplined. Accept for exploration.
Three decisions that need a human before implementation
1. E2's owner is an unresolved two-way choice, not just missing code. Open question 4 of the child-agents design reads: "What durable owner a detached child takes (a tenant-level retention policy, or the root Session authority) is left to H4c; the close path only enforces that one exists." Two things follow. The doc routes the question to H4c, but #13505's map reassigned H4c to the
workflowkind — so the question landed on H4e and the design doc was never updated to say so. And it interacts with E2's own exit check: if the owner is the root Session authority, a detached child still dies when the root Session closes, which does not satisfy "outlives the parent's Session" in the general case. The tenant-level retention policy looks like the only one of the two candidates that meets E2 as written — worth stating explicitly rather than leaving to the implementer.2. The merged H4b design assigned "teammate routing" to H4e, and this issue never mentions it. H4b decision 11: the managed Agent tool takes
description,promptandrun_in_backgroundand deliberately noname, because "v1 has noname: teammate routing is H4e's, and an inert name would be a dead switch". E1–E3 are all record- and runtime-level, so that inheritance currently sits in the gap between the two documents. H4e should either own the managednameparameter as an explicit exit check or re-defer it with a reason — silently dropping it would leave H4b's stated rationale unfulfilled.3. A full in-process Agent Team implementation already exists, and the four registered domain names map 1:1 onto it.
packages/core/src/agents/team/carriesTeamManager,mailbox,board-tasks,tasks,asks,identity,team-eventsandleaderPermissionBridge; beside it are theteam-create/team-delete/team-plan-approval/task-create|list|update|stop/send-message/list-agentstools, theteam-memory-*modules and the bundledcoordinateskill. The correspondence is direct:team_state↔ team lifecycle,team_task↔ board/task tools,team_message↔mailbox/send-message,team_plan↔team-plan-approval.team_planis already a value inMANAGED_SESSION_ACTION_SOURCES, so some coupling is baked in regardless. E1 needs to state whether the Managed team domains are the durable projection of that existing model — same vocabulary, same lifecycle — or an independent parallel one. The design's "Legacy subagent changes" non-goal is a separation precedent, but it is scoped to the Agent tool, not to the team surface. This existingmailboxis also a third party to the messaging overlap the issue already (correctly) flags with H4d.Three smaller things to pin down in the same design pass
detachis already taken in this runtime.managed-harness-factory.tsexposeshandle.detach()/isDetached()meaning "release the harness handle at a turn-complete or durable-wait checkpoint so a successor continues the wait", with its own refusal ("cannot detach before a turn-complete or durable-wait checkpoint"). E2's child→owner detach is a different operation on a different object; naming it distinctly avoids one subsystem carrying twodetachverbs.childCancelBodyalready exists.MANAGED_SESSION_ENABLED_CHILD_RUN_KINDSbeside the domain list rather than enablingchild_run, which would have woken H3's still-gated shell producers. If the four team domains enable at different times (plausiblyteam_statebeforeteam_message), E1 should say whether it flips domains individually or needs a similar per-capability gate. The team domains are not inMANAGED_SESSION_ENVELOPE_DOMAINS, so no envelope-to-body move is required.Verdict
Accept for exploration, design-doc-first. The slice is correctly identified, correctly scoped and its premises all verify at head. It is not
status/ready-for-agent: decisions 1–3 above are architectural calls that an autonomous agent would otherwise make silently, and decision 3 in particular risks building a second, incompatible team model next to the one already shipping.--- Qwen Code
中文说明（分析部分）
已在
main=669b2f0f上重核 issue 的每条事实声明原 issue 在
55ee50d34e上核实，main 此后有推进，因此全部重核，结论无漂移。detach在managed-child-run-record.ts与managed-child-operations.ts中仍然零出现。后者的操作面是 launch / dispatch / attach / settle-completed / fail / stop-requested / cancel / delivery / acceptance / acceptance-consumed —— 没有 detach，也没有 team 记录体。确认是零实现，不是部分实现。V54__managed_child_lineage_relay.sql，OpenAPI 契约仍为 1.33.0，作者核实的基线标记在当前 head 依然成立。team_state、team_task、team_message、team_plan已注册在封闭的MANAGED_SESSION_DOMAINS索引中，且不在MANAGED_SESSION_ENABLED_DOMAINS内 —— E1 的验收条件准确描述了现状。方向：对齐
这是已接受的阶段化交付（#12380 → #12827 → 已合入的 #13505 六片图）中的计划内工作，能力缺口有证据而非理论推演，范围外清单也相当克制。接受进入探索。
实现前需要人来定的三个决策
1. E2 的所有者是一个未决的二选一，不只是缺代码。 child-agents 设计的未决问题 4 原文：「What durable owner a detached child takes (a tenant-level retention policy, or the root Session authority) is left to H4c; the close path only enforces that one exists.」由此有两点：文档把该问题交给 H4c，但 #13505 的交付图把 H4c 改成了
workflowkind —— 于是这个问题落到了 H4e，而设计文档从未相应更新。它也直接影响 E2 自己的验收：如果所有者是 root Session authority，已 detach 的 child 仍会随 root Session 关闭而死，一般情况下并不满足「outlives the parent's Session」。两个候选里看起来只有 tenant 级保留策略能满足 E2 的写法 —— 这一点应当明说，而不是留给实现者。2. 已合入的 H4b 设计把「teammate routing」划给了 H4e，而本 issue 完全没提。 H4b 决策 11：managed Agent 工具只接受
description、prompt、run_in_background，故意不要name，理由是「v1 has noname: teammate routing is H4e's, and an inert name would be a dead switch」。E1–E3 都停留在记录与运行时层面，于是这项继承正落在两份文档之间的缝里。H4e 要么把 managed 的name参数作为一条明确的验收接下来，要么给出理由再次推迟 —— 静默丢掉会让 H4b 写下的理由落空。3. 进程内已经有一整套 Agent Team 实现，且四个已注册 domain 名与它一一对应。
packages/core/src/agents/team/下有TeamManager、mailbox、board-tasks、tasks、asks、identity、team-events、leaderPermissionBridge；旁边还有team-create/team-delete/team-plan-approval/task-create|list|update|stop/send-message/list-agents工具、team-memory-*模块与内置coordinateskill。对应关系很直接：team_state↔ team 生命周期，team_task↔ board/task 工具，team_message↔mailbox/send-message，team_plan↔team-plan-approval。而且team_plan已经是MANAGED_SESSION_ACTION_SOURCES的一个取值，所以部分耦合已成事实。E1 必须说明：Managed 的 team domain 是这套既有模型的持久化投影（同一套词汇、同一套生命周期），还是一套独立的并行模型。设计里的「Legacy subagent changes」非目标是一个分离先例，但它针对的是 Agent 工具，不是 team 面。这个既有mailbox同时也是 issue 已经（正确地）点出的与 H4d 消息重叠的第三方。同一轮设计里需要定下来的三件小事
detach在这个运行时里已被占用。managed-harness-factory.ts暴露的handle.detach()/isDetached()含义是「在 turn-complete 或 durable-wait 检查点释放 harness handle，由后继 handle 继续等待」，并有自己的拒绝（「cannot detach before a turn-complete or durable-wait checkpoint」）。E2 的 child→owner detach 是另一个对象上的另一种操作；换个名字可以避免同一子系统里出现两个detach动词。childCancelBody已经存在。MANAGED_SESSION_ENABLED_CHILD_RUN_KINDS，而没有启用child_run（启用会连带唤醒 H3 仍在闸门后的 shell 生产者）。如果四个 team domain 需要分批启用（很可能team_state先于team_message），E1 应说明是逐个 domain 放行，还是需要类似的按能力闸门。team domain 不在MANAGED_SESSION_ENVELOPE_DOMAINS内，因此不需要 envelope→body 的迁移。结论
接受进入探索，先出设计文档。 切片识别准确、范围划定得当，所有前提在当前 head 均可核实。但它不属于
status/ready-for-agent：上面决策 1–3 是架构判断，否则会被自主 agent 静默地替人做掉；其中决策 3 尤其有风险 —— 可能在已经上线的 team 模型旁边再造一套互不兼容的模型。--- Qwen Code
feat(managed-agent): H4d-a session message record contract and child …
feat(managed-agent): H4e-a team record contract (QwenLM#13811)
docs(managed-agent): H4e-b1 lead-side team runtime design (QwenLM#13817)
feat(managed-agent): H4e-b1 lead-side team runtime
feat(managed-agent): H4e-b1 lead-side team runtime (QwenLM#13824)
fix(managed-agent): answer journal-only calls on every interrupted-tu…
docs(managed-agent): H4e-b2 team mailbox design
docs(managed-agent): H4e-b2 team mailbox design (QwenLM#13879)
feat(managed-agent): Stop Hosted team members with request_shutdown (…