Skip to content

Tree: per-child Bot harness and model (mix backends for different tasks) #365

Closed as duplicate
Closed as duplicate
Tree: per-child Bot harness and model (mix backends for different tasks)#365
Labels
area:automationScheduled tasks and automationenhancementNew feature or request

Description

@hsliuustc0106
hsliuustc0106
opened on Oct 18, 2026

Why

In a tree (Chief → children), different child Bots often do different jobs (research, coding, planning, short replies). Different harness backends plus different models can change quality a lot on those jobs. Today it is unclear whether each Bot in a tree can pin its own harness + model, or whether the whole tree shares one runtime. We want an explicit design: per-Bot harness and model, with safe defaults.

Related: tree plugin, #198 (cross-runtime agents), #361 (capability gaps), live-e2e / DSH pinning in CI.

Goal

A parent Bot can assemble a tree where each child declares:

  • harness (e.g. DSH version / alternate runtime that speaks the FlyBot Bot contract),
  • model (provider + id),
  • optional tool / plugin allow-list,
    so the Chief routes work to the child that is best for that task.

Proposed behavior

  1. Per-Bot config: each Bot node has harness + model (and display of both in UI / Timeline).
  2. Defaults: new children inherit the parent's pair unless overridden; changing a parent does not silently rewrite existing children.
  3. Capability matrix: a small table of which harness × model is known-good for which task class (fast chat, long tool use, code, vision, …) — living doc, not marketing.
  4. Failure isolation: one child's harness crash or rate-limit does not take down siblings or the Chief; errors surface on that lane in Timeline and as a Needs-you style signal when human input is required.
  5. Interop: if a harness is an external runtime ([RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198), it still appears as a Bot in the tree with the same approval and grant rules ([Team] Gate cross-owner agent routes by per-Bot grants (default deny; superseded the publication gate) #51).

Personal vs team

Acceptance (design + first cut)

Open questions

  1. Is "harness" only DSH version pins, or any runtime that implements the Bot / adapter contract?
  2. Who is allowed to change a child's harness in team mode — owner only, or assigner?
  3. How do we version and ship multi-harness images under Deployment step 1: official image and one isolated instance per person #352 (one container with many runtimes vs sidecar per harness)?
  4. How do cost and rate limits aggregate at tree vs Bot level ([Team] Bound agent loops and resource consumption #56)?

Process

RFC here; implementation via OpenCode + Codex review.

Activity

  1. hsliuustc0106 commented on Oct 18, 2026

    @hsliuustc0106
    hsliuustc0106
    on Oct 18, 2026
    ContributorAuthor

    Learn from yetone/magpie (精髓, not a copy)

    Magpie's core idea matches this issue: any agent (harness) × any provider/model, from one place.

    Useful patterns to steal for FlyBot trees:

    1. Harness ≠ provider
      Magpie treats Claude Code / Codex / OpenCode / DSH / … as agents, and DeepSeek / Kimi / GLM / ChatGPT plan / … as providers. The matrix is agent × provider/model. FlyBot should keep the same split on each tree node: harness + provider/model, not a single "backend" field.

    2. One local gateway
      Magpie runs 127.0.0.1:3425 and speaks OpenAI / Anthropic / Gemini, translating streaming, tools and reasoning. Child Bots with different harnesses can still share one credential and routing layer if FlyBot (or an optional Magpie/gateway sidecar under Deployment step 1: official image and one isolated instance per person #352) sits in front of providers.

    3. Routing groups + failover
      When a quota dies, Magpie moves to the next account/model without the agent seeing the error. Trees should allow a child to bind a group (ordered provider/models) not only a single model — ties to [Team] Bound agent loops and resource consumption #56 caps and to not blocking the Chief on one 429.

    4. Profiles
      Save a whole tree's harness×model map as a named profile ("Budget", "Code-heavy") and switch in one move — useful for personal and for team assigners.

    5. Atomic config edits
      Magpie rewrites only the one key that matters in each agent's own config and keeps formatting. Whatever we generate for DSH / external runtimes ([RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198) should be the same: no destructive full-file overwrites.

    6. What not to copy blindly
      Magpie is a menu-bar gateway for many CLI agents. FlyBot's difference stays multi-Bot tree + Social approvals + Timeline. We learn the provider/harness split and gateway, not the whole product shell. FlyBot docs already call out Magpie-style process habits without copying product docs (docs/code-standards.md).

    Proposed field shape (update to issue body when agreed)

    Bot node:
  harness:  dsh@x | opencode | …   # how it runs
  model:    provider/model | group/<name>  # what it thinks with
  tools:    allow-list (optional)

    Open questions added

    1. Do we embed a Magpie-compatible gateway, shell out to an installed Magpie, or reimplement a thin FlyBot-native gateway?
    2. Are subscription-style providers (Claude/ChatGPT plans) in scope for v1, or API keys only?
    3. Should Timeline show harness and provider/model as separate labels on every turn?

    Refs: https://github.com/yetone/magpie — also community bitxeno/dsh-magpie-connect for DSH↔Magpie.

  2. hsliuustc0106 commented on Oct 18, 2026

    @hsliuustc0106
    hsliuustc0106
    on Oct 18, 2026
    ContributorAuthor

    Broader RFC spun out: see the new parent discussion issue linked in the next comment / search title RFC: harness × provider.

  3. hsliuustc0106 commented on Oct 18, 2026

    @hsliuustc0106
    hsliuustc0106
    on Oct 18, 2026
    ContributorAuthor

    Broader RFC: #366 (harness × provider, Magpie-inspired). This issue (#365) stays the tree per-child follow-through.

  4. Birfy
    added
    enhancementNew feature or request
    area:automationScheduled tasks and automation
    needs-humanThe agent loop stopped; a person must decide (reason in the last comment)
    on Oct 19, 2026

  5. Birfy commented on Oct 19, 2026

    @Birfy
    Birfy
    on Oct 19, 2026
    Collaborator

    Triage on main 7b9e90b, 2026-10-19 ~12:10 Asia/Shanghai: needs-human, not agent-ready. Waits on the harness × provider RFC (#366). Question for the owner: per-child model only (DSH routes, works today) as a first step, or wait for per-child harness?

  6. Birfy commented on Oct 20, 2026

    @Birfy
    Birfy
    on Oct 20, 2026
    Collaborator

    Closing (maintenance triage, 2026-10-20 08:59 Asia/Shanghai). Per-child models are already on main bae4128. Each Bot has its own model (core/src/host/models.js). create_bot starts a child on its parent's model unless one is named, and changing the parent does not rewrite existing children. update_bot / list_models change a child's model, and list_bots shows it (core/src/host/tools.js). So two children in one tree can already run on different models.

    The remaining parts (per-child harness, routing groups / failover, profiles, showing the model on each Timeline turn) are the same design as #366 and are tracked there. External runtimes are tracked in #198.

  7. Birfy
    closed this as not plannedon Oct 20, 2026
  8. Birfy
    reopened this on Oct 20, 2026
  9. Birfy
    closed this as a duplicateof RFC: harness × provider (Magpie-inspired gateway, routing groups, profiles) #366 on Oct 20, 2026
  10. Birfy
    removed
    needs-humanThe agent loop stopped; a person must decide (reason in the last comment)
    on Oct 21, 2026
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

    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