Skip to content

Main Bot can create and change Bots but has no tool to remove or retire one #638

Closed
#1674
Closed
Main Bot can create and change Bots but has no tool to remove or retire one#638
#1674
Assignees
Birfy
Labels
area:automationScheduled tasks and automationenhancementNew feature or request

Description

@hsliuustc0106
hsliuustc0106
opened on Oct 21, 2026

Summary

The Main Bot is documented as the highest-rights Bot that "creates, changes and removes other Bots", but the tool surface it actually gets has no way to remove one. Deletion exists only in the UI channel, so a Main Bot can build a team but never retire a member or reorganise it. This issue is to decide whether that is intentional and, if so, what the supported path should be.

What happens today

  • core/src/host/tools.js registers create_bot, update_bot and stop_bot for the model. There is no delete_bot (and no archive/hide).
  • core/src/host/channel.js has a delete-bot endpoint used by the UI, calling rt.deleteBot, so the core can delete a Bot — it is just not exposed to Bots.
  • stop_bot is the only intervention a Main Bot has: it ends a running turn, it does not remove the Bot. update_bot can rename or repurpose it, so a "retired" specialist keeps sitting in the sidebar, counting against the tree's maxChildren (8) and against the sidebar itself.
  • The tree plugin (tree: cannot move a bot to a new parent; bots skipped by maxChildren never rejoin #635) has the same shape for parent edges: the parent is fixed at creation, and there is no reparent tool. Deleting a tree Bot does re-attach its children upwards; the deletion needed for that work is again UI-only.

We hit both limits on a real team: Chief reached maxChildren, new Bots stayed outside the tree, and there was no way to free a slot or move an existing Bot under a coordinator without deleting from the sidebar and recreating (losing the conversation).

Why this needs a decision

Deletion is destructive and irreversible: the Bot's conversations and memory go with it, and an autonomous model can decide to do that on its own. Keeping it human-only is defensible. What is not defensible is the mismatch: the prompt and the README tell the Main Bot it can remove Bots, and the model has no such tool, so it reasons about capabilities it does not have.

Options

A. Keep deletion human-only, and say so. Document that only the owner deletes Bots; make the Main Bot's prompt/README say it creates, changes and stops, never removes. Lowest risk, but a Main Bot still cannot reorganise a full team.

B. Add delete_bot with guards. Main Bot only; require an explicit confirmation (e.g. an ask_user card naming the Bot and what is lost) or a dry-run that reports the number of conversations/memory entries; refuse for Main Bots and for the caller. This keeps the structural ability but makes an irreversible action deliberate.

C. Add a reversible archive instead of deletion. The tree plugin already has fields['flybot-tree'].retired (adoption skips it, and the sidebar lists it outside the tree) but no tool sets it. A retire_bot/unretire_bot pair would free tree slots and hide a Bot from coordination while keeping its history, leaving real deletion to the owner.

My preference is C plus A: reversible for the team, irreversible for the human. B is acceptable if C is too much, but B alone still makes an autonomous agent able to destroy history.

Related

Acceptance (for whichever option is chosen)

  • The Main Bot's prompt and README match the tool surface.
  • If a tool is added: Main-Bot-only, refuses self/target errors cleanly, and an irreversible path requires an explicit confirmation that names what is lost.
  • If only documentation changes: no code change, and the prompt no longer claims a removal right.

Activity

  1. hsliuustc0106
    added
    enhancementNew feature or request
    questionFurther information is requested
    on Oct 21, 2026

  2. hsliuustc0106 commented on Oct 21, 2026

    @hsliuustc0106
    hsliuustc0106
    on Oct 21, 2026
    ContributorAuthor

    Related point raised by the user: deleting a Bot does not delete its memory today.

    • deleteBot (core/src/host/roster.js:490) calls rt.archiveBotMemory(id) before removing the Bot.
    • archiveBotMemory (core/src/host/memory.js:628) moves the Bot's own memory directory to memory/archive/<botId>-<timestamp> and journals an archive op. The team memory is not touched.
    • So after deletion the conversations are archived as Sessions and the memory survives in the archive; there is no tool or UI path to purge either.

    Questions for the same decision:

    1. Should deletion offer a permanent purge (memory + archive) with the explicit confirmation, or stay archive-only?
    2. If we add retire_bot, archived memory fits naturally: retire keeps everything, purge is the human-only irreversible action.
    3. At minimum the delete confirmation should say "archived, not deleted" so the owner knows what remains.

    Also: deleting a Bot leaves its team-memory entries in place; decide whether a purge should scan and remove entries authored by that Bot.

  3. Birfy
    added
    area:automationScheduled tasks and automation
    needs-humanThe agent loop stopped; a person must decide (reason in the last comment)
    and removed
    questionFurther information is requested
    on Oct 21, 2026

  4. Birfy commented on Oct 23, 2026

    @Birfy
    Birfy
    on Oct 23, 2026
    Collaborator

    Triaged on be48393b. The mismatch is real — core/src/host/tools.js registers create_bot, update_bot and stop_bot for the model, and nothing removes or retires a Bot, while the prompt and the README say the Main Bot removes other Bots — but which way to close it is the owner's call, so this needs a decision before anyone writes code.

    Two ways out, with different risk:

    • A. Retire, not delete. A new Main-Bot tool that archives a Bot: it leaves the sidebar and stops counting against the tree's maxChildren (8), its conversations are kept, and the owner can restore it. Deletion stays UI-only. This closes the practical pain in the issue (Chief hit maxChildren and could not free a slot) without giving a model an irreversible destructive action.
    • B. Keep the surface as it is. Then the prompt and the README must stop claiming the Main Bot removes Bots; that half is a small docs-only change I can scope as agent-ready on your word.

    Deletion itself should stay human-only either way: it takes the Bot's conversations and memory with it, and stop_bot already exists as the non-destructive intervention.

    Say A or B (or "both": A now, B as the doc half) and I will turn the chosen slice into acceptance criteria and flip this to agent-ready.

  5. Birfy
    added
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 29, 2026

  6. Birfy commented on Oct 29, 2026

    @Birfy
    Birfy
    on Oct 29, 2026
    Collaborator

    Written-by: Triage

    Owner 决定：只加 archive（退役），删除仍只归人（用户 2026-10-29 拍板「全按建议走」）。

    范围：给 Main Bot 增加一个 archive 工具（core/src/host/tools.js 的注册表 + 相应 roster/store 支持），把 Bot 标记为退役：让出树的 maxChildren 名额、不再出现在默认活跃名单，历史与会话仍可读可查；不新增任何 delete_bot 给模型。

    不做：删除、不做 reparent。

    验收：单测断言 archive 后树 maxChildren 计数释放、活跃名单不再列它、历史仍可读；非 Main Bot 调用被拒；撤掉改动后变红。

  7. Birfy
    removed
    needs-humanThe agent loop stopped; a person must decide (reason in the last comment)
    on Oct 29, 2026

  8. Birfy commented on Oct 29, 2026

    @Birfy
    Birfy
    on Oct 29, 2026
    Collaborator

    Written-by: Triage

    Scope confirmed from the 2026-10-29 owner decision above — no code re-research needed. Kept agent-ready; dropped the stale conflicting state label so exactly one state label remains.

    Brief: Main-Bot-only archive tool in core/src/host/tools.js + roster/store support; acceptance = tree maxChildren slot freed, default active list omits the Bot, history/sessions still readable, non-Main caller refused, test red without the change.

  9. Birfy
    added a commit that references this issue on Oct 29, 2026

    Add a Main-Bot-only archive_bot tool that retires a Bot (#638)

    275b7b1
  10. Birfy
    self-assigned this
    on Oct 29, 2026
  11. Birfy
    added
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 29, 2026

  12. Birfy commented on Oct 29, 2026

    @Birfy
    Birfy
    on Oct 29, 2026
    Collaborator

    Written-by: Dev

    Claimed #638 — first step: the Main-Bot-only archive_bot tool and the retired field write. Branch dev/638-archive-bot.

  13. Birfy
    removed
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 29, 2026
  14. Birfy
    added 3 commits that reference this issue on Oct 29, 2026

    Add a Main-Bot-only archive_bot tool that retires a Bot (#638)

    504cf3a

    Add a Main-Bot-only archive_bot tool that retires a Bot (#638)

    7be7ce3

    Add a Main-Bot-only archive_bot tool that retires a Bot (#638)

    e212a01
  15. Birfy
    closed this as completedin #1674on Oct 29, 2026
  16. github-actions
    removed
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:automationScheduled tasks and automationenhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions